To Trigger an individuel Interrupt with the two Buttons

Your question has been asked - and answered - many times w/in this forum.   Building your investigative skills will greatly aid your efforts - here & in other areas.  (i.e. Forum Search Box should produce multiple, past postings - well covering your request.)

W/in your interrupt handler it is possible to "read" the condition of those two switches - don't you agree?   And - via that method - you may determine which switch is "active" - and then "branch" to your desired program code and/or operation.

Your use of GPIOIntRegister() may add unwanted/unneeded complexity - placing the interrupt handler's name w/in your start-up file (code) & the handler's code w/in MCU Flash proves less error prone & easier.

Beware that simple switches - as on your board - always "bounce" (i.e. the switch contacts "chatter" - thus produce several, rapid voltage transitions upon the MCU's input) which may cause unreliable operation.   The cure for this may be software or hardware - you must allow sufficient time for the switches to become stable - and read each of them after the bouncing has ended...

Ohh i didn't found a question like this

Kindly read on/again - net is in/out as I'm airborne - I've added detail.
Where did you look - what were your search "keywords?"

Investigation is your most valued "friend" - your learning will be immensely aided by adding that skill...

Ok but i only want to differntiate which button is pressed to increase/degrade a counter

That's been answered - you "read" the appropriate GPIO Port w/in your (flash-based) interrupt handler (after) "de-bouncing" those switches. What's not understood?

and is there a function for de-bouncing??

Nope.

btw in my opinion GPIOIntRegister doesn't really add to complexity.

You can see here the simplest debounce technique which is very bad for interrupts - but maybe for your needs it will work. It's a delay after reading the button, it's like the crudest way to go about it. There's plenty of problems with it
sites.google.com/.../simple-digital-input


The best way that I know of (and I do know little on the subject) is to disable readings for a period of time after getting a pressed button.
Imagine for your situation. You get the interrupt from the button being pressed - you disable the interrupt, do what you need in your interrupt and then set a timer in countdown which after ending will generate a interrupt by itself, which will enable the button interrupt again.

Now about your statement. "With the Fuction GPIOIntRegister its only possbile to trigger the same Interrupt. ". It's not quite correct. Let's see what really is happening.
Your GPIO peripherals have 8 pins, from 0 to 7. The GPIO can generate a interrupt -> this means only 1 ISR (interrupt handler). But! Your GPIO can be configured to generate that interrupt by multiple events. And those events can be a falling edge on a pin for example. Or it can be a rising edge on another one.

Take your launchpad. Buttons are on PJ1 and PJ0. You configure PJ0 to interrupt on a falling edge and the same on PJ1. These belong both to GPIO J - meaning no mater which one you trigger, it will go to the same handler! But this won't prevent you from doing what you want.
You can check which one triggered the interrupt! So in your interrupt handler you need to check if it was PJ0 or it was PJ1 that was pressed.
You can see in this example, that although only 1 pin is used, it checks to see which one triggered the interrupt for demonstration sake.
sites.google.com/.../digital-input-with-interrupt

Try to get the 2 button system working in the interrupt like that code above. It uses the delay for debouncing for simplicity sake (not good to 99% of applications)
Only then worry to add good debouncing code, go step by step, little steps.

To add, as cb1 said, investigation is key. There are plenty of examples on the web, in the Tivaware package and on the forum. It's ok to get some guidance by asking, but you should try to search first. There won't be always someone to teach you what to do and to direct you to the info

I can tell you most of my colleagues that have problems with MCUs are the ones that never try searching or ignore it as a skill to develop.

user4558488 said:

is there a function for de-bouncing??

While it may not be marked as such - indeed the switches upon the various LPads & Eval boards are de-bounced.   You may review the source code which is supplied with the "standard" program which is provided w/each board.

That switch contact bounce will vary with the switch - usually a delay between 5 - 10 mS will insure that the switch has "stabilized."   That delay can be placed w/in the interrupt (which usually is undesired) or can be placed w/in a regularly executed program loop - placed w/in main.  If the de-bounce delay is placed w/in "main" you simply set a flag w/in your interrupt handler - then exit.   Main then "looks for that flag" and inserts delay and (then) reads each switch - if that flag was set.  (remember to clear that flag upon exit from that, "delay & switch read loop.") 

Note that should your "de-bounce delay" be too short - you may enter your, "Switch interrupt handler" multiple times.  

Time now for you to answer questions.   Would that "multiple entry" w/in the interrupt handler be bad?   How?   Could it be good?   How?   And how would you "tweak" your "de-bounce delay" to an optimal value?

I agree that this "bounce" issue diverts you from your desired, "Simple switch handling" - yet if I left you w/out this warning - your results would prove erratic - thus unsatisfying.

You can eliminate the "bounce" by having the switch trigger a solid, "one-shot" output.   In days/years/decades past we did this via a "555 Timer IC" which would accept a bouncing input - cleanse it - and produce a clean, single, bounce-free output pulse.   You'd have to hack your board to achieve this - yet your use of a separate, momentary switch - which then feeds the 555 - and then the 555's output is routed to the MCU - solves (via avoiding) the bounce issue.