[Bug tree-optimization/41442] missed optimization for boolean expression

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2009-09-23 06:49 ---
Created an attachment (id=18634)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18634&action=view)
test case


-- 


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

[Bug tree-optimization/41442] New: missed optimization for boolean expression

[carrot at google dot com]

The boolean expression ((p1->next && !p2->next) || p2->next) can be simplified
as (p1->next || p2->next), but gcc failed to detect this.


The attached source code is an example, compile it with options -Os
-march=armv5te -mthumb, I got

push{lr}
ldr r3, [r0]
cmp r3, #0  
beq .L2 
ldr r3, [r1]// redundant load and comparison
mov r0, #0  
cmp r3, #0  //
beq .L3 // can branch to L3 directly
.L2:
ldr r0, [r1]
neg r3, r0
adc r0, r0, r3
.L3:
@ sp needed for prologue
pop {pc}


-- 
   Summary: missed optimization for boolean expression
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
 GCC build triplet: i686-linux
  GCC host triplet: i686-linux
GCC target triplet: arm-eabi


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

[Bug rtl-optimization/39779] ICE shifting byte to the right with constant > 7FFFFFFF

[uros at gcc dot gnu dot org]

--- Comment #12 from uros at gcc dot gnu dot org  2009-09-23 06:44 ---
Subject: Bug 39779

Author: uros
Date: Wed Sep 23 06:43:56 2009
New Revision: 152058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152058
Log:
PR c/39779
* c-typeck.c (build_binary_op) : Check that integer
constant is more than zero.

testsuite/ChangeLog:

PR c/39779
* gcc.c-torture/compile/pr39779.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr39779.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script

[rwild at gcc dot gnu dot org]

--- Comment #11 from rwild at gcc dot gnu dot org  2009-09-23 04:22 ---
patch at .


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[howarth at nitro dot med dot uc dot edu]

--- Comment #47 from howarth at nitro dot med dot uc dot edu  2009-09-23 
04:22 ---
The build failure appears to be at...

checking for _FILE_OFFSET_BITS value needed for large files... configure:
error: unsupported system, cannot find sizeof (omp_lock_t)
no

when passing BOOT_CFLAGS="-O2 -g -gstrict-dwarf" to make. Do we also need
CFLAGS_FOR_TARGET="-O2 -g -gstrict-dwarf" as well?


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[howarth at nitro dot med dot uc dot edu]

--- Comment #46 from howarth at nitro dot med dot uc dot edu  2009-09-23 
03:33 ---
Created an attachment (id=18633)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18633&action=view)
failed buildlog for x86_64-apple-darwin10

Failed build log from x86_64-apple-darwin10 when using...

make -j $num_cpu BOOT_CFLAGS="-O2 -g -gstrict-dwarf"

instead of patching common.opt to have Init(1) on gno-strict-dwarf (which
always builds completely).


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2009-09-23 
03:02 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first. 

Mike,
 Remember on llvm-dev Nick said...

On a SnowLeopard system you *can* link against /usr/lib/libgcc_s. 
10.5.dylib, but the linker will not record any symbols coming from  
it.  In fact, the link order does not matter.  That is because /usr/ 
lib/libgcc_s.10.5.dylib has magic symbols in it that say if you are  
targeting 10.6 then _Unwind_Resume  (and other other symbols) are not  
in that dylib, so the linker looks elsewhere and finds them in  
libSystem.B.dylib.  In other words, the compiler changes to  
SnowLeopard to omit /re-order the linking with -lgcc_s when targeting  
10.6 was just an optimization and not required.

Doesn't this imply that you can't make force libgcc to be found before
libSystem under SL?


-- 


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

[Bug c/41440] SEG FAULT in CSE.C caused by bad RTL expansion

[hutchinsonandy at gcc dot gnu dot org]

--- Comment #1 from hutchinsonandy at gcc dot gnu dot org  2009-09-23 02:49 
---
Created an attachment (id=18632)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18632&action=view)
Expanded RTL

Expanded RTL dump


-- 


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

[Bug c/41441] New: failure to warn about uninitialized induction var

[regehr at cs dot utah dot edu]

In foo() below, I'd expect gcc to emit a warning about use of i without
initialization, but this does not happen.

reg...@john-home:~$ current-gcc -O -Wall uninit.c -o uninit
reg...@john-home:~$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/regehr/z/tmp/gcc-r151949-install
--program-prefix=r151949- --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090921 (experimental) (GCC) 
reg...@john-home:~$ cat uninit.c

#include 

void foo (void) {
  int i;
  for (; i<10; i=11) {
  }
}

int main (void)
{
  foo();
  return 0;
}


-- 
   Summary: failure to warn about uninitialized induction var
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/41440] New: SEG FAULT in CSE.C caused by bad RTL expansion

[hutchinsonandy at gcc dot gnu dot org]

Segmentation fault occurs on test gcc.c-torture/execute/memcpy-1.c and many
other tests. 
I have created a reduced case that shows problem. This, dumps and backtrace are
attached.

The cause seem to be that cse assumes previous instruction is CC0 setter. The
expanded RTL show this is surprising not true. So CSE crashes with null rtx.
The problem occurs on memcpy() expansion.

The expansion of memcpy() uses RTL expander movemem which is a simple RTL do
loop. This indeed correctly has compare directly before test and jump (see
pattern attached). Yet when the RTL is expanded, part of the next block's "i=0"
is inserted after compare and before jump. The tree dump looks right.

The next block RTL loop is not right either, it is supposed to be checking
dst[i] != i  - but in reality is  dst[i] != 0.



Using built-in specs.
Target: avr
Configured with: ../../gccsvn/configure --prefix=/home/andy/local/avr
--target=avr --enable-languages=c,c++ --disable-nls --disable-libssp
--with-dwarf2 --enable-checking
Thread model: single
gcc version 4.5.0 20090922 (experimental) (GCC) 



#include 

#define MEMCPY_SIZE (100)

main ()
{
  unsigned i;
  unsigned char src[MEMCPY_SIZE];
  unsigned char dst[MEMCPY_SIZE];

  for (i = 0; i < MEMCPY_SIZE; i++)
  {
src[i] = (unsigned char) i;
dst[i] = 0;
  }

  (void) memcpy (dst, src, MEMCPY_SIZE);

  for (i = 0; i < MEMCPY_SIZE; i++)
if (dst[i] != (unsigned char) i)
  abort ();

  exit (0);
}


===
(gdb) run  -mmcu=atmega128 -Os -O2  -DSTACK_SIZE=1535 -fdump-rtl-all
-fdump-tree-all  memcpy-1.c 

Starting program: /home/andy/local/avr/bin/avr-cc1 -mmcu=atmega128 -Os -O2 
-DSTACK_SIZE=1535 -fdump-rtl-all -fdump-tree-all  memcpy-1.c
 main
memcpy-1.c: In function 'main':
memcpy-1.c:21:7: warning: incompatible implicit declaration of built-in
function 'abort'
memcpy-1.c:23:3: warning: incompatible implicit declaration of built-in
function 'exit'

Analyzing compilation unit
Performing interprocedural optimizations
  <>
 Assembling functions:
 main
Program received signal SIGSEGV, Segmentation fault.
equiv_constant (x=0x0) at ../../../gccsvn/gcc/cse.c:3809
3809  if (REG_P (x)
(gdb) where
#0  equiv_constant (x=0x0) at ../../../gccsvn/gcc/cse.c:3809
#1  0x085f16e3 in fold_rtx (x=0xb7de5c18, insn=0xb7d8ea28) at
../../../gccsvn/gcc/cse.c:3277
#2  0x085f16da in fold_rtx (x=0xb7de66a0, insn=0xb7d8ea28) at
../../../gccsvn/gcc/cse.c:3276
#3  0x085f5af6 in cse_insn (insn=0xb7d8ea28) at ../../../gccsvn/gcc/cse.c:4496
#4  0x085f8a45 in cse_main (f=0xb7de9ba0, nregs=167) at
../../../gccsvn/gcc/cse.c:6269
#5  0x085f93da in rest_of_handle_cse () at ../../../gccsvn/gcc/cse.c:7158
#6  0x0833f3b2 in execute_one_pass (pass=0x87a1fa0) at
../../../gccsvn/gcc/passes.c:1295
#7  0x0833f62c in execute_pass_list (pass=0x87a1fa0) at
../../../gccsvn/gcc/passes.c:1344
#8  0x0833f63f in execute_pass_list (pass=0x879f200) at
../../../gccsvn/gcc/passes.c:1345
#9  0x08410110 in tree_rest_of_compilation (fndecl=0xb7dbda80) at
../../../gccsvn/gcc/tree-optimize.c:389
#10 0x0857399a in cgraph_expand_function (node=0xb7d34900) at
../../../gccsvn/gcc/cgraphunit.c:1158
#11 0x085763e5 in cgraph_finalize_compilation_unit () at
../../../gccsvn/gcc/cgraphunit.c:1217
#12 0x080b694b in c_write_global_declarations () at
../../../gccsvn/gcc/c-decl.c:9361
#13 0x083b518a in toplev_main (argc=8, argv=0xbfabb114) at
../../../gccsvn/gcc/toplev.c:1050
#14 0x0813abf2 in main (argc=Cannot access memory at address 0x10
) at ../../../gccsvn/gcc/main.c:35
(gdb) up
#1  0x085f16e3 in fold_rtx (x=0xb7de5c18, insn=0xb7d8ea28) at
../../../gccsvn/gcc/cse.c:3277
3277const_arg = equiv_constant (folded_arg);
(gdb) print folded_arg
$4 = (rtx) 0x0
(gdb) pr insn
(nil)
(gdb) print insn
$5 = (rtx) 0xb7d8ea28
(gdb) pr insn
(jump_insn 138 111 151 5 memcpy-1.c:17 (set (pc)
(if_then_else (ne (cc0)
(const_int 0 [0x0]))
(label_ref 131)
(pc))) 110 {branch} (expr_list:REG_BR_PROB (const_int 9900
[0x26ac])
(nil))
 -> 131)
(gdb) print folded_arg
$6 = (rtx) 0x0
(gdb) list
3272break;
3273#endif
3274
3275  default:
3276folded_arg = fold_rtx (folded_arg, insn);
3277const_arg = equiv_constant (folded_arg);
3278break;
3279  }
3280
3281/* For the first three operands, see if the operand
(gdb) 

===
TREE DUMP - OPTIMIZED:

;; Function main (main)

main ()
{
  unsigned int src.33;
  unsigned int D.2132;
  unsigned char D.2128;
  unsigned char D.2130;
  unsigned int ivtmp.29;
  unsigned int ivtmp.24;
  unsigned char dst[100];
  unsigned char src[100];
  unsigned int i;
  unsigned char D.2091;
  unsigned char D.2090;

:
  ivtmp.24_23 = (unsigned int) &src[0];
  ivtmp.29_26 = (unsig

[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 #43 from howarth at nitro dot med dot uc dot edu  2009-09-23 
02:38 ---
Fixed as of r151961.Tested on x86_64-apple-darwin10.


-- 

howarth at nitro dot med dot uc dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[howarth at nitro dot med dot uc dot edu]

--- Comment #45 from howarth at nitro dot med dot uc dot edu  2009-09-23 
01:35 ---
Okay, using r152049 with...

--- gcc-4.5-20090922/gcc/common.opt.org 2009-09-22 20:58:14.0 -0400
+++ gcc-4.5-20090922/gcc/common.opt 2009-09-22 20:58:51.0 -0400
@@ -1473,7 +1473,7 @@
 Generate debug information in extended STABS format

 gno-strict-dwarf
-Common RejectNegative Var(dwarf_strict,0)
+Common RejectNegative Var(dwarf_strict,0) Init(1)
 Emit DWARF additions beyond selected version

 gstrict-dwarf

allows x86_64-apple-darwin10 to bootstrap without additional patches. We still
need some graceful way to enable this for darwin automatically. Passing
-gstrict-dwarf on BOOT_CFLAGS doesn't seem to survive through the entire build
process...at least in my attempts.


-- 


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

[Bug target/33431] [4.3/4.4/4.5 Regression] [SH4] performance regression between 3.4.6 and 4.x

[kkojima at gcc dot gnu dot org]

--- Comment #7 from kkojima at gcc dot gnu dot org  2009-09-23 00:39 ---
There has been no news for ~2 years and we have no reproducible
test case.  Probably it's due to the 7750's cache pointed out
in #5 by Andrew.  I'd like to close this PR.


-- 

kkojima at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists

[amodra at gcc dot gnu dot org]

--- Comment #4 from amodra at gcc dot gnu dot org  2009-09-23 00:23 ---
Subject: Bug 40473

Author: amodra
Date: Wed Sep 23 00:23:24 2009
New Revision: 152056

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152056
Log:
PR target/40473
* config/rs6000/rs6000.c (rs6000_output_function_prologue): Don't
call final to emit non-scheduled prologue, instead insert at entry.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c


-- 


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

[Bug bootstrap/41436] [4.5 regression] Revision option 152018 caused `param_is' may only be applied to structures or structure pointers

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-09-23 00:11 ---
It is caused by revision 152018:

http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00767.html

I also saw on Linux/ia32, but not Linux/x86-64.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i386-pc-solaris2.10 |
   GCC host triplet|i386-pc-solaris2.10 |
 GCC target triplet|i386-pc-solaris2.10 |i386
   Last reconfirmed|-00-00 00:00:00 |2009-09-23 00:11:09
   date||
Summary|[4.5 regression] option |[4.5 regression] Revision
   |`param_is' may only be  |option 152018 caused
   |applied to structures or|`param_is' may only be
   |structure pointers  |applied to structures or
   ||structure pointers


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[howarth at nitro dot med dot uc dot edu]

--- Comment #44 from howarth at nitro dot med dot uc dot edu  2009-09-23 
00:11 ---
Is there a trick to getting BOOT_CFLAGS set from gcc/config/t-darwin? Simply
adding...

BOOT_CFLAGS = -gdwarf-3 -gstrict-dwarf -O2

doesn't work. it always is left as -O2 -g during the build.


-- 


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

[Bug target/41365] [4.5 Regression] gcc.dg/vect/vect-cond-[123].c abort due to bad code generation at -O1 and above

[sje at cup dot hp dot com]

-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |sje at cup dot hp dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-22 23:13:08
   date||


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

[Bug target/41302] Cast of return value from uint32 to pointer cannot be optimized by a jump to called rtn.

[dferbas at etech dot cz]

--- Comment #2 from dferbas at etech dot cz  2009-09-22 22:39 ---
We tried to modify the m68k variant of sibcall fn. But we have a problem with
compilation. Is there anyone who can test if following is OK ?

/* Implement TARGET_FUNCTION_OK_FOR_SIBCALL_P.  We cannot use sibcalls
   for nested functions because we use the static chain register for
   indirect calls.  */


static bool
m68k_ok_for_sibcall_p (tree decl, tree exp)
{
  tree func;
  rtx a, b;

  enum m68k_function_kind kind;


  if (TREE_OPERAND (exp, 2))
return false;


  /* --- incorporated from x386 ---
   * This addresses issue when 1 fn returns a pointer in an address  
register
   * it is casted and the other fn returns a value in data register. */
  if (decl)
func = decl;
  else
{
  func = TREE_TYPE (TREE_OPERAND (exp, 0));
  if (POINTER_TYPE_P (func))
func = TREE_TYPE (func);
}

  /* Check that the return value locations are the same.  Like
 if we are returning floats on the 80387 register stack, we cannot
 make a sibcall from a function that doesn't return a float to a
 function that does or, conversely, from a function that does return
 a float to a function that doesn't; the necessary stack adjustment
 would not be executed.  This is also the place we notice
 differences in the return value ABI.  Note that it is ok for one
 of the functions to have void return type as long as the return
 value of the other is passed in a register.  */
  a = m68k_function_value (TREE_TYPE (exp), func);
  b = m68k_function_value (TREE_TYPE (DECL_RESULT (current_function_decl)),
   current_function_decl);


  if (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl
  ;
  else if (!rtx_equal_p (a, b))
return false;   
  /* --- */


  kind = m68k_get_function_kind (current_function_decl);
  if (kind == m68k_fk_normal_function)
/* We can always sibcall from a normal function, because it's
   undefined if it is calling an interrupt function.  */
return true;


  /* Otherwise we can only sibcall if the function kind is known to be
 the same.  */
  if (decl && m68k_get_function_kind (decl) == kind)
return true;


  return false;
}


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[developer at sandoe-acoustics dot co dot uk]

--- Comment #43 from developer at sandoe-acoustics dot co dot uk  
2009-09-22 21:42 ---
(In reply to comment #42)
> Are you building with --enable-build-with-cxx or something similar?
> libstdc++-v3 isn't normally compared.  The difference you are seeing is likely
> related to different random seed, you'd need to pass the same
> -frandom-seed= in both stage2 and stage3 builds...

--enable-stage1-languages=c,c++
AFAIK this is now necessary when building in-tree GMP/MPFR .
If that requirement has been lifted.. then this problem will evaporate (or I
can take a diff. approach to building GMP/MPFR).


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[jakub at gcc dot gnu dot org]

--- Comment #42 from jakub at gcc dot gnu dot org  2009-09-22 21:34 ---
Are you building with --enable-build-with-cxx or something similar?
libstdc++-v3 isn't normally compared.  The difference you are seeing is likely
related to different random seed, you'd need to pass the same
-frandom-seed= in both stage2 and stage3 builds...


-- 


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

[Bug debug/41439] New: choose DW_OP_stack_value over DW_OP_implicit_value more often, please

[roland at redhat dot com]

The comment in address_of_int_loc_descriptor doesn't make a lot of sense to me.
 In any case of a value no larger than address size, you can use
DW_OP_stack_value to get the same size or smaller.  When the size is the same,
such as DW_OP_implicit_value(address-sized block) vs
DW_OP_addr(address-consant) DW_OP_stack_value (both address-size + 2 bytes), I
think DW_OP_stack_value is preferable because consumers do not have to involve
overly-general variable-sized-stuff-with-relocs logic that the general case of
constant blocks involves.  There is no need for a DW_OP_{bit_,}piece in these
cases when the expressed value is in the low bits of the value computed on the
stack.


-- 
   Summary: choose DW_OP_stack_value over DW_OP_implicit_value more
often, please
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roland at redhat dot com


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

--- Comment #8 from mrs at apple dot com  2009-09-22 21:17 ---
I meant the idea that libSystem has new symbols in it is relevant only to
darwin10.  The system libgcc_s is present on older OSes, so those aspects are
still relevant.  Yeah, to solve that problem one would either have to have a
new name, or possibly an explicit path.  I've not tried the later, but it might
offer a way to construct the library with fewer mods.

from darwin10:
$ nm /usr/lib/libgcc_s.1.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace
$ nm /usr/lib/libSystem.dylib | grep Unwind_Bac
0019f9c6 S $ld$hide$os10.4$__Unwind_Backtrace
0019f9c7 S $ld$hide$os10.5$__Unwind_Backtrace
00163b30 T __Unwind_Backtrace

also note, there is add as well as hide;

$ nm /usr/lib/libgcc_s.10.5.dylib | grep Unwind_Back
0f0a S $ld$add$os10.4$__Unwind_Backtrace
0f0b S $ld$add$os10.5$__Unwind_Backtrace

As for what functions (symbols), well, the ones in common between
libSystem/libgcc_s on the system and libgcc from gcc.


-- 


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

[Bug debug/41438] New: [4.5 Regression] VTA: libgomp build fails due to inconsistent debug info

[sje at cup dot hp dot com]

If I compile the included two C files on IA64 HP-UX and then link them into
a shared library using the HP linker I get an error from the HP linker.

$ gcc -mlp64 -shared -fPIC -O2 -g x.c y.c
ld: Non TP-relative relocation for the thread local storage symbol
"gomp_tls_data"
1 errors.
collect2: ld returned 1 exit status

While I do not get this error on IA64 Linux the compiler does generate the same
debug information as on HP-UX, the linker just doesn't complain.

If I look at the generated assembly code for x.c and y.c the .debug_info
section of x.c contains:

data8.uagomp_tls_data#+8

while the .debug_info section of y.c contains:

data8.ua@dtprel(gomp_tls_data#)

If I change x.s by hand to use dtprel then the HP linker does not complain.

Here are the two C files, x.c and y.c:

 x.c =

struct gomp_team_state { };
struct gomp_thread
{
  void (*fn) (void *data);
  struct gomp_team_state ts;
};
extern __thread struct gomp_thread gomp_tls_data;
inline struct gomp_thread *gomp_thread (void)
{
  return &gomp_tls_data;
}
GOMP_parallel_end (void)
{
  struct gomp_team_state *ts = &gomp_thread ()->ts;
}

== y.c ===

struct gomp_team_state { };
struct gomp_thread
{
  void (*fn) (void *data);
  struct gomp_team_state ts;
};

__thread struct gomp_thread gomp_tls_data;


-- 
   Summary: [4.5 Regression] VTA: libgomp build fails due to
inconsistent debug info
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: aoliva at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
 GCC build triplet: ia64-hp-hpux11.23
  GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[dominiq at lps dot ens dot fr]

--- Comment #41 from dominiq at lps dot ens dot fr  2009-09-22 21:00 ---
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison failure!
> i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs
> i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs
> i686-apple-darwin9/libstdc++-v3/src/future.o differs
> i686-apple-darwin9/libstdc++-v3/src/system_error.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs
> make[2]: *** [compare] Error 1

This seems weird: AFAIK libstdc++-v3 is not built at stage 2. So what is
compared to what?


-- 


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

[Bug debug/41097] Inlined variable debug location disappears when ptr type

[aoliva at gcc dot gnu dot org]

--- Comment #5 from aoliva at gcc dot gnu dot org  2009-09-22 20:56 ---
... which means the bug is fixed.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/41097] Inlined variable debug location disappears when ptr type

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2009-09-22 20:53 ---
Jan Hubicka fixed this in revision 151917.


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[howarth at nitro dot med dot uc dot edu]

--- Comment #40 from howarth at nitro dot med dot uc dot edu  2009-09-22 
20:47 ---
Iain, that is odd. I had no problems last night at r151946
on x86_64-apple-darwin10. Why don't you try r151946 with 
Jakub's patch applied from...

http://gcc.gnu.org/viewcvs?view=revision&revision=151978

to see if the breakage still exists.


-- 


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

[Bug debug/41266] Emit DW_TAG_template_parameter_pack and DW_TAG_formal_parameter_pack

[dodji at gcc dot gnu dot org]

--- Comment #3 from dodji at gcc dot gnu dot org  2009-09-22 20:37 ---
Committed to 4.5


-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/41266] Emit DW_TAG_template_parameter_pack and DW_TAG_formal_parameter_pack

[dodji at gcc dot gnu dot org]

--- Comment #2 from dodji at gcc dot gnu dot org  2009-09-22 20:20 ---
Subject: Bug 41266

Author: dodji
Date: Tue Sep 22 20:20:03 2009
New Revision: 152043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152043
Log:
Fix for PR debug/41266

ChangeLog:

* include/dwarf2.h (enum dwarf_tag): Add
DW_TAG_template_parameter_pack and DW_TAG_formal_parameter_pack.

gcc/ChangeLog:

* dwarf2out.c (template_parameter_pack_die,
gen_formal_parameter_pack_die ): New functions.
(make_ith_pack_parameter_name): Remove this function.
(dwarf_tag_name): Support printing DW_TAG_template_parameter_pack and
DW_TAG_formal_parameter_pack.
(gen_generic_params_dies): Represent each template parameter pack
by a DW_TAG_template_parameter_pack DIE. Argument pack elements are
represented by usual DW_TAG_template_*_parameter DIEs that are
children of the DW_TAG_template_parameter_pack element DIE.
(generic_parameter_die): This doesn't deal with parameter pack
names anymore. Don't generate DW_AT_name for some DIEs, e.g. children
of
parameter pack DIEs.
(gen_formal_parameter_die): Add a flag to not emit DW_AT_name
in certain cases, e.g. for pack elements.
(gen_formal_types_die, gen_decl_die): Adjust usage of
gen_formal_parameter_die.
(gen_subprogram_die): Represent each function parameter pack by a
DW_TAG_formal_parameter_pack DIE. Arguments of of the pack are
represented by usual DW_TAG_formal_parameter DIEs that are children
of the DW_TAG_formal_parameter_pack DIE. Remove references to
builtin_va_alist decls as no part of the compiler uses those
anymore.
* langhooks.h (struct lang_hooks_for_decls): Add
function_parm_expanded_from_pack_p, get_generic_function_decl
and function_parameter_pack_p hooks.  Fix comment for
get_innermost_generic_parms hook.
* langhooks-def.h (LANG_HOOKS_FUNCTION_PARAMETER_PACK_P,
LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P ): Declare new hook
macros and use them to initialize lang_hook.

gcc/cp/ChangeLog:

* cp-lang.c (LANG_HOOKS_FUNCTION_PARAMETER_PACK_P,
LANG_HOOKS_FUNCTION_PARM_EXPANDED_FROM_PACK_P,
LANG_HOOKS_GET_GENERIC_FUNCTION_DECL): Initialize these
hooks for the c++ FE.
* cp-tree.h (function_parameter_pack_p, get_function_template_decl,
function_parameter_expanded_from_pack_p): Declare ...
* pt.c (function_parameter_pack_p, get_function_template_decl,
function_parameter_expanded_from_pack_p): ... new hooks.
(get_template_info): Make this more robust.
(template_args_variadic_p, make_ith_pack_parameter_name): Add a new
line between comment and function.
(get_template_argument_pack_elems): Fix comment.
(tsubst_decl): Arguments of function parameter packs are not
parameter packs themselves.

gcc/testsuite/ChangeLog:
* g++.dg/debug/dwarf2/template-func-params-4.C: Adjust.
* g++.dg/debug/dwarf2/template-func-params-7.C: Likewise.
* g++.dg/debug/dwarf2/template-params-4.C: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-lang.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/dwarf2out.c
trunk/gcc/langhooks-def.h
trunk/gcc/langhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-4.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-func-params-7.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/template-params-4.C
trunk/include/ChangeLog
trunk/include/dwarf2.h


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[developer at sandoe-acoustics dot co dot uk]

--- Comment #39 from developer at sandoe-acoustics dot co dot uk  
2009-09-22 20:17 ---
object differences currently causing bootstrap fail - these look unrelated to
the original bug:
.. anyone throw any light on this?

stripped future.o from stage 2
07e0  63 5f 5f 5f 76 33 5f 73  72 63 5f 66 75 74 75 72  |c___v3_src_futur|
07f0  65 2e 63 63 5f 30 30 30  30 30 30 30 30 5f 34 37  |e.cc__47|
0800  44 39 32 31 34 32 32 31  66 75 74 75 72 65 5f 65  |D9214221future_e|
0810  72 72 6f 72 5f 63 61 74  65 67 6f 72 79 45 00 00  |rror_categoryE..|

stripped future.o from stage 3
07e0  63 5f 5f 5f 76 33 5f 73  72 63 5f 66 75 74 75 72  |c___v3_src_futur|
07f0  65 2e 63 63 5f 30 30 30  30 30 30 30 30 5f 45 35  |e.cc__E5|
0800  45 38 41 43 44 37 32 31  66 75 74 75 72 65 5f 65  |E8ACD721future_e|
0810  72 72 6f 72 5f 63 61 74  65 67 6f 72 79 45 00 00  |rror_categoryE..|

===

stripped system_error.o from stage 2
07a0  30 30 30 5f 37 37 34 44  41 30 30 45 32 32 67 65  |000_774DA00E22ge|
07b0  6e 65 72 69 63 5f 65 72  72 6f 72 5f 63 61 74 65  |neric_error_cate|
07c0  67 6f 72 79 45 00 00 00  00 00 00 00 00 00 00 00  |goryE...|
07d0  4e 38 39 5f 47 4c 4f 42  41 4c 5f 5f 4e 5f 2e 2e  |N89_GLOBAL__N_..|
07e0  5f 2e 2e 5f 2e 2e 5f 2e  2e 5f 67 63 63 5f 34 5f  |_.._.._.._gcc_4_|
07f0  35 5f 72 65 67 74 65 73  74 5f 6c 69 62 73 74 64  |5_regtest_libstd|
0800  63 5f 5f 5f 76 33 5f 73  72 63 5f 73 79 73 74 65  |c___v3_src_syste|
0810  6d 5f 65 72 72 6f 72 2e  63 63 5f 30 30 30 30 30  |m_error.cc_0|
0820  30 30 30 5f 37 37 34 44  41 30 30 45 32 31 73 79  |000_774DA00E21sy|

stripped system_error.o from stage 3
07a0  30 30 30 5f 35 39 44 36  31 37 37 43 32 32 67 65  |000_59D6177C22ge|
07b0  6e 65 72 69 63 5f 65 72  72 6f 72 5f 63 61 74 65  |neric_error_cate|
07c0  67 6f 72 79 45 00 00 00  00 00 00 00 00 00 00 00  |goryE...|
07d0  4e 38 39 5f 47 4c 4f 42  41 4c 5f 5f 4e 5f 2e 2e  |N89_GLOBAL__N_..|
07e0  5f 2e 2e 5f 2e 2e 5f 2e  2e 5f 67 63 63 5f 34 5f  |_.._.._.._gcc_4_|
07f0  35 5f 72 65 67 74 65 73  74 5f 6c 69 62 73 74 64  |5_regtest_libstd|
0800  63 5f 5f 5f 76 33 5f 73  72 63 5f 73 79 73 74 65  |c___v3_src_syste|
0810  6d 5f 65 72 72 6f 72 2e  63 63 5f 30 30 30 30 30  |m_error.cc_0|
0820  30 30 30 5f 35 39 44 36  31 37 37 43 32 31 73 79  |000_59D6177C21sy|


-- 


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

[Bug c++/41437] New: No access control for classes in template functions

[guillaume dot melquiond at inria dot fr]

In the following testcase, A::B is a private type of A, yet function f has no
trouble manipulating it. The error is detected by gcc neither in the definition
of f nor in its instantiation in g.

class A { struct B { B(); }; };
template void f() { A::B b; }
void g() { f(); }

Tested with the 4.3.3 release and the 20090912 snapshot of 4.5.0.


-- 
   Summary: No access control for classes in template functions
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at inria dot fr


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

[Bug bootstrap/41436] New: [4.5 regression] option `param_is' may only be applied to structures or structure pointers

[ro at gcc dot gnu dot org]

Between 20090915 (rev. 151722) and 20090922 (rev. 152032), mainline started to
fail bootstrap on Solaris 10/x86 in stage2 building s-gtype:

build/gengtype /vol/gcc/src/gcc-dist/gcc gtyp-input.list
/vol/gcc/src/gcc-dist/gcc/cgraph.c:94: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/cgraph.c:96: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2out.c:414: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2out.c:5641: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2out.c:5645: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2out.c:5649: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2out.c:5682: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/dwarf2asm.c:768: option `param2_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/emit-rtl.c:156: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/emit-rtl.c:160: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/emit-rtl.c:164: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/emit-rtl.c:168: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/emit-rtl.c:172: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/function.c:129: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/function.c:131: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/function.c:486: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/except.c:161: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/optabs.c:121: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/optabs.c:6009: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:175: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:180: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:190: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:196: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:199: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree.c:203: option `param_is' may only be applied to
structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/varasm.c:180: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/varasm.c:183: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/varasm.c:194: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/varasm.c:2787: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree-mudflap.c:1212: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree-scalar-evolution.c:310: option `param_is' may
only be applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/varpool.c:51: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/omp-low.c:5880: option `param2_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/config/i386/i386.c:10245: option `param_is' may only
be applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/ipa-reference.c:125: option `param2_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/tree-ssa-structalias.c:164: option `param_is' may
only be applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/ada/gcc-interface/decl.c:114: option `param_is' may
only be applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/cp/mangle.c:3045: option `param_is' may only be
applied to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/cp/decl.c:2912: option `param_is' may only be applied
to structures or structure pointers
/vol/gcc/src/gcc-dist/gcc/cp/pt.c:93: option `para

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[developer at sandoe-acoustics dot co dot uk]

--- Comment #7 from developer at sandoe-acoustics dot co dot uk  2009-09-22 
19:20 ---
(In reply to comment #6)
> I wonder if we could just trim out the symbols from libgcc that are in
> libSystem, and arrange for gcc's installed libgcc to be found first. 

OK. If I understand this from the symbol PoV 
- that's the same machinery as builds the _ext 
(i.e. there are the same symbols left at each revision as would be in the _ext
)...
in a change-control sense, at least.

> Advantage, simplicity, less target specific work, easy to understand.
Simplicity & less work sound good... I'm working on the understanding bit ;)

> Downside, OS upgrades require recompiling the world, to the extent there are
> new symbols in libgcc that are then added to libSystem in later OS releases. 

meaning that a binary from on OSX release would not work on a later one or vice
versa.  
I guess there's an amount of this anyway .. 

> ld has magic in it that can appear and disappear symbols from a dylib 
> depending
> upon which OS is targeted.  Target old OSes, all the usual symbols are there,
> target newer OSes, large swaths disappear (but are found anyway in libSystem).
>
> Also, all this fun stuff it relevant to darwin10 and later only (not 
> darwin9). 

why not relevant to D9 and D8?
(D8 is still the end of the road for a whole bunch of perfectly good PPC
hardware)

if we override the /usr/lib/libgcc_s we mess up the unwinding 
(the whole reason I made the _ext in the first place was that we can't 'lose' 
that version because it's linked with system frameworks.)

To add symbols to D9/D8 we still have to link two libgcc variants (whether one
is named _ext or not is not important) ..

> I'm not a fan of yet more compile flags in general.  I'd rather have a nice
> design that covers the bases, that doesn't really need yet more flags.
> 
> The hiding trick goes something like:
> 
> #define NOT_HERE_BEFORE_10_6(sym) \
> extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
> __attribute__((visibility("default"))) const char sym##_tmp3 = 0; 
> \

where do we have to apply this macro ? 
to every function in libgcc? (with appropriate 'NOT_HERE_BEFOREs' )
or is it something that could be scripted?


-- 


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

[Bug middle-end/33803] ICE during build of DES

[joel at gcc dot gnu dot org]

--- Comment #3 from joel at gcc dot gnu dot org  2009-09-22 19:10 ---
Is it time to close this one?  It doesn't cause an ICE in 4.4.1.

$ h8300-rtems4.10-gcc --version
h8300-rtems4.10-gcc (GCC) 4.4.1
$ h8300-rtems4.10-gcc -O0 -c des1.c
des1.c:4117: error: size of variable 'des_f' is too large
$ h8300-rtems4.10-gcc -O1 -c des1.c
des1.c:4117: error: size of variable 'des_f' is too large
$ h8300-rtems4.10-gcc -O2 -c des1.c
des1.c:4117: error: size of variable 'des_f' is too large


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

--- Comment #15 from aoliva at gcc dot gnu dot org  2009-09-22 19:03 ---
(In reply to comment #12)
> Why do you think refering to other debug stmts decl is not a good idea?

Because referring to decls already has a well-defined meaning in debug stmts,
and that meaning refers to a run-time value/location arbitrarily assigned the
name of the variable, rather than to the source-level value of the variable. 
These values may very well be different, especially if optimizations coalesced
multiple variables into a single run-time location, and we move the references
across modifications of the run-time location.

This would get very messy in RTL, although it may not be immediately apparent
in gimple, and it might even appear to work for trivial cases.  But once the
ambiguity hits, you lose.


-- 


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

[Bug other/39888] TLS emutls not linked to automatically on Darwin

[mrs at apple dot com]

--- Comment #6 from mrs at apple dot com  2009-09-22 18:56 ---
I wonder if we could just trim out the symbols from libgcc that are in
libSystem, and arrange for gcc's installed libgcc to be found first. 
Advantage, simplicity, less target specific work, easy to understand. 
Downside, OS upgrades require recompiling the world, to the extent there are
new symbols in libgcc that are then added to libSystem in later OS releases. 
ld has magic in it that can appear and disappear symbols from a dylib depending
upon which OS is targeted.  Target old OSes, all the usual symbols are there,
target newer OSes, large swaths disappear (but are found anyway in libSystem).

Also, all this fun stuff it relevant to darwin10 and later only (not darwin9). 
I'm not a fan of yet more compile flags in general.  I'd rather have a nice
design that covers the bases, that doesn't really need yet more flags.

The hiding trick goes something like:

#define NOT_HERE_BEFORE_10_6(sym) \
extern const char sym##_tmp3 __asm("$ld$hide$os10.3$_" #sym ); \
__attribute__((visibility("default"))) const char sym##_tmp3 = 0; \


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  Component|middle-end  |debug


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

[Bug debug/41295] [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[aoliva at gcc dot gnu dot org]

--- Comment #7 from aoliva at gcc dot gnu dot org  2009-09-22 18:33 ---
Fixed.


-- 

aoliva at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug debug/41295] [4.5 Regression] gfortran.dg/loc_2.f90 -O3 -g fails on SH with orphaned debug_insn

[aoliva at gcc dot gnu dot org]

--- Comment #6 from aoliva at gcc dot gnu dot org  2009-09-22 18:31 ---
Subject: Bug 41295

Author: aoliva
Date: Tue Sep 22 18:31:26 2009
New Revision: 152040

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152040
Log:
gcc/ChangeLog:
PR debug/41295
* reload1.c (reload): Reset debug insns with pseudos without
equivalences.
gcc/testsuite/ChangeLog:
PR debug/41295
* gcc.dg/pr41295.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/pr41295.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist

[rwild at gcc dot gnu dot org]

--- Comment #13 from rwild at gcc dot gnu dot org  2009-09-22 18:05 ---
trunk implements the warning from comment #10 now, and r151880 fixes the
long-standing include-fixed bug with an in-tree build, so this can be
considered as fixed on trunk I guess.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.5.0


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

[Bug bootstrap/32272] make exit because build/genmodes.exe doesn't exist

[rwild at gcc dot gnu dot org]

--- Comment #12 from rwild at gcc dot gnu dot org  2009-09-22 18:00 ---
Subject: Bug 32272

Author: rwild
Date: Tue Sep 22 18:00:15 2009
New Revision: 152037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152037
Log:
Error out if building separately but srcdir has build remnants.

/:
PR bootstrap/32272
* configure.ac: Error out if $srcdir isn't '.' but contains
host-${host_noncanonical}.
* configure: Regenerate.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[developer at sandoe-acoustics dot co dot uk]

--- Comment #38 from developer at sandoe-acoustics dot co dot uk  
2009-09-22 16:38 ---

> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison failure!
> i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs
> i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs
> i686-apple-darwin9/libstdc++-v3/src/future.o differs
> i686-apple-darwin9/libstdc++-v3/src/system_error.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs
> i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs
> make[2]: *** [compare] Error 1

FWIW powerpc-apple-darwin8 exhibits the same phenomenon.


-- 


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

[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid

[fche at gcc dot gnu dot org]

--- Comment #3 from fche at redhat dot com  2009-09-22 16:18 ---
Committed.


--- Comment #4 from fche at redhat dot com  2009-09-22 16:18 ---
Subject: Bug 41433

Author: fche
Date: Tue Sep 22 16:17:50 2009
New Revision: 152026

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152026
Log:
2009-09-22  Frank Ch. Eigler  

PR libmudflap/41433
* mf-runtime.c (__mf_init): Ignore $MUDFLAP_OPTIONS if
running setuid or setgid.

Modified:
trunk/libmudflap/ChangeLog
trunk/libmudflap/mf-runtime.c


-- 

fche at redhat dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid

[fche at redhat dot com]

--- Comment #3 from fche at redhat dot com  2009-09-22 16:18 ---
Committed.


-- 

fche at redhat dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/41049] conversion from integer to decimal float loses trailing zeros

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-09-22 16:16 ---
Fixed in trunk, 4.4 branch, 4.3 branch.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[developer at sandoe-acoustics dot co dot uk]

--- Comment #37 from developer at sandoe-acoustics dot co dot uk  
2009-09-22 16:09 ---
(In reply to comment #36)
> Remove -gdwarf-2 as well.  -gdwarf-2 is the same as -g when dwarf_version
> defaults to 2 (which is true on the trunk).
> Easiest quick hack to turn -gstrict-dwarf on is add Init(1) to 
> gno-strict-dwarf
> in common.opt (that's how I've been testing it).

yeah I was adding Init(1) yesterday.
I did that and bootstrapped again;  
double-checked and the flags are correctly init-ed (=2 and =1).
NO CHANGE (2 fails x 4  on compare-debug), so something else is broken.  I'll
try and investigate.. but time is shot now.


-- 


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

[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid

[fche at redhat dot com]

--- Comment #2 from fche at redhat dot com  2009-09-22 15:52 ---
Created an attachment (id=18631)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18631&action=view)
proposed patch

This patch fixes and documents the can-of-wormsness of setuid.


-- 


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

[Bug lto/41380] lto.exp leaves temporary files behind

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-22 15:50 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/41380] lto.exp leaves temporary files behind

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-22 15:48 ---
Subject: Bug 41380

Author: rguenth
Date: Tue Sep 22 15:48:39 2009
New Revision: 152020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152020
Log:
2009-09-22  Richard Guenther  

PR testsuite/41380
* lib/lto.exp (lto-execute): Remove executables.

Modified:
branches/lto/gcc/testsuite/ChangeLog.lto
branches/lto/gcc/testsuite/lib/lto.exp


-- 


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

[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-09-22 15:44 
---
Re-confirmed with current trunk, testcase from (comment #8).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-02-06 13:44:58 |2009-09-22 15:44:58
   date||


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

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-22 15:42 ---
Similar testcase from PR40011

SUBROUTINE c()
 CALL a()
END SUBROUTINE c

SUBROUTINE a()
END SUBROUTINE a

MODULE M
CONTAINS
 SUBROUTINE b()
   CALL c()
 END SUBROUTINE
END MODULE

USE M
CALL b()
END

> gfortran -fwhole-file -O t.f90
/tmp/ccW7Uhc6.o: In function `__m_MOD_b':
t.f90:(.text+0xa): undefined reference to `c_'
collect2: ld returned 1 exit status


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||40011
  nThis||


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

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-22 15:34 ---
Reconfirmed with current trunk.  If I move three to the top of the file I
even get

/tmp/ccGHHCCU.o: In function `main':
t.f90:(.text+0x1e): undefined reference to `three_'
t.f90:(.text+0x28): undefined reference to `three_'
collect2: ld returned 1 exit status

this makes -fwhole-file less useful than necessary.  LTO manages to fix up
the decls (thus, with -flto it builds and links fine with -fwhole-program).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2009-07-28 13:12:15 |2009-09-22 15:34:34
   date||


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

[Bug target/41246] should "sorry" when regparm=3 and nested functions are encountered

[rth at gcc dot gnu dot org]

--- Comment #21 from rth at gcc dot gnu dot org  2009-09-22 15:21 ---
Fixed.


-- 

rth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/41435] New: GCC doesn't fold complex int division

[ghazi at gcc dot gnu dot org]

For integral complex types like complex int, GCC doesn't fold division with
constant arguments.  E.g. this testcase should evaluate at compile-time and
link without any errors but doesn't:

extern void link_error(void);
#define EXPR ((2 + 4i) / 2)
int main(void)
{
  if (__real EXPR != 1 || __imag EXPR != 2)
link_error();

  return 0;
}


-- 
   Summary: GCC doesn't fold complex int division
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org


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

[Bug target/41246] should "sorry" when regparm=3 and nested functions are encountered

[rth at gcc dot gnu dot org]

--- Comment #20 from rth at gcc dot gnu dot org  2009-09-22 15:17 ---
Subject: Bug 41246

Author: rth
Date: Tue Sep 22 15:16:49 2009
New Revision: 152018

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152018
Log:
PR target/41246
* config/i386/i386.c (ix86_function_regparm): Do not issue an
error for nested functions with regparm=3.
(ix86_compute_frame_layout): Adjust frame pointer offset for
ix86_static_chain_on_stack.
(ix86_expand_prologue): Handle ix86_static_chain_on_stack.
(ix86_emit_restore_reg_using_pop): Increment ix86_cfa_state->offset,
don't reset to UNITS_PER_WORD.
(ix86_emit_leave): Adjust ix86_cfa_state.
(ix86_expand_epilogue): Handle ix86_static_chain_on_stack.
(ix86_static_chain): New.
(ix86_trampoline_init): Rename from x86_initialize_trampoline;
make static; update for target hook parameters; use ix86_static_chain.
(TARGET_STATIC_CHAIN, TARGET_TRAMPOLINE_INIT): New.
* config/i386/i386.h (STATIC_CHAIN_REGNUM): Remove.
(INITIALIZE_TRAMPOLINE): Remove.
(TRAMPOLINE_SIZE): Use 24 for 64-bit.
(struct machine_function): Use BOOL_BITFIELD; rearrange bitfields
to the end.  Add static_chain_on_stack.
(ix86_static_chain_on_stack): New.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h


-- 


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

[Bug target/41246] should "sorry" when regparm=3 and nested functions are encountered

[rth at gcc dot gnu dot org]

--- Comment #19 from rth at gcc dot gnu dot org  2009-09-22 15:12 ---
Subject: Bug 41246

Author: rth
Date: Tue Sep 22 15:11:37 2009
New Revision: 151983

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151983
Log:
PR target/41246
* target.h (struct gcc_target): Add asm_out.trampoline_template,
calls.static_chain, calls.trampoline_init,
calls.trampoline_adjust_address.
* target-def.h (TARGET_ASM_TRAMPOLINE_TEMPLATE): New.
(TARGET_STATIC_CHAIN, TARGET_TRAMPOLINE_INIT): New.
(TARGET_TRAMPOLINE_ADJUST_ADDRESS): New.
* builtins.c (expand_builtin_setjmp_receiver): Use
targetm.calls.static_chain; only clobber registers.
(expand_builtin_init_trampoline): Use targetm.calls.trampoline_init;
set up memory attributes properly for the trampoline block.
(expand_builtin_adjust_trampoline): Use
targetm.calls.trampoline_adjust_address.
* calls.c (prepare_call_address): Add fndecl argument.  Use
targetm.calls.static_chain.
* df-scan.c (df_need_static_chain_reg): Remove.
(df_get_entry_block_def_set): Use targetm.calls.static_chain;
consolodate static chain handling.
* doc/tm.texi: Document new hooks.
* emit-rtl.c (static_chain_rtx, static_chain_incoming_rtx): Remove.
(init_emit_regs): Don't initialize them.
* expr.h (prepare_call_address): Update decl.
* final.c (profile_function): Use targetm.calls.static_chain.
* function.c (expand_function_start): Likewise.
* rtl.h (static_chain_rtx, static_chain_incoming_rtx): Remove.
* stmt.c (expand_nl_goto_receiver): Use targetm.calls.static_chain;
only clobber registers.
* targhooks.c (default_static_chain): New.
(default_asm_trampoline_template, default_trampoline_init): New.
(default_trampoline_adjust_address): New.
* targhooks.h: Declare them.
* varasm.c (assemble_trampoline_template): Use
targetm.asm_out.trampoline_template.  Make the memory block const
and set its size.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/calls.c
trunk/gcc/config/darwin.h
trunk/gcc/config/netbsd.h
trunk/gcc/df-scan.c
trunk/gcc/doc/tm.texi
trunk/gcc/emit-rtl.c
trunk/gcc/expr.h
trunk/gcc/final.c
trunk/gcc/function.c
trunk/gcc/rtl.h
trunk/gcc/stmt.c
trunk/gcc/target-def.h
trunk/gcc/target.h
trunk/gcc/targhooks.c
trunk/gcc/targhooks.h
trunk/gcc/varasm.c


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[jakub at gcc dot gnu dot org]

--- Comment #36 from jakub at gcc dot gnu dot org  2009-09-22 15:04 ---
Remove -gdwarf-2 as well.  -gdwarf-2 is the same as -g when dwarf_version
defaults to 2 (which is true on the trunk).
Easiest quick hack to turn -gstrict-dwarf on is add Init(1) to gno-strict-dwarf
in common.opt (that's how I've been testing it).


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[rguenth at gcc dot gnu dot org]

--- Comment #35 from rguenth at gcc dot gnu dot org  2009-09-22 15:01 
---
BOOT_CFLAGS="-g -gdwarf-2 -gstrict-dwarf -O2" likely doesn't work with
bootstrap-debug.  Try just BOOT_CFLAGS="-gdwarf-2 -gstrict-dwarf -O2".


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #28 from rguenth at gcc dot gnu dot org  2009-09-22 14:58 
---
Subject: Bug 41395

Author: rguenth
Date: Tue Sep 22 14:58:05 2009
New Revision: 151981

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151981
Log:
2009-09-22  Richard Guenther  

PR middle-end/41395
* tree-dfa.c (get_ref_base_and_extent): Handle trailing
arrays really properly.

* gcc.c-torture/execute/pr41395-1.c: New testcase.
* gcc.c-torture/execute/pr41395-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr41395-1.c
trunk/gcc/testsuite/gcc.c-torture/execute/pr41395-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-dfa.c


-- 


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

[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid

[fche at redhat dot com]

-- 

fche at redhat dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fche at redhat dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-22 14:54:43
   date||


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[developer at sandoe-acoustics dot co dot uk]

--- Comment #34 from developer at sandoe-acoustics dot co dot uk  
2009-09-22 14:36 ---
(In reply to comment #32)
> Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html

thanks - actually I was trying this - but in the end updated to 151978...
with BOOT_CFLAGS="-g -gdwarf-2 -gstrict-dwarf -O2" and CFLAGS_FOR_TARGET the
same/

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/libstdc++-v3/src/future.o differs
i686-apple-darwin9/libstdc++-v3/src/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs
i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs
make[2]: *** [compare] Error 1

> You used a too simple testcase which doesn't need any of the DWARF4 additions.
> Use a more complicated one, e.g. try the gcc.dg/guality/ testcases with
> -g{,no-}strict-dwarf.

well that's true - but I'd stopped there since even that simplistic case was
giving errors with
 dwarfdump --debug-frame 

once we figure out how to get bootstrap working again .. I'll do the 
gcc.dg/guality testcases as you suggest


-- 


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

[Bug lto/41380] lto.exp leaves temporary files behind

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-22 14:25 ---
I have a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-22 14:25:09
   date||


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2009-09-22 
14:12 ---
Subject: Re:  [4.5 Regression] Internal error compiling fortran/intrinsic.c

> I see this has -g and this sounds like PR41343 where cc1 is killed because the
> compiler runs out of VM . Could you try the same file without -g or without
> var-tracking ? 

Didn't help.  I will try to figure out which change caused the regression.

Dave


-- 


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

[Bug ada/41434] coldfire ACATS failures

[joel at gcc dot gnu dot org]

--- Comment #1 from joel at gcc dot gnu dot org  2009-09-22 14:10 ---
Created an attachment (id=18630)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18630&action=view)
qemu debug trace with in_asm,cpu

qemu trace of run. Qemu needs patch posted to their list by Till Straumann.

qemu-system-m68k -M uc5282 -nographic  -kernel c34007j -d in_asm,cpu


-- 


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

[Bug ada/41434] New: coldfire ACATS failures

[joel at gcc dot gnu dot org]

We now have a Coldfire (uC5282) BSP that can run on a simulator (qemu).  I am
trying to run the ACATS and getting ~300 failures on the GCC head.  There are
no anomalies in the RTEMS tests.  

$ m68k-rtems4.10-gcc --version
m68k-rtems4.10-gcc (GCC) 4.5.0 20090921 (experimental) [trunk revision 151936]

This version is getting very good results on sparc and mips.

In tracing into the failure, I see this:

(gdb) bt
#0  sigaction (sig=6, act=0xfff0, oact=0xffe4)
at /users/joel/test-gcc/rtems/cpukit/posix/src/sigaction.c:39
#1  0x000462e6 in system.task_primitives.operations.initialize (
environment_task=) at s-taprop.adb:1470
(gdb) p/x $sp
$6 = 0xe3c00

The $sp is perfectly valid and it doesn't look like we have used much stack.
But the act and oact pointers are completely bogus.  An earlier call showed
this:

Breakpoint 1, sigaction (sig=11, act=0xe3c10, oact=0xe3c04)
at /users/joel/test-gcc/rtems/cpukit/posix/src/sigaction.c:39
39  {
(gdb) 

Suggestions on what to look for are definitely appreciated.


-- 
   Summary: coldfire ACATS failures
   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: m68k-rtems4.10


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

[Bug objc++/41430] [4.5 Regression] exception handling testsuite failures in objc++

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-22 13:55 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug objc++/41430] [4.5 Regression] exception handling testsuite failures in objc++

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-22 13:49 ---
Subject: Bug 41430

Author: rguenth
Date: Tue Sep 22 13:49:03 2009
New Revision: 151979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151979
Log:
2009-09-22  Richard Guenther  

PR objc++/41430
* Make-lang.in (objcp-lang.o): Add $(EXCEPT_H) dependency.
* objcp-lang.c (LANG_HOOKS_EH_PERSONALITY): Define.
(LANG_HOOKS_EH_RUNTIME_TYPE): Likewise.
(objcxx_eh_personality): New function.

Modified:
trunk/gcc/objcp/ChangeLog
trunk/gcc/objcp/Make-lang.in
trunk/gcc/objcp/objcp-lang.c


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[jakub at gcc dot gnu dot org]

--- Comment #33 from jakub at gcc dot gnu dot org  2009-09-22 13:22 ---
Subject: Bug 41405

Author: jakub
Date: Tue Sep 22 13:22:15 2009
New Revision: 151978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151978
Log:
PR bootstrap/41405
* dwarf2out.c (base_type_die, record_type_tag, gen_subprogram_die,
add_call_src_coords_attributes, add_high_low_attributes,
gen_compile_unit_die, gen_type_die_with_usage force_decl_die,
gen_decl_die, dwarf2out_imported_module_or_decl_1, dwarf2out_finish,
dwarf2out_imported_module_or_decl): Avoid using DWARF3 additions
when -gdwarf-2 -gstrict-dwarf.
(loc_list_from_tree): Likewise.  Avoid using DWARF4 additions when
-gdwarf-[23] -gstrict-dwarf.
(address_of_int_loc_descriptor, loc_descriptor,
loc_list_for_address_of_addr_expr_of_indirect_ref): Avoid using
DWARF4 additions when -gdwarf-[23] -gstrict-dwarf.
* common.opt (gno-strict-dwarf, gstrict-dwarf): New options.

* gfortran.dg/debug/pr37738.f: Add -gno-strict-dwarf to dg-options.
* gfortran.dg/debug/pr35154-dwarf2.f: Likewise.
* g++.dg/debug/dwarf2/explicit-constructor.C: Likewise.
* g++.dg/debug/dwarf2/imported-module-2.C: Likewise.
* g++.dg/debug/dwarf2/imported-module-3.C: Likewise.
* g++.dg/debug/dwarf2/imported-module-4.C: Likewise.
* g++.dg/debug/dwarf2/namespace-1.C: Likewise.
* objc.dg/dwarf-2.m: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/debug/dwarf2/explicit-constructor.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-2.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-3.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-4.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/namespace-1.C
trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f
trunk/gcc/testsuite/gfortran.dg/debug/pr37738.f
trunk/gcc/testsuite/objc.dg/dwarf-2.m


-- 


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

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

[joel at gcc dot gnu dot org]

--- Comment #11 from joel at gcc dot gnu dot org  2009-09-22 13:07 ---
Patch applied to head.  GNAT/RTEMS for the mips has 1 failure now and that is a
blown stack.  c380004 takes a lot of stack.

Thanks.


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

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

[xxcv07 at gmail dot com]

--- Comment #3 from xxcv07 at gmail dot com  2009-09-22 12:28 ---
I am reopening this bug based on that I have retested and recompiled using
gcc-trunk which leads to trying to reduce to the exact optimization flag which
was causing this problem. As you can see the gdb output above is invalid (which
was my mistake) but the bug for taking snapshots and -O2 optimization breaks
vlc at playback idx/sub + avi file.
I have narrowed it right down to a single flag -foptimize-sibling-calls this
flag is enabled in -O2 and produces faulty codes. In the runtime it will
trigger when vlccore was compiled with this flag which is the default
optimization for -O2.
Target specific ?
So please ignore the "assembler dump" in the initial description as it doesn't
apply now.
This is a rather critical bug, where it's unreproducible inside a debugger
instance. Its effects I have already outlined in the original description.
You probably have more knowledge in why this flag causes such a big issue for
x86_64-w64 target.
I'm only a user with minimal programming knowledge, I have provide all the
information and tests reports to the best of my ability.


-- 

xxcv07 at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2009-09-22 12:13 ---
Correction - artificial variables aren't needed, DW_TAG_dwarf_procedure with
just DW_AT_location with the expression or loclist is enough.
That's BTW something that a dwarf compactor could do - look at dwarf
expressions in DW_AT_location attributes and .debug_loc, see if there are
subexpressions that occur frequently and big enough that replacing them with 3
byte DW_OP_call2  would be worthwhile, for those add
DW_TAG_dwarf_procedure at some low DIE offset (< 64KB into .debug_info).  GCC
could do that too of course, perhaps as a special pass over the debug info
before sizing it.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||roland at redhat dot com


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

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

[davek at gcc dot gnu dot org]

--- Comment #11 from davek at gcc dot gnu dot org  2009-09-22 11:54 ---
I'll try and get to testing it today, but it'll be late tonight before I can
start, I've got to spend the day doing some binutils stuff.  Will be back in
touch when I know something, thanks for the patch.


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #27 from rguenth at gcc dot gnu dot org  2009-09-22 11:48 
---
struct VEC_char_base
{
  unsigned num;
  unsigned alloc;
  short vec[1];
};

short __attribute__((noinline))
foo (struct VEC_char_base *p, int i)
{
  short *q;
  p->vec[i] = 0;
  q = &p->vec[1];
  *q = 1;
  return p->vec[i];
}

extern void abort (void);
extern void *malloc (__SIZE_TYPE__);

int
main()
{
  struct VEC_char_base *p = malloc (sizeof (struct VEC_char_base));
  if (foo (p, 1) != 1)
abort ();
  return 0;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jamborm at gcc dot gnu dot  |rguenth at gcc dot gnu dot
   |org |org


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

[Bug c++/41425] switch with enums doesn't work

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-22 11:43 
---
Yes, as part of a wrong-code fix.


-- 


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

[Bug bootstrap/41432] [4.5 Regression] Gcc is getting slower and slower

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-22 11:42 ---
works for me.


-- 


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

[Bug fortran/40996] [F03] ALLOCATABLE scalars

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2009-09-22 11:40 ---
Subject: Bug 40996

Author: janus
Date: Tue Sep 22 11:40:30 2009
New Revision: 151975

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151975
Log:
2009-09-22  Janus Weil  

PR fortran/40996
* decl.c (build_struct): Handle allocatable scalar components.
* expr.c (gfc_add_component_ref): Correctly set typespec of expression,
after inserting component reference.
* match.c (gfc_match_type_is,gfc_match_class_is): Make sure that no
variables are being used uninitialized.
* primary.c (gfc_match_varspec): Handle CLASS array components.
* resolve.c (resolve_select_type): Transform EXEC_SELECT_TYPE to
EXEC_SELECT.
* trans-array.c (structure_alloc_comps,gfc_trans_deferred_array):
Handle allocatable scalar components.
* trans-expr.c (gfc_conv_component_ref): Ditto.
* trans-types.c (gfc_get_derived_type): Ditto.


2009-09-22  Janus Weil  

PR fortran/40996
* gfortran.dg/allocatable_scalar_3.f90: New test.
* gfortran.dg/select_type_2.f03: Ditto.
* gfortran.dg/typebound_proc_5.f03: Changed error messages.

Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/allocatable_scalar_3.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/select_type_2.f03
Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
branches/fortran-dev/gcc/fortran/decl.c
branches/fortran-dev/gcc/fortran/expr.c
branches/fortran-dev/gcc/fortran/match.c
branches/fortran-dev/gcc/fortran/primary.c
branches/fortran-dev/gcc/fortran/resolve.c
branches/fortran-dev/gcc/fortran/trans-array.c
branches/fortran-dev/gcc/fortran/trans-expr.c
branches/fortran-dev/gcc/fortran/trans-types.c
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
branches/fortran-dev/gcc/testsuite/gfortran.dg/typebound_proc_5.f03


-- 


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

[Bug libmudflap/41433] security: mudflap accepts environment variables if setuid

[krahmer at suse dot de]

--- Comment #1 from krahmer at suse dot de  2009-09-22 11:33 ---
Changing system() to execve() is not enough since ressources
like open files may also leak from a setuid binary.


-- 


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

[Bug lto/41379] WPA leaves asm temporary file behind

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-22 11:29 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2009-09-22 11:29 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug lto/41379] WPA leaves asm temporary file behind

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-22 11:29 ---
Subject: Bug 41379

Author: rguenth
Date: Tue Sep 22 11:29:10 2009
New Revision: 151974

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151974
Log:
2009-09-22  Richard Guenther  

PR lto/41379
* toplev.c (finalize): In WPA mode remove the asm file.

Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/toplev.c


-- 


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

[Bug lto/39276] [lto] - Testsuite gcc.log shows many "getconf: Invalid argument (_NPROCESSORS_ONLN)"

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-22 11:28 
---
Subject: Bug 39276

Author: rguenth
Date: Tue Sep 22 11:28:14 2009
New Revision: 151973

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151973
Log:
2009-09-22  Richard Guenther  

PR lto/39276
* doc/invoke.texi (-fltrans-driver): Remove.

lto/
* lto.c (lto_execute_ltrans): Perform ltrans phase manually.
* Make-lang.in: Remove ltrans-driver stuff.
* config-lang.in: Likewise.
* lang.opt (fltrans-driver): Remove.
* lto-lang.c (lto_init_options): Remove code initializing
ltrans_driver.
* ltrans-driver: Remove.

Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/doc/invoke.texi
branches/lto/gcc/lto/ChangeLog
branches/lto/gcc/lto/Make-lang.in
branches/lto/gcc/lto/config-lang.in
branches/lto/gcc/lto/lang.opt
branches/lto/gcc/lto/lto-lang.c
branches/lto/gcc/lto/lto.c


-- 


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

[Bug libmudflap/41433] New: security: mudflap acepts environment variables if setuid

[krahmer at suse dot de]

mudflap accepts options via $MUDFLAP_OPTIONS even when running setuid.

-viol-gdb option invokes programs upon error detection which is bad.
Note that NULL ptr derefs which are unexploitable in userspace programs, then
become exploitable.
Fix by either ignoring this variable for setuid's (other options
are bad too; what worth a mudflap if it can be disabled for
setuids which it should protect) or some other magic.


-- 
   Summary: security: mudflap acepts environment variables if setuid
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libmudflap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krahmer at suse dot de


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

[Bug preprocessor/38987] Including a precompiled header from another header causes invalid assembly to be generated

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-22 08:38 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug preprocessor/38987] Including a precompiled header from another header causes invalid assembly to be generated

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2009-09-22 08:37 ---
Subject: Bug 38987

Author: rguenth
Date: Tue Sep 22 08:37:31 2009
New Revision: 151970

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151970
Log:
2009-09-22  Richard Guenther  

PR pch/38987
* files.c (pch_open_file): Disallow non-toplevel PCH inclusion.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/files.c


-- 


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

[Bug tree-optimization/41428] CCP doesn't fold all comparisons it could

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-09-22 08:35 ---
Subject: Bug 41428

Author: rguenth
Date: Tue Sep 22 08:34:52 2009
New Revision: 151969

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151969
Log:
2009-09-22  Richard Guenther  

PR tree-optimization/41428
* tree-ssa-ccp.c (ccp_fold_stmt): New function.
(ccp_finalize): Pass it to substitute_and_fold.

* g++.dg/tree-ssa/pr41428.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr41428.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

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

[rguenth at gcc dot gnu dot org]

--- Comment #26 from rguenth at gcc dot gnu dot org  2009-09-22 08:21 
---
I will have a look at the get_ref_base_and_extent issue.


-- 


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

[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails on *-apple-darwin* due to revision 151815

[jakub at gcc dot gnu dot org]

--- Comment #32 from jakub at gcc dot gnu dot org  2009-09-22 07:08 ---
Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html
You used a too simple testcase which doesn't need any of the DWARF4 additions.
Use a more complicated one, e.g. try the gcc.dg/guality/ testcases with
-g{,no-}strict-dwarf.


-- 


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