Re: [buildrobot] microblaze-elf / microblaze-linux

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joel Sherrill]

Was microblaze-rtems attempted? I would have expected a failure like these if so.

--joel

Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:


Hi!

Build logs at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718

(I also think that we'd have the little endian version on the target
list at contrib/config-list.mk ...)


g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c
../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’:
../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     *recog_data.dup_loc[i] = orig_dup[i];
                                         ^
cc1plus: all warnings being treated as errors
make[2]: *** [reload1.o] Error 1

MfG, JBG

--
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                          Zensur im Internet? Nein danke!
  the second  :

Re: [buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]

On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill <Joel.Sherrill@OARcorp.com> wrote:
> Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> > Build logs at
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718
> > 
> > (I also think that we'd have the little endian version on the
> > target list at contrib/config-list.mk ...)
> > 
> > 
> > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c
> > ../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’:
> > ../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >      *recog_data.dup_loc[i] = orig_dup[i];
> >                                          ^
> > cc1plus: all warnings being treated as errors
> > make[2]: *** [reload1.o] Error 1
> > 
> Was microblaze-rtems attempted? I would have expected a failure like
> these if so.

No, it wasn't.  It's not on the list of targets in
.../gcc/contrib/config-list.mk .  So we'd probably add that to the
target list I guess?  I'll propose a patch later tonight (adding to
another pending patch to config-list.mk)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                   ...und wenn Du denkst, es geht nicht mehr,
the second  :                          kommt irgendwo ein Lichtlein her.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joern Rennecke]

On 26 November 2013 14:51, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill <Joel.Sherrill@OARcorp.com> wrote:

>> Was microblaze-rtems attempted? I would have expected a failure like
>> these if so.
>
> No, it wasn't.  It's not on the list of targets in
> .../gcc/contrib/config-list.mk .  So we'd probably add that to the
> target list I guess?  I'll propose a patch later tonight (adding to
> another pending patch to config-list.mk)

The idea if config-list.mk is not to build every conceivable target
configuration,
but to give a reasonable converage of the different target architectures and
OS/library configurations so that you can effectively  test a patch with unknown
target-specific impact.

Is there something that microblaze-rtems exposes that is not already
covered by other microblaze or rtems targets that are already included?

Re: [buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

On Tue, 2013-11-26 15:21:12 +0000, Joern Rennecke <joern.rennecke@embecosm.com> wrote:
> On 26 November 2013 14:51, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> > On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill <Joel.Sherrill@OARcorp.com> wrote:
> > > Was microblaze-rtems attempted? I would have expected a failure
> > > like these if so.
> >
> > No, it wasn't.  It's not on the list of targets in
> > .../gcc/contrib/config-list.mk .  So we'd probably add that to the
> > target list I guess?  I'll propose a patch later tonight (adding
> > to another pending patch to config-list.mk)
> 
> The idea if config-list.mk is not to build every conceivable target
> configuration, but to give a reasonable converage of the different
> target architectures and OS/library configurations so that you can
> effectively  test a patch with unknown target-specific impact.

Is it like that?  My impression is/was that people collected a list of
targets they somewhat care for. With around 200 configurations, among
them some that are quite similar, adding another just adds 1/2%, which
I'd call neglectible.

> Is there something that microblaze-rtems exposes that is not already
> covered by other microblaze or rtems targets that are already included?

Probably not (without having looked at what that configuration would
actually pull in.)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [buildrobot] microblaze-elf / microblaze-linux

[Michael Eager]

On 11/26/13 07:27, Jan-Benedict Glaw wrote:

>> Is there something that microblaze-rtems exposes that is not already
>> covered by other microblaze or rtems targets that are already included?
>
> Probably not (without having looked at what that configuration would
> actually pull in.)

I believe that microblaze-rtems is almost identical to microblaze-elf.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joseph S. Myers]

On Tue, 26 Nov 2013, Jan-Benedict Glaw wrote:

> > The idea if config-list.mk is not to build every conceivable target
> > configuration, but to give a reasonable converage of the different
> > target architectures and OS/library configurations so that you can
> > effectively  test a patch with unknown target-specific impact.
> 
> Is it like that?  My impression is/was that people collected a list of
> targets they somewhat care for. With around 200 configurations, among
> them some that are quite similar, adding another just adds 1/2%, which
> I'd call neglectible.

For example, the list should include at least one target for every target 
header in GCC.  So if there's a header specific to an (architecture, OS) 
pair, a matching configuration should be included.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joel Sherrill]

On 11/26/2013 10:52 AM, Joseph S. Myers wrote:
> On Tue, 26 Nov 2013, Jan-Benedict Glaw wrote:
> 
>>> The idea if config-list.mk is not to build every conceivable target
>>> configuration, but to give a reasonable converage of the different
>>> target architectures and OS/library configurations so that you can
>>> effectively  test a patch with unknown target-specific impact.
>>
>> Is it like that?  My impression is/was that people collected a list of
>> targets they somewhat care for. With around 200 configurations, among
>> them some that are quite similar, adding another just adds 1/2%, which
>> I'd call neglectible.
> 
> For example, the list should include at least one target for every target 
> header in GCC.  So if there's a header specific to an (architecture, OS) 
> pair, a matching configuration should be included.
> 

It is true that the RTEMS configurations are generally similar to
the *-elf ones. However, we turn on pthreads support in C++ and
multitasking in the languages which have it including Ada. We
have good test results even in FORTRAN. With tasking and
filesystem support on near bare metal,  *-rtems can potentially
be used to test a lot more than *-elf.

For the basic code generation, there likely isn't much
difference. I often can reproduce our code generation
problems using *-elf. But we have different code and
more code.

The key to seeing the value of testing *-rtems is moving
beyond "builds or not" and into running tests on more
languages.

as to Joern's question:
> Is there something that microblaze-rtems exposes that is not already
> covered by other microblaze or rtems targets that are already included?

I believe it was on the microblaze where someone broke the
libgcc pattern for rtems by changing the pattern from
XXX*-*-* to XXX*-*-elf.

Plus we do have at least one OS/Target specific file for
each *-rtems configuration. There is at least a
config/*/*rtems*.h and often a config/*/t-* which is specific
to RTEMS. Plus config/*rtems* is used in all *-rtems targets.


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: [buildrobot] microblaze-elf / microblaze-linux

[Ralf Corsepius]

On 11/26/2013 06:38 PM, Joel Sherrill wrote:

>> Is there something that microblaze-rtems exposes that is not already
>> covered by other microblaze or rtems targets that are already included?
>
> I believe it was on the microblaze where someone broke the
> libgcc pattern for rtems by changing the pattern from
> XXX*-*-* to XXX*-*-elf.
Correct. microblaze-rtems* is incomplete in libgcc.

I have a patch pending for gcc-4.8.x, but haven't yet tried with
gcc-4.9.x.

Ralf

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joel Sherrill]

On 11/26/2013 11:58 AM, Ralf Corsepius wrote:
> On 11/26/2013 06:38 PM, Joel Sherrill wrote:
> 
>>> Is there something that microblaze-rtems exposes that is not already
>>> covered by other microblaze or rtems targets that are already included?
>>
>> I believe it was on the microblaze where someone broke the
>> libgcc pattern for rtems by changing the pattern from
>> XXX*-*-* to XXX*-*-elf.
> Correct. microblaze-rtems* is incomplete in libgcc.
> 
> I have a patch pending for gcc-4.8.x, but haven't yet tried with
> gcc-4.9.x.

It should be the same patch. I wrote one too and obviously
forgot to upstream it.

For those who care, this is the seemingly benign patch
which broke it.

http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=98f2ac05e3adaf283a55531a3e274e20aad6048d

The lesson is that every target has to take a
path through those large switches. And things can
and do break.

> Ralf
> 
> 



-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: [buildrobot] microblaze-elf / microblaze-linux

[Joern Rennecke]

On 26 November 2013 17:38, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:

> The key to seeing the value of testing *-rtems is moving
> beyond "builds or not" and into running tests on more
> languages.

Well, we are already configuring with --enable-languages=all,ada,go ,
so there are a lot of frontends being build - just not the libraries.
>
> as to Joern's question:
>> Is there something that microblaze-rtems exposes that is not already
>> covered by other microblaze or rtems targets that are already included?
>
> I believe it was on the microblaze where someone broke the
> libgcc pattern for rtems by changing the pattern from
> XXX*-*-* to XXX*-*-elf.

In order to catch such a problem, we'd have to at least build libgcc.
Which requires to have an assembler for the respective target first.

How should this be handled?  Test if an cross-asembler for target
has been installedon the host?
Or having a separate list of targets that are supported by FSF GAS, and
a curent gas checkout, and then building gas for those targets?

Re: [buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

On Tue, 2013-11-26 19:50:10 +0000, Joern Rennecke <joern.rennecke@embecosm.com> wrote:
> On 26 November 2013 17:38, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> > as to Joern's question:
> > > Is there something that microblaze-rtems exposes that is not
> > > already covered by other microblaze or rtems targets that are
> > > already included?
> >
> > I believe it was on the microblaze where someone broke the libgcc
> > pattern for rtems by changing the pattern from XXX*-*-* to
> > XXX*-*-elf.
> 
> In order to catch such a problem, we'd have to at least build
> libgcc.  Which requires to have an assembler for the respective
> target first.
> 
> How should this be handled?  Test if an cross-asembler for target
> has been installedon the host?  Or having a separate list of targets
> that are supported by FSF GAS, and a curent gas checkout, and then
> building gas for those targets?

I think it'd possible to eg. first create a linked tree and then build
all-gas all-ld install-gas install-ld all-gcc .  I think that most
targets should be gas-/ld-supported. At least, we'd give that a try
and see where it takes us.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[buildrobot] First results of running contrib/config-list.mk

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

Hi!

The two build robot instances that schedule jobs using
contrib/config-list.mk are done with two rounds. I haven't looked at
the details (and thus there are no patches), but I'd like to point out
the results.

Depending on the host, gcc/g++ is:

	gcc20: g++ (GCC) 4.9.0 20131122 (experimental)
	gcc76: g++ (GCC) 4.9.0 20131121 (experimental)

Binutils were not freshly build, so they're older.

I tried to find the respective maintainers and Cc'ed them, but that
wasn't obvious in some cases.  But I hope we'll see some fixes soon.
At least a good number of the -Werror build breakages look quite
simple to fix.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of: "Debugging is twice as hard as writing the code in the first place.
the second  :  Therefore, if you write the code as cleverly as possible, you are,
               by definition, not smart enough to debug it." - Brian W. Kernighan

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

Hi!

Build logs at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718

(I also think that we'd have the little endian version on the target
list at contrib/config-list.mk ...)


g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c
../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’:
../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     *recog_data.dup_loc[i] = orig_dup[i];
                                         ^
cc1plus: all warnings being treated as errors
make[2]: *** [reload1.o] Error 1

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                          Zensur im Internet? Nein danke!
  the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [buildrobot] microblaze-elf / microblaze-linux

[Michael Eager]

On 11/25/13 19:26, Jan-Benedict Glaw wrote:
> Hi!
>
> Build logs at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718
>
> (I also think that we'd have the little endian version on the target
> list at contrib/config-list.mk ...)
>
>
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. -I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc/gcc/../libbacktrace    -o reload1.o -MT reload1.o -MMD -MP -MF ./.deps/reload1.TPo ../../../gcc/gcc/reload1.c
> ../../../gcc/gcc/reload1.c: In function ‘void elimination_costs_in_insn(rtx)’:
> ../../../gcc/gcc/reload1.c:3750:41: error: ‘orig_dup[0]’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>       *recog_data.dup_loc[i] = orig_dup[i];
>                                           ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [reload1.o] Error 1

I do not see this error in my build of microblaze-elf.

I notice that there are flags in your compile that do not appear in mine:
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror

I don't see any warnings in my build, either.

My build is using gcc-4.1.2 (on CentOS 5.9) as a build compiler.  My
guess is that this is the cause of the differences.

I'll upgrade to building with a more recent version of gcc and investigate
this failure, but I won't be able to look at this for about two weeks.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

On Tue, 2013-11-26 07:50:34 -0800, Michael Eager <eager@eagercon.com> wrote:
> On 11/25/13 19:26, Jan-Benedict Glaw wrote:
> > Build logs at
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718
> >
> > (I also think that we'd have the little endian version on the target
> > list at contrib/config-list.mk ...)
[...]

> I do not see this error in my build of microblaze-elf.
> 
> I notice that there are flags in your compile that do not appear in mine:
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror

See the introduction email: This is (as advised) with an up-to-date
GCC (just a few days old), using --enable-werror-always at configure
time (as done by .../contrib/config-list.mk).

  Thanks for looking into the issue anyways!  (...and what do you
think about adding a microblazeel target to the list?)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                http://catb.org/~esr/faqs/smart-questions.html
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [buildrobot] microblaze-elf / microblaze-linux

[Michael Eager]

On 11/26/13 08:08, Jan-Benedict Glaw wrote:
> On Tue, 2013-11-26 07:50:34 -0800, Michael Eager <eager@eagercon.com> wrote:
>> On 11/25/13 19:26, Jan-Benedict Glaw wrote:
>>> Build logs at
>>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
>>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718
>>>
>>> (I also think that we'd have the little endian version on the target
>>> list at contrib/config-list.mk ...)
> [...]
>
>> I do not see this error in my build of microblaze-elf.
>>
>> I notice that there are flags in your compile that do not appear in mine:
>> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
>
> See the introduction email: This is (as advised) with an up-to-date
> GCC (just a few days old), using --enable-werror-always at configure
> time (as done by .../contrib/config-list.mk).

Missed that email.

>    Thanks for looking into the issue anyways!  (...and what do you
> think about adding a microblazeel target to the list?)

Sounds OK to me.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [buildrobot] microblaze-elf / microblaze-linux

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Tue, 2013-11-26 08:13:12 -0800, Michael Eager <eager@eagercon.com> wrote:
> On 11/26/13 08:08, Jan-Benedict Glaw wrote:
> > Thanks for looking into the issue anyways!  (...and what do you
> > think about adding a microblazeel target to the list?)
> 
> Sounds OK to me.

Any suggestion of which target(s) to choose?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                        Lauf nicht vor Deinem Glück davon:
  the second  :                             Es könnte hinter Dir stehen!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [buildrobot] microblaze-elf / microblaze-linux

[Michael Eager]

On 11/26/13 08:16, Jan-Benedict Glaw wrote:
> On Tue, 2013-11-26 08:13:12 -0800, Michael Eager <eager@eagercon.com> wrote:
>> On 11/26/13 08:08, Jan-Benedict Glaw wrote:
>>> Thanks for looking into the issue anyways!  (...and what do you
>>> think about adding a microblazeel target to the list?)
>>
>> Sounds OK to me.
>
> Any suggestion of which target(s) to choose?

microblazeel-elf.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077