[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-31 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #30 from Rich Felker bugdal at aerifal dot cx ---
I don't really understand how weak aliases come into play for implementing C++
features, but if their semantics are not identical to the necessary C++
semantics, the compiler should just distinguish between the relevant C++
semantics and weak alias semantics rather than trying to force two semantically
different concepts to use the same feature in ways that breaks either one or
the other.

Also, was C++ behavior broken prior to 4.9.0, or is there some other reason
that weak aliases worked without breaking C++ mandatory constant folding prior
to 4.9.0?


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-30 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #29 from Jan Hubicka hubicka at gcc dot gnu.org ---
Created attachment 33209
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33209action=edit
patch I am testing

Sorry for taking so long on this issue - I had busy time and there is no really
good answer to this problem.  C++ require constant variables to be folded, ELF
interposition interpreted in full generality prevents folding of many symbols. 
We behave in C++ way for years and I think it should stay a default, so I think
we can special case the user specified WEAK attribute - i.e. do not give up on
PIC exported symbols nor C++ COMDATs as we already special case COMDAT.

I hope this won't break non-ELF targets, like AIX - will give it a try.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|4.9.1   |4.9.2

--- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org ---
GCC 4.9.1 has been released.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-16 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #28 from Rich Felker bugdal at aerifal dot cx ---
I'm quite disappointed that another release was made with this bug present.
I've been trying to find a workaround, but even at -O0 the invalid constant
folding optimizations are made. Is there anything I can do short of
blacklisting 4.9.0 and 4.9.1 (either hard-coded or via detecting the bug)?


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-14 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

Alexander Monakov amonakov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #25 from Alexander Monakov amonakov at gcc dot gnu.org ---
I have tried to bootstrap and regtest the patch (to be attached) that reflects
the latest comments on the mailing list (except the concern raised by Jan about
C++ optimization).  Unfortunately the patch regresses the following simple C++
testcase, not folding the conditional access to the constant (even at -O3), but
not emitting the constant either and thus causing an undefined reference at
link time.  Uncommenting the commented line allows folding but also emits the
definition of the static member, increasing .rodata size.

It seems odd to me that decl_replaceable_p(z::cst) is true, and that for
instance TREE_PUBLIC(z::cst) is true.  Any help here please?

struct z {
  static const int cst = 1;
};

// const int z::cst;

int foo(int cond)
{
  return cond ? z::cst : 0;
}


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-14 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

Alexander Monakov amonakov at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #32830|0   |1
is obsolete||

--- Comment #26 from Alexander Monakov amonakov at gcc dot gnu.org ---
Created attachment 33120
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33120action=edit
updated patch


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-02 Thread patrick at parcs dot ath.cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

patrick at parcs dot ath.cx changed:

   What|Removed |Added

 CC||patrick at parcs dot ath.cx

--- Comment #23 from patrick at parcs dot ath.cx ---
(In reply to Rich Felker from comment #22)
  Richard Biener rguenth at gcc dot gnu.org changed:
 What|Removed |Added
  
 Priority|P3  |P2
 
 Can we please make this P1 rather than P2? It is a wrong-code
 regression and only present in a single release, so by the bug
 management guidelines (https://gcc.gnu.org/bugs/management.html) I
 think it should be P1.
 
 There is already a working patch, test-case, and discussion on the
 gcc-patches list so I don't see what's blocking fixing it before the
 next release.

It looks like this bug has been recently fixed in the trunk (no testsuite
addition however).  I'm not sure what its status is on the release branches,
though.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-07-02 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #24 from Rich Felker bugdal at aerifal dot cx ---
On Wed, Jul 02, 2014 at 12:22:40PM +, patrick at parcs dot ath.cx wrote:
 It looks like this bug has been recently fixed in the trunk (no testsuite
 addition however).  I'm not sure what its status is on the release branches,
 though.

Per discussion on gcc-patches, the issue for this exact test case went
away due to related changes not explicitly aimed at fixing this bug.
However, if dummy is const-qualified, the bug supposedly remains. I
have not yet tested with trunk to confirm this; I can do that if
necessary.

Here is the new test case:

static const int dummy = 0;
extern const int foo __attribute__((__weak__, __alias__(dummy)));
int bar() { if (foo) return 1; return 0; }

Even with the const qualifier on both dummy and foo, foo should not be
considered for constant folding because it's replaceable by alternate
definitions which may provide different values.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-06-26 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P2


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-06-26 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #22 from Rich Felker bugdal at aerifal dot cx ---
 Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
 
Priority|P3  |P2

Can we please make this P1 rather than P2? It is a wrong-code
regression and only present in a single release, so by the bug
management guidelines (https://gcc.gnu.org/bugs/management.html) I
think it should be P1.

There is already a working patch, test-case, and discussion on the
gcc-patches list so I don't see what's blocking fixing it before the
next release.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-20 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #19 from Rich Felker bugdal at aerifal dot cx ---
Here is the commit that seems to have introduced the bug:

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=df8d3e8981a99e264b49876f0f5064bdb30ac981

In the function ctor_for_folding, the following erroneous logic appears:

+  /* Non-readonly alias of readonly variable is also de-facto readonly,
+ because the variable itself is in readonly section.  
+ We also honnor READONLY flag on alias assuming that user knows
+ what he is doing.  */
+  if (!TREE_READONLY (decl)  !TREE_READONLY (real_decl))
+return error_mark_node;

This treats the value of an alias as a compile-time constant if either the
alias itself or the alias target has TREE_READONLY being true. Replacing the 
with || seems to make the problem go away in my test case, and makes a bit more
sense (perhaps that was the original intent?), but it's only sufficient if
TREE_READONLY is always false for weak aliases (since they can always be
overridden by a strong symbol from another translation unit, even if the alias
is const-qualified). I'm not sure where the value of TREE_READONLY is set for
aliases yet but I'll keep looking...


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-20 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #20 from Rich Felker bugdal at aerifal dot cx ---
On further investigation, it looks like the code I cited deals with strong
aliases as well as weak ones, and in the strong alias case, the strong folding
behavior might be desirable. A better fix seems to be adding an explicit check
for weak aliases (DECL_WEAK(decl)) when an alias is found and returning
error_mark_node in that case.

Note that prior to the above-mentioned commit, the !TREE_READONLY(decl) case
was always treated as non-foldable, so there seems to have been no subtlety to
avoiding errors with weak aliases. But the new code performs much more
aggressive constant folding and thus needs to avoid stepping on weak aliases.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-20 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #21 from Rich Felker bugdal at aerifal dot cx ---
Created attachment 32830
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32830action=edit
proposed patch

patch is generated against the revision that introduced this bug.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.8.2
Version|unknown |4.9.0
   Keywords||wrong-code
   Last reconfirmed||2014-05-13
  Component|c   |ipa
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Invalid optimizations for   |[4.9/4.10 Regression]
   |extern vars with local weak |Invalid optimizations for
   |definitions |extern vars with local weak
   ||definitions
   Target Milestone|--- |4.9.1
  Known to fail||4.9.0

--- Comment #17 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed for 4.9.0.  Note that I agree that the testcase looks suspicious,
but weak aliases have odd behavior.


[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions

2014-05-13 Thread bugdal at aerifal dot cx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144

--- Comment #18 from Rich Felker bugdal at aerifal dot cx ---
Any ideas on how to reliably test for this bug without having to run programs
(breaks cross-compiling) or use additional tools (nm, objdump, etc. which we
don't already depend on) to detect it? Since this issue was raised in relation
to musl libc we're holding up the pending release trying to decide how best to
work around it. My hope is to simply reject the broken version(s) with a
message to try -fno-toplevel-reorder, and I could just hard-code 4.9.0 as the
only broken version if folks on the GCC side are willing to make sure this gets
fixed in time for 4.9.1, but obviously having a test for the bug would be
preferable.