[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[fabien dot chene at gmail dot com]

--- Comment #7 from fabien dot chene at gmail dot com  2010-03-31 07:06 
---
(In reply to comment #6)
> (In reply to comment #5)
> > > Nevertheless, can you confirm that it is valid C++03 ?
> > 
> > I mean invalid, sorry.
> 
> Yup :-)
> 
> It is invalid.  A is a non-POD class type, so 5.3.4/15 says the new-expression
> without a new-initializer causes the object to be default-initialized, which
> causes a default constructor to be implicitly-defined with an empty
> mem-initializer list (12.1/7) which is ill-formed by 8.5/5 because the
> reference member is not initialized.
> 
> 
> In C++03 the cases of Foo and A are slightly different, "new Foo" is 
> ill-formed
> according to 5.3.4/15 and "new A" is ill-formed as described above.

Thanks for the clarification !
Patch here for the non C++0X part: 
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01467.html

> In C++0x both "new Foo" and "new A" result in a call to a deleted constructor.


-- 


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

[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-03-31 07:45 ---
When it is approved, I will, of course.


-- 


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

[Bug target/43597] New: Move and compare with 0 can be combined

[carrot at google dot com]

Compile the attached source code with options -Os -march=armv7-a -mthumb, gcc
generates:

foo4:
push{r3, r4, r5, lr}
bl  bar
cmp r0, #0 // A
mov r5, r0 // B
blt .L3
...

Instructions AB can be merged into one instruction   "sub r5, r0, 0"

The rtx for instructions AB are:

(insn:TI 9 7 8 src/ta.c:8 (set (reg:CC 24 cc)
(compare:CC (reg:SI 0 r0 [orig:134 f ] [134])
(const_int 0 [0x0]))) 220 {*arm_cmpsi_insn} (expr_list:REG_DEAD
(reg:SI 0 r0 [orig:134 f ] [134])
(nil)))

(insn 8 9 10 src/ta.c:7 (set (reg/v:SI 5 r5 [orig:134 f ] [134])
(reg:SI 0 r0)) 658 {*thumb2_movsi_insn} (nil))

We have another insn pattern "*movsi_compare0" that can be used to represent
the combined operations. Should insns AB be combined automatically?


-- 
   Summary: Move and compare with 0 can be combined
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
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=43597

[Bug target/43597] Move and compare with 0 can be combined

[carrot at google dot com]

--- Comment #1 from carrot at google dot com  2010-03-31 07:50 ---
Created an attachment (id=20262)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20262&action=view)
test case


-- 


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

[Bug target/43129] Simplify global variable's address loading with option -fpic

[carrot at google dot com]

--- Comment #3 from carrot at google dot com  2010-03-31 08:01 ---
(In reply to comment #2)
> Doesn't this belong in the linker as a relaxation?  This would solve the reloc
> problem in the process.
> 

Gnu linker has already support R_ARM_GOT_PREL. And the new relocation
(GOT_PREL) has been added to trunk gas. So the offset can be represented as

  i(GOT_PREL)+(.-(.LPIC1+4))

Now my question is where is the best place to insert this enhancement?


-- 


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

[Bug libstdc++/43595] std::unique incorrectly assumes transitive property on functor, operator==

[chris at bubblescope dot net]

--- Comment #1 from chris at bubblescope dot net  2010-03-31 08:09 ---
Fixing this would make std::unique quite a bit less efficient. I personally
believe the intention was always to make it an equivalence relation and as you
say C++0x tightens up the condition.

If this had come up 5 or 6 years ago, I might have suggested fixing it, but
changing it now would produce an incompatibility between our C++03 and C++0x
implementations unnecessarily.

Does any other compiler get this right? If they did that would make a more
convincing case, but I'm fairly sure they don't.


-- 

chris at bubblescope dot net changed:

   What|Removed |Added

 CC||chris at bubblescope dot net


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

[Bug debug/43557] ICE with -combine and -g

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-31 08:39 ---
Subject: Bug 43557

Author: jakub
Date: Wed Mar 31 08:39:22 2010
New Revision: 157852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157852
Log:
PR debug/43557
* cfgexpand.c (expand_debug_expr): Handle VOIDmode mode like
BLKmode.

* gcc.dg/pr43557-1.c: New test.
* gcc.dg/pr43557-2.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/pr43557-1.c
trunk/gcc/testsuite/gcc.dg/pr43557-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2010-03-31 08:41 ---
Subject: Bug 43580

Author: jakub
Date: Wed Mar 31 08:41:28 2010
New Revision: 157853

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157853
Log:
PR target/43580
* config/arm/arm.c (arm_save_coproc_regs): Use Pmode instead of
V2SImode or XFmode on PRE_DEC.

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


-- 


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

[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux

[rearnsha at gcc dot gnu dot org]

--- Comment #31 from rearnsha at gcc dot gnu dot org  2010-03-31 08:47 
---
(In reply to comment #30)
> (In reply to comment #29)
> > Wouldn't it be better to just remove _Unwind_GetRegionStart?
> > This function is not part of the ARM EABI, and removing it would expose any
> > (already broken) users at compile time.
> 
> No.
> 
> First it'd break most of gcc since the c, c++, and objc unwinders use it. And
> they generally use it to provide a base address when interpreting LSDA and
> computing landing pad addresses.
> 
> Second, all _Unwind_GetRegionStart does is give r/o access to the fnstart 
> value
> in ARM's UCB.  But ARM's own unwinder uses fnstart in __gnu_unwind_pr_common,
> so if fnstart is broken then so it ARM's unwinder.
> 
> ARM's unwinder is in the same boat as the c/c++/objc ones.  It works because
> .ARM.exidx merging is limited to immediate table data, but the code using
> fnstart (by luck or design) only runs when the table contains non-immediate
> data, and in those cases fnstart is accurate.
> 

There appears to be a mistaken presumption running through this thread that
there is a 1<->1 mapping between unwind blocks and source language functions. 
This is not the case, and any code written with such a presumption is just
wrong code.

Just because such behaviour may work on other machines does not make the
presumption correct or the ARM unwinding code wrong.

1) Compilers may inline functions.  If they do so, then unwind blocks will get
merged.

2) Compilers may create extra frames (though currently rarely).  If they do,
then a function may have more than one frame.

3) They may do some combination of the above.

4) The ARM frame-unwinding annotations are designed to unwind C++ exceptions. 
If they don't work outside that specification that does not make them wrong;
they simply weren't designed for the other (mis-)uses to which some people are
trying to put them.

Source language code is run on an abstract machine.  When it's mapped onto real
hardware the reality can be very different.  You can't rely on the two
corresponding directly beyond the semantics of the language.


-- 


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

[Bug target/43580] [4.5 Regression] ICE segfault compiling libgcc2.c

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2010-03-31 08:51 ---
Should be fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug debug/43557] ICE with -combine and -g

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-03-31 08:54 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[redi at gcc dot gnu dot org]

--- Comment #8 from redi at gcc dot gnu dot org  2010-03-31 08:55 ---
(N.B. your email to gcc-patches gives the wrong PR number in the subject.)

This reject the following valid program:

struct X {
  X() : c(0), r(c) {}
  const int c;
  int const& r;
};

int main()
{
  new X;
}

If there is a default constructor it will be called, and so the members will
not be uninitialized.


-- 


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

[Bug target/43597] Move and compare with 0 can be combined

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 09:01:30
   date||


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

[Bug inline-asm/39048] gcc 4.4.0 20090131 - Extra underscore hides libgcc's soft-fp functions from Testsuite causing FAILs + naming error in libgcc

[ro at gcc dot gnu dot org]

--- Comment #11 from ro at gcc dot gnu dot org  2010-03-31 09:03 ---
Subject: Bug 39048

Author: ro
Date: Wed Mar 31 09:03:29 2010
New Revision: 157854

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157854
Log:
gcc:
PR target/39048
* config.gcc (i[34567]86-*-solaris2*): Add i386/t-fprules-softfp
and soft-fp/t-softfp to tmake_file.
* config/i386/sol2.h (LIBGCC2_HAS_TF_MODE): Redefine.
(LIBGCC2_TF_CEXT): Define.
(TF_SIZE): Define.

libgcc:
PR target/39048
* config.host (i[34567]86-*-solaris2): Handle 32-bit Solaris 2/x86
like other remaining 32-bit x86 OSes.
* config/i386/32/sfp-machine.h (FP_HANDLE_EXCEPTIONS): Support Sun
assembler syntax.
* config/i386/libgcc-sol2.ver: New file.
* config/i386/t-sol2 (SHLIB_MAPFILES): Add it.

Added:
trunk/libgcc/config/i386/libgcc-sol2.ver
Modified:
trunk/gcc/config.gcc
trunk/gcc/config/i386/sol2.h
trunk/libgcc/ChangeLog
trunk/libgcc/config.host
trunk/libgcc/config/i386/32/sfp-machine.h
trunk/libgcc/config/i386/t-sol2


-- 


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

[Bug target/39048] gcc 4.4.0 20090131 - Extra underscore hides libgcc's soft-fp functions from Testsuite causing FAILs + naming error in libgcc

[ro at gcc dot gnu dot org]

-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|inline-asm  |target
 Ever Confirmed|0   |1
  Known to fail||4.4.0
  Known to work||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 09:05:14
   date||
   Target Milestone|--- |4.5.0


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

[Bug target/39048] gcc 4.4.0 20090131 - Extra underscore hides libgcc's soft-fp functions from Testsuite causing FAILs + naming error in libgcc

[ro at gcc dot gnu dot org]

--- Comment #12 from ro at gcc dot gnu dot org  2010-03-31 09:07 ---
Fixed for 4.5.0.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||03/msg01071.html
 Status|ASSIGNED|RESOLVED
   Keywords||patch
 Resolution||FIXED


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

[Bug target/43597] Move and compare with 0 can be combined

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization
  Known to fail||4.5.0


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

[Bug bootstrap/43596] [4.5 regression] Failed to boostrap

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |4.5.0


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

[Bug c++/43558] [4.5 Regression] Rejects specialization

[dodji at gcc dot gnu dot org]

--- Comment #3 from dodji at gcc dot gnu dot org  2010-03-31 09:21 ---
Subject: Bug 43558

Author: dodji
Date: Wed Mar 31 09:21:02 2010
New Revision: 157857

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157857
Log:
Fix PR c++/43558

gcc/cp/ChangeLog:
PR c++/43558
* cp-tree.h (TEMPLATE_TYPE_PARM_SIBLING_PARMS): New accessor macro.
* pt.c (end_template_parm_list): Store sibling template parms of
each TEMPLATE_TYPE_PARMs into its TEMPLATE_TYPE_PARM_SIBLING_PARMS.
(push_template_decl_real): Don't store the containing template decl
into the DECL_CONTEXT of TEMPLATE_TYPE_PARMs anymore.
* typeck.c (get_template_parms_of_dependent_type): Get sibling parms
of a TEMPLATE_TYPE_PARM from TEMPLATE_TYPE_PARM_SIBLING_PARMS.
Simplify the logic.

gcc/testsuite/ChangeLog:
PR c++/43558
* g++.dg/template/typedef31.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/template/typedef31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug lto/43581] exception handling broken across shared libaries with -fuse-linker-plugin

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-31 09:22 ---
It is enough to build the shared library with -flto -fuse-linker-plugin.
You then get

/tmp> LD_LIBRARY_PATH=. ./main
terminate called after throwing an instance of 'libexc'
  what():  exception in library
Aborted


-- 

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 |2010-03-31 09:22:54
   date||


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

[Bug c++/43558] [4.5 Regression] Rejects specialization

[dodji at gcc dot gnu dot org]

--- Comment #4 from dodji at gcc dot gnu dot org  2010-03-31 09:33 ---
Fixed in 4.5 (trunk).


-- 

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=43558

[Bug debug/43325] [4.5 Regression] C++ external inner reference does not override outer scope

[dodji at gcc dot gnu dot org]

-- 

dodji at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 09:35:28
   date||
Summary|C++ external inner reference|[4.5 Regression] C++
   |does not override outer |external inner reference
   |scope   |does not override outer
   ||scope


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

[Bug libstdc++/43595] std::unique incorrectly assumes transitive property on functor, operator==

[redi at gcc dot gnu dot org]

--- Comment #2 from redi at gcc dot gnu dot org  2010-03-31 09:57 ---
This is a defect in the original standard:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#202

The policy of libstdc++ is to fix defects, and I see no benefit in changing the
C++03 behaviour to be incompatible with C++0x.

I'm closing this as WONTFIX rather than INVALID


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o

[jiez at gcc dot gnu dot org]

--- Comment #5 from jiez at gcc dot gnu dot org  2010-03-31 09:57 ---
Subject: Bug 43574

Author: jiez
Date: Wed Mar 31 09:57:03 2010
New Revision: 157859

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157859
Log:
PR 43574
* opt-functions.awk (var_type_struct): Use signed char type
for simple variables.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opt-functions.awk


-- 


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

[Bug c/36367] warning for questionable compound expression

[pzhao at gcc dot gnu dot org]

--- Comment #2 from pzhao at gcc dot gnu dot org  2010-03-31 09:58 ---
Author: ebotcazou
Date: Thu May 29 11:33:17 2008
New Revision: 136154

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136154
Log:
* tree-nested.c (check_for_nested_with_variably_modified): Fix typo.


Added:
trunk/gcc/testsuite/gcc.dg/nested-func-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nested.c


-- 

pzhao at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/43574] [4.5 Regression] Revision 157795 failed gcc.dg/lto/20090914-1 c_lto_20090914-1_0.o

[jiez at gcc dot gnu dot org]

--- Comment #6 from jiez at gcc dot gnu dot org  2010-03-31 09:58 ---
Should be fixed now.


-- 

jiez at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug debug/43325] [4.5 Regression] C++ external inner reference does not override outer scope

[dodji at gcc dot gnu dot org]

--- Comment #1 from dodji at gcc dot gnu dot org  2010-03-31 10:08 ---
A patch was proposed at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01473.html


-- 


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

[Bug c/36367] warning for questionable compound expression

[ebotcazou at gcc dot gnu dot org]

--- Comment #3 from ebotcazou at gcc dot gnu dot org  2010-03-31 10:08 
---
Not clear what happened but the aforementioned commit is not a fix for this PR.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pzhao at gcc dot gnu dot org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug ada/43598] New: GNAT.Expect.Non_Blocking_Spawn double free or corruption

[reet at codelabs dot ch]

(forwarding Debian bug #575954)

Under some conditions, using GNAT.Expect.Non_Blocking_Spawn in
conjunction with GNAT.Expect.Close leads to memory corruption on amd64.

Given the following small reproducer:

--  expect_test.adb

with Ada.Text_IO;

with GNAT.Expect;
with GNAT.OS_Lib;
with GNAT.Regpat;

procedure Expect_Test is
   use GNAT.Expect;

   Fd   : Process_Descriptor;
   Command  : constant String := "./print_file";
   Arg_List : GNAT.OS_Lib.Argument_List (1 .. 0);
   Result   : Expect_Match;
   Match: GNAT.Regpat.Match_Array (0 .. 0);
begin
   Non_Blocking_Spawn
 (Descriptor  => Fd,
  Command => Command,
  Args=> Arg_List,
  Buffer_Size => 128,
  Err_To_Out  => True);

   Expect
 (Descriptor  => Fd,
  Result  => Result,
  Regexps => Regexp_Array'
(+"END TESTS(.*)FAILED",
 +"END TESTS(.*)PASSED"),
  Matched => Match,
  Timeout => 10);
   Ada.Text_IO.Put_Line ("Terminated");
   Ada.Text_IO.Put_Line (Expect_Out (Descriptor => Fd));
   Ada.Text_IO.Put_Line ("Buffer len " &
 Expect_Out (Descriptor => Fd)'Length'Img);
   Close (Descriptor => Fd);

exception
   when Process_Died =>
  Ada.Text_IO.Put_Line ("Process died");
  Ada.Text_IO.Put_Line (Expect_Out (Descriptor => Fd));
  Close (Descriptor => Fd);
end Expect_Test;

--  print_file.adb

with Ada.Text_IO;

procedure Print_File is
   Filename : constant String := "output";
   File : Ada.Text_IO.File_Type;
begin
   Ada.Text_IO.Open (File => File,
 Mode => Ada.Text_IO.In_File,
 Name => Filename);

   while not Ada.Text_IO.End_Of_File (File => File) loop
  delay 0.001;
  Ada.Text_IO.Put_Line (Ada.Text_IO.Get_Line (File => File));
   end loop;

   Ada.Text_IO.Close (File => File);
end Print_File;

--  output




END TESTS...: PASSED
--

Running the expect_test binary on amd64 results in memory corruption. As
it seems this only happens if the following conditions are met:

* the binary spawned produces more output than the expect buffer size

This should not matter because Non_Blocking_Spawn is expected to discard
old characters:

"The expect buffer associated with that process can contain at most
Buffer_Size characters. Older characters are simply discarded when this
buffer is full."

* the spawned binary uses file IO
* the code sleeps between the text output cycles

Tests:
* gnat 4.3.2:
*** glibc detected *** ./obj/expect_test: double free or corruption
(!prev): 0x006040a0 ***

* gnat 4.4.3:
*** glibc detected *** ./obj/expect_test: free(): invalid next size
(fast): 0x00605090 ***

The bug is also present with the tip of the gcc-4_4-branch (Subversion
revision 157750) from upstream (verified by Ludovic Brenta).

Full gdb backtrace with gnat 4.3.2:

#0  0x7f9502737ed5 in raise () from /lib/libc.so.6
No symbol table info available.
#1  0x7f95027393f3 in abort () from /lib/libc.so.6
No symbol table info available.
#2  0x7f9502774388 in __libc_message () from /lib/libc.so.6
No symbol table info available.
#3  0x7f9502779928 in malloc_printerr () from /lib/libc.so.6
No symbol table info available.
#4  0x7f950277ba36 in free () from /lib/libc.so.6
No symbol table info available.
#5  0x7f9502ee53a5 in <__gnat_free> (ptr=6308000) at s-memory.adb:117
No locals.
#6  0x7f9502e670af in gnat.expect.close (descript...@0x7fffbe50) at
g-expect.adb:227
current_filter = 
next_filter = 
#7  0x00402ff7 in _ada_expect_test ()
No locals.

The complete reproducer code can be downloaded at [1].

- reto

[1] - http://www.codelabs.ch/~reet/reproducers/gnat-expect.tar.bz2


-- 
   Summary: GNAT.Expect.Non_Blocking_Spawn double free or corruption
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reet at codelabs dot ch
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c/43599] New: Several missing optimizations

[piotr dot wyderski at gmail dot com]

I was wondering whether GCC can optimize
sin(x) and cos(x) of the same angle in order
to use the combined fsincos x86 instruction.
The testcase is:

8<

#include 

double fn1(double x) {

return sin(x) * cos(x);
}

double fn2(double x) {

return __builtin_sin(x) * __builtin_cos(x);
}

8<

I compile it with:

gcc -O3 -fomit-frame-pointer -S testcase.cpp

The result turned out to be rather surprising:

8<

.file   "testcase.cpp"
.text
.p2align 4,,15
.globl __Z3fn1d
.def__Z3fn1d;   .scl2;  .type   32; .endef
__Z3fn1d:
subl$60, %esp
fldl64(%esp)
fstl(%esp)
fstpl   16(%esp)
call_sin
fstpl   40(%esp)
fldl16(%esp)
fstpl   (%esp)
call_cos
fmull   40(%esp)
addl$60, %esp
ret
.p2align 4,,15
.globl __Z3fn2d
.def__Z3fn2d;   .scl2;  .type   32; .endef
__Z3fn2d:
subl$60, %esp
fldl64(%esp)
fstl(%esp)
fstpl   16(%esp)
call_sin
fstpl   40(%esp)
fldl16(%esp)
fstpl   (%esp)
call_cos
fmull   40(%esp)
addl$60, %esp
ret
.def_sin;   .scl2;  .type   32; .endef
.def_cos;   .scl2;  .type   32; .endef
.def_sin;   .scl2;  .type   32; .endef
.def_cos;   .scl2;  .type   32; .endef 

8<

As you can see:

a) fsin and fcos are not combined into fsincos, because
b) there are no fsin and fcos -- library calls have been emitted;
c) the stack top manipulation (subl / addl $60, %esp) has no purpose.


-- 
   Summary: Several missing optimizations
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
 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=43599

[Bug c/43599] Several missing optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-03-31 10:47 ---
fsin and fcos are not precise, you have to use -funsafe-math-optimizations to
enable their use.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug c/43599] Several missing optimizations

[piotr dot wyderski at gmail dot com]

--- Comment #2 from piotr dot wyderski at gmail dot com  2010-03-31 11:00 
---
With -ffast-math the code becomes

.file   "testcase.cpp"
.text
.p2align 4,,15
.globl __Z3fn1d
.def__Z3fn1d;   .scl2;  .type   32; .endef
__Z3fn1d:
fldl4(%esp)
fsincos
fmulp   %st, %st(1)
ret
.p2align 4,,15
.globl __Z3fn2d
.def__Z3fn2d;   .scl2;  .type   32; .endef
__Z3fn2d:
fldl4(%esp)
fsincos
fmulp   %st, %st(1)
ret 

which is exactly the expected output, but:

-ffast-math: This option should never be turned
on by any -O option since it can result in
incorrect output for programs which depend on
an exact implementation of IEEE or ISO rules/specifications
for math functions. 

So, what IEEE rules does the fsin/fcos/fsincos
emission/fussion break? The only problem I see
is excessive accuracy, but it can be removed using
the fld/fst trick used by -ffloat-store (and THAT
can be removed by -ffast-math), without the need
to declare the entire program as IEEE754 non-conformant.


-- 


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

[Bug target/43590] ICE in spill_failure, at reload1.c:2158

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|arm-unknown-linux-gnueabi   |arm-unknown-linux-gnueabi,
   ||arm-eabi
   Keywords||ice-on-valid-code
  Known to fail||4.4.3 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 11:05:50
   date||


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

[Bug c/43599] Several missing optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-03-31 11:08 ---
fsin/fcos are known to get wrong results for certain values and their precision
is nowhere near acceptable.  Note that when emitting fsin/fcos GCC omits
necessary range reduction for large arguments - fsin/fcos only work
correctly for a limited range.

Proper code is in libm for example:

ENTRY(__sinf)
flds4(%esp)
fxam
fstsw   %ax
movb$0x45, %dh
andb%ah, %dh
cmpb$0x05, %dh
je  3f
4:  fsin
fnstsw  %ax
testl   $0x400,%eax
jnz 1f
ret
.align ALIGNARG(4)
1:  fldpi
fadd%st(0)
fxch%st(1)
2:  fprem1
fnstsw  %ax
testl   $0x400,%eax
jnz 2b
fstp%st(1)
fsin
ret
3:
#ifdef PIC
pushl   %ebx
cfi_adjust_cfa_offset (4)
cfi_rel_offset (ebx, 0)
LOAD_PIC_REG (bx)
call__errno_locat...@plt
movl$EDOM, (%eax)
popl%ebx
cfi_adjust_cfa_offset (-4)
cfi_restore (ebx)
#else
call__errno_locat...@plt
movl$EDOM, (%eax)
#endif
jmp 4b


-- 


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

[Bug c/43599] Several missing optimizations

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-31 11:10 ---
Btw, on targets which have sincos in their libm gcc emits a call to that
routine when optimizing.


-- 


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

[Bug target/42886] [4.5 Regression] GCC is not relocatable anymore on Windows (mingw32)

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-31 11:52 ---
Back to P3 due to waiting state.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P3


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

[Bug target/39725] [4.5 Regression][cond-optab] MIPS pessimizations on floating-point

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-03-31 11:55 ---
Unconfirmed -> P3.  Also mips-linux isn't primary nor secondary - unclear if
this bug also applies to mipsisa64-elf.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P2  |P3


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2010-03-29 17:28:22 |2010-03-31 11:56:08
   date||


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

[Bug c/43600] New: Segmentation fault for large C file (24MB)

[ihusar at fit dot vutbr dot cz]

For my generated C file that has 24MB, gcc fails after 11 seconds 
with:

gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.

Fedora 11 64-bit, Pentium Quad Core, 2.83GHz, 4GB memory,
gcc 4.4.1

$ uname -a
Linux 2.6.30.9-99.fc11.x86_64 #1 SMP Tue Nov 17 21:30:38 EST 2009 x86_64 x86_64
x86_64 GNU/Linux

Source file and valgrind report are added as attachment.


-- 
   Summary: Segmentation fault for large C file (24MB)
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ihusar at fit dot vutbr dot cz
  GCC host triplet: x86_64-linux-gnu


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[ihusar at fit dot vutbr dot cz]

--- Comment #1 from ihusar at fit dot vutbr dot cz  2010-03-31 11:57 ---
Created an attachment (id=20263)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20263&action=view)
testing C file


-- 


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[ihusar at fit dot vutbr dot cz]

--- Comment #2 from ihusar at fit dot vutbr dot cz  2010-03-31 11:57 ---
Created an attachment (id=20264)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20264&action=view)
valgrind report


-- 


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[ihusar at fit dot vutbr dot cz]

--- Comment #3 from ihusar at fit dot vutbr dot cz  2010-03-31 11:59 ---
Other details, e.g. why I want to compile so huge file, can be found here:
http://n3.nabble.com/Memory-and-time-consumption-for-larger-files-td683717.html#a683717


-- 


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

[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[fabien dot chene at gmail dot com]

--- Comment #9 from fabien dot chene at gmail dot com  2010-03-31 12:20 
---
(In reply to comment #8)
> (N.B. your email to gcc-patches gives the wrong PR number in the subject.)
> 
> This reject the following valid program:
> 
> struct X {
>   X() : c(0), r(c) {}
>   const int c;
>   int const& r;
> };
> 
> int main()
> {
>   new X;
> }
> 
> If there is a default constructor it will be called, and so the members will
> not be uninitialized.

OK, I've revised the patch to check for a user defined constructor.
I have also added your testcase, and others dealing with arrays.

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01486.html


-- 


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-31 12:23 ---
needs -DCLANG to build.  cgraph verification takes ages, so make sure to
turn off checking.  The issue is:

Program received signal SIGSEGV, Segmentation fault.
0x007b9f6e in cgraph_output_in_order ()
at /space/rguenther/src/svn/gcc-4_4-branch/gcc/cgraphunit.c:1148
1148  memset (nodes, 0, size);
(gdb) p size
$1 = 13406704
(gdb) l
1143  struct cgraph_asm_node *pa;
1144
1145  max = cgraph_order;
1146  size = max * sizeof (struct cgraph_order_sort);
1147  nodes = (struct cgraph_order_sort *) alloca (size);
1148  memset (nodes, 0, size);
1149
1150  varpool_analyze_pending_decls ();
1151
1152  for (pf = cgraph_nodes; pf; pf = pf->next)

well.  We shouldn't try to allocate so much memory on stack.

Mine.


-- 

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
  Known to fail||4.4.2 4.4.3 4.4.4
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 12:23:51
   date||


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

[Bug c++/43601] New: Enormous increase in DLL object files size in 4.5

[vz-gcc at zeitlins dot org]

Hello,

 This is not necessarily a bug but I don't know about any other place to
discuss this so I'm reporting it here -- please let me know if I should post
somewhere else.

 Anyhow, there seems to be a big problem with building shared C++ libraries
using the typical

class __attribute(dllexport) SomePublicClass
{
public:
... a lot of inline functions without dllexport ...

... and also a lot of non-inline functions ...
};

pattern, wxWidgets being one particular example (but AFAIK there is really
nothing special about wxWidgets here). I've described the problem in details
in http://thread.gmane.org/gmane.comp.gnu.mingw.user/32435 but, basically,
the size of object files produced by mingw32 4.5 has been multiplied by 10
compared to mingw32 4.4 making linking them extremely time consuming and
plainly impossible on machines with modest amounts of RAM.

 This seems to be due to the following change in gcc itself (and not
mingw32): http://gcc.gnu.org/viewcvs?view=revision&revision=147799 and I'd
like to know if there is any way to undo its effect. For example, the reply
from Cesar Strauss in the thread above suggested using -fhide-inline-functions
option for this. IMHO ideal would be to revert to the old behaviour at
least until some better approach can be found but any solution would be
nicer than nothing.

 Thanks in advance,
VZ


-- 
   Summary: Enormous increase in DLL object files size in 4.5
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
  GCC host triplet: i686-pc-mingw32


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

[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[redi at gcc dot gnu dot org]

--- Comment #10 from redi at gcc dot gnu dot org  2010-03-31 12:34 ---
Thanks. I can't test it now but that looks better.

Just below your new code I see this error:

error ("uninitialized const in % of %q#T", elt_type);

Maybe your new diagnostics should also include 'new' like that.


-- 


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

[Bug bootstrap/43596] [4.5 regression] Failed to boostrap

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-03-31 13:06 ---
Created an attachment (id=20265)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20265&action=view)
gcc45-pr43596.patch

Untested fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-31 13:20 ---
Subject: Bug 43600

Author: rguenth
Date: Wed Mar 31 13:20:19 2010
New Revision: 157867

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157867
Log:
2010-03-31  Richard Guenther  

PR middle-end/43600
* cgraphunit.c (cgraph_output_in_order): Do not allocate
temporary data on stack.

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


-- 


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

[Bug middle-end/43602] New: ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

The commit of...

Author: rguenth
Date: Tue Mar 30 13:10:16 2010
New Revision: 157822

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157822
Log:
2010-03-30  Seongbae Park 
Jack Howarth 

* tree-profile.c (tree_init_ic_make_global_vars): Make static
variables TLS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-profile.c

...resulted in a number of profile related testsuite regressions on darwin.
These are all of the form...

[MacPro:~] howarth%
/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20100330/gcc-4.5-20100330/gcc/testsuite/gcc.dg/matrix/transpose-1.c
   -fprofile-generate -O3  -lm   -o
/sw/src/fink.build/gcc45-4.4.999-20100330/darwin_objdir/gcc/testsuite/gcc/transpose-1.x01
Undefined symbols:
  "___emutls_v.__gcov_indirect_call_counters", referenced from:
  _mem_init in cc591Wfh.o
  _main in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
  "___emutls_v.__gcov_indirect_call_callee", referenced from:
  _mem_init in cc591Wfh.o
  _mem_init in cc591Wfh.o
  _main in cc591Wfh.o
  _main in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
  global constructors keyed to 65535_0_transpose_1.c in cc591Wfh.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Reverting r157822 eliminates these failures. These are surprising since darwin
should now provide all of the additional emutls symbols via a versioned
libgcc_ext shared library.

On x86_64-apple-darwin10, current gcc trunk produces...

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_s.1.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
00013e20 t _emutls_destroy
00013de0 t _emutls_init
00015100 b _emutls_key
000150a0 d _emutls_mutex
000150fc b _emutls_size

[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common

The undefined ___emutls_v.__gcov_indirect_call_counters and
___emutls_v.__gcov_indirect_call_callee symbols occur for the following
permutations...

1) r157820 with r157822 applied (where libgcc is built with only
-DHAVE_CC_TLS).
2) r157822 (where libgcc is built with both -DHAVE_CC_TLS and -DUSE_EMUTLS)
3) r157822 with the following patch applied to invert the logic of that commit
so that neither -DHAVE_CC_TLS  or -DUSE_EMUTLS are used in building libgcc)

Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in  (revision 157840)
+++ libgcc/Makefile.in  (working copy)
@@ -226,7 +226,7 @@
 # will usually contain -g, so for the moment CFLAGS goes first.  We must
 # include CFLAGS - that's where multilib options live.
 INTERNAL_CFLAGS = $(CFLAGS) $(LIBGCC2_CFLAGS) $(HOST_LIBGCC2_CFLAGS) \
- $(INCLUDES) @set_have_cc_tls@ @set_use_emutls@
+ $(INCLUDES) @set_have_cc_tls@

 MULTIDIR := $(shell $(CC) $(CFLAGS) -print-multi-directory)
 MULTIOSDIR := $(shell $(CC) $(CFLAGS) -print-multi-os-directory)
Index: libgcc/configure.ac
===
--- libgcc/configure.ac (revision 157840)
+++ libgcc/configure.ac (working copy)
@@ -232,20 +232,13 @@
 # gcc, which can't be used to build executable due to that libgcc
 # is yet to be built here.
 GCC_CHECK_CC_TLS
+GCC_CHECK_EMUTLS
 set_have_cc_tls=
-if test "$enable_tls $gcc_cv_have_cc_tls" = "yes yes"; then
+if test "$enable_tls $gcc_cv_have_cc_tls $gcc_cv_use_emutls" = "yes yes no";
then
   set_have_cc_tls="-DHAVE_CC_TLS"
 fi
 AC_SUBST(set_have_cc_tls)

-# See if we have emulated thread-local storage.
-GCC_CHECK_EMUTLS
-set_use_emutls=
-if test "$enable_tls $gcc_cv_use_emutls" = "yes yes"; then
-  set_use_emutls="-DUSE_EMUTLS"
-fi
-AC_SUBST(set_use_emutls)
-
 # Conditionalize the makefile for this target machine.
 tmake_file_=
 for f in ${tmake_file}


-- 
   Summary: ___emutls_v.__gcov_indirect_call_[counters|callee]
undefined on *-*-darwin*
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
 GCC build triplet: *-*-darwin*
  GCC host triplet: *-*-darwin*
GCC target triplet: *-*-darwin*


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2010-03-31 13:23 ---
Subject: Bug 43600

Author: rguenth
Date: Wed Mar 31 13:23:17 2010
New Revision: 157868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157868
Log:
2010-03-31  Richard Guenther  

PR middle-end/43600
* cgraphunit.c (cgraph_output_in_order): Do not allocate
temporary data on stack.

Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/cgraphunit.c


-- 


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

[Bug c/43600] Segmentation fault for large C file (24MB)

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-03-31 13:25 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.4.2 4.4.3 4.4.4   |4.4.2 4.4.3
  Known to work||4.3.4 4.4.4 4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.4.4


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #1 from howarth at nitro dot med dot uc dot edu  2010-03-31 
13:29 ---
The commit of the patch to eliminate race conditions in indirect value
profiling (r157822) hasn't triggered the same profile related testsuite
failures in any other target. This leads to two questions...

1) Does any other target really use emulated tls besides darwin?
2) Is standard tls the same as native tls? In other words, are there really
three forms, (tls, native tls and emulated tls, or just two forms (native) tls
and emulated tls?

I ask because according to...

case ${host} in
i[34567]86-*-linux* | x86_64-*-linux* | \
  i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | \
  i[34567]86-*-gnu*)
tmake_file="${tmake_file} t-tls"
;;
esac

...only those targets are using native tls which would suggest (if there are
only two forms of tls) that targets like powerpc64-*-linux* should be using
emulated tls like darwin and thus be failing the profile testcases now. This
isn't the case.


-- 


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #2 from howarth at nitro dot med dot uc dot edu  2010-03-31 
13:42 ---
Richard Guenther has suggested that these two unresolved symbols need to be
exported. I'll test that this evening.


-- 


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

[Bug c/43603] New: gcc-4.4.3 ICE on ia64 with -O3

[mariah dot lenox at gmail dot com]

/* 
% uname -a
Linux cleo 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:57:09 EST 2009 ia64 ia64
ia64 GNU/Linux
% 
% gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /usr/local/gcc-4.4.3/src/gcc-4.4.3/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.20/ia64-Linux-rhel-gcc-4.4.2/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.20/ia64-Linux-rhel-gcc-4.4.2/bin/ld
--with-gmp=/usr/local/mpir-1.2.2/ia64-Linux-rhel-gcc-4.4.2
--with-mpfr=/usr/local/mpfr-2.4.2/ia64-Linux-rhel-mpir-1.2.2-gcc-4.4.2
--prefix=/usr/local/gcc-4.4.3/ia64-Linux-rhel
Thread model: posix
gcc version 4.4.3 (GCC) 
%
% gcc -O2 -c foo.c
%
% gcc -O3 -c foo.c
foo.c: In function ‘foo’:
foo.c:35: error: unrecognizable insn:
(insn:TI 222 209 248 19 (parallel [
(set (reg:SI 135 f7)
(asm_operands:SI ("xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0") ("=&f") 0 [
(reg:SI 136 f8)
(reg:SI 130 f2 [394])
]
 [
(asm_input:SI ("f") 0)
(asm_input:SI ("f") 0)
] 2896))
(set (reg/v:SI 134 f6 [orig:370 b ] [370])
(asm_operands:SI ("xma.hu %0 = %2, %3, f0
xma.l %1 = %2, %3, f0") ("=f") 1 [
(reg:SI 136 f8)
(reg:SI 130 f2 [394])
]
 [
(asm_input:SI ("f") 0)
(asm_input:SI ("f") 0)
] 2896))
]) -1 (nil))
foo.c:35: internal compiler error: in get_attr_first_insn, at
config/ia64/itanium2.md:1909
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
%
*/

int 
foo( long * np, int * dp, int qn)
{
  int i;
  int n0;
  int d0;
  int a;
  int b;
  int c;
  int d;

  a = 1;
  b = 0;
  c = 1;
  d = 1;

  d0 = dp[0];

  for (i = qn; i >= 0; i--) {
if (bar((c == 0)) && (np[1] == d0)) {
  car(np - 3, dp, 3);
} else { 
  __asm__ ("xma.hu %0 = %2, %3, f0\n\txma.l %1 = %2, %3, f0" : "=&f" ((a)), 
"=f" (b) : "f" ((c)), "f" ((d))); 
  n0 = np[0]; 
  if (n0 < d0) 
c = 1; 
  else 
c = 0; 

}
*--np = a;
  }

  return 0;
}


-- 
   Summary: gcc-4.4.3 ICE on ia64 with -O3
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mariah dot lenox at gmail dot com
 GCC build triplet: ia64-unknown-linux-gnu
  GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[fabien dot chene at gmail dot com]

--- Comment #11 from fabien dot chene at gmail dot com  2010-03-31 13:46 
---
(In reply to comment #10)
> Thanks. I can't test it now but that looks better.
> 
> Just below your new code I see this error:
> 
> error ("uninitialized const in % of %q#T", elt_type);
> 
> Maybe your new diagnostics should also include 'new' like that.

Would 'error ("uninitialized const member in %q#T using %", elt_type)'
suit you ?


-- 


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

[Bug c++/25811] No failure creating a POD containing a const member, using new without a new-initializer.

[redi at gcc dot gnu dot org]

--- Comment #12 from redi at gcc dot gnu dot org  2010-03-31 13:52 ---
That works for me, although I should point out I can't approve the patch, so
it's just my opinion


-- 


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

[Bug c/43604] New: Error on compilling kernel FreeBSD

[eduardo dot orige at gmail dot com]

When I try install my new kernel, gcc show follow message:
../../../dev/ex/if_ex.c:290: internal compiler error: Segmentation fault: 11


-- 
   Summary: Error on compilling kernel FreeBSD
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eduardo dot orige at gmail dot com
 GCC build triplet: gcc version 4.2.1 20070719
  GCC host triplet: FreeBSD 7.2 amd64
GCC target triplet: amd64-undermydesk-freebsd


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

[Bug c/43604] Error on compilling kernel FreeBSD

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-03-31 14:03 
---
4.2.x is not maintained anymore.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/43605] New: Regression: wrong results with ftell

[manfred99 at gmx dot ch]

cat telltest.txt
123456
789
CC
DD


cat telltest.f
C234567
  integer i
  character*99 buffer
  open(10,FILE="telltest.txt")
  read(10,'(a)') buffer
  !!read(10,*) buffer
  call ftell(10,i)
  print*,i
  close(10)
  end

With gfortran-4.3, this prints "7".
With gfortran-4.5, I get "99" for the "(a)" variant,
and "80" for the "*" variant.

"7" is definitely the right answer, IMO.


-- 
   Summary: Regression: wrong results with ftell
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch


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

[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2010-03-31 14:27 ---
Working: 2009-04-05-r145558
Failing: 2009-04-06-r145580

Changelog shows a couple of I/O patches - and indeed if one uses the failing
version with libgfortran of 4.4.3 the bug is gone. The I/O patch I suspect is:
  PR fortran/38654
  http://gcc.gnu.org/viewcvs?view=rev&revision=145571

Which is - again - our beloved I/O restructuring check in. But this time,
GFORTRAN_UNBUFFERED_ALL makes no difference.

> "7" is definitely the right answer, IMO.

I agree that "7" makes more sense than 99 or 80, but ifort always prints "1"
and sunf95 prints "0" (while Open64, g95, and pathf95 do not have "ftell") -
thus "7" is not as universal as 42. :-)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
  Known to fail||4.4.4 4.5.0
  Known to work||4.3.4
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 14:27:13
   date||
Summary|Regression: wrong results   |[4.4/4.5 Regression] wrong
   |with ftell  |results with ftell
   Target Milestone|--- |4.4.4


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2010-03-31 
14:53 ---
Does this change applied to libmudflap (which we don't build on darwin) provide
a template for what we might need to do?

Author: jiez
Date: Fri Jan 23 04:58:03 2009
New Revision: 143583

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143583
Log:
libmudflap/
* mf-impl.h (__mf_get_state, __mf_set_state): Don't use
__thread when TLS support is emulated.
* mf-hooks3.c (__mf_get_state, __mf_set_state): Likewise.
* mf-runtime.c (__mf_state_1): Likewise.
* configure.ac: Use GCC_CHECK_EMUTLS.
* configure: Regenerate.
* config.h.in: Regenerate.

config/
* tls.m4 (GCC_CHECK_EMUTLS): Define.

Modified:
trunk/config/ChangeLog
trunk/config/tls.m4
trunk/libmudflap/ChangeLog
trunk/libmudflap/config.h.in
trunk/libmudflap/configure
trunk/libmudflap/configure.ac
trunk/libmudflap/mf-hooks3.c
trunk/libmudflap/mf-impl.h
trunk/libmudflap/mf-runtime.c

I noticed they they are opting out of using __thread in a particular case for
emulated TLS. Perhaps this is another instance requiring a similar change. This
was proposed in...

http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00406.html

and discussed in the thread leading up to that post (which terminates the
thread).


-- 


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

[Bug target/43597] Move and compare with 0 can be combined

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2010-03-31 14:59 ---
In .final, the insns look like this:
@(insn:TI 9 7 8 t.c:8 (set (reg:CC 24 cc)
@(compare:CC (reg:SI 0 r0 [orig:134 f ] [134])
@(const_int 0 [0x0]))) 220 {*arm_cmpsi_insn} (expr_list:REG_DEAD
(reg:SI 0 r0 [orig:134 f ] [134])
@(nil)))
cmp r0, #0  @ 9 *arm_cmpsi_insn/1   [length = 4]
@(insn 8 9 10 t.c:7 (set (reg/v:SI 5 r5 [orig:134 f ] [134])
@(reg:SI 0 r0)) 658 {*thumb2_movsi_insn} (nil))
mov r5, r0  @ 8 *thumb2_movsi_insn/1[length = 4]



This, AFAICT, would match with the pattern and constraints of movsi_compare0:

;; If copying one reg to another we can set the condition codes according to
;; its value.  Such a move is common after a return from subroutine and the
;; result is being tested against zero.

(define_insn "*movsi_compare0"
  [(set (reg:CC CC_REGNUM)
(compare:CC (match_operand:SI 1 "s_register_operand" "0,r")
(const_int 0)))
   (set (match_operand:SI 0 "s_register_operand" "=r,r")
(match_dup 1))]
  "TARGET_32BIT"
  "@
   cmp%?\\t%0, #0
   sub%.\\t%0, %1, #0"
  [(set_attr "conds" "set")]
)


But this insns can probably only be formed in the .combine pass, since (to the
best of my knowledge) we don't construct multiple-set insns in any other pass.

In the .combine pass, the two insns look like this (obviously reversed, as you
could already suspect from the insns numbers 9 and 8 above):

(insn 8 7 9 2 t.c:7 (set (reg/v:SI 134 [ f ])
(reg:SI 0 r0)) 658 {*thumb2_movsi_insn} (expr_list:REG_DEAD (reg:SI 0
r0)
(nil)))

(insn 9 8 10 2 t.c:8 (set (reg:CC 24 cc)
(compare:CC (reg/v:SI 134 [ f ])
(const_int 0 [0x0]))) 220 {*arm_cmpsi_insn} (nil))

But combine does not even try to combine these two insns:

...
insn_cost 24: 0

Trying 9 -> 10:
Failed to match this instruction:
(set (pc)
(if_then_else (lt (reg/v:SI 134 [ f ])
(const_int 0 [0x0]))
(label_ref:SI 29)
(pc)))


foo4
...



-- 


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

[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2010-03-31 15:07 ---
Janne, could you please have a look.

  * * *

The following looks very fishy:

  gfc_unit * u = find_unit (*unit);
  ret = (size_t) stell (u->s);


pt find_unit(*unit)->s
type = struct stream {
ssize_t (*read)(struct stream *, void *, ssize_t);
ssize_t (*write)(struct stream *, const void *, ssize_t);
gfc_offset (*seek)(struct stream *, gfc_offset, int);
gfc_offset (*tell)(struct stream *);
int (*trunc)(struct stream *, gfc_offset);
int (*flush)(struct stream *);
int (*close)(struct stream *);
}

stell (stream * s)
{
  return s->tell (s);

 

And in unix.c:

typedef struct
{
  stream st;
  (...)
  int fd;   /* The POSIX file descriptor.  */


raw_tell (unix_stream * s)
{
  return lseek (s->fd, 0, SEEK_CUR);

Which only works because of eval casting:
buf_init (unix_stream * s)
  s->st.tell = (void *) buf_tell;

 * * *

I have no idea whether the pointer is initialized correctly, but I can imagine
several ways how it could break (e.g. also with LTO) and it makes debugging a
mess!


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org


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

[Bug target/43597] Move and compare with 0 can be combined

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2010-03-31 15:15 ---
Well, according to GDB, combine does try to combine in try_combine:
Breakpoint 8, try_combine (i3=0x204fc8b8, i2=0x204fc828,
i1=0x0, new_direct_jump_p=0x6fd4ae28) at ../../trunk/gcc/combine.c:2389
2389  rtx newpat, newi2pat = 0;
3: debug_rtx(i3) = (insn 9 8 10 2 t.c:8 (set (reg:CC 24 cc)
(compare:CC (reg/v:SI 134 [ fD.1273 ])
(const_int 0 [0x0]))) 220 {*arm_cmpsi_insn} (nil))
void
2: debug_rtx(i2) = (insn 8 7 9 2 t.c:7 (set (reg/v:SI 134 [ fD.1273 ])
(reg:SI 0 r0)) 658 {*thumb2_movsi_insn} (expr_list:REG_DEAD (reg:SI 0
r0)
(nil)))

But then we hit cant_combine_insn_p(i2) because r0 is LO_REGS, we're compiling
for TARGET_THUMB, and so CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (src)))
is true for src=r0 in this reg-reg move:

  if (REG_P (src) && REG_P (dest)
  && ((REGNO (src) < FIRST_PSEUDO_REGISTER
   && ! fixed_regs[REGNO (src)]
   && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (src
  || (REGNO (dest) < FIRST_PSEUDO_REGISTER
  && ! fixed_regs[REGNO (dest)]
  && CLASS_LIKELY_SPILLED_P (REGNO_REG_CLASS (REGNO (dest))
return 1;


-- 


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #4 from howarth at nitro dot med dot uc dot edu  2010-03-31 
15:19 ---
If I am reading gcc/configure.ac correctly, darwin shouldn't using TLS in that
part of the build. So perhaps we just need to add a wrapper like...

Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 157868)
+++ gcc/tree-profile.c  (working copy)
@@ -82,7 +82,9 @@
   TREE_PUBLIC (ic_void_ptr_var) = 0;
   DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
   DECL_INITIAL (ic_void_ptr_var) = NULL;
+  #ifdef HAVE_AS_TLS
   DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
+  #endif 
   varpool_finalize_decl (ic_void_ptr_var);

   gcov_type_ptr = build_pointer_type (get_gcov_type ());

or do we need more tests for TLS in configure.ac there?


-- 


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2010-03-31 
15:23 ---
Of course this does beg the question of why other instances of...

DECL_TLS_MODEL ()=decl_default_tls_model ();

...such as...

DECL_TLS_MODEL (v) = decl_default_tls_model (v);

...in gcc/c-parser.c and...

DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);

in gcc/c-decl.c don't trigger undefined symbols on darwin.


-- 


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

[Bug bootstrap/43596] [4.5 regression] Failed to boostrap

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-03-31 15:27 ---
Subject: Bug 43596

Author: jakub
Date: Wed Mar 31 15:26:57 2010
New Revision: 157869

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157869
Log:
PR bootstrap/43596
* cselib.c (cselib_process_insn): Clear cselib_current_insn
even before returning from label, setjmp call or volatile asm
handling.

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


-- 


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

[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell

[jb at gcc dot gnu dot org]

--- Comment #3 from jb at gcc dot gnu dot org  2010-03-31 15:38 ---
Assigning to myself. This is probably due to ftell not taking into account
fbuf.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jb at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-03-31 14:27:13 |2010-03-31 15:38:45
   date||


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

[Bug bootstrap/43596] [4.5 regression] Failed to boostrap

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-03-31 15:47 ---
Hopefully fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug objc++/23613] obj-c++.dg/isa-field-1.mm fails with the GNU runtime

[janis at gcc dot gnu dot org]

--- Comment #8 from janis at gcc dot gnu dot org  2010-03-31 15:48 ---
Subject: Bug 23613

Author: janis
Date: Wed Mar 31 15:47:42 2010
New Revision: 157872

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157872
Log:
2010-03-31  Iain Sandoe  

PR objc++/23613
* gcc/testsuite/objc-obj-c++-shared/next-mapping.h (CLASSPTRFIELD):
New macro.
* gcc/testsuite/obj-c++.dg/isa-field-1.mm: Use new CLASSPTRFIELD macro.
Remove dg-xfail-if.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/isa-field-1.mm
trunk/gcc/testsuite/objc-obj-c++-shared/next-mapping.h


-- 


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[tschwinge at gcc dot gnu dot org]

--- Comment #24 from tschwinge at gcc dot gnu dot org  2010-03-31 15:49 
---
Regression report for arm-none-linux-gnueabi:

Patch: 


-- 

tschwinge at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu dot
   ||org


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

[Bug objc/35165] Massive failures of objc on i686-apple-darwin9

[janis at gcc dot gnu dot org]

--- Comment #14 from janis at gcc dot gnu dot org  2010-03-31 15:51 ---
Subject: Bug 35165

Author: janis
Date: Wed Mar 31 15:50:45 2010
New Revision: 157873

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157873
Log:
2010-03-31  Iain Sandoe  

PR testsuite/35165
* obj-c++.dg/try-catch-9.mm: Don't XFAIL m32 NeXT runtime.
* obj-c++.dg/try-catch-2.mm: Ditto.
* obj-c++.dg/lookup-2.mm: Ditto.
* obj-c++.dg/encode-8.m: Ditto.
* obj-c++.dg/cxx-ivars-2.mm: Ditto.
* obj-c++.dg/cxx-ivars-3.mm: Skip for GNU, XFail for m64 NeXT.
* obj-c++.dg/const-str-10.mm: Skip for GNU, match .quad for m64 NeXT.
* obj-c++.dg/const-str-11.mm: Ditto.
* obj-c++.dg/const-str-9.mm: Ditto.
* obj-c++.dg/bitfield-3.mm: Skip for GNU runtime.
* obj-c++.dg/bitfield-2.mm: XFAIL run for m64 NeXT runtime.
* obj-c++.dg/except-1.mm: Ditto.
* obj-c++.dg/const-str-7.mm: Ditto.
* obj-c++.dg/cxx-ivars-1.mm: Ditto.
* obj-c++.dg/const-str-3.mm: Ditto.
* obj-c++.dg/const-str-7.mm: Ditto.
* obj-c++.dg/stubify-2.mm: Change dump file name.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/bitfield-2.mm
trunk/gcc/testsuite/obj-c++.dg/bitfield-3.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-10.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-11.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-3.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-7.mm
trunk/gcc/testsuite/obj-c++.dg/const-str-9.mm
trunk/gcc/testsuite/obj-c++.dg/cxx-ivars-1.mm
trunk/gcc/testsuite/obj-c++.dg/cxx-ivars-2.mm
trunk/gcc/testsuite/obj-c++.dg/cxx-ivars-3.mm
trunk/gcc/testsuite/obj-c++.dg/encode-8.mm
trunk/gcc/testsuite/obj-c++.dg/except-1.mm
trunk/gcc/testsuite/obj-c++.dg/lookup-2.mm
trunk/gcc/testsuite/obj-c++.dg/stubify-2.mm
trunk/gcc/testsuite/obj-c++.dg/try-catch-2.mm
trunk/gcc/testsuite/obj-c++.dg/try-catch-9.mm


-- 


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

[Bug preprocessor/43606] New: Raw string support fails to preserve backslash whitespace newline

[jason at gcc dot gnu dot org]

...and so the execution test fails for c-c++-common/raw-string-7.c.


-- 
   Summary: Raw string support fails to preserve backslash
whitespace newline
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org


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

[Bug preprocessor/43606] Raw string support fails to preserve backslash whitespace newline

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-03-31 17:27:50
   date||


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

[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell

[pault at gcc dot gnu dot org]

--- Comment #4 from pault at gcc dot gnu dot org  2010-03-31 18:03 ---
(In reply to comment #3)
> Assigning to myself. This is probably due to ftell not taking into account
> fbuf.
> 
Janne,

I hate to say it but you are going to have to move pretty fast to beat Richi's
2nd April deadline - good luck!

Paul 


-- 


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

[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2010-03-31 18:05 ---
Note: For coarrays/coindexed variables, the shape must be the same. That means
that there is _no_ reallocate on assignment, cf. F2008, "7.2.1.2 Intrinsic
assignment statement":
"In an intrinsic assignment statement, [...] (3) the variable and expr shall be
conformable unless the variable is an allocatable array that has the same rank
as expr and is neither a coarray nor a coindexed object,"


-- 


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

[Bug libfortran/43572] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2010-03-31 18:08 ---
It appears to be a regression.  See results for 4.4:
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg02690.html

I'll rebuild 4.5 and check point a.


-- 


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

[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux

[uros at gcc dot gnu dot org]

--- Comment #12 from uros at gcc dot gnu dot org  2010-03-31 18:09 ---
Subject: Bug 43528

Author: uros
Date: Wed Mar 31 18:09:04 2010
New Revision: 157880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157880
Log:
Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* stor-layout.c (place_field): Check that constant fits into
unsigned HWI when skipping calculation of MS bitfield layout.

2010-03-26  Uros Bizjak  

PR target/43524
* config/i386/i386.c (ix86_expand_prologue) [TARGET_STACK_PROBE]:
Remove invalid assert and wrong comment.

testsuite/ChangeLog:

Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* gcc.target/i386/pr43528.c: New test.

2010-03-26  Uros Bizjak  

PR target/43524
* gcc.target/i386/pr43524.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43524.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43528.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/stor-layout.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43524] ICE: in ix86_expand_prologue, at config/i386/i386.c:8636 with -mstack-arg-probe on x86_64-linux

[uros at gcc dot gnu dot org]

--- Comment #4 from uros at gcc dot gnu dot org  2010-03-31 18:09 ---
Subject: Bug 43524

Author: uros
Date: Wed Mar 31 18:09:04 2010
New Revision: 157880

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157880
Log:
Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* stor-layout.c (place_field): Check that constant fits into
unsigned HWI when skipping calculation of MS bitfield layout.

2010-03-26  Uros Bizjak  

PR target/43524
* config/i386/i386.c (ix86_expand_prologue) [TARGET_STACK_PROBE]:
Remove invalid assert and wrong comment.

testsuite/ChangeLog:

Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* gcc.target/i386/pr43528.c: New test.

2010-03-26  Uros Bizjak  

PR target/43524
* gcc.target/i386/pr43524.c: New test.


Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43524.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43528.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/stor-layout.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/43351] ICE: SIGSEGV with -fgraphite-identity in 4.4

[spop at gcc dot gnu dot org]

--- Comment #4 from spop at gcc dot gnu dot org  2010-03-31 18:37 ---
Subject: Bug 43351

Author: spop
Date: Wed Mar 31 18:36:45 2010
New Revision: 157882

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157882
Log:
Add testcase for PR43351.

2010-03-13  Sebastian Pop  

PR middle-end/43351
* gcc.dg/graphite/id-pr43351.c

Added:
trunk/gcc/testsuite/gcc.dg/graphite/id-pr43351.c
Modified:
trunk/gcc/ChangeLog.graphite


-- 


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

[Bug middle-end/43464] copy prop breaks loop closed SSA form

[spop at gcc dot gnu dot org]

--- Comment #15 from spop at gcc dot gnu dot org  2010-03-31 18:38 ---
Subject: Bug 43464

Author: spop
Date: Wed Mar 31 18:37:41 2010
New Revision: 157889

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157889
Log:
Fix PR43464: copyprop should maintain loop close phi nodes with multiple
arguments.

2010-03-30  Richard Guenther  
Zdenek Dvorak  
Sebastian Pop  

PR middle-end/43464
* tree-ssa-copy.c (init_copy_prop): Handle loop close phi nodes
with multiple arguments.
(execute_copy_prop): Remove call to rewrite_into_loop_closed_ssa.

Modified:
trunk/gcc/ChangeLog.graphite
trunk/gcc/tree-ssa-copy.c


-- 


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

[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell

[jb at gcc dot gnu dot org]

--- Comment #5 from jb at gcc dot gnu dot org  2010-03-31 18:42 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01523.html


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||03/msg01523.html


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

[Bug middle-end/43464] copy prop breaks loop closed SSA form

[spop at gcc dot gnu dot org]

--- Comment #16 from spop at gcc dot gnu dot org  2010-03-31 18:48 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug lto/43581] exception handling broken across shared libaries with -fuse-linker-plugin

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2010-03-31 18:49 ---
Here's the analogous test case from Libtool for dlopen'ed modules.  Also passes
when -fuse-linker-plugin is removed from the link line for module.so.

CXX=g++
CXXFLAGS='-O2 -flto'
LDFLAGS='-fuse-linker-plugin'

cat >module.h <<\EOF
#include 
#include 
class modexc : public std::exception {
public:
  modexc (std::string str) : message (str) { }
  ~modexc () throw () { }
  virtual const char *what () const throw ()
  {
return message.c_str ();
  }
private:
  std::string message;
};
extern "C" int modfoo () throw (modexc);
EOF

cat >module.cpp <<\EOF
#include 
#include "module.h"

int modbar (void) throw (modexc)
{
  throw modexc ("exception in module");
}

extern "C"
int modfoo (void) throw (modexc)
{
  try {
modbar ();
  }
  catch (modexc e) {
std::cerr << "caught inside module: " << e.what () << '\n';
throw modexc ("exception from module");
  }
  return 0;
}
EOF

cat >main.cpp <<\EOF
#include 
#include 
#include 
#include 
#include "module.h"

class exc : public std::exception {
public:
  exc (std::string str) : message (str) { }
  ~exc () throw () { }
  virtual const char *what () const throw ()
  {
return message.c_str ();
  }
private:
  std::string message;
};

int exceptions_in_module (void)
{
  std::cerr << "exceptions_in_module\n";

  void *handle = dlopen ("module.so", RTLD_GLOBAL | RTLD_LAZY);
  if (handle == NULL)
{
  std::cerr << "dlopen failed: " << dlerror () << '\n';
  return 1;
}

  typedef int (*pfun) (void);
  pfun pf = (pfun) dlsym (handle, "modfoo");
  if (pf == NULL)
{
  std::cerr << "dlsym failed: " << dlerror () << '\n';
  return 1;
}

  try {
(*pf) ();
  }
  catch (modexc e) {
std::cerr << "caught: " << e.what () << '\n';
if (dlclose (handle))
  {
std::cerr << "dlclose failed: " << dlerror () << '\n';
return 1;
  }
return 0;
  }
  return 1;
}

int main (void)
{
  if (exceptions_in_module ())
return 1;
  return 0;
}
EOF

$CXX $CXXFLAGS -c main.cpp
$CXX $CXXFLAGS -c module.cpp -fPIC -o module.o
$CXX $CXXFLAGS $LDFLAGS -fPIC -shared module.o -o module.so
$CXX $CXXFLAGS $LDFLAGS -o main main.o -Wl,--export-dynamic -ldl
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH ./main


-- 


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

[Bug lto/43576] lto: ICE with partial linking (ld -r, both bfd and gold)

[rwild at gcc dot gnu dot org]

--- Comment #1 from rwild at gcc dot gnu dot org  2010-03-31 18:53 ---
FWIW, same failure happens with  s/-flto/-fwhopr/g but is probably worth
another testcase once fixed.


-- 


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

[Bug middle-end/43607] New: ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape

[zsojka at seznam dot cz]

+++ This bug was initially created as a clone of Bug #38360 +++

The testcase fails with -fipa-type-escape:

trunk r157877:
$ /mnt/svn/gcc-trunk/binary-157877-lto/bin/gcc -fipa-type-escape
testsuite/gcc.c-torture/compile/pr38360.c
testsuite/gcc.c-torture/compile/pr38360.c:9:1: internal compiler error: in
gimple_op, at gimple.h:1633

4.4 r153668:
$ /mnt/svn/gcc-4_4/binary-153668/bin/gcc -fipa-type-escape
testsuite/gcc.c-torture/compile/pr38360.c
testsuite/gcc.c-torture/compile/pr38360.c:9: internal compiler error: in
gimple_op, at gimple.h:1609

4.3.4 (no checking):
$ gcc-4.3.4 -fipa-type-escape testsuite/gcc.c-torture/compile/pr38360.c
testsuite/gcc.c-torture/compile/pr38360.c: In function 'main':
testsuite/gcc.c-torture/compile/pr38360.c:9: internal compiler error:
Segmentation fault


-- 
   Summary: ICE in gimple_op, at gimple.h:1633 with -fipa-type-
escape
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz


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

[Bug middle-end/43607] ICE in gimple_op, at gimple.h:1633 with -fipa-type-escape

[zsojka at seznam dot cz]

--- Comment #1 from zsojka at seznam dot cz  2010-03-31 19:36 ---
Created an attachment (id=20266)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20266&action=view)
testsuite/gcc.c-torture/compile/pr38360.c


-- 


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

[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux

[uros at gcc dot gnu dot org]

--- Comment #13 from uros at gcc dot gnu dot org  2010-03-31 20:14 ---
Subject: Bug 43528

Author: uros
Date: Wed Mar 31 20:14:10 2010
New Revision: 157894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157894
Log:
Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* stor-layout.c (place_field): Check that constant fits into
unsigned HWI when skipping calculation of MS bitfield layout.

2010-03-26  Uros Bizjak  

PR target/43524
* config/i386/i386.c (ix86_expand_prologue) [TARGET_STACK_PROBE]:
Remove invalid assert and wrong comment.

testsuite/ChangeLog:

Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* gcc.target/i386/pr43528.c: New test.

2010-03-26  Uros Bizjak  

PR target/43524
* gcc.target/i386/pr43524.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr43524.c
  - copied unchanged from r157880,
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43524.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr43528.c
  - copied unchanged from r157880,
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43528.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c
branches/gcc-4_3-branch/gcc/stor-layout.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/43524] ICE: in ix86_expand_prologue, at config/i386/i386.c:8636 with -mstack-arg-probe on x86_64-linux

[uros at gcc dot gnu dot org]

--- Comment #5 from uros at gcc dot gnu dot org  2010-03-31 20:14 ---
Subject: Bug 43524

Author: uros
Date: Wed Mar 31 20:14:10 2010
New Revision: 157894

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157894
Log:
Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* stor-layout.c (place_field): Check that constant fits into
unsigned HWI when skipping calculation of MS bitfield layout.

2010-03-26  Uros Bizjak  

PR target/43524
* config/i386/i386.c (ix86_expand_prologue) [TARGET_STACK_PROBE]:
Remove invalid assert and wrong comment.

testsuite/ChangeLog:

Backport from mainline:
2010-03-27  Uros Bizjak  

PR tree-optimization/43528
* gcc.target/i386/pr43528.c: New test.

2010-03-26  Uros Bizjak  

PR target/43524
* gcc.target/i386/pr43524.c: New test.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr43524.c
  - copied unchanged from r157880,
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43524.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr43528.c
  - copied unchanged from r157880,
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr43528.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/i386/i386.c
branches/gcc-4_3-branch/gcc/stor-layout.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/43528] ICE: in tree_low_cst, at tree.c:6198 with -mms-bitfields at x86_64-linux

[ubizjak at gmail dot com]

--- Comment #14 from ubizjak at gmail dot com  2010-03-31 20:17 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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

[Bug c++/43608] New: Boost.MPL code doesn't get the placeholders substituted anymore

[sefi at s-e-f-i dot de]

The following code stopped working with gcc-4.5.
gcc-4.4.3 and clang both accept it.
On gcc-4.5, boost::mpl_::arg<2> is passed to metafunction instead of test1.
The strange thing is: If the specialization of metafunction<_2> is provided,
the code works again.
I'm sorry that this is not a minimal test case, because I don't know how to get
rid of the MPL parts.


#include 
#include 
#include 
#include 
#include 

struct test1
{
typedef int inner_type;
};

template<
typename Foo
>
struct metafunction
{
typedef typename Foo::inner_type type;
};

#if 0
template<>
struct metafunction<
boost::mpl::_2
>;
#endif

int main()
{
typedef boost::mpl::fold<
boost::mpl::vector1<
test1
>,
boost::mpl::vector0<>,
boost::mpl::push_back<
boost::mpl::_1,
metafunction<
boost::mpl::_2
>
>
>::type transformed;

boost::mpl::at_c::type i = 42;
}


-- 
   Summary: Boost.MPL code doesn't get the placeholders substituted
anymore
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sefi at s-e-f-i dot de


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

[Bug target/43524] ICE: in ix86_expand_prologue, at config/i386/i386.c:8636 with -mstack-arg-probe on x86_64-linux

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2010-03-31 20:18 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.5


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-03-31 
20:21 ---
Untested patch...

Index: varasm.c
===
--- varasm.c(revision 157893)
+++ varasm.c(working copy)
@@ -332,6 +332,7 @@
   TREE_STATIC (to) = TREE_STATIC (decl);
   TREE_PUBLIC (to) = TREE_PUBLIC (decl);
   DECL_VISIBILITY (to) = DECL_VISIBILITY (decl);
+  DECL_VISIBILITY_SPECIFIED (to) = DECL_VISIBILITY_SPECIFIED (decl);
 }
   else
 TREE_STATIC (to) = 1;
@@ -353,8 +354,8 @@
   struct tree_map *h, in;
   void **loc;

-  if (targetm.have_tls || decl == NULL || decl == error_mark_node
-  || TREE_CODE (decl) != VAR_DECL || ! DECL_THREAD_LOCAL_P (decl))
+  assert (!targetm.have_tls && TREE_CODE (decl) == VAR_DECL
+  && DECL_THREAD_LOCAL_P (decl));
 return decl;

   /* Look up the object in the hash; return the control structure if
@@ -413,6 +414,7 @@
   DECL_COMMON (to) = DECL_COMMON (decl);
   DECL_WEAK (to) = DECL_WEAK (decl);
   DECL_VISIBILITY (to) = DECL_VISIBILITY (decl);
+  DECL_VISIBILITY_SPECIFIED (to) = DECL_VISIBILITY_SPECIFIED (decl);

   return to;
 }
Index: tree-profile.c
===
--- tree-profile.c  (revision 157893)
+++ tree-profile.c  (working copy)
@@ -79,7 +79,8 @@
  get_identifier ("__gcov_indirect_call_callee"),
  ptr_void);
   TREE_STATIC (ic_void_ptr_var) = 1;
-  TREE_PUBLIC (ic_void_ptr_var) = 0;
+  TREE_PUBLIC (ic_void_ptr_var) = 1;
+  DECL_COMMON (ic_void_ptr_var) = 1;
   DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
   DECL_INITIAL (ic_void_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_void_ptr_var) = decl_default_tls_model (ic_void_ptr_var);
@@ -91,7 +92,8 @@
  get_identifier ("__gcov_indirect_call_counters"),
  gcov_type_ptr);
   TREE_STATIC (ic_gcov_type_ptr_var) = 1;
-  TREE_PUBLIC (ic_gcov_type_ptr_var) = 0;
+  TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
+  DECL_COMMON (ic_void_ptr_var) = 1;
   DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
   DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
   DECL_TLS_MODEL (ic_gcov_type_ptr_var) = decl_default_tls_model
(ic_gcov_type_ptr_var);


-- 


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

[Bug lto/43609] New: LTO -fwhopr generating shared library: ICE in csi_node at cgraph.h:663

[rwild at gcc dot gnu dot org]

touch a.c
gcc -fPIC -fwhopr -O2 -c a.c
gcc -shared -fPIC a.o -fwhopr -O2 -o liba.so

leads to:

lto1: internal compiler error: vector VEC(cgraph_node_ptr,base) index domain
error, in csi_node at cgraph.h:663
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: gcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Doesn't happen with -flto instead of -fwhopr at link time, or with neither
flag.

This ICE fails several tests in the Libtool testsuite, with several different
(valid) source files.  I'm guessing the actual source file contents are
irrelevant for the bug.

If the -fwhopr flag was not meant to be passed at shared library creation time,
then this would be a documentation bug and an ice-on-invalid-code instead.


-- 
   Summary: LTO -fwhopr generating shared library: ICE in csi_node
at cgraph.h:663
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, lto
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwild at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[dominiq at lps dot ens dot fr]

--- Comment #7 from dominiq at lps dot ens dot fr  2010-03-31 20:40 ---
> +  assert (!targetm.have_tls && TREE_CODE (decl) == VAR_DECL
> +  && DECL_THREAD_LOCAL_P (decl));

s/assert/gcc_assert/


-- 


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2010-03-31 20:54 ---
With the patch in comment #6, I get:

[macbook] f90/bug% gcc45 -fprofile-generate -O3
/opt/gcc/work/gcc/testsuite/gcc.dg/matrix/transpose-1.c
gcc45: Internal error: Segmentation fault (program cc1)

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x7fff5bc00ff8
0x000100811f9b in lookup_attribute (attr_name=0x10098a348 "ms_abi",
list=0x141dafbb8) at ../../work/gcc/tree.c:5073
5073{
(gdb) bt
#0  0x000100811f9b in lookup_attribute (attr_name=0x10098a348 "ms_abi",
list=0x141dafbb8) at ../../work/gcc/tree.c:5073
#1  0x00010087020c in ix86_function_type_abi (fntype=) at ../../work/gcc/config/i386/i386.c:4816
#2  0x000100870a45 in ix86_reg_parm_stack_space (fndecl=) at ../../work/gcc/config/i386/i386.c:4798
#3  0x000100317db4 in expand_call (exp=0x101774288, target=0x0, ignore=0)
at ../../work/gcc/calls.c:2082
#4  0x0001002fab1e in expand_builtin (exp=0x101774288, target=0x0,
subtarget=0x0, mode=,
ignore=0) at ../../work/gcc/builtins.c:6418
#5  0x000100405673 in expand_expr_real_1 (exp=0x101774288, target=, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9251
#6  0x000100415092 in expand_expr_real_2 (ops=0x7fff5bc01630, target=, tmode=DImode,
modifier=EXPAND_NORMAL) at expr.h:558
#7  0x00010040401f in expand_expr_real_1 (exp=0x101773810, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9650
#8  0x000100412127 in expand_expr_addr_expr_1 (exp=, target=0x0, tmode=DImode,
modifier=EXPAND_NORMAL, as=) at expr.h:558
#9  0x000100405d16 in expand_expr_real_1 (exp=0x101773720, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:7007
#10 0x00010031a656 in expand_call (exp=0x101774240, target=0x0, ignore=0)
at expr.h:564
#11 0x0001002fab1e in expand_builtin (exp=0x101774240, target=0x0,
subtarget=0x0, mode=,
ignore=0) at ../../work/gcc/builtins.c:6418
#12 0x000100405673 in expand_expr_real_1 (exp=0x101774240, target=, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9251
#13 0x000100415092 in expand_expr_real_2 (ops=0x7fff5bc01fb0, target=, tmode=DImode,
modifier=EXPAND_NORMAL) at expr.h:558
#14 0x00010040401f in expand_expr_real_1 (exp=0x101773780, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9650
#15 0x000100412127 in expand_expr_addr_expr_1 (exp=, target=0x0, tmode=DImode,
modifier=EXPAND_NORMAL, as=) at expr.h:558
#16 0x000100405d16 in expand_expr_real_1 (exp=0x101773690, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:7007
#17 0x00010031a656 in expand_call (exp=0x1017741f8, target=0x0, ignore=0)
at expr.h:564
#18 0x0001002fab1e in expand_builtin (exp=0x1017741f8, target=0x0,
subtarget=0x0, mode=,
ignore=0) at ../../work/gcc/builtins.c:6418
#19 0x000100405673 in expand_expr_real_1 (exp=0x1017741f8, target=, tmode=VOIDmode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9251
#20 0x000100415092 in expand_expr_real_2 (ops=0x7fff5bc02930, target=, tmode=DImode,
modifier=EXPAND_NORMAL) at expr.h:558
#21 0x00010040401f in expand_expr_real_1 (exp=0x1017736f0, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:9650
#22 0x000100412127 in expand_expr_addr_expr_1 (exp=, target=0x0, tmode=DImode,
modifier=EXPAND_NORMAL, as=) at expr.h:558
#23 0x000100405d16 in expand_expr_real_1 (exp=0x101773600, target=, tmode=DImode,
modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../work/gcc/expr.c:7007
...
and so on
...


-- 


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

[Bug middle-end/43602] ___emutls_v.__gcov_indirect_call_[counters|callee] undefined on *-*-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-03-31 
21:05 ---
What happens if you revert the section...

@@ -353,8 +354,8 @@
   struct tree_map *h, in;
   void **loc;

-  if (targetm.have_tls || decl == NULL || decl == error_mark_node
-  || TREE_CODE (decl) != VAR_DECL || ! DECL_THREAD_LOCAL_P (decl))
+  assert (!targetm.have_tls && TREE_CODE (decl) == VAR_DECL
+  && DECL_THREAD_LOCAL_P (decl));
 return decl;

   /* Look up the object in the hash; return the control structure if


-- 


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

[Bug target/21803] [ia64] gcc produces really odd predicated code

[bernds at codesourcery dot com]

--- Comment #4 from bernds at codesourcery dot com  2010-03-31 21:36 ---
Patch at
  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01536.html

Only tested on ARM (same issue as PR42496), but should also solve the ia64
problem.


-- 


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

[Bug rtl-optimization/21803] [ia64] gcc produces really odd predicated code

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2010-03-31 21:37 ---
I had saw this too and I thought I filed a bug about this same problem but I
cannot find it right now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |rtl-optimization


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

[Bug target/41514] redundant compare instruction of consecutive conditional branches

[bernds at codesourcery dot com]

--- Comment #4 from bernds at codesourcery dot com  2010-03-31 21:41 ---
A simple patch is at http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01405.html


-- 

bernds at codesourcery dot com changed:

   What|Removed |Added

 CC||bernds at codesourcery dot
   ||com


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