Re: New test is invalid for AVR

[Andreas Krebbel1]

Hi Eric,

it is important for the testcase that the array is that big. In order to
avoid breaking other targets with that I've moved the testcase to the s390
specific directory. I've already committed the patch. Sorry for the
breakage.

Mit  freundlichem Gruß / Kind regards,
Andreas Krebbel

***
IBM Deutschland Entwicklung GmbH
Linux on zSeries Development & Service, Dept. D1419
Schönaicherstr. 220, 71032 Böblingen
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Erich Baier
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Office: 06/122 --- Phone: +49-(0)7031-16-1089
External mail: [EMAIL PROTECTED]

"Weddington, Eric" <[EMAIL PROTECTED]> wrote on 08/06/2008 06:48:31
PM:

> "Weddington, Eric" <[EMAIL PROTECTED]>
> 08/06/2008 06:48 PM
>
> To
>
> 
>
> cc
>
> "Andy Hutchinson" <[EMAIL PROTECTED]>, "Anatoly Sokolov"
> <[EMAIL PROTECTED]>, Andreas Krebbel1/Germany/[EMAIL PROTECTED],
<[EMAIL PROTECTED]>
>
> Subject
>
> New test is invalid for AVR
>
> Hi All,
>
> The new test gcc.c-torture/compile/20080806-1.c, added by Andreas
> Krebbel on 2008-08-06, causes 8 new test failures for the AVR
> target. This test is invalid for the AVR because the local array is
> too large for the AVR (64+ K). IIRC, for testing purposes the AVR
> target only allows a 2K stack.
>
> Could someone please mark this test as unsupported for avr-*-*? I
> don't have copyright assignment yet (but we're currently working
> with the FSF on it).
>
> Thanks for your help.
>
> Eric Weddington
> Atmel

gcj

[LAMOME Julien CS-SI]

Hello.
I read this page : http://gcc.gnu.org/java/ and see no news until about one 
year. The most links (status, done) have the same old update.
Gcj project do it abandon or stop ? Or just stop web maintain ?
I'm interest by advance of integration of java 1.5 into gcj. When a new 
release ? etc.
Can you specify in http://gcc.gnu.org/java/ the status of project ? 
Thanks.

bootstrap broken?

[VandeVondele Joost]

dwarf2out.c:13496: internal compiler error: in extract_insn, at 
recog.c:1988


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37045

Re: GCC Tests For ARM/Neon

[Paul Brook]

>  arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> test_neon.c
>
> #if !defined(__ARM_NEON__)
> #error "Neon not supported"
> #endif
>
> void neon_code(void)
> {
>   asm volatile ("vldr d18,[fp,#-32]");
> }

Works fine here. Either your assembler is busted, or there is something else 
you're not telling us about.

Paul

Re: GCC Tests For ARM/Neon

[Paul Brook]

On Wednesday 06 August 2008, Joseph S. Myers wrote:
> On Wed, 6 Aug 2008, Joel Sherrill wrote:
> > $ arm-rtems4.9-gcc  -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
> > test_neon.c /tmp/ccBzigjD.s: Assembler messages:
> > /tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr
> > d18,[fp,#-32]'
> >
> >
> > So with that combination of options gcc defines __ARM_NEON__.
> > And gas ends up knowing the instructions are invalid.
>
> The compiler generates
>
> .cpu arm7tdmi
> .fpu neon
>
> for this example.

Oh, I bet this is a crufty old target that doesn't use the .cpu/.fpu 
directives. The gcc driver is almost certainly passing the wrong set of 
commandline options to the the assembler.  I find it hard to care about 
non-eabi targets nowadays.

Paul

Re: GCC Tests For ARM/Neon

[Joel Sherrill]

Paul Brook wrote:

On Wednesday 06 August 2008, Joseph S. Myers wrote:
  

On Wed, 6 Aug 2008, Joel Sherrill wrote:


$ arm-rtems4.9-gcc  -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c /tmp/ccBzigjD.s: Assembler messages:
/tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr
d18,[fp,#-32]'


So with that combination of options gcc defines __ARM_NEON__.
And gas ends up knowing the instructions are invalid.
  

The compiler generates

.cpu arm7tdmi
.fpu neon

for this example.



Oh, I bet this is a crufty old target that doesn't use the .cpu/.fpu
directives. The gcc driver is almost certainly passing the wrong set of
commandline options to the the assembler.  I find it hard to care about
non-eabi targets nowadays.

  

The binutils version is 2.18 but the target is arm-rtems.
arm-*-rtems* appears to be effectively the same as
arm-*-elf* in binutils and very close in gcc.  The
eabi difference in binutils is minor but in gcc, it looks
like a very different configuration.

Mike Stein's arm-elf test results don't show this failure but
I doubt he is adding special CPU arguments when testing and
thus not tripping this.

We chose arm-elf as the starting point years.  If we need to
move to arm-eabi as the starting point that is OK.  We usually
just chose the CPU-coff or CPU-elf as a starting point
for CPU-rtems.

What is the difference and how will it impact code?  I am
worried about our assembly code.

Is there a standard conditional to know the difference if
it matters?


--joel

Re: GCC Tests For ARM/Neon

[Joel Sherrill]

Paul Brook wrote:

 arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c
test_neon.c

#if !defined(__ARM_NEON__)
#error "Neon not supported"
#endif

void neon_code(void)
{
  asm volatile ("vldr d18,[fp,#-32]");
}



Works fine here. Either your assembler is busted, or there is something else
you're not telling us about.
  

I assume based on your next post that you tried this with
an EABI arm target not a simple arm-elf one?

--joel

Re: Problem reading corefiles on ARM

[Paul Koning]

> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:

 Joe> Paul Koning <[EMAIL PROTECTED]> writes:
 >> > That's sufficient for live debugging but not for corefiles.  In
 >> that > case you do want caller-saved registers, because they may
 >> contain > local variable values that don't live in memory at the
 >> time of the > abort call.

 Joe> On Wed, Aug 06, 2008 at 11:38:14PM +0200, Andreas Schwab wrote:
 >> In an optimized build you can't expect any local variable to
 >> survive, since it may just be dead before the call, or its value
 >> may be unavailable for any other reason.  The use of the noreturn
 >> attribute only adds little to this.

 Joe> Agreed.  I think that the objective should be that if there is
 Joe> an abort call, then from either a core dump or when gdb'ing a
 Joe> live process it should be possible to determine the call site of
 Joe> the abort() call, even with -O2/-Os.  But beyond that, the
 Joe> optimizer should be free, just as in other cases, to discard
 Joe> values in registers that will never be used again.

 Joe> After all, if we have

 Joe> int func1(int); void func2(int); void ordinary_function(void);

 Joe> void func(int arg) { int v1 = func1(arg); func2(v1);
 Joe> ordinary_function(); }

 Joe> and there's a segfault in ordinary_function, in general v1 isn't
 Joe> going to be kept around for inspection in the core dump.  So why
 Joe> should we impose a stricter requirement if ordinary_function is
 Joe> replaced by abort() ?  It seems Paul thinks we should be
 Joe> required to save v1 if there's an abort call, unless I'm
 Joe> misunderstanding.

My view is that abort() should be like other (returning) functions --
no special treatment for variable liveness.  Yes, that means in the
optimized case you may lose, some of the time.  People chose -O
settings with that issue in mind.  I'm not asking for more to be saved
for abort() than for regular functions -- but also no less.

paul

Re: GCC Tests For ARM/Neon

[Paul Brook]

> We chose arm-elf as the starting point years.  If we need to
> move to arm-eabi as the starting point that is OK.  We usually
> just chose the CPU-coff or CPU-elf as a starting point
> for CPU-rtems.

I highly recommend switching to the EABI.

If you want to support recent (Thumb-2) CPUs I'd expect that you pretty much 
have to use an EABI based target.

> What is the difference and how will it impact code?  I am
> worried about our assembly code.

The main visible change is that that you must preserve 8-byte stack alignment 
at public entry points.

> Is there a standard conditional to know the difference if
> it matters?

__ARM_EABI__

Paul

Re: GCC Tests For ARM/Neon

[Joel Sherrill]

Thanks.  We are close to branching an RTEMS release.
Sounds like this will be a good thing to switch to
immediately after that.

--joel
Paul Brook wrote:

We chose arm-elf as the starting point years.  If we need to
move to arm-eabi as the starting point that is OK.  We usually
just chose the CPU-coff or CPU-elf as a starting point
for CPU-rtems.



I highly recommend switching to the EABI.

If you want to support recent (Thumb-2) CPUs I'd expect that you pretty much
have to use an EABI based target.

  

What is the difference and how will it impact code?  I am
worried about our assembly code.



The main visible change is that that you must preserve 8-byte stack alignment
at public entry points.

  

Is there a standard conditional to know the difference if
it matters?



__ARM_EABI__

Paul
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

SVN trunk broken on Linux?

[Joel Sherrill]

Hi,

I started with a fresh tree this morning
and get this building the native.  Is anyone
else seeing this?

/home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc 
-B/home/joel/work-gnat/svn/b-native/./prev-gcc/ 
-B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu/bin/ -c 
-DHAVE_CONFIG_H -g -O2 -I. -I../../gcc/libiberty/../include  -W -Wall 
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  
../../gcc/libiberty/regex.c -o regex.o

In file included from ../../gcc/libiberty/regex.c:638:
../../gcc/libiberty/regex.c: In function 'byte_regex_compile':
../../gcc/libiberty/regex.c:4221: error: unrecognizable insn:
(insn 1225 4440 1226 256 ../../gcc/libiberty/regex.c:3124 (parallel [
   (set (mem:QI (reg:SI 664) [0 S1 A8])
   (subreg:QI (reg:SI 666) 0))
   (set (reg:SI 664)
   (plus:SI (reg:SI 664)
   (const_int 1 [0x1])))
   ]) -1 (nil))
../../gcc/libiberty/regex.c:4221: internal compiler error: in 
extract_insn, at recog.c:1988

Please submit a full bug report,

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: SVN trunk broken on Linux?

[H.J. Lu]

On Thu, Aug 7, 2008 at 7:46 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I started with a fresh tree this morning
> and get this building the native.  Is anyone
> else seeing this?
>
> /home/joel/work-gnat/svn/b-native/./prev-gcc/xgcc
> -B/home/joel/work-gnat/svn/b-native/./prev-gcc/
> -B/home/joel/work-gnat/svn//install/i686-pc-linux-gnu/bin/ -c
> -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc/libiberty/../include  -W -Wall
> -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
>  ../../gcc/libiberty/regex.c -o regex.o
> In file included from ../../gcc/libiberty/regex.c:638:
> ../../gcc/libiberty/regex.c: In function 'byte_regex_compile':
> ../../gcc/libiberty/regex.c:4221: error: unrecognizable insn:
> (insn 1225 4440 1226 256 ../../gcc/libiberty/regex.c:3124 (parallel [
>   (set (mem:QI (reg:SI 664) [0 S1 A8])
>   (subreg:QI (reg:SI 666) 0))
>   (set (reg:SI 664)
>   (plus:SI (reg:SI 664)
>   (const_int 1 [0x1])))
>   ]) -1 (nil))
> ../../gcc/libiberty/regex.c:4221: internal compiler error: in extract_insn,
> at recog.c:1988
> Please submit a full bug report,
>


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37048

-- 
H.J.

build_fold_addr_expr breaks verify_stmt

[Martin Schindewolf]

Dear GCC-Developers,

I am currently experiencing two problems (which seem related).

(1) I wrote a pass that works after the gimplification is
completed and amongst other things does the following:
It passes the address of a variable to a function. To pass
the address I use the build_fold_addr_expr which takes the
address and seems to work quite well.
The problem now occurs when the variable is used after the
function call. Since the variable is used in a binary
expression, the compiler complains about the following:

error: invalid operand to binary operator
m
file.c: internal compiler error: verify_stmts failed

I assume that the error occurs because one of the GIMPLE
assumptions (that every global variable is assigned to
a local one) is violated. This happens because the call to
build_fold_addr_expr takes the address of the variable and
the variable escapes the local scope. Are there any means
to work around this issue?

(2) I would like to capture the value of a variable in a
temporary and restore it under certain conditions. Adding
the temporaries and inserting the assignments both ways
(to save and restore the values) works fine.
Unfortunately, none of the temporary variables
survives the SSA optimisations. Is there something (maybe
similar to the VDEF for memory locations) that prevents
optimisation of variables? (I tried to set VDEFs on the
variables directly but this breaks the SSA properties).

Thank you very much for your suggestions!

Regards,
Martin

Re: build_fold_addr_expr breaks verify_stmt

[Richard Guenther]

On Thu, Aug 7, 2008 at 4:55 PM, Martin Schindewolf <[EMAIL PROTECTED]> wrote:
> Dear GCC-Developers,
>
> I am currently experiencing two problems (which seem related).
>
> (1) I wrote a pass that works after the gimplification is
> completed and amongst other things does the following:
> It passes the address of a variable to a function. To pass
> the address I use the build_fold_addr_expr which takes the
> address and seems to work quite well.
> The problem now occurs when the variable is used after the
> function call. Since the variable is used in a binary
> expression, the compiler complains about the following:
>
> error: invalid operand to binary operator
> m
> file.c: internal compiler error: verify_stmts failed

You need to replace all uses of the former(!) register variable
by a load into a register and a use of that new register.  This
is because by taking the address of the variable you made
the variable no longer be a register.

In general doing what you do after gimplification is not a good idea.

Richard.

Re: Problem reading corefiles on ARM

[Joe Buck]

Joe> After all, if we have

int func1(int);
void func2(int);
void ordinary_function(void);
 
void func(int arg) {
  int v1 = func1(arg);
  func2(v1);
  ordinary_function();
}

>  Joe> and there's a segfault in ordinary_function, in general v1 isn't
>  Joe> going to be kept around for inspection in the core dump.  So why
>  Joe> should we impose a stricter requirement if ordinary_function is
>  Joe> replaced by abort() ?  It seems Paul thinks we should be
>  Joe> required to save v1 if there's an abort call, unless I'm
>  Joe> misunderstanding.

On Thu, Aug 07, 2008 at 09:28:30AM -0400, Paul Koning wrote:
> My view is that abort() should be like other (returning) functions --
> no special treatment for variable liveness.  Yes, that means in the
> optimized case you may lose, some of the time.  People chose -O
> settings with that issue in mind.  I'm not asking for more to be saved
> for abort() than for regular functions -- but also no less.

I'm not sure if anyone besides Paul and me care any more, but I'll just
do one more.

OK, consider this case:

int func1(int);
void func2(int);
bool test(void);
void func3(int);

void func(int arg) {
  int v1 = func1(arg);
  func2(v1);
  if (test()) {
  func3(v1);
  }
}

Here if we put v1 in a register, we obviously have to save it across
the call to test(), unless we know that test() will never return true,
in which case we don't need to save v1.

But what about replacing the "if" by

  if (!test())
  abort();
  func3(v1);

Now, if I read you right, we'd have so save v1 even if we know that
test() returns false.

Re: Update libtool?

[Peter O'Gorman]

Paolo Bonzini wrote:
> 
>> That said, updating in trunk is a different matter.  There, the question
>> IMHO is mostly which libtool version to update to.  The git version may
>> still have a regression or two, but 2.2.4 doesn't have the -fPIC on
>> HP/IA patch from Steve (which would be trivial to backport of course).
>> Alternatively GCC can wait for 2.2.6 (hopefully in the "couple of weeks
>> at most" time frame).
> 
> Updating to 2.2.6 would be okay for me.

Thanks. I'll test quickly with current libtool git now, and will test
more thoroughly and submit a patch when libtool-2.2.6 is released.

Peter
-- 
Peter O'Gorman
http://pogma.com

Re: Problem reading corefiles on ARM

[Paul Koning]

> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:

 Joe> ...OK, consider this case:

 Joe> int func1(int); void func2(int); bool test(void); void
 Joe> func3(int);

 Joe> void func(int arg) { int v1 = func1(arg); func2(v1); if (test())
 Joe> { func3(v1); } }

 Joe> Here if we put v1 in a register, we obviously have to save it
 Joe> across the call to test(), unless we know that test() will never
 Joe> return true, in which case we don't need to save v1.

 Joe> But what about replacing the "if" by

 Joe> if (!test()) abort(); func3(v1);

 Joe> Now, if I read you right, we'd have so save v1 even if we know
 Joe> that test() returns false.

All I meant is "treat abort() like a regular function that returns,
from the point of view of what state is saved.  If in this case it
means that normal GCC processing would mean "save v1" that's what it
means.  No special handling to save more than the usual -- but no
saving less than the usual either.

   paul

Turning off denormals (subnormals) in GCC

[MeMooMeM]

Hi, 

I would like to avoid denormal handling latencies. On Intel, this is turned
ON by default and Intel compiler has the -ftz- option to turn it off. I am
looking for a similar option of GCC. Any ideas?

Thanks a lot in advance!
-Memo
 
-- 
View this message in context: 
http://www.nabble.com/Turning-off-denormals-%28subnormals%29-in-GCC-tp18875926p18875926.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Turning off denormals (subnormals) in GCC

[H.J. Lu]

On Thu, Aug 7, 2008 at 10:41 AM, MeMooMeM <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I would like to avoid denormal handling latencies. On Intel, this is turned
> ON by default and Intel compiler has the -ftz- option to turn it off. I am
> looking for a similar option of GCC. Any ideas?
>

-ffast-math?

-- 
H.J.

Re: Turning off denormals (subnormals) in GCC

[MeMooMeM]

H.J. Lu-30 wrote:
> 
> On Thu, Aug 7, 2008 at 10:41 AM, MeMooMeM <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I would like to avoid denormal handling latencies. On Intel, this is
>> turned
>> ON by default and Intel compiler has the -ftz- option to turn it off. I
>> am
>> looking for a similar option of GCC. Any ideas?
>>
> 
> -ffast-math?
> 
> -- 
> H.J.
> 
> 

Oh,  I just found the other thread on this issue. In my first search I used
'subnormal' as the keyword, that's why I couldn't find the tread. 

Thank you, I think this option will do it!   

-- 
View this message in context: 
http://www.nabble.com/Turning-off-denormals-%28subnormals%29-in-GCC-tp18875926p18876103.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: New test is invalid for AVR

[Ian Lance Taylor]

Andreas Krebbel1 <[EMAIL PROTECTED]> writes:

> it is important for the testcase that the array is that big. In order to
> avoid breaking other targets with that I've moved the testcase to the s390
> specific directory. I've already committed the patch. Sorry for the
> breakage.

If the test will run on most normal targets, then a better approach is
to add something like

#if defined(STACK_SIZE) && STACK_SIZE < 1000
  exit (0); /* or "return 0" from main, as appropriate"
#endif

See many examples of use of STACK_SIZE in gcc.c-torture/execute.

Ian

s-oscons technique does not work for RTEMS

[Joel Sherrill]

Hi,

As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
the new technique for generating s-oscons.ads does not work
for RTEMS.  The OS .h files are not available when the compiler
is built -- only those strictly owned by the newlib C library.

As indicated by this from the build log, you have neither
termios nor network .h files available when the compiler
is built.

checking for ANSI C header files... In file included from 
s-oscons-tmplt.c:95:

gsocket.h:160:24: error: sys/socket.h: No such file or directory
gsocket.h:161:24: error: netinet/in.h: No such file or directory
gsocket.h:162:25: error: netinet/tcp.h: No such file or directory
gsocket.h:163:23: error: sys/ioctl.h: No such file or directory
gsocket.h:164:19: error: netdb.h: No such file or directory
In file included from s-oscons-tmplt.c:102:
/home/joel/work-gnat/svn/gcc/newlib/libc/include/termios.h:4:25: error: 
sys/termios.h: No such file or directory

yes
checking for sys/types.h... s-oscons-tmplt.c: In function 'main':
s-oscons-tmplt.c:1096: error: invalid application of 'sizeof' to 
incomplete type 'struct sockaddr_in'


Is there an alternative way to generate s-oscons?

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: s-oscons technique does not work for RTEMS

[Arnaud Charlet]

> As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
> the new technique for generating s-oscons.ads does not work
> for RTEMS.  The OS .h files are not available when the compiler
> is built -- only those strictly owned by the newlib C library.
>
> As indicated by this from the build log, you have neither
> termios nor network .h files available when the compiler
> is built.

Then what I'd suggest is that you first build a C (or C and C++)
compiler, build newlib and co, install the system, and then
from there, redo a build with Ada enabled.

That's I believe how such bootstrap issue is resolved in general.

Arno

Re: s-oscons technique does not work for RTEMS

[Thomas Quinot]

* Arnaud Charlet, 2008-08-07 :

> > As I warned in http://gcc.gnu.org/ml/gcc/2008-07/msg00387.html,
> > the new technique for generating s-oscons.ads does not work
> > for RTEMS.  The OS .h files are not available when the compiler
> > is built -- only those strictly owned by the newlib C library.
> >
> > As indicated by this from the build log, you have neither
> > termios nor network .h files available when the compiler
> > is built.
> 
> Then what I'd suggest is that you first build a C (or C and C++)
> compiler, build newlib and co, install the system, and then
> from there, redo a build with Ada enabled.
> 
> That's I believe how such bootstrap issue is resolved in general.

As an alternative to Arno's suggestion, maybe you could use the
--with-sysroot configure parameter to make the required headers
available to the build process. I know others have used this method on
some cross targets.

Thomas.

-- 
Thomas Quinot, Ph.D. ** [EMAIL PROTECTED] ** Senior Software Engineer
   AdaCore -- Paris, France -- New York, USA

gcc-4.3-20080807 is now available

[gccadmin]

Snapshot gcc-4.3-20080807 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080807/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch 
revision 138850

You'll find:

gcc-4.3-20080807.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080807.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080807.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080807.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080807.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080807.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080807.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080807.tar.bz2The GCC testsuite

Diffs from 4.3-20080731 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

RE: New test is invalid for AVR

[Dave Korn]

Ian Lance Taylor wrote on 07 August 2008 19:20:

> If the test will run on most normal targets, then a better approach is
> to add something like
> 
> #if defined(STACK_SIZE) && STACK_SIZE < 1000
>   exit (0); /* or "return 0" from main, as appropriate"
> #endif

  :)  Actually, it's a compile test!
 

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: New test is invalid for AVR

[Ian Lance Taylor]

"Dave Korn" <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote on 07 August 2008 19:20:
>
>> If the test will run on most normal targets, then a better approach is
>> to add something like
>> 
>> #if defined(STACK_SIZE) && STACK_SIZE < 1000
>>   exit (0); /* or "return 0" from main, as appropriate"
>> #endif
>
>   :)  Actually, it's a compile test!

A compile test breaks because it uses a large stack?

In that case, just comment out the bulk of the test based on
STACK_SIZE.

Ian

regressions on i686-apple-darwin9

[Jack Howarth]

  Is anyone else seeing some new internal compiler errors in the gcc
testsuite on i686-apple-darwin9? I am using the same graphite patch
I used a couple days back with the current svn of gcc trunk and now
I see failures like...

FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/930506-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/930506-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (test for excess errors)
FAIL: gcc.c-torture/execute/conversion.c compilation,  -Os  (internal compiler 
error)
FAIL: gcc.c-torture/execute/gofast.c compilation,  -Os  (internal compiler 
error)
FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)
FAIL: gcc.c-torture/unsorted/conv.c,  -Os   (internal compiler error)
FAIL: gcc.c-torture/unsorted/conv_tst.c,  -Os   (internal compiler error)

These are showing up in gcc.log as below.
 Jack

Executing on host: 
/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/  -w  -Os   
-fno-show-column -c  -o /sw/src/fink.build/gcc44-4.3.999
-20080807/darwin_objdir/gcc/testsuite/gcc/BUG11.o 
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c
(timeout = 300)
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:
 In function 'foo':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:6:
 internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:
 In function 'foo':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:6:
 internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)

Executing on host: 
/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/   -Os  -w 
-fno-show-column -c  -o 930506-1.o /sw/src/fink.build/gcc
44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c
(timeout = 300)
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c:
 In function 'f':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c:4:
 internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c:
 In function 'f':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c:4:
 internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

FAIL: gcc.c-torture/compile/930506-1.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/930506-1.c  -Os  (test for excess errors)
Excess errors:
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/930506-1.c:4:
 internal compiler error: in emit_unop_insn, at optabs.c:3806

Executing on host: 
/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc44-4.3.999-20080807/darwin_objdir/gcc/   -Os  -w 
-fno-show-column -c  -o fix-trunc-mem-1.o /sw/src/fink.bu
ild/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/fix-trunc-mem-1.c
(timeout = 300)
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/fix-trunc-mem-1.c:
 In function 'f2':
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-torture/compile/fix-trunc-mem-1.c:6:
 internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
compiler exited with status 1
output is:
/sw/src/fink.build/gcc44-4.3.999-20080807/gcc-4.4-20080807/gcc/testsuite/gcc.c-tortur

Re: regressions on i686-apple-darwin9

[Eric Christopher]

On Thu, Aug 7, 2008 at 8:47 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
>  Is anyone else seeing some new internal compiler errors in the gcc
> testsuite on i686-apple-darwin9? I am using the same graphite patch
> I used a couple days back with the current svn of gcc trunk and now
> I see failures like...
>
> FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (internal compiler error)
> FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (test for excess errors)
> FAIL: gcc.c-torture/compile/930506-1.c  -Os  (internal compiler error)
> FAIL: gcc.c-torture/compile/930506-1.c  -Os  (test for excess errors)
> FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (internal compiler error)
> FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (test for excess errors)
> FAIL: gcc.c-torture/execute/conversion.c compilation,  -Os  (internal 
> compiler error)
> FAIL: gcc.c-torture/execute/gofast.c compilation,  -Os  (internal compiler 
> error)
> FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)
> FAIL: gcc.c-torture/unsorted/conv.c,  -Os   (internal compiler error)
> FAIL: gcc.c-torture/unsorted/conv_tst.c,  -Os   (internal compiler error)
>
> These are showing up in gcc.log as below.

They all look to be the same bug. I'd track down what's trying to emit
that instruction.

-eric

Re: regressions on i686-apple-darwin9

[Jack Howarth]

Eric,
   Thanks for looking into this. FYI, the problem also occurs in...

FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-double.c  -Os  compilation failed to 
produce executable
FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-float.c  -Os  compilation failed to 
produce executable
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (internal compiler error)
FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (test for excess errors)
WARNING: gcc.dg/torture/fp-int-convert-timode.c  -Os  compilation failed to 
produce executable

with the same " in emit_unop_insn, at optabs.c:3806" error message. I don't see
this failure anywhere in the g++ testsuite though.
  Jack

On Thu, Aug 07, 2008 at 08:57:32PM -0700, Eric Christopher wrote:
> On Thu, Aug 7, 2008 at 8:47 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> >  Is anyone else seeing some new internal compiler errors in the gcc
> > testsuite on i686-apple-darwin9? I am using the same graphite patch
> > I used a couple days back with the current svn of gcc trunk and now
> > I see failures like...
> >
> > FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (internal compiler error)
> > FAIL: gcc.c-torture/compile/20020930-1.c  -Os  (test for excess errors)
> > FAIL: gcc.c-torture/compile/930506-1.c  -Os  (internal compiler error)
> > FAIL: gcc.c-torture/compile/930506-1.c  -Os  (test for excess errors)
> > FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (internal compiler 
> > error)
> > FAIL: gcc.c-torture/compile/fix-trunc-mem-1.c  -Os  (test for excess errors)
> > FAIL: gcc.c-torture/execute/conversion.c compilation,  -Os  (internal 
> > compiler error)
> > FAIL: gcc.c-torture/execute/gofast.c compilation,  -Os  (internal compiler 
> > error)
> > FAIL: gcc.c-torture/unsorted/BUG11.c,  -Os   (internal compiler error)
> > FAIL: gcc.c-torture/unsorted/conv.c,  -Os   (internal compiler error)
> > FAIL: gcc.c-torture/unsorted/conv_tst.c,  -Os   (internal compiler error)
> >
> > These are showing up in gcc.log as below.
> 
> They all look to be the same bug. I'd track down what's trying to emit
> that instruction.
> 
> -eric

Re: regressions on i686-apple-darwin9

[Eric Christopher]

On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
>   Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-double.c  -Os  compilation failed to 
> produce executable
> FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-float.c  -Os  compilation failed to 
> produce executable
> FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-timode.c  -Os  compilation failed to 
> produce executable
>
> with the same " in emit_unop_insn, at optabs.c:3806" error message. I don't 
> see
> this failure anywhere in the g++ testsuite though.
>

Looks rather fishy that they're all at -Os. I'd look at things that
went in recently
that would have affected that.

-eric

Re: regressions on i686-apple-darwin9

[Andrew Pinski]

On Thu, Aug 7, 2008 at 9:24 PM, Eric Christopher <[EMAIL PROTECTED]> wrote:

> Looks rather fishy that they're all at -Os. I'd look at things that
> went in recently
> that would have affected that.
>

Most likely http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00355.html .

Thanks,
Andrew Pinski

Re: regressions on i686-apple-darwin9

[H.J. Lu]

On Thu, Aug 7, 2008 at 9:13 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> Eric,
>   Thanks for looking into this. FYI, the problem also occurs in...
>
> FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-double.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-double.c  -Os  compilation failed to 
> produce executable
> FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-float.c  -Os  compilation failed to 
> produce executable
> FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (internal compiler error)
> FAIL: gcc.dg/torture/fp-int-convert-timode.c  -Os  (test for excess errors)
> WARNING: gcc.dg/torture/fp-int-convert-timode.c  -Os  compilation failed to 
> produce executable
>
> with the same " in emit_unop_insn, at optabs.c:3806" error message. I don't 
> see
> this failure anywhere in the g++ testsuite though.

Please open a bug report. They also fail on Linux with SSE fpmath:

bash-3.2$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/  -w  -Os
-fno-show-column -c  -o
/export/build/gnu/gcc/build-x86_64-linux/gcc/testsuite/gcc/BUG11.o
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c
-m32 -msse2 -mfpmath=sse
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:
In function 'foo':
/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.c-torture/unsorted/BUG11.c:6:
internal compiler error: in emit_unop_insn, at optabs.c:3806
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
bash-3.2$

Re: regressions on i686-apple-darwin9

[Eric Christopher]

> Please open a bug report. They also fail on Linux with SSE fpmath:
>
>
That'd be why they fail on darwin then - we default to sse2 :)

-eric

Re: s-oscons technique does not work for RTEMS

[Arnaud Charlet]

> As an alternative to Arno's suggestion, maybe you could use the
> --with-sysroot configure parameter to make the required headers
> available to the build process. I know others have used this method on
> some cross targets.

Another (at least short term) solution would be to use
DUMMY_SOCKETS_TARGET_PAIRS on RTEMS. This would disable socket support
(which is not part of the Ada standard, so wouldn't e.g. change the ACATS
profile, but at least would not break the whole Ada build.

Arno