[Bug inline-asm/41422] incorrect code generated with asm function pointers when compiled with -fPIC on x84_64

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-09-21 06:58 ---
I think it is an assembler bug, unless GOTPCREL is only allowed for non-local
symbols (then it would be testcase author's fault).
GOTPCREL which is address of a pointer to the symbol should never be resolved
to
the actual address of the symbol.
You can always add .global my_asm_func to the asm, or that plus .hidden
my_asm_func to avoid exporting it from the current file.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug inline-asm/41422] incorrect code generated with asm function pointers when compiled with -fPIC on x84_64

[scott dot gccbugs dot 2009 at scottrix dot co dot uk]

--- Comment #2 from scott dot gccbugs dot 2009 at scottrix dot co dot uk  
2009-09-21 06:25 ---
I have changed 

extern void my_asm_func(void);

to

static void my_asm_func(void);

This gives me a warning:

a.c:3: warning: 'my_asm_func' used but never defined

and still produces incorrect code, as before.

I am more than happy to accept that this is an assembler problem (it's not the
linker since the problem is in the .o file.)  How do I generate the code that
you gave ? (movqmy_asm_f...@gotpcrel(%rip), %rsi)

thanks...


-- 

scott dot gccbugs dot 2009 at scottrix dot co dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/41424] Heavily optimized x86_64-w64 binary produces negative effects

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
  Component|c   |target


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

[Bug c/41424] New: Heavily optimized x86_64-w64 binary produces negative effects

[xxcv07 at gmail dot com]

Hello:
I found the optimized binary created by gcc-4_4-branch and trunk, is unstable
in someway.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4116.0x15d4]
0x08d8f304 in ?? ()
(gdb) bt
#0  0x08d8f304 in ?? ()
#1  0x in ?? ()
(gdb) disass $pc-30 $pc+30
Dump of assembler code from 0x8d8f2e6 to 0x8d8f322:
0x08d8f2e6: outsl  %ds:(%rsi),(%dx)
0x08d8f2e7: cltd   0x08d8f2e8: pushq  $0xf20
0x08d8f2ed: outsl  %ds:(%rsi),(%dx)
0x08d8f2ee: jrcxz  0x8d8f338
0x08d8f2f0: lea0x1058(%rcx),%edx
0x08d8f2f6: mov(%rdx),%rsi
0x08d8f2f9: nopl   0x0(%rax)
0x08d8f300: movq   0x8(%rdx),%mm0
0x08d8f304: movq   (%rsi,%rax,2),%mm2
0x08d8f308: movq   0x8(%rsi,%rax,2),%mm5
0x08d8f30d: add$0x10,%rdx
0x08d8f311: mov(%rdx),%rsi
0x08d8f314: test   %rsi,%rsi
0x08d8f317: pmulhw %mm0,%mm2
0x08d8f31a: pmulhw %mm0,%mm5
0x08d8f31d: paddw  %mm2,%mm3
0x08d8f320: paddw  %mm5,%mm4
End of assembler dump.
(gdb) info all-registers
rax0x29a8   10664
rcx0xd8e6958227436888
rdx0xd8e79c0227441088
rbx0x133f4b30   322915120
rsp0xdbbdcd0230415568
rbp0xd7e2e90226373264
rsi0x1340ccb0   323013808
rdi0x133f9530   322934064
r8 0xa2470f8170160376
r9 0x0  0
r100xd7b4f90226185104
r110xd55ec58223734872
r120xa2470f8170160376
r130x133f9530   322934064
r140x133fdf30   322953008
r150x24f591
rip0x8d8f3040x8d8f304
eflags 0x10202  [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
st0-nan(0x5d205d205d205d2)  (raw 0x05d205d205d205d2)
st1-nan(0x35ab0dd2fc83) (raw 0x35ab0dd2fc83)
st2-nan(0x) (raw 0x)
st3-nan(0x3000300030003)(raw 0x0003000300030003)
st4-nan(0x3000300030003)(raw 0x0003000300030003)
st5-nan(0x) (raw 0x)
st6-nan(0x8282828182828181) (raw 0x8282828182828181)
st7-inf (raw 0x)
fctrl  0xff0420027f 1095285867135
fstat  0xff0420 16712736
ftag   0xff 255
fiseg  0x23 150323855360
fioff  0x0  0
foseg  0x1f80   34634616274944
fooff  0x0  0
fop0x27 167503724544
xmm0   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm1   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm2   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm3   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm4   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm5   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm6   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm7   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x0 }, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
   0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
 uint128 = 0x}
xmm8   {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
 v16_int8 = {0x

[Bug c/41182] [4.5 Regression] Revision 145254 caused ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-09-20 23:31 
---
It is caused by revision 145254:

http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.5 Regression] ICE: tree  |[4.5 Regression] Revision
   |check: expected integer_cst,|145254 caused ICE: tree
   |have nop_expr in|check: expected integer_cst,
   |tree_int_cst_lt, at |have nop_expr in
   |tree.c:5259 |tree_int_cst_lt, at
   ||tree.c:5259


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

[Bug fortran/41389] problem compiling file

[clerman at fuse dot net]

--- Comment #4 from clerman at fuse dot net  2009-09-20 23:28 ---
Subject: Re:  problem compiling file

Thank you for your response. I would appreciate very much if you could you
please supply me with a web site and the name of the particular version of
binutils.

Thanks for your assistance.

Yours truly,

Norm

Norman S. Clerman

 pinskia at gcc dot gnu dot org  wrote: 
> 
> 
> --- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-20 21:02 
> ---
> You are using a gfortran binary which was compiled for use with a newer 
> version
> of binutils than you have.  You should either install a newer version of
> binutils or compile gfotran yourself.
> 
> 
> -- 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>What|Removed |Added
> 
>  Status|UNCONFIRMED |RESOLVED
>  Resolution||INVALID
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41389
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[developer at sandoe-acoustics dot co dot uk]

--- Comment #19 from developer at sandoe-acoustics dot co dot uk  
2009-09-20 22:37 ---
(In reply to comment #16)

firstly, backing out of all mods to dwarf2out.c after 151814 both allows the
bootstrap to complete and checking the log files shows no dsymutil fails 

powerpc-apple-darwin8, i686-apple-darwin9 

> Instead of reverting the patch 

[this might not be quite enough; backing out of only 151814->151815 for trunk
version 151904 produced a working bootstrap but with still some dsymutil
fails].

we should add a -gstrict-dwarf[23] switch
> that darwin can use by default instead.

Please can we do this; even if there is a fix applied to darwin10/9 dsymutil we
are unlikely to see a fix applicable to darwin8 since active development is now
on darwin10.


-- 


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

[Bug target/41025] v4.3.3, 4.4.1, etc -ftracer sometimes fails by "is already defined"

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-09-20 22:10 ---
Can you provide the preprocessed source?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c   |target


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

[Bug inline-asm/41422] incorrect code generated with asm function pointers when compiled with -fPIC on x84_64

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-09-20 22:01 ---
GCC outputs:
movqmy_asm_f...@gotpcrel(%rip), %rsi

Which looks correct but since my_asm_func is local to the object file only, the
assembler/linker decides something different.

If you do:
static void my_asm_func(void); instead
it works the way you want it to work.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/41423] missing warning for an uncallable function template

[msebor at gmail dot com]

-- 

msebor at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c++/41423] New: missing warning for an uncallable function template

[msebor at gmail dot com]

There is no way for a program to refer to the template constructor defined
in the class below.  EDG eccp issues a warning to point this out, but gcc
silently accepts the code.  It would be helpful if gcc were enhanced to
issue a similar diagnostic.

$ cat t.cpp && gcc -dumpversion && gcc -W -Wall -Wextra -pedantic -c t.cpp &&
eccp -c -v t.cpp
struct S { template  S () { } };
4.4.1
Edison Design Group C/C++ Front End, version 3.10.1 (Apr 22 2008 17:02:08)
Copyright 1988-2007 Edison Design Group, Inc.

"t.cpp", line 1: warning: template parameter "" is not used in
  declaring the parameter types of function template "S::S"
  struct S { template  S () { } };
^


-- 
   Summary: missing warning for an uncallable function template
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[pogma at gcc dot gnu dot org]

--- Comment #18 from pogma at gcc dot gnu dot org  2009-09-20 21:49 ---
(In reply to comment #17)
> > 
> There still is an oddity here. I can trigger this problem in current gcc trunk
> with a conftest.c but not with a conftest.i (comment 6). 
> 

dsymutil does not get run when compiling conftest.i

The specs file has:
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:
%%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm:
%%{g*:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!o:a.out

So, as far as I can tell, dsymutil only gets run for files with the extensions
.c,.cc,.C,.cpp,.cp,.c++,.cxx,.CPP,.m and .mm


-- 


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

[Bug inline-asm/41422] New: incorrect code generated with asm function pointers when compiled with -fPIC on x84_64

[scott dot gccbugs dot 2009 at scottrix dot co dot uk]

I have only seen this problem ono x86_64, cannot reproduce on i686.

Example code (a.c):

#include 

extern void my_asm_func(void);

asm(".text\n" \
"my_asm_func:\n" \
"  mov 1234,%rax\n" \
"  ret\n" \
".previous\n");

int my_c_func() { return 1; }

int main()
{
   void *fred;

   fred=(void *)my_asm_func;
   printf("function = %p\n",fred);
   fred=(void *)my_c_func;
   printf("function = %p\n",fred);
   return 0;
}

if this is compiled with the line:

gcc -c -g -o a.o a.c

The assemble code for the two "fred=" function pointer assignments are correct:

   fred=(void *)my_asm_func;
  1c:   48 c7 45 f8 00 00 00movq   $0x0,-0x8(%rbp)
  23:   00 

   fred=(void *)my_c_func;
  37:   48 c7 45 f8 00 00 00movq   $0x0,-0x8(%rbp)
  3e:   00 

Values will be fixed up at link time:

gcc -g -o a a.o

Giving:

   fred=(void *)my_asm_func;
  400528:   48 c7 45 f8 0c 05 40movq   $0x40050c,-0x8(%rbp)
  40052f:   00 

   fred=(void *)my_c_func;
  400543:   48 c7 45 f8 15 05 40movq   $0x400515,-0x8(%rbp)
  40054a:   00 

as expected.  However, when used with -fPIC:

gcc -fPIC -c -g -o a.o a.c

we get :

   fred=(void *)my_asm_func;
  1c:   48 8b 05 dd ff ff ffmov-0x23(%rip),%rax# 0

  23:   48 89 45 f8 mov%rax,-0x8(%rbp)

   fred=(void *)my_c_func;
  3c:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 43 
  43:   48 89 45 f8 mov%rax,-0x8(%rbp)

For some reason the asm function point has already been fixed up with a value,
which is actually the location the of the function, but it will move the value
at that address into rax, not the address itself.  Linking with:

 gcc -fPIC -g -o a a.o

gives:

   fred=(void *)my_asm_func;
  400568:   48 8b 05 dd ff ff ffmov-0x23(%rip),%rax# 40054c

  40056f:   48 89 45 f8 mov%rax,-0x8(%rbp)

   fred=(void *)my_c_func;
  400588:   48 8b 05 51 0a 20 00mov0x200a51(%rip),%rax#
600fe0 <_DYNAMIC+0x1a8>
  40058f:   48 89 45 f8 mov%rax,-0x8(%rbp)

showing that the c function has correctly been fixed up, the asm one is still
incorrect.

I have reproduced this problem on gcc 4.3.2 and 4.4.1.  I have only given
objdump -S output for the relevant sections of code.  If you require more
information please please let me know.

This problem was actually found while compiling valgrind for a 64 bit x86
target machine.


-- 
   Summary: incorrect code generated with asm function pointers when
compiled with -fPIC on x84_64
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scott dot gccbugs dot 2009 at scottrix dot co dot uk


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Comment #133 from pinskia at gcc dot gnu dot org  2009-09-20 21:28 
---
*** Bug 41195 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mehta at roguewave dot com


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

[Bug c++/41195] floating point optimization

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-09-20 21:28 ---
Yes it is a dup of 323.  Since really the target is 32bits :).

*** This bug has been marked as a duplicate of 323 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[joseph at codesourcery dot com]

--- Comment #10 from joseph at codesourcery dot com  2009-09-20 21:23 
---
Subject: Re:  [4.5 Regression] ICE: tree check: expected
 integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

Where (backtrace) did the C_MAYBE_CONST_EXPR get created?  Where 
(backtrace) did the NOP_EXPR get created?  The tree going inside a 
C_MAYBE_CONST_EXPR should have been folded at the point the 
C_MAYBE_CONST_EXPR was created, though that is meant to be an efficiency 
issue (avoiding multiple folding of the same trees) rather than required 
to avoid ICEs.


-- 


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-09-20 21:16 ---
We likely should recursively fold all trees during gimplification.  That also
would prepare us to no longer fold in the frontends.  Didn't we do this at
some point in the past?


-- 


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-09-20 21:12 ---
>The op0 of the call to fold_build2_stat_loc is not fully folded which causes
the ICE.

And op0 of the call to fold_build2_stat_loc does not contain c_maybe_const_expr
but just the NOP_EXPR.


-- 


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-09-20 21:11 ---
sorry for not adding a backtrace:
#2  0x00b86862 in tree_int_cst_lt (t1=0x76fc6990,
t2=0x76fcc040)
at /home/pinskia/src/local/gcc/gcc/tree.c:6087
#3  0x00710ea0 in optimize_minmax_comparison (loc=482, code=GT_EXPR,
type=0x77ed8540, 
op0=0x77ff8c80, op1=0x76fcc040) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:6150
#4  0x0072e64c in fold_comparison (loc=482, code=GT_EXPR,
type=0x77ed8540, 
op0=0x77ff8c80, op1=0x76fcc040) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:9616
#5  0x0076ba81 in fold_binary_loc (loc=482, code=GT_EXPR,
type=0x77ed8540, 
op0=0x77ff8c80, op1=0x76fcc040) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:13105
#6  0x0077752a in fold_build2_stat_loc (loc=482, code=GT_EXPR,
type=0x77ed8540, 
op0=0x77ff8c80, op1=0x76fcc040) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:14374
#7  0x00728e28 in fold_comparison (loc=482, code=LT_EXPR,
type=0x77ed8540, 
op0=0x76fcc040, op1=0x77ff8c80) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:9159
#8  0x0076ba81 in fold_binary_loc (loc=482, code=LT_EXPR,
type=0x77ed8540, 
op0=0x76fcc040, op1=0x77ff8c80) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:13105
#9  0x0077752a in fold_build2_stat_loc (loc=482, code=LT_EXPR,
type=0x77ed8540, 
op0=0x76fcc040, op1=0x77ff8c80) at
/home/pinskia/src/local/gcc/gcc/fold-const.c:14374
#10 0x004fd2a6 in c_fully_fold_internal (expr=0x76fcc000, in_init=0
'\0', 
maybe_const_operands=0x7fffe0af "", maybe_const_itself=0x7fffe0ae
"\001")
at /home/pinskia/src/local/gcc/gcc/c-common.c:1308
#11 0x004fbf28 in c_fully_fold (expr=0x76fcc000, in_init=0 '\0', 
maybe_const=0x7fffe0af "") at
/home/pinskia/src/local/gcc/gcc/c-common.c:1108
#12 0x004eee23 in c_finish_return (loc=460, retval=0x76fcc000,
origtype=0x0)
at /home/pinskia/src/local/gcc/gcc/c-typeck.c:8078

The op0 of the call to fold_build2_stat_loc is not fully folded which causes
the ICE.


-- 


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

[Bug fortran/41309] 4.4.1 build of fortran fails on T5140

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[joseph at codesourcery dot com]

--- Comment #6 from joseph at codesourcery dot com  2009-09-20 21:08 ---
Subject: Re:  [4.5 Regression] ICE: tree check: expected
 integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

There is no backtrace in this bug or any statement of the point in such a 
backtrace at which you think an invalid argument has been passed to a 
function that should not have been passed there.  C_MAYBE_CONST_EXPRs are 
created at various stages in the front end and are lowered by 
c_fully_fold, so none should exist by gimplification.  If the 
C_MAYBE_CONST_EXPR is being seen during gimplification, that's a front end 
bug.  Otherwise, non-front-end code dealing with trees needs to accept 
them just like any other front-end-specific trees.


-- 


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

[Bug middle-end/41396] missed space optimization related to basic block reorder

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug target/41323] Add new _mm_extract_epu16 intrinsic (resquest)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|trivial |enhancement


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

[Bug bootstrap/41322] [4.5 Regression] Failed to bootstrap

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[joseph at codesourcery dot com]

--- Comment #41 from joseph at codesourcery dot com  2009-09-20 21:04 
---
Subject: Re:  [4.5 Regression] major regressions on
 *-apple-darwin10 at -m64 caused by r147995

On Sun, 20 Sep 2009, howarth at nitro dot med dot uc dot edu wrote:

> If so, we can't just apply an "ifndef __APPLE__/#endif" wrapper appropriately
> there to suppress the addition of the epilog note? The question remains if the

__APPLE__ relates to the host and this issue relates to the target.  You'd 
at least be looking at a new target hook.


-- 


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

[Bug fortran/41389] problem compiling file

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-20 21:02 ---
You are using a gfortran binary which was compiled for use with a newer version
of binutils than you have.  You should either install a newer version of
binutils or compile gfotran yourself.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug ada/41419] [4.5 regression] many new ACATs failures (breakpoint instruction in object)

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[450 regression] many new   |[4.5 regression] many new
   |ACATs failures (breakpoint  |ACATs failures (breakpoint
   |instruction in object)  |instruction in object)
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/41397] [4.5 regression] RTL checking failure compiling libiberty

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug bootstrap/41399] [4.5 Regression] Internal error compiling fortran/intrinsic.c

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/41352] [4.5 Regression] Revision 151676 failed to bootstrap

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/15319] [x86] ICE in change_stack, at reg-stack.c:2299

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-09-20 20:52 ---
Uhm.  It's very hard to not crash on randomly broken inline-asm.


-- 


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

[Bug tree-optimization/41377] [4.5 Regression] gimple EH rewrite causes ICE with PPRE (enabled at -O3)

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-20 20:49 ---
This is a PPRE issue as turning off PRE fixes the issue and 
  do_partial_partial = optimize > 2;

changing that to 0 instead also does not expose the issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.5 Regression] Revision   |[4.5 Regression] gimple EH
   |151696 caused ICE in|rewrite causes ICE with PPRE
   |unsplit_eh  |(enabled at -O3)


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

[Bug target/15319] [x86] ICE in change_stack, at reg-stack.c:2299

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2009-09-20 20:42 
---
The code is invalid. But the compiler shouldn't crash on invalid code.
So this is an ice-on-invalid-code bug.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-09-20 20:39 ---
orig_op0 in c-common.c:
(gdb) p debug_tree(orig_op0)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x77ed8780 precision
64 min  max >
tree_1
arg 1 
constant
arg 0 
t.c:4:18>>

Hmm, actually I don't understand how c_maybe_const_expr are suposed to work.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug c/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-09-20 20:32 ---
op1 comes from the front-end which means this is most likely caused by the
constant expression patch.  Trying to figure out how to fix it ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |c


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

[Bug middle-end/41182] [4.5 Regression] ICE: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:5259

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-20 20:29 ---
6148  comp_const = fold_convert_loc (loc, TREE_TYPE (arg0), op1);

op1 is already not folded:
(gdb) p debug_tree(op1)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x77ed8780 precision
64 min  max >
constant
arg 0  constant 2>>
$5 = void


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


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

[Bug tree-optimization/40642] [4.5 regression] ICE with -fprofile-generate

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2009-09-20 20:28 
---
Btw, the bug disappeared between 2009-09-06 and 2009-09-11.


-- 


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

[Bug bootstrap/41401] Graphite branch broken after merge

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-20 20:22 ---
it just means that graphite doesn't properly deal with DEBUG_STMTs and thus
different code is generated with/without -g.


-- 


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

[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused

[pinskia at gcc dot gnu dot org]

--- Comment #33 from pinskia at gcc dot gnu dot org  2009-09-20 20:20 
---
*** Bug 28481 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||vda dot linux at googlemail
   ||dot com


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

[Bug target/28481] [4.3/4.4/4.5 Regression] uses memory where it can use registers

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2009-09-20 20:20 
---
(In reply to comment #10)
> Trunk does very unfunny things to this testcase as well.  -fno-tree-reassoc
> recovers the register allocation problems.
> 

Then this is a duplication of bug 27855.

*** This bug has been marked as a duplicate of 27855 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2009-09-20 20:12 ---
I am no longer working on this patch ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug c++/36912] [4.3/4.4/4.5 regression] ICE with "-frounding-math -g"

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2009-09-20 20:09 
---
t.cc:5:1: error: initializer for floating value is not a floating constant
t.cc:5:1: internal compiler error: tree check: expected real_cst, have
plus_expr in output_constant, at varasm.c:4545
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


The ICE is still there ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2008-08-13 20:48:09 |2009-09-20 20:09:14
   date||


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

[Bug tree-optimization/40642] [4.5 regression] ICE with -fprofile-generate

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-09-20 20:05 ---
Fixed, added a testcase also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/40642] [4.5 regression] ICE with -fprofile-generate

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-20 20:05 ---
Subject: Bug 40642

Author: pinskia
Date: Sun Sep 20 20:05:00 2009
New Revision: 151907

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151907
Log:
2009-09-20  Andrew Pinski  

PR middle-end/40642
* g++.dg/torture/pr40642.C: New testcase.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr40642.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/41401] Graphite branch broken after merge

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2009-09-20 19:52 ---
The patch svn://gcc.gnu.org/svn/gcc/tr...@151362 breaks bootstrap with graphite
enabled.

2009-09-03  Alexandre Oliva  

* toplev.c (process_options): Enable var-tracking-assignments
by default if var-tracking is enabled.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-20 19:52:48
   date||


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #10 from joel at gcc dot gnu dot org  2009-09-20 19:40 ---
Created an attachment (id=18619)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18619&action=view)
RTEMS Get_Page_Size should no longer return 0

With this patch only 1 ACATS failed.  Is it OK to commit?


-- 


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

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

[hjl dot tools at gmail dot com]

--- Comment #23 from hjl dot tools at gmail dot com  2009-09-20 19:37 
---
*** Bug 41417 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||m4rkusxxl at web dot de


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

[Bug c/41417] Segfault while build

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-09-20 19:37 ---


*** This bug has been marked as a duplicate of 41395 ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/41417] Segfault while build

[m4rkusxxl at web dot de]

--- Comment #2 from m4rkusxxl at web dot de  2009-09-20 19:18 ---
When I overwrite by global CFLAGS with just "-march=opteron" (without the
"-O2") it compiles fine.
Is optimization not supported or is it a bug?


-- 


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

[Bug c++/41421] [C++0x] Trivial types should require trivial default constructor.

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-09-20 19:11 
---
Jason, can you have a look to this issue? I believe submitter is right. Should
we use TYPE_HAS_TRIVIAL_DFLT instead? Note sure about
TYPE_HAS_TRIVIAL_INIT_REF, TYPE_HAS_TRIVIAL_ASSIGN_REF, and
TYPE_HAS_TRIVIAL_DESTRUCTOR. Humm, maybe just "reversing" the logic in
trivial_type_p is enough?!?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com, jason at gcc dot
   ||gnu dot org


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #42 from hjl dot tools at gmail dot com  2009-09-20 18:44 
---
(In reply to comment #39)
> The updated patch fixes align-counterexample1.c, but not
> align-counterexample2.c. Note that you must align the stack for all functions
> that have some SSE operations, because you never know if the registers will be
> spilled. The generated code is:
> 

Please try the new patch in comment #41.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #41 from hjl dot tools at gmail dot com  2009-09-20 18:44 
---
Created an attachment (id=18618)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18618&action=view)
An updated patch for gcc 4.4


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #18610|0   |1
is obsolete||


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #40 from hjl dot tools at gmail dot com  2009-09-20 18:43 
---
Created an attachment (id=18617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18617&action=view)
An updated patch for gcc trunk


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #18611|0   |1
is obsolete||


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

[Bug c++/41421] New: [C++0x] Trivial types should require trivial default constructor.

[cadaker at gmail dot com]

The C++0x standard draft defines a trivial type as one that has trivial default
construct, copy constructor, copy assignment operator and destructor. g++ from
the current trunk, however, classifies types without default constructor as
trivial, meaning that the following code does not compile:

#include 

struct Foo {
Foo(int) {}
};

static_assert(!std::is_trivial::value,
  "Not trivial - no (trivial) default constructor.");


This seems like a bug (unless I've misunderstood the draft or missed some
pending change to it).


-- 
   Summary: [C++0x] Trivial types should require trivial default
constructor.
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cadaker at gmail dot com


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

[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995

[howarth at nitro dot med dot uc dot edu]

--- Comment #40 from howarth at nitro dot med dot uc dot edu  2009-09-20 
18:27 ---
Is this the location of the additional epilogue notes being added in r147995?

@@ -8637,7 +8757,17 @@
  + frame.nregs * UNITS_PER_WORD
 + frame.nsseregs * 16
 + frame.padding0));
- emit_insn (gen_rtx_SET (VOIDmode, stack_pointer_rtx, tmp));
+ tmp = emit_insn (gen_rtx_SET (VOIDmode, stack_pointer_rtx, tmp));
+
+ gcc_assert (ix86_cfa_state->reg == stack_pointer_rtx);
+ if (ix86_cfa_state->offset != UNITS_PER_WORD)
+   {
+ ix86_cfa_state->offset = UNITS_PER_WORD;
+ add_reg_note (tmp, REG_CFA_DEF_CFA,
+   plus_constant (stack_pointer_rtx,
+  UNITS_PER_WORD));
+ RTX_FRAME_RELATED_P (tmp) = 1;
+   }
}
}
   else if (!frame_pointer_needed)

If so, we can't just apply an "ifndef __APPLE__/#endif" wrapper appropriately
there to suppress the addition of the epilog note? The question remains if the
new unwinder
will tolerate missing them. Remember that on darwin >= 10, libgcc is subsumed
into
libSystem and the libgcc built by FSF gcc is never actually used. So we have to
be
careful to not break darwin9 and earlier when suppressing the epilog notes for
darwin10.


-- 


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

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #22 from hjl at gcc dot gnu dot org  2009-09-20 18:00 ---
Subject: Bug 41395

Author: hjl
Date: Sun Sep 20 17:59:44 2009
New Revision: 151905

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151905
Log:
2009-09-20  H.J. Lu  

PR middle-end/41395
* opts.c (decode_options): Don't turn on flag_ipa_sra for opt2.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c


-- 


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

[Bug c++/41420] Command-line defines(-D) are not working with include(-I)

[smal dot root at gmail dot com]

--- Comment #2 from smal dot root at gmail dot com  2009-09-20 17:30 ---
I correct clock, restart Xorg and everything work... Its good. Sorry


-- 

smal dot root at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/40364] ICE in in purge_dead_edges, at cfgrtl.c:2325 compiling MAME

[ktietz at gcc dot gnu dot org]

--- Comment #5 from ktietz at gcc dot gnu dot org  2009-09-20 17:26 ---
I tested your attachment against patched trunk and fix of PR/39886 resolved it.
So I mark it as duplicate.

*** This bug has been marked as a duplicate of 39886 ***


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/39886] [4.5 Regression] Revision 145283 caused ICE in purge_dead_edges, at cfgrtl.c:2274

[ktietz at gcc dot gnu dot org]

--- Comment #10 from ktietz at gcc dot gnu dot org  2009-09-20 17:26 ---
*** Bug 40364 has been marked as a duplicate of this bug. ***


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dopefishjustin at gmail dot
   ||com


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #9 from joel at gcc dot gnu dot org  2009-09-20 17:12 ---
Thanks for the quick response.  I am in the process of adding getpagesize() to
RTEMS.  We already had sysconf(_SC_PAGESIZE) and returned 4096.  I will change
the s-osinte-rtems.ad* to use that and post a patch when it is tested.


-- 


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

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-20 17:09 
---
Yes that's ok.  What is not ok is to compare addresses of labels and to rely
on different labels having different addresses.


-- 


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

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[jvdelisle at verizon dot net]

--- Comment #11 from jvdelisle at verizon dot net  2009-09-20 17:04 ---
Subject: Re:  [4.3/4.4/4.5 Regression] miscompilation of
 goto/label using code

rguenth at gcc dot gnu dot org wrote:
> but instead it should have used a computed goto, like
> 
>   C.0 = { &__label_001262, &__label_001263, &__label_001264 };
>   goto *C.0[i - 1262];
> 
> for assigned goto.
> 
> Thus, this is a frontend issue with assigned goto (a deleted feature btw).
> 

I was confused by the parenthetical statement.

Is this:

C.0 = { &__label_001262, &__label_001263, &__label_001264 };
goto *C.0[i - 1262];

OK to use or not?  Computed goto in Fortran is a legacy feature we must
support.


-- 


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

[Bug libfortran/41387] OPEN, STATUS='NEW' of a symbolic link to a non-existing file fails.

[toon at moene dot org]

--- Comment #6 from toon at moene dot org  2009-09-20 17:03 ---
It seems we have exhausted the arguments in this case.

The best cause of action seems to be to document that gfortran won't allow to
open dangling symlinks with STATUS='NEW'.

This bug report remains open until that is done.


-- 

toon at moene dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |toon at moene dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-20 17:03:39
   date||


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #17 from howarth at nitro dot med dot uc dot edu  2009-09-20 
17:02 ---
(In reply to comment #16)
> As specified they should ignore dwarf codes they do not understand, not assert
> on them.  Please if you care report this issue to apple (it's probably enough
> to send them along a file that crashes their tool).
> 
There still is an oddity here. I can trigger this problem in current gcc trunk
with a conftest.c but not with a conftest.i (comment 6). This suggest it might
be difficult to construct a standalone testcase since the assembly files
created from both methods are identical (but only the first case results in an
asset...weird).


-- 


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[laurent at guerby dot net]

--- Comment #8 from laurent at guerby dot net  2009-09-20 16:59 ---
Given s-taprop-posix code it's obvious that Page_Size cannot be zero:

  --  Round stack size as this is required by some OSes (Darwin)

  Adjusted_Stack_Size := Adjusted_Stack_Size + Page_Size - 1;
  Adjusted_Stack_Size :=
Adjusted_Stack_Size - Adjusted_Stack_Size mod Page_Size;


-- 


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[charlet at gcc dot gnu dot org]

--- Comment #7 from charlet at gcc dot gnu dot org  2009-09-20 16:58 ---
Get_Page_Size should indeed now not be a dummy value and cannot be 0.
I'll take care of updating the comments in s-osinte*.ads when I get a chance


-- 


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #6 from joel at gcc dot gnu dot org  2009-09-20 16:46 ---
Every s-osinte*.ads which has Get_Page_Size includes a comment about 0 being
valid to return and indicate that Page_Size does not matter.

   --  Returns the size of a page, or 0 if this is not relevant on this target

Either every OS's interface has a wrong claim in its comments or someone
violated this assumption.

Before I paper over this on RTEMS, I would appreciate someone making a comment
on the general requirements.  


-- 


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

[Bug c++/41420] Command-line defines(-D) are not working with include(-I)

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-20 16:41 ---
That is not the file you are compiling as it is not valid C++.  I bet on a
pilot error, something is included from that directory and undefining
SOME64 again.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #5 from joel at gcc dot gnu dot org  2009-09-20 16:40 ---
The LynxOS s-osinte-lynxos.ads has this:

   function Get_Page_Size return size_t;
   function Get_Page_Size return Address;
   pragma Import (C, Get_Page_Size, "getpagesize");
   --  Returns the size of a page, or 0 if this is not relevant on this
   --  target

I can't find any reference in the GNU/Linux man pages or at opengroup.org on 0
being allowed or not allowed.  But apparently whoever worked on that port
thought 0 was a valid thing to return also.

Doesn't matter much. RTEMS has PAGE_SIZE defined and the support for
sysconf(_SC_PAGESIZE) so I will just add a wrapper to that for the legacy 
getpagesize().


-- 


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

[Bug bootstrap/41386] incorrect configure results in "The following requested languages could not be built: lto"

[marcus at jet dot franken dot de]

--- Comment #3 from marcus at jet dot franken dot de  2009-09-20 16:39 
---
hmm, if I rerun: configure --enable-lto --enable-languages=c   it works

perhaps the auto reconfig logic was broken a bit


-- 

marcus at jet dot franken dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-09-20 16:36 
---
> As far as I understand the problem, I do not see why tools not designed to
> accept "dwarf_version 4" can be blamed for that (it would be like blaming the
> CD player in my car for not reading MP3 CDs).

But you would complain to them if it was eating your MP3 CDs, right? ;)

As specified they should ignore dwarf codes they do not understand, not assert
on them.  Please if you care report this issue to apple (it's probably enough
to send them along a file that crashes their tool).

Instead of reverting the patch we should add a -gstrict-dwarf[23] switch
that darwin can use by default instead.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-20 16:36:58
   date||


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2009-09-20 16:28 ---
from s-osinte-rtems.adb:

   function Get_Page_Size return size_t is
   begin
  return 0;
   end Get_Page_Size;

May be this value wasn't used before...


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #15 from howarth at nitro dot med dot uc dot edu  2009-09-20 
16:24 ---
You might want to change the Summary here to "[4.5 Regression] Bootstrap broken
by r151815 on *-apple-darwin9"


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[howarth at nitro dot med dot uc dot edu]

--- Comment #14 from howarth at nitro dot med dot uc dot edu  2009-09-20 
16:22 ---
Reverting r151815 also eliminates the bootstrap breakage on
x86_64-apple-darwin10. Nice catch.


-- 


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

[Bug middle-end/30447] Evaluate complex math functions at compile-time

[ghazi at gcc dot gnu dot org]

--- Comment #8 from ghazi at gcc dot gnu dot org  2009-09-20 16:21 ---
Current GCC mainline incorporates all the complex math functions included with
mpc-0.7.  All that's left are the complex "arc" functions which are expected in
a future MPC release, possibly mpc-0.8.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||40302
OtherBugsDependingO|40302   |
  nThis||
   Last reconfirmed|2009-04-11 15:55:05 |2009-09-20 16:21:55
   date||


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

[Bug c++/41420] New: Command-line defines(-D) are not working with include(-I)

[smal dot root at gmail dot com]

We have simple source file: file.64.cpp
int main()
{
#ifdef SOME64
printf("64\r\n");
#else
printf("32\r\n");
#endif
return 0;
}

So. If we build file with that command
$CC -DSOME64 -I../../common/src -O0 -g3 -Wall -c "systemcontroller.64.cpp"
then SOME64 are undefined in file(../../common/src is valid path).
if we erase include block(-I) or write invalid path like this
$CC -DSOME64 -I../../common/src_1 -O0 -g3 -Wall -c "systemcontroller.64.cpp"
than everithing work fine... i mean SOME64 are defined in file.

$CC can be g++, gcc, cc, c++.

os: Bluewhite64-current
gcc-config:
Reading specs from /usr/lib/gcc/x86_64-pc-linux/4.3.3/specs
Target: x86_64-pc-linux
Configured with: ../gcc-4.3.3/configure --prefix=/usr --libdir=/usr/lib
--enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose
--disable-multilib --target=x86_64-pc-linux --build=x86_64-pc-linux
--host=x86_64-pc-linux
Thread model: posix
gcc version 4.3.3 (GCC)


-- 
   Summary: Command-line defines(-D) are not working with include(-
I)
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smal dot root at gmail dot com
 GCC build triplet: x86_64
  GCC host triplet: x86_64
GCC target triplet: x86_64


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

[Bug middle-end/30789] complex folding inexact

[ghazi at gcc dot gnu dot org]

--- Comment #11 from ghazi at gcc dot gnu dot org  2009-09-20 16:08 ---
Fixed, but depends on hard-requiring MPC.


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||40302
 Status|ASSIGNED|RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2009-09-20 15:56 ---
The debug information is weak since optimization hides a lot.  But it looks
like Page_Size might be 0.


(gdb) c
Continuing.

,.,. A85013B ACATS 2.5 88-01-01 00:00:00
 A85013B CHECK THAT A SUBPROGRAM CAN BE RENAMED WITHIN ITS OWN BODY 
AND THAT THE NEW NAME CAN BE USED IN A RENAMING
DECLARATION.

Breakpoint 3, pthread_attr_init (attr=0x880b6c78) at
/users/joel/test-gcc/rtems/c/src/../../cpukit/posix/src/pthreadattrinit.c:28
28if ( !attr )
(gdb) s
31*attr = _POSIX_Threads_Default_attributes;
(gdb) 
32 return 0;
(gdb) 
system.task_primitives.operations.create_task (t=0x881a2e90,
wrapper=(system.address) 0x8800c7c8, stack_size=,
priority=122) at s-taprop.adb:967
967   if Result /= 0 then
Current language:  auto
The current source language is "auto; currently ada".
(gdb) p Result
$1 = 
(gdb) s
960   Adjusted_Stack_Size := Adjusted_Stack_Size + Page_Size - 1;
(gdb) p Adjusted_Stack_Size
$2 = 
(gdb) s
974   (Attributes'Access, PTHREAD_CREATE_DETACHED);
(gdb) s
pthread_attr_setdetachstate (attr=0x880b6c78, detachstate=0) at
/users/joel/test-gcc/rtems/c/src/../../cpukit/posix/src/pthreadattrsetdetachstate.c:26
26if ( !attr || !attr->is_initialized )
Current language:  auto
The current source language is "auto; currently c".
(gdb) s
29switch ( detachstate ) {
(gdb) 
32attr->detachstate = detachstate;
(gdb) 
33return 0;
(gdb) 
system.task_primitives.operations.create_task (t=0x881a2e90,
wrapper=(system.address) 0x8800c7c8, stack_size=,
priority=122) at s-taprop.adb:962
962 Adjusted_Stack_Size - Adjusted_Stack_Size mod Page_Size;
Current language:  auto
The current source language is "auto; currently ada".
(gdb) 


-- 


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

[Bug middle-end/30789] complex folding inexact

[ghazi at gcc dot gnu dot org]

--- Comment #10 from ghazi at gcc dot gnu dot org  2009-09-20 15:39 ---
Subject: Bug 30789

Author: ghazi
Date: Sun Sep 20 15:39:22 2009
New Revision: 151904

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151904
Log:
PR middle-end/30789
* builtins.c (do_mpc_arg2): Accept DO_NONFINITE parameter.
(do_mpc_ckconv): Accept FORCE_CONVERT parameter.
(fold_builtin_2, do_mpc_arg1): Update accordingly.
* fold-const.c (const_binop): Likewise.
* real.h (do_mpc_arg2): Update prototype.

testsuite:
* gcc.dg/torture/builtin-math-7.c: Update for testing Annex G
cases in static initializers.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/fold-const.c
trunk/gcc/real.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/builtin-math-7.c


-- 


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

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

[dominiq at lps dot ens dot fr]

--- Comment #21 from dominiq at lps dot ens dot fr  2009-09-20 15:36 ---
In reply to comment #20
> bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
> gcc version 4.5.0 20090913 (experimental) (GCC)

You may try to revert revision 151815 (see pr41405, the patch is in
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html).


-- 


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-09-20 15:33 ---
Ada code in s-taprop-posix.adb

  Result := pthread_attr_init (Attributes'Access);
  pragma Assert (Result = 0 or else Result = ENOMEM);

  if Result /= 0 then
 Succeeded := False;
 return;
  end if;

Could you breakpoint on pthread_attr_init and see what's going on from there
(what is passed to and returned by RTEMS)? May be the "break 07" is just what
pragma Assert does.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #13 from dominiq at lps dot ens dot fr  2009-09-20 15:24 ---
The culprit is indeed r151815. Reverting the change after having updated to
r151893 on i686-apple-darwin9 ( r151895 on powerpc-apple-darwin9) allows a
successful bootstrap (currently building the libs on powerpc).

In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html the patch is
motivated by:

> I think the important question is whether older debuggers would be able
> to deal gracefully with these location entries or constant values.  I
> understand they're supposed to, and I have no evidence that GDB isn't, so
> I offer this patch to revert the last-minute addition of tests for
> dwarf_version >= 4 in the VTA merge patch.
> 
> Should I check it in so that we can get a better idea of what, if
> anything, breaks?

Apparently the changes affect more than GDB. So now that you have "get a better
idea of what, if anything, breaks" it seems appropriate to revert them.

> Yes, probably the apple tools barf on the new dwarf opcodes.  Please report 
> the
> issue to them.  

As far as I understand the problem, I do not see why tools not designed to
accept "dwarf_version 4" can be blamed for that (it would be like blaming the
CD player in my car for not reading MP3 CDs).

> A GCC side fix would be to add an option to restrict dwarf to dwarf2 and turn 
> that option on by 
> default for darwin.

What is the difference with reverting the patch?


-- 


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

[Bug ada/41419] [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-09-20 15:20 ---
Should have included command line.  This is for arch=r3900.

mips-rtems4.10-gnatmake --RTS=. -fstack-check -v -O -gnatws -O2
-I/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/support
a85013b.adb -bargs -Mgnat_main -largs
-B/users/joel/test-gcc/install-svn/mips-rtems4.10/jmr3904/lib/ -specs bsp_specs
-qrtems -march=r3900 -Wa,-xgot -G0
/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/rtems_init.o


-- 


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

[Bug ada/41419] New: [450 regression] many new ACATs failures (breakpoint instruction in object)

[joel at gcc dot gnu dot org]

Starting program:
/users/joel/test-gcc/gcc-svn/gcc/testsuite/ada/acats/work-jmr3904/tests/a/a85013b/a85013b
 

,.,. A85013B ACATS 2.5 88-01-01 00:00:00
 A85013B CHECK THAT A SUBPROGRAM CAN BE RENAMED WITHIN ITS OWN BODY 
AND THAT THE NEW NAME CAN BE USED IN A RENAMING
DECLARATION.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x88004be8 in system.task_primitives.operations.create_task (t=0x881a2e90, 
wrapper=(system.address) 0x8800c7c8, stack_size=, 
priority=122) at s-taprop.adb:962
962 Adjusted_Stack_Size - Adjusted_Stack_Size mod Page_Size;
Current language:  auto
The current source language is "auto; currently ada".
(gdb) bt
#0  0x88004be8 in system.task_primitives.operations.create_task (t=0x881a2e90, 
wrapper=(system.address) 0x8800c7c8, stack_size=, 
priority=122) at s-taprop.adb:962
#1  0x8800bbe0 in system.tasking.stages.activate_tasks (
chain_access=) at s-tassta.adb:291
#2  0x8800390c in _ada_a85013b ()
(gdb) 

When I disassemble at 0x88004be8, I see this:

0x88004be0 :  bnez   
s4,0x88004bec 
0x88004be4 :  divu   
zero,s5,s4
0x88004be8 :  break  
0x7

To confirm this was actually in the program executable, I objdump'ed it.
88004be0:   1682bnezs4,88004bec

88004be4:   02b4001bdivuzero,s5,s4
88004be8:   0007000dbreak   0x7


-- 
   Summary: [450 regression] many new ACATs failures (breakpoint
instruction in object)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: mips-rtems4.10


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

[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran

[davek at gcc dot gnu dot org]

--- Comment #2 from davek at gcc dot gnu dot org  2009-09-20 14:59 ---
Perhaps the two single most salient points from that diff:

 # Is the compiler the GNU compiler?
-with_gcc=no
+with_gcc=yes

 # Whether we are building with GNU ld or not.
-with_gnu_ld="no"
+with_gnu_ld="yes"

Did not having fortran in the mix maybe cause some basic tests of the build
tools/environment to be omitted?


-- 


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

[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran

[davek at gcc dot gnu dot org]

--- Comment #1 from davek at gcc dot gnu dot org  2009-09-20 14:57 ---
Created an attachment (id=18616)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18616&action=view)
diffs in generated libtool files

This looks like it might be informative.


-- 


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

[Bug c/41417] Segfault while build

[m4rkusxxl at web dot de]

--- Comment #1 from m4rkusxxl at web dot de  2009-09-20 14:44 ---
Created an attachment (id=18615)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18615&action=view)
The file created with the xgcc and -save-temps


-- 


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

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-20 14:44 
---
No, the C code is valid, but it's results depend on optimization level
(just like if you would compare the addresses of stack locals).


-- 


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

[Bug libgomp/41418] New: Can't build libgomp without --enable-languages=fortran

[davek at gcc dot gnu dot org]

[ ref: http://gcc.gnu.org/ml/gcc/2009-08/msg00085.html ]

> libtool: link: /opt/gcc-tools/i686-pc-cygwin/bin/ar rc .libs/libgomp.lib  
> alloc.
> o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o 
> ordered
> .o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o 
> sem
> .o bar.o ptrlock.o time.o fortran.o affinity.o
> /opt/gcc-tools/i686-pc-cygwin/bin/ar: .libs/libgomp.lib: File format not 
> recogni
> zed
> make[4]: *** [libgomp.la] Error 1
> 
> $ file i686-pc-cygwin/libgomp/.libs/libgomp.lib
> i686-pc-cygwin/libgomp/.libs/libgomp.lib: symbolic link to `libgomp-1.dll'

  There's one immediately obvious difference in the generated makefiles between
a bad and a good build:

> -#nodist_finclude_HEADERS = omp_lib.h omp_lib.f90 omp_lib.mod 
> omp_lib_kinds.mod
> +nodist_finclude_HEADERS = omp_lib.h omp_lib.f90 omp_lib.mod omp_lib_kinds.mod

  The good file has the nodist_finclude_HEADERS defined (makes sense), this
adds extra dependencies in the build, and because these files are generated by
running config.status I wonder if there's some kind of either parallel build
missing dependency problem or just a consequence of invoking config.status at a
different time during the build sequence.

  In connection with that, I found an interesting difference when comparing two
config.log files (both from successful builds, as it happens):

@@ -1498,3 +1500,21 @@ toolexeclibdir='$(toolexecdir)/$(gcc_ver
 #define HAVE_SYNC_BUILTINS 1

 configure: exit 0
+
+## -- ##
+## Running config.status. ##
+## -- ##
+
+This file was extended by GNU OpenMP Runtime Library config.status 1.0, which
w
as
+generated by GNU Autoconf 2.64.  Invocation command line was
+
+  CONFIG_FILES=
+  CONFIG_HEADERS  =
+  CONFIG_LINKS=
+  CONFIG_COMMANDS =
+  $ ./config.status Makefile depfiles
+
+on ubik
+
+config.status:1233: creating Makefile
+config.status:1446: executing depfiles commands

  This also makes me think that there's some uncertainty in exactly how and
where config.status is getting run.


-- 
   Summary: Can't build libgomp without --enable-languages=fortran
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c/41417] New: Segfault while build

[m4rkusxxl at web dot de]

I tried to build the current gcc-4.5.0 svn (rev. 151902)
It now failes for a few days with a segfault.

It happends if the ./gcc/xgcc is used, the broken down command is now:
LC_ALL=C gcc/xgcc -Bgcc -g -O2 -c gcc/libgcc2.i
./gcc/libgcc2.c: In function '__powixf2':
./gcc/libgcc2.c:1739:1: internal compiler error: Segmentation fault

Removing any other parameters will not trigger the segfault.
The normal CFLAGS are "-march=opteron -O2".
The gcc used to compile is a 4.3.2.


-- 
   Summary: Segfault while build
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m4rkusxxl at web dot de


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

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[jv244 at cam dot ac dot uk]

--- Comment #9 from jv244 at cam dot ac dot uk  2009-09-20 14:18 ---
(In reply to comment #8)
> Thus, this is a frontend issue with assigned goto (a deleted feature btw).

so just for my curiosity, is the C code thus invalid?


-- 


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

[Bug fortran/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-20 14:05 ---
On the tree level we end up with the correct (but unfortunately unfolded)

main ()
{
  int icon01;

:
  if (&label_001263 == &label_001262)
goto  (label_001265);
  else
goto  (label_001262);

label_001262:
  if (&label_001263 == &label_001263)
goto  (label_001265);
  else
goto  (label_001263);

label_001263:

  # icon01_1 = PHI <1262(4), 1263(3), 1262(2)>
label_001265:

label_001271:
  if (icon01_1 != 1263)
goto ;
  else
goto ;

:
  abort ();

:
  return 0;


Note that comparing addresses of labels is inherently fragile as they may
collapse to a single location (like it happens here):

main:
pushl   %ebp
movl%esp, %ebp
andl$-16, %esp
.L4:
.L3:
.L2:
.L5:
movl$.L3, %eax
cmpl$.L4, %eax
jne .L6
callabort
.L6:
movl$0, %eax
movl%ebp, %esp
popl%ebp
ret

forcing addresses of non-equivalent labels to compare non-equal would be
a way out here, but I think the Fortran frontend relies on a
fragile area of label address comparisons - labels are supposed to be
jumped to only.

That is, the Frontend presents us with

  i.0 = -2;
  ivfail = 0;
  i.0 = -1;
  i.1 = &__label_001263;
  if ((logical(kind=4)) __builtin_expect (i.0 != -1, 0))
{
  _gfortran_runtime_error_at (&"At line 3 of file t.f"[1]{lb: 1 sz: 1},
&"Assigned label is not a target label"[1]{lb: 1 sz: 1});
}
  if (i.1 == &__label_001262) goto __label_001262;
  if (i.1 == &__label_001263) goto __label_001263;
  if (i.1 == &__label_001264) goto __label_001264;
...

but instead it should have used a computed goto, like

  C.0 = { &__label_001262, &__label_001263, &__label_001264 };
  goto *C.0[i - 1262];

for assigned goto.

Thus, this is a frontend issue with assigned goto (a deleted feature btw).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |fortran


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

[Bug ada/41416] New: Conversion Float to fixed-point behaves differently for static expressions

[dirk dot herrmann-privat at gmx dot de]

Hi,

the following complete sample code shows different conversion behaviours
between fixed-point types and Float to fixed-point depending on whether the
expressions are static or not.  In the static case, GNAT uses a conversion
strategy comparable to truncation, otherwise rounding is used.

I assume that this difference in behaviour is unintended.

--- start ---
with Ada.Text_IO;
use Ada.Text_IO;

procedure Conversion is

   type FpA is delta 0.5 range -10.0 .. +10.0;
   for FpA'Small use 0.5;
   type FpB is delta 0.4 range -10.0 .. +10.0;
   for FpB'Small use 0.4;

   function MakeB(F: in Float) return FpB is
   begin
  return FpB(F);
   end MakeB;

   function MakeBFromA(F: in FpA) return FpB is
   begin
  return FpB(F);
   end MakeBFromA;

   function MakeBViaA(F: in Float) return FpB is
   begin
  return FpB(FpA(F));
   end MakeBViaA;

   function Get_Minus_1_5 return Float is
   begin
  return -1.5;
   end Get_Minus_1_5;

begin

   Put_Line(FpA'Image(FpA(-1.5)));
   Put_Line(
  FpB'Image(FpB(-1.5)) & " "   --> -1.2  (truncation)
  & FpB'Image(FpB(Float(-1.5))) & " "  --> -1.2  (truncation)
  & FpB'Image(FpB(Get_Minus_1_5)) & " "--> -1.6  (rounding)
  & FpB'Image(MakeB(-1.5)));   --> -1.6  (rounding)
   Put_Line(
  FpB'Image(FpB(FpA(-1.5))) & " "  --> -1.2  (truncation)
  & FpB'Image(FpB(FpA(Float(-1.5 & " " --> -1.2  (truncation)
  & FpB'Image(FpB(FpA'Succ(FpA(-2.0 & " "  --> -1.2  (truncation)
  & FpB'Image(FpB(FpA(Get_Minus_1_5))) & " "   --> -1.6  (rounding)
  & FpB'Image(MakeBFromA(FpA(-1.5))) & " " --> -1.6  (rounding)
  & FpB'Image(MakeBViaA(-1.5)));   --> -1.6  (rounding)

end Conversion;
 end 

The command line I am using for building:
> gnatmake -f -gnatVa -gnata -gnatwadhl.o -O3 -save-temps conversion.adb

The output from GNAT:
--- start ---
conversion.adb:35:17: warning: static fixed-point value is not a multiple of
Small
conversion.adb:36:19: warning: static fixed-point value is not a multiple of
Small
conversion.adb:40:17: warning: static fixed-point value is not a multiple of
Small
conversion.adb:41:19: warning: static fixed-point value is not a multiple of
Small
conversion.adb:42:19: warning: static fixed-point value is not a multiple of
Small
gnatbind -x conversion.ali
gnatlink conversion.ali
 end 

The version of GNAT I am using:
> gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-2'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --with-tune=generic --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-2)

Friendly regards,
Dirk Herrmann


-- 
   Summary: Conversion Float to fixed-point behaves differently for
static expressions
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dirk dot herrmann-privat at gmx dot de


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

[Bug middle-end/41403] [4.3/4.4/4.5 Regression] miscompilation of goto/label using code

[jv244 at cam dot ac dot uk]

--- Comment #7 from jv244 at cam dot ac dot uk  2009-09-20 13:18 ---
Not easy to find a machine that old, but it works with 3.3.3 and it fails
already with 4.1.2. Pretty old regression thus [tested with the C code].


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Known to fail|4.3.1 4.4.2 4.5.0   |4.1.2 4.3.1 4.4.2 4.5.0
  Known to work||3.3.3
Summary|miscompilation of goto/label|[4.3/4.4/4.5 Regression]
   |using code  |miscompilation of goto/label
   ||using code
   Target Milestone|--- |4.3.5


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

[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap

[jsg at openbsd dot org]

--- Comment #20 from jsg at openbsd dot org  2009-09-20 13:14 ---
bootstrap also fails on OpenBSD/i386 when it used to work a week ago ie:
gcc version 4.5.0 20090913 (experimental) (GCC)

When stage1 is building libgcc:

configure:3003: $? = 0
configure:2992: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown-openbsd4.6/bin/
-B/usr/gcc/i386-unknown-openbsd4.6/lib/ -isystem
/usr/gcc/i386-unknown-openbsd4.6/include -isystem
/usr/gcc/i386-unknown-openbsd4.6/sys-include-v >&5
Reading specs from /usr/users/jsg/src/obj/./gcc/specs
Target: i386-unknown-openbsd4.6
Configured with: ../gcc/configure --prefix=/usr/gcc/ --enable-languages=c
--program-transform-name='s,^,e,' --disable-nls --disable-checking --with-syst
em-zlib --disable-libmudflap --disable-libgomp --disable-tls
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-ld --with-gnu-as
--enable-threads=po
six --enable-cpp --with-gmp=/usr/local --with-mpfr=/usr/local --enable-shared
Thread model: posix
gcc version 4.5.0 20090920 (experimental) (GCC) 
configure:3003: $? = 0
configure:2992: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown-openbsd4.6/bin/
-B/usr/gcc/i386-unknown-openbsd4.6/lib/ -isystem
/usr/gcc/i386-unknown-openbsd4.6/include -isystem
/usr/gcc/i386-unknown-openbsd4.6/sys-include-V >&5
xgcc: '-V' must come at the start of the command line
configure:3003: $? = 1
configure:2992: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown-openbsd4.6/bin/
-B/usr/gcc/i386-unknown-openbsd4.6/lib/ -isystem
/usr/gcc/i386-unknown-openbsd4.6/include -isystem
/usr/gcc/i386-unknown-openbsd4.6/sys-include-qversion >&5
xgcc: unrecognized option '-qversion'
xgcc: no input files
configure:3003: $? = 1
configure:3019: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown-openbsd4.6/bin/
-B/usr/gcc/i386-unknown-openbsd4.6/lib/ -isystem
/usr/gcc/i386-unknown-openbsd4.6/include -isystem
/usr/gcc/i386-unknown-openbsd4.6/sys-include-o conftest -g -O2   conftest.c
 >&5
conftest.c:1:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
configure:3022: $? = 1
configure:3210: checking for suffix of object files
configure:3232: /usr/users/jsg/src/obj/./gcc/xgcc
-B/usr/users/jsg/src/obj/./gcc/ -B/usr/gcc/i386-unknown-openbsd4.6/bin/
-B/usr/gcc/i386-unknown-openbsd4.6/lib/ -isystem
/usr/gcc/i386-unknown-openbsd4.6/include -isystem
/usr/gcc/i386-unknown-openbsd4.6/sys-include-c -g -O2  conftest.c >&5
conftest.c:1:1: internal compiler error: Segmentation fault


-- 


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

[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P4
   Target Milestone|--- |4.4.2


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

[Bug pch/39420] Using pre-compiled headers results in a bus error

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-20 11:25 ---
Invalid according to comment #2


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/40364] ICE in in purge_dead_edges, at cfgrtl.c:2325 compiling MAME

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2009-09-20 11:24 ---
(In reply to comment #3)
> Will have to be tested again once PR 39886 is done with; hopefully, should 
> then
> be gone.
> 

As 39886 is fixed on trunk. Could you please verify if it was an duplicate of
39886?

Cheers,
Kai


-- 


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

[Bug pch/36273] Please add notyfication/warning when pch IS use

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug pch/33980] Precompiled header file not removed on error

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-20 11:22 ---
*** Bug 30702 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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