[Bug libgcj/38298] libjava link failures.

[rwild at gcc dot gnu dot org]

--- Comment #9 from rwild at gcc dot gnu dot org  2009-09-26 09:03 ---
proposed patch at .


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-26 09:03:36
   date||


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

[Bug lto/40758] [LTO] ICE in partition_view_bitmap, at tree-ssa-live.c:331

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2009-09-26 16:47 ---
Subject: Bug 40758

Author: matz
Date: Sat Sep 26 16:46:43 2009
New Revision: 152203

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152203
Log:
PR lto/40758
PR middle-end/41470
* tree-ssa-coalesce.c (coalesce_ssa_name): Add only SSA names
that are mentioned in the body.

testsuite/
* gcc.dg/pr41470.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr41470.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-coalesce.c


-- 


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

[Bug debug/41474] [4.5 Regression] 951116-1.c ICEs in mem_loc_descriptor, at dwarf2out.c:11279

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-09-26 12:13 ---
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..." since revision 151907

On Sat, 26 Sep 2009, dominiq at lps dot ens dot fr wrote:

> --- Comment #2 from dominiq at lps dot ens dot fr  2009-09-26 12:10 
> ---
> > How's that a GCC bug?
> 
> Can you PROVE it is not? If you have a PROOF, could you be kind enough to post
> it so we can fill a bug report upstream. Meanwhile the WAITING status is fine.

I can't PROVE it.  But I think it's not the obligation of GCC developers
to prove that a bug is not a bug in GCC.  It is up to the reporter to
make reasonable arguments that a bug is a GCC bug, for example by
providing a testcase that makes the bug show up with only GCC tools,
or by showing GCC output and comparing it to whatever specs exist
for the output format and show that GCC doesn't conform.

So, file the bug report upstream please.  By your reasoning they'd have
to PROVE that it isn't their bug.

Richard.


-- 


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

[Bug middle-end/41470] [4.5 Regression] -fexceptions ICE in partition_view_bitmap, at tree-ssa-live.c:331

[matz at gcc dot gnu dot org]

--- Comment #4 from matz at gcc dot gnu dot org  2009-09-26 16:50 ---
Fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/40205] OpenMP do loop with MAXINT gives wrong trip count

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2009-09-26 10:15 ---
Jakub, OpenMP bug, is this something you have time for?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug rtl-optimization/40987] Wrong optimization with if-conversion

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||09/msg01655.html
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||patch
   Last reconfirmed|-00-00 00:00:00 |2009-09-26 10:18:29
   date||


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

[Bug middle-end/24332] asm label declaration may be missing aliasing info

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-26 11:30 ---
Undefined / invalid.

There is no sensible way to deal with aliasing here without pessimizing every
legitimate use.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at gcc dot gnu dot org]

--- Comment #7 from geoffk at gcc dot gnu dot org  2009-09-26 11:51 ---
I looked up 'weakref' in the GCC documentation because I'd forgotten exactly
what it was supposed to do, and noticed that it's actually documented as
applying only to functions.  So, maybe we could just say that this attribute is
only allowed for functions, and produce an error on line 3.

Alexandre's original mail proposing the extension,
, suggests the attribute for
both variables and functions, but the explanation of why you'd want this
feature only talks about functions.

The weakref documentation does specifically talk about the case where the
function is referenced both via the weakref and directly through the original
symbol, and I think the typical use cases actually do this.


-- 


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

[Bug tree-optimization/41454] [4.4 Regression] DOM miscompiles gcc.c-torture/execute/990513-1.c at -O2 -fno-tree-vrp

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-09-26 11:20 ---
Fixed on trunk.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Known to fail||4.4.1
  Known to work||4.5.0
 Resolution|FIXED   |
Summary|[4.4/4.5 Regression] DOM|[4.4 Regression] DOM
   |miscompiles gcc.c-  |miscompiles gcc.c-
   |torture/execute/990513-1.c  |torture/execute/990513-1.c
   |at -O2 -fno-tree-vrp|at -O2 -fno-tree-vrp


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2009-09-26 12:10 ---
> How's that a GCC bug?

Can you PROVE it is not? If you have a PROOF, could you be kind enough to post
it so we can fill a bug report upstream. Meanwhile the WAITING status is fine.


-- 

dominiq at lps dot ens dot fr changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[geoffk at gcc dot gnu dot org]

--- Comment #9 from geoffk at gcc dot gnu dot org  2009-09-26 12:15 ---
(In reply to comment #8)
> Hm, I only can see references to "symbol" not to either function or variable
> declaration in the documentation.  Can you cite the part that makes you think
> it restricts the use to functions?

It's documented in the section on function attributes, but not listed in the
section on variable attributes.  Compare 'deprecated' or 'weak', which are
listed in both places.

It does say 'symbol' in referring to the target, but I doubt it's really
supposed to mean that you can declare a function as a weakref to a variable
(and that couldn't work anyway on most platforms, the variable will be in a
non-executable region of memory).


-- 


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

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-26 12:01 ---
Hm, I only can see references to "symbol" not to either function or variable
declaration in the documentation.  Can you cite the part that makes you think
it restricts the use to functions?


-- 


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

[Bug target/8010] [vax-netbsdelf] ICE in extract_insn for g77.f-torture/execute/20010116.f

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2009-09-26 09:53 ---
Wow, a g77 bug.  I thought we had all of those closed by now -- g77 is
unsupported since GCC 4.0.  Closing this as WONTFIX.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/20165] Pointer does not really escape with write

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-26 15:33 ---
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|NEW |ASSIGNED
   Last reconfirmed|2006-03-05 03:09:54 |2009-09-26 15:33:38
   date||


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

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

[hjl dot tools at gmail dot com]

--- Comment #49 from hjl dot tools at gmail dot com  2009-09-26 14:06 
---
(In reply to comment #48)
> It can be seen from the patch. I don't know how to detect that a structure
> contains an array with required SSE align, so I realign the stack for all 
> types

Please find a testcase first. Otherwise, nothing will be done. Thanks.


-- 


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

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

[hjl dot tools at gmail dot com]

--- Comment #53 from hjl dot tools at gmail dot com  2009-09-26 16:58 
---
Created an attachment (id=18656)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18656&action=view)
An updated patch for gcc 4.4

Oops. Wrong patch.  Trry this one.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #18655|0   |1
is obsolete||


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

[Bug middle-end/41470] [4.5 Regression] -fexceptions ICE in partition_view_bitmap, at tree-ssa-live.c:331

[matz at gcc dot gnu dot org]

-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |matz at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-09-25 15:04:20 |2009-09-26 16:49:41
   date||


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-26 11:19 ---
How's that a GCC bug?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/41475] common variables cannot be expected to be aligned

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-26 14:37 ---
The bug is about common symbols.


-- 


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

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

[hjl dot tools at gmail dot com]

--- Comment #52 from hjl dot tools at gmail dot com  2009-09-26 16:55 
---
Created an attachment (id=18655)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18655&action=view)
An updated patch for gcc 4.4

Please try this patch for gcc 4.4.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Attachment #18618|0   |1
is obsolete||


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

[Bug middle-end/41475] common variables cannot be expected to be aligned

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-09-26 14:14 ---
(In reply to comment #4)
> Isn't this a linker issue in that it doesn't use the biggest alignment?
> 

Linker can't change alignment on non-common symbols. I think it is wrong
to give a different alignment for the same symbol in different files.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

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

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #50 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-09-26 15:44 ---
> Please find a testcase first. Otherwise, nothing will be done. Thanks.

I don't want anything to be done (unless the patch causes generation of wrong
code --- I am not aware of such case).

I am saying that the patch could be included in 4.4 as a quick fix and that 4.5
needs stack alignment redesign. You can't redesign it by incrementally testing
against a set of examples. You (or someone else) need to sit down, draft the
rules for propagation of preferred and enforced alignment across types down to
the stack frame and code it. If you understand what you're doing, you can
create test examples on your own. If you don't understand, then don't hack it
at all.


-- 


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

[Bug middle-end/25140] aliases, including weakref, break alias analysis

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-26 11:29 ---
Whoever designed this feature should be beaten with a cluebat for not asking
people on how this will interact with aliasing.

IMHO the testcase should be declared invalid and it should be documented that
an aliased or weakreffed var may be only accessed via its original declaration
(x in this case).

Case closed for me.  Any other way not only breaks points-to analysis but
also trivial alias checks throughout the compiler.


-- 


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

[Bug middle-end/41470] [4.5 Regression] -fexceptions ICE in partition_view_bitmap, at tree-ssa-live.c:331

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2009-09-26 16:47 ---
Subject: Bug 41470

Author: matz
Date: Sat Sep 26 16:46:43 2009
New Revision: 152203

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152203
Log:
PR lto/40758
PR middle-end/41470
* tree-ssa-coalesce.c (coalesce_ssa_name): Add only SSA names
that are mentioned in the body.

testsuite/
* gcc.dg/pr41470.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr41470.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-coalesce.c


-- 


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

[Bug c/41476] New: [4.5 regression] __typeof__ expands to const type

[schwab at linux-m68k dot org]

When __typeof__ is applied to a conditional expression that contains a call to
a const function it expands to a const type.

$ cat tgmath.c
int foo (int) __attribute__ ((const));

void
test (void)
{
  __typeof__ (1 ? foo (0) : 0) texpr;
  texpr = 0;
}
$ gcc -c tgmath.c 
tgmath.c: In function ‘test’:
tgmath.c:7:3: error: assignment of read-only variable ‘texpr’


-- 
   Summary: [4.5 regression] __typeof__ expands to const type
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at linux-m68k dot org


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

[Bug rtl-optimization/20972] Register allocator/reload uses auto-inc register in non-addressing operand

[steven at gcc dot gnu dot org]

--- Comment #12 from steven at gcc dot gnu dot org  2009-09-26 09:58 ---
Is there still a bug here, after the IRA merge?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ra


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

[Bug middle-end/41475] common variables cannot be expected to be aligned

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-09-26 11:23 ---
Isn't this a linker issue in that it doesn't use the biggest alignment?


-- 


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

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

[hjl dot tools at gmail dot com]

--- Comment #51 from hjl dot tools at gmail dot com  2009-09-26 16:15 
---
(In reply to comment #50)
> 
> I am saying that the patch could be included in 4.4 as a quick fix and that 
> 4.5
> needs stack alignment redesign. You can't redesign it by incrementally testing
> against a set of examples. You (or someone else) need to sit down, draft the
> rules for propagation of preferred and enforced alignment across types down to
> the stack frame and code it. If you understand what you're doing, you can
> create test examples on your own. If you don't understand, then don't hack it
> at all.
>

The stack realignment works correctly as designed. The problems come from

1. Gcc generates code for 16byte-aligned incoming stack.
2. Gcc generates 16byte-aligned outgoing stack.
3. SSE variables segfault if they aren't 16byte aligned.
4. Some incoming stacks aren't aligned at 16byte, which violates #1 and
may cause #3.

We have to do #2 since many existing binaries need 16byte-aligned
incoming stack. If we assume incoming stack is 4byte aligned, we
have to realign stack for every function due to #2, which isn't
acceptable. To accommodate #4, which isn't strictly required, and
avoid #3 with minimum stack realignment, we need to list all #4
cases which lead to #3. Then we can investigate how to address them.


-- 


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

[Bug middle-end/41475] common variables cannot be expected to be aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-09-26 15:27 ---
Richard Guenther: the bug caused by common symbol (in file commonalign1.o) with
the same name as data section symbol (in file commonalign2.o). In this case,
the linker redirects the common symbol to the symbol in the data section. But
the linker cannot change the content of the data section, so it cannot make
both symbols array and array2 aligned. Linker is innocent in this and giving a
warning is the best thing it can do.


-- 


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

[Bug tree-optimization/41186] VN doesn't look through non-aliasing by offset memcpy

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-09-26 15:27 ---
Fixed.  Related is PR13954 where VN does not look through (partial) struct
copies
using memcpy.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-09-26 15:30 
---
On trunk we get

:
  # .MEM_3 = VDEF <.MEM_2(D)>
  param.f1 = 0;
  # .MEM_4 = VDEF <.MEM_3>
  memcpy (&local, ¶m, 9);
  # VUSE <.MEM_4>
  D.1743_1 = local.f1;
  if (D.1743_1 != 0)
goto ;
  else
goto ;

:
  # .MEM_5 = VDEF <.MEM_4>
  link_error ();

:
  return;

which shows this is an issue of value-numbering not looking through
memcpy.  SRA obviously does not work here because both vars have their
address taken.  The issue in the summary should have been fixed by the
SRA rewrite.

I'm looking at the VN issue.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2006-10-24 12:34:46 |2009-09-26 15:30:16
   date||


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

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

[developer at sandoe-acoustics dot co dot uk]

--- Comment #46 from developer at sandoe-acoustics dot co dot uk  
2009-09-26 17:28 ---
Created an attachment (id=18657)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18657&action=view)
much simplified version of the ext patch

OK. Jack made a Good Catch there... 

There is a much simpler way of doing this; using the -R option on strip one can
make an "ext" lib that refers to all the symbols not in the 10.X.dylib (using
the ver files that generate those stub libs).

So I now generate two new stub libs (_ext.10.X.dylib) that contain the set of
missing symbols.  The stub files refer to the newly built libgcc_s.1.dylib
installed along with gcc.

I don't know that "scalable" is exactly the right term - but this is '0
maintenance' unless a new version of 10.5 or 10.4 libgcc_s is made (unlikely at
this stage).

bootstrapped on i686-apple-darwin9, and x86_64-apple-darwin10 (reg-testing on
both).

more than 20 lines... but not too too much.

Log:
  *libgcc/configure.ac: Make sure the the rpath is correct in build tree
libraries when using --enable-version-specific-runtime-libs.
  *libgcc/configure: Regenerated.
  *libgcc/config/t-slibgcc-darwin: Don't make the _s.10X.dylib stubs unless
we're building for /usr/lib.  Build libgcc_ext.10.X.dylib containing newer
symbols
  *gcc/config/darwin.opt: Add muse-shared-libgcc-ext to hide behind for
testing.
  *gcc/config/darwin.h: use libgcc_ext.10.X to provide newer gcc functionality
to older systems

there are NO new files needed.


-- 


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

[Bug target/40641] gcc-4.4.0 does not honor the alway_inline attribute when using -Os

[florian at openwrt dot org]

--- Comment #8 from florian at openwrt dot org  2009-09-26 17:59 ---
(In reply to comment #7)
> Ping ? Anything else I should provide ? The bug is still present with 
> gcc-4.4.1
> 

The bug is now solved with Dan's uClibc patch to prevent some registers to be
clobberd in syscalls.(In reply to comment #7)
> Ping ? Anything else I should provide ? The bug is still present with 
> gcc-4.4.1
> 

The bug is fixed with the following patch :
http://lists.uclibc.org/pipermail/uclibc/2009-September/043020.html


-- 

florian at openwrt dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/41477] New: gcc does not optimize a case that it should to make __builtin_object_size() more useful

[arjan at linux dot intel dot com]

(see attached testcases; testcase.c shows the problem, testcase2.c shows that
reorging the code works around it)

it appears that gcc does not realize that after

if (variable < 1 || variable > 10)
 return -1;

the "variable" is in the range [1..10], likely because the execution of the
second check is optional due to the ||.

in a typical __builtin_object_size() scenario, like

if (__builtin_object_size(foo) < variable)
some_error();

where foo is 10 bytes in size, this means the check does not get optimized out.


-- 
   Summary: gcc does not optimize a case that it should to make
__builtin_object_size() more useful
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: arjan at linux dot intel dot com


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

[Bug c/41477] gcc does not optimize a case that it should to make __builtin_object_size() more useful

[arjan at linux dot intel dot com]

--- Comment #1 from arjan at linux dot intel dot com  2009-09-26 18:02 
---
Created an attachment (id=18658)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18658&action=view)
testcase showing the missed optimization


-- 


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

[Bug c/41477] gcc does not optimize a case that it should to make __builtin_object_size() more useful

[arjan at linux dot intel dot com]

--- Comment #2 from arjan at linux dot intel dot com  2009-09-26 18:02 
---
Created an attachment (id=18659)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18659&action=view)
testcase that shows a slight reorder of the code works around the issue


-- 


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

[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

[howarth at nitro dot med dot uc dot edu]

--- Comment #5 from howarth at nitro dot med dot uc dot edu  2009-09-26 
18:14 ---
Jakub,
Can you check what --save-temps produces for g++.dg/tree-prof/partition1.C
in partition1.s on linux? Does it produce two sets of global statements as
well?

grep __Z3bari.eh partition1.S
.globl __Z3bari.eh
__Z3bari.eh:
.globl __Z3bari.eh
__Z3bari.eh:

If so, is this by design or is it a gcc bug which binutils tolerates.


-- 


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

[Bug tree-optimization/41477] gcc does not optimize a case that it should to make __builtin_object_size() more useful

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-26 18:20 ---
This has been fixed since 4.4.0.


-- 


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

[Bug tree-optimization/30317] VRP cannot extract a range from (unsigned int) i + 0x0ffffffff > 4

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2009-09-26 18:22 ---
*** Bug 41477 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||arjan at linux dot intel dot
   ||com


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

[Bug tree-optimization/41477] gcc does not optimize a case that it should to make __builtin_object_size() more useful

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-09-26 18:22 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2009-09-26 19:10 ---
I also see similar failures on i686-apple-darwin9 in 32-bit mode (but not with
-m64) for
gcc.dg/tree-prof/bb-reorg.c and gcc.dg/tree-prof/pr34999.c:

output is:
/var/tmp//cc3DMvjA.s:230:FATAL:Symbol _foo.eh already defined.

FAIL: gcc.dg/tree-prof/bb-reorg.c compilation,  -fprofile-use -D_PROFILE_USE
...
output is:
/var/tmp//ccHG6m6S.s:219:FATAL:Symbol _main.eh already defined.

FAIL: gcc.dg/tree-prof/pr34999.c compilation,  -fprofile-use -D_PROFILE_USE


-- 


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

[Bug middle-end/41475] common variables cannot be expected to be aligned

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2009-09-26 19:29 ---
This code is undefined I think (and really it is not valid C90/C99 code).


-- 


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

[Bug libstdc++/40974] cannot build gcc-4.4.1: fenv_t has not been declared

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2009-09-26 19:44 
---
fenv.h should come from glibc ...


-- 


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

[Bug c++/41161] Hello World in C++ ISO does NOT compile

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-09-26 19:45 ---
This program works for me, I copied and pasted your sample and it worked.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME


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

[Bug target/40871] g++ does not find lstdc++ on AIX

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-09-26 19:47 ---
--disable-shared is not fully supported on AIX until 4.5 so closing as fixed
for 4.5.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug boehm-gc/40785] Powerpc bootstrap is broken due to problems in boehm-gc

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-09-26 19:48 ---
Fixed.
2009-07-17  Michael Meissner  

PR boehm-gc/40785
* include/private/gc_locks.h (GC_test_and_set): If GCC 4.4, use
the __sync_lock_test_and _set and __sync_lock_release builtins on
the powerpc.  If not GCC 4.4, fix up the constraints so that it
builds without error.
(GC_clear): Ditto.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |RESOLVED
   Keywords||build
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2009-09-26 19:53 ---
the target for crtfastmath.o should come from libgcc/config/ia64/t-ia64.
Does this patch fix it:
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 152205)
+++ libgcc/config.host  (working copy)
@@ -342,6 +342,8 @@ ia64*-*-elf*)
tmake_file="ia64/t-ia64"
;;
 ia64*-*-freebsd*)
+   extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o"
+   tmake_file="ia64/t-ia64"
;;
 ia64*-*-linux*)
extra_parts="crtbegin.o crtend.o crtbeginS.o crtendS.o crtfastmath.o"


-- 


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

[Bug fortran/41478] New: function "pack" causes double free violation

[reuter at physik dot uni-freiburg dot de]

The following program causes a double free violation, when compiled and run,
the error message is:
a.out(12292) malloc: *** error for object 0x2009d0: double free
*** set a breakpoint in malloc_error_break to debug
The code is:
program main

 type :: container_t
integer, dimension(:), allocatable :: entry
 end type container_t

 type(container_t), dimension(2) :: a1, a2
 integer :: i

 do i = 1, 2
allocate (a1(i)%entry (1), a2(i)%entry (1))
a1(i)%entry = 0
a2(i)%entry = i
 end do

 print *, "array1:"
 do i = 1, 2
print *, a1(i)%entry
 end do
 print *, "array2:"
 do i = 1, 2
print *, a2(i)%entry
 end do

 print *, "pack array2(2) into array1:"
 a1(1:1) = pack (a2(1:2), mask = [.false., .true.])

 print *, "array1:"
 do i = 1, 2
print *, a1(i)%entry
 end do


end program main


-- 
   Summary: function "pack" causes double free violation
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reuter at physik dot uni-freiburg dot de
 GCC build triplet: i386-32bit, MAC OS X Leopard
  GCC host triplet: i386-32bit, MAC OS X Leopard
GCC target triplet: i386-32bit, MAC OS X Leopard


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

[Bug fortran/41478] function "pack" causes double free violation

[reuter at physik dot uni-freiburg dot de]

--- Comment #1 from reuter at physik dot uni-freiburg dot de  2009-09-26 
20:06 ---
Created an attachment (id=18660)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18660&action=view)
Test code triggering the runtime error.


-- 


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

[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-09-26 20:20 ---
(In reply to comment #5)
> Jakub,
> Can you check what --save-temps produces for g++.dg/tree-prof/partition1.C
> in partition1.s on linux? Does it produce two sets of global statements as
> well?
> 
> grep __Z3bari.eh partition1.S
> .globl __Z3bari.eh
> __Z3bari.eh:
> .globl __Z3bari.eh
> __Z3bari.eh:
> 

Linux doesn't have __Z3bari.eh at all.


-- 


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

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

[howarth at nitro dot med dot uc dot edu]

--- Comment #47 from howarth at nitro dot med dot uc dot edu  2009-09-26 
20:36 ---
(In reply to comment #46)
> more than 20 lines... but not too too much.
> 

Iain,
It bootstraps fine here on x86_64-apple-darwin10 as well. Why don't you
submit it
to gcc-patches after regtesting but as two separate patches. The first patch to
build libgcc-ext
on darwin...

 *libgcc/configure.ac: Make sure the the rpath is correct in build tree
libraries when using --enable-version-specific-runtime-libs.
  *libgcc/configure: Regenerated.
  *libgcc/config/t-slibgcc-darwin: Don't make the _s.10X.dylib stubs unless
we're building for /usr/lib.  Build libgcc_ext.10.X.dylib containing newer
symbols

and the second to enable its usage...

  *gcc/config/darwin.opt: Add muse-shared-libgcc-ext to hide behind for
testing.
  *gcc/config/darwin.h: use libgcc_ext.10.X to provide newer gcc functionality
to older systems

This will reduce the total line count for each submitted patch.


-- 


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

[Bug c++/41313] g++.dg/tree-prof/partition1.C compilation and execution test failures on *-apple-darwin*

[rguenth at gcc dot gnu dot org]

--- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-26 20:43 ---
darwin has -fpic by default.


-- 


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

[Bug bootstrap/41345] bootstrap comparison failure with --disable-checking

[dirtyepic at gentoo dot org]

--- Comment #3 from dirtyepic at gentoo dot org  2009-09-26 20:46 ---
still broken in -r152199.  is there more info you need?


-- 


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

[Bug fortran/41479] New: wrong code, mis-initialization

[reuter at physik dot uni-freiburg dot de]

The example below shows that besides the fact that declared as INTENT(OUT) the
component 'n' is not initialized per default the second time. This is demanded
by the FORTRAN standard. 
Example code:
program main

 type :: container_t
integer :: n = 0
! if the following line is omitted, the problem disappears
integer, dimension(:), allocatable :: a
 end type container_t

 type(container_t) :: container

 call init (container)
 print *, "Initial state:"
 call dump (container)

 container%n = 1
 print *, "Modified state:"
 call dump (container)

 call init (container)
 print *, "Initial state again:"
 call dump (container)

contains

 subroutine init (container)
   type(container_t), intent(out) :: container
 end subroutine init

 subroutine dump (container)
   type(container_t), intent(in) :: container
   print "(A,I0,1x,L)", "   value = ", container%n
 end subroutine dump

end program main


-- 
   Summary: wrong code, mis-initialization
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reuter at physik dot uni-freiburg dot de
 GCC build triplet: i386-32bit, MAC OS X Leopard
  GCC host triplet: i386-32bit, MAC OS X Leopard
GCC target triplet: i386-32bit, MAC OS X Leopard


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

[Bug fortran/41479] wrong code, mis-initialization

[reuter at physik dot uni-freiburg dot de]

--- Comment #1 from reuter at physik dot uni-freiburg dot de  2009-09-26 
21:14 ---
Created an attachment (id=18661)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18661&action=view)
test case for the mis-initialization


-- 


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

[Bug fortran/41478] function "pack" causes double free violation

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2009-09-26 21:15 ---
Works for me on FreeBSD.

REMOVE:kargl[201] cd tmp
REMOVE:kargl[202] setenv MALLOC_OPTIONS AJ
REMOVE:kargl[203] gfc4x -o z asd.f90 
REMOVE:kargl[204] ./z
 array1:
   0
   0
 array2:
   1
   2
 pack array2(2) into array1:
 array1:
   2
   0


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|function "pack" causes  |function "pack" causes
   |double free violation   |double free violation


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

[Bug ada/41434] coldfire ACATS failures

[schwab at linux-m68k dot org]

--- Comment #2 from schwab at linux-m68k dot org  2009-09-26 22:24 ---
Looks like something has clobbered register A6.


-- 


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

[Bug debug/41474] [4.5 Regression] 951116-1.c ICEs in mem_loc_descriptor, at dwarf2out.c:11279

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-09-26 22:41 ---
Same thing on powerpc-apple-darwin9 at revision 152186 with -m64. I don't see
it on i686-apple-darwin9 at revision 152156.


-- 


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

[Bug fortran/41478] function "pack" causes double free violation

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-09-27 00:39 
---
I can reproduce this on 4.3.3 and 4.5.0 r151904.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-09-27 00:39:22
   date||


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

[Bug fortran/41479] wrong code, mis-initialization

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2009-09-27 00:50 
---
gfortran is not considered release critical and so is never given a blocker
status.

Changing to normal.

Regarding the intent(out) issue.  I will defer to others.  


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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

[Bug fortran/41479] wrong code, mis-initialization

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2009-09-27 01:13 
---
The problem goes away if the allocatable specification is removed from the
declaration of 'a'

Problem also occurs on gfortran 4.3.0


-- 


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

[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin

[howarth at nitro dot med dot uc dot edu]

--- Comment #3 from howarth at nitro dot med dot uc dot edu  2009-09-27 
03:43 ---
The logical candidate for these failures is...
Author: espindola
Date: Mon Jun 15 14:25:50 2009
New Revision: 148492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148492
Log:
2009-06-15  Rafael Avila de Espindola  

* cgraphunit.c (cgraph_function_versioning,save_inline_function_body):
Use DECL_COMDAT_GROUP instead of DECL_ONE_ONLY.
* cgraph.c (cgraph_create_virtual_clone): Use DECL_COMDAT_GROUP.
* config/i386/i386.c (ix86_file_end): Compute DECL_COMDAT_GROUP.
* dwarf2asm.c(dw2_force_const_mem): Update call to make_decl_one_only.
* langhooks-def.h (lhd_comdat_group, LANG_HOOKS_COMDAT_GROUP): Remove.
(LANG_HOOKS_DECLS): Remove LANG_HOOKS_COMDAT_GROUP.
* langhooks.c (lhd_comdat_group): Remove.
* langhooks.h (lang_hooks_for_decls): Remove comdat_group.
* tree.h (DECL_COMDAT_GROUP): New.
(DECL_ONE_ONLY): Use DECL_COMDAT_GROUP.
(tree_decl_with_vis): Add comdat_group. Remove one_only.
(make_decl_one_only): Change signature.
* varasm.c (get_emutls_init_templ_addr, emutls_decl): Update call to
make_decl_one_only.
(make_decl_one_only): Change signature.
(default_elf_asm_named_section): Use DECL_COMDAT_GROUP.

2009-06-15  Rafael Avila de Espindola  

* cp-objcp-common.h (LANG_HOOKS_COMDAT_GROUP): Remove.
* cp-tree.h (cxx_comdat_group): Change signature.
* decl.c (duplicate_decls): Use DECL_COMDAT_GROUP.
(cxx_comdat_group): Change signature.
* decl2.c (comdat_linkage, maybe_make_one_only): Update call to
make_decl_one_only.
(constrain_visibility, get_guard): Use DECL_COMDAT_GROUP.
* method.c (use_thunk): Update call to make_decl_one_only.
* optimize.c (maybe_clone_body): Use DECL_COMDAT_GROUP

2009-06-15  Rafael Avila de Espindola  

* g++.dg/abi/mangle11.C: Update warning line.
* g++.dg/abi/mangle12.C: Update warning line.
* g++.dg/abi/mangle17.C: Update warning line.
* g++.dg/abi/mangle20-2.C: Update warning line.


-- 


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

[Bug libgcj/38298] libjava link failures.

[rwild at gcc dot gnu dot org]

--- Comment #10 from rwild at gcc dot gnu dot org  2009-09-27 06:49 ---
Subject: Bug 38298

Author: rwild
Date: Sun Sep 27 06:49:33 2009
New Revision: 152215

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152215
Log:
Fix library dependencies for -Wl,--as-needed.

gcc/:
PR bootstrap/40928
* configure.ac: Use $LIBS for '-ldl', not $LDFLAGS.
* configure: Regenerate.

libjava/:
PR libgcj/38298
* Makefile.am (libgcj_tools_la_LIBADD): Add '-lm'.
* Makefile.in: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/libjava/ChangeLog
trunk/libjava/Makefile.am
trunk/libjava/Makefile.in


-- 


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

[Bug bootstrap/40928] build failure w/ -Wl,--as-needed - undefined references in plugin.c

[rwild at gcc dot gnu dot org]

--- Comment #1 from rwild at gcc dot gnu dot org  2009-09-27 06:49 ---
Subject: Bug 40928

Author: rwild
Date: Sun Sep 27 06:49:33 2009
New Revision: 152215

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152215
Log:
Fix library dependencies for -Wl,--as-needed.

gcc/:
PR bootstrap/40928
* configure.ac: Use $LIBS for '-ldl', not $LDFLAGS.
* configure: Regenerate.

libjava/:
PR libgcj/38298
* Makefile.am (libgcj_tools_la_LIBADD): Add '-lm'.
* Makefile.in: Regenerate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/libjava/ChangeLog
trunk/libjava/Makefile.am
trunk/libjava/Makefile.in


-- 


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

[Bug bootstrap/40928] build failure w/ -Wl,--as-needed - undefined references in plugin.c

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2009-09-27 06:53 ---
Fixed


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rwild at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/38298] libjava link failures.

[rwild at gcc dot gnu dot org]

--- Comment #11 from rwild at gcc dot gnu dot org  2009-09-27 06:56 ---
Fixed in trunk.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.3.2   |4.3.2 4.5.0


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