http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54399
Bug #: 54399
Summary: Invalid partial change from dynamic to static
initialization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170
Bug #: 55170
Summary: incorrect mangling, should not include prefix
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170
--- Comment #1 from Rafael Avila de Espindola 2012-11-01 20:29:02 UTC ---
The relevant thread seems to be
http://sourcerytools.com/pipermail/cxx-abi-dev/2011-April/002404.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #1 from Rafael Avila de Espindola 2012-11-06 13:53:00 UTC ---
I can see two options for fixing this
1) producing a copy of the destructor when we devirtualize and not
devirtualizing if we cannot emit one.
2) making the destru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #12 from Rafael Avila de Espindola 2011-02-14 19:59:22 UTC ---
A quick summary to see if got this right:
Currently the linker has three options for a symbol in a comdat:
*) pick one not in the IL. The plugin gets a PREEMPTED_REG
*) p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #14 from Rafael Avila de Espindola 2011-02-15 19:39:09 UTC ---
Sorry, can you expand on what gcc was doing that was causing it to expand the
dynamic symbol table?
With LLVM what we are doing is
*) Report all symbols
*) Any symbol not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #16 from Rafael Avila de Espindola 2011-02-16 04:03:36 UTC ---
> The problem is with dropping linkonce_odr that has been previously reported.
> This way gold will allocate entry in the dynamic symbol table (you can see it
> in
> nm of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #18 from Rafael Avila de Espindola 2011-02-16 16:14:52 UTC ---
I have created a "small" test of the symbol table problem. It is in
http://people.mozilla.com/~respindola/test.tar.xz
The test is firefox's libxul with most files copied
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #21 from Rafael Avila de Espindola 2011-02-17 01:13:35 UTC ---
Most of it is in the string table. Ian gave me some pointers and I will try to
fix it tomorrow :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47980
Summary: Inefficient code for local const char arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47980
--- Comment #2 from Rafael Avila de Espindola 2011-03-03 21:50:07 UTC ---
I agree that the code is correct. The bug is because of a missing optimization,
not about wrong behavior.
The only use of foo is passing it function expecting a const point
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: hubicka at gcc dot gnu.org, jason at redhat dot com
Created attachment 30582
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #4 from Rafael Avila de Espindola ---
The equivalent clang bug (llvm.org/pr13124) just got fixed by avoiding the
devirtualization in this case.
Not sure how similar the issues are internally, but I summarized what I found
in clang in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #17 from Rafael Avila de Espindola 2011-08-17 21:31:43 UTC ---
Created attachment 25041
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25041
gcc 4.5 backport
I have tried porting the vrp patch to 4.5. It works out of the box on 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
Bug #: 50284
Summary: possible miscompilation with -fstrict-aliasing
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #1 from Rafael Avila de Espindola 2011-09-03 18:53:58 UTC ---
Created attachment 25188
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25188
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #2 from Rafael Avila de Espindola 2011-09-03 19:07:54 UTC ---
Forgot to mention, this only reproduces with -fPIC. So to reproduce this you
need
* a linux 32 bit build older than 160947
* run cc1 with: -quiet -fPIC -O2 -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #4 from Rafael Avila de Espindola 2011-09-03 22:54:10 UTC ---
(In reply to comment #3)
> struct Value {
> struct jsval data;
> };
> ...
> struct jsval y = t3.array[i];
> struct Value *z = (struct Value*)&y;
> if (z->data.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
Rafael Avila de Espindola changed:
What|Removed |Added
Attachment #25188|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #19 from Rafael Avila de Espindola 2011-09-05 17:14:29 UTC ---
> I've lost the track of whether anything else needs to be done to close
> this bug, though. Should the patch be applied to the 4.6 and 4.5
> branches too (assuming it pas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #22 from Rafael Avila de Espindola 2011-09-07 14:58:57 UTC ---
Thanks!
> * testsuite/g++.dg/tree-ssa/pr49911.C: New test.
I think you forgot to add -fstrict-enums to the command line in the test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
Bug #: 53808
Summary: Undefined symbol when building a library with lto
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52995
Bug #: 52995
Summary: Change in the handling of templates and visibility
attributes
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52995
--- Comment #2 from Rafael Avila de Espindola 2012-04-15 12:28:44 UTC ---
(In reply to comment #1)
> http://gcc.gnu.org/gcc-4.7/changes.html
> "The ELF symbol visibility of a template instantiation is now properly
> constrained by the visibility o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52995
--- Comment #3 from Rafael Avila de Espindola 2012-04-19 06:00:59 UTC ---
This just got discussed on the clang list. In the end we implemented what gcc
does. The winning argument was that it is not just the class that is templated,
but its members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59236
--- Comment #2 from Rafael Avila de Espindola ---
(In reply to H.J. Lu from comment #1)
> Works on Linux/x86-64.
Yes, it is a COFF only issue (tested on mingw).
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target: mingw
$ cat test1.cpp
#include "test.h"
struct zed : public foo {
virtual ~zed();
};
zed::~zed() {}
$ cat test2.cp
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Given
namespace nfoo {
class foo {
void f();
};
}
namespace nfoo __attribute__((visibility("hidden"))) {
void foo::f() {}
}
gcc tru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
--- Comment #1 from Rafael Avila de Espindola ---
clang had an even stranger behavior
(http://llvm.org/bugs/show_bug.cgi?id=18174). I fixed that in a way that it now
agrees with gcc on the testcase in this bug.
It would still be nice to know if t
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Created attachment 43092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43092&action=edit
testcase
If a function with
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given the c++ code
int __attribute__((target("sse4.2"))) foo_overload(int);
int __a
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Created attachment 42408
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42408&action=edit
testcase
If the attached file is compiled with "g++ test.cpp -fPIC -g -O
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Created attachment 42407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42407&action=edit
testcase
If the attached file is compiled with "g++ test.cpp -fPIC -g -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630
--- Comment #6 from Rafael Avila de Espindola ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > The problem is the assembler's special treatment of _GLOBAL_OFFSET_TABLE_,
> > that
> > .long _GLOBAL_OFFSET
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
test.h:
inline int *foo() {
static thread_local int i = 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82906
--- Comment #2 from Rafael Avila de Espindola ---
(In reply to Andrew Pinski from comment #1)
> Could this be a bug in ld.so rather than gcc? Not doing copy relocs for TLS?
I don't think there is enough information left for ld.so to fix the sit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael.espindola at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #26 from Rafael Avila de Espindola ---
> Yes, is see the weak symbol both in BasicBlock.o and Function.o.
> However it gets optimized away when I link them with "-flto -O3" into
> libLLVMCore.so (see comment 0).
That optimization seem
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: chandlerc at gmail dot com, echristo at gmail dot com
We noticed that both clang and gcc were fairly inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael.espindola at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986
--- Comment #3 from Rafael Avila de Espindola ---
In clang this was fixed by putting a .init_array section in the same comdat as
the variable it is initializing. That way if the variable is dropped, so is the
initialization code.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: hubicka at gcc dot gnu.org
Given
struct generic_parser_base {
virtual void getOption();
void getExtraOptionNames() { getOption(); }
};
template struct parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #1 from Rafael Avila de Espindola ---
The undefined is still present with -fno-devirtualize-speculatively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555
Rafael Avila de Espindola changed:
What|Removed |Added
CC||rafael.espindola at gmail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #4 from Rafael Avila de Espindola ---
I ran the testcase with just -O2 (original code with -O3, but the reduced
testcase with -O2).
getOption will be part of the vtable, but it can end up being hidden.
In the original source code it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #15 from Rafael Avila de Espindola ---
(In reply to Jason Merrill from comment #14)
> Right. My patch causes us to synthesize ~I so that it's available for
> devirtualization, which we weren't doing before. This is allowed by the C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #12 from Rafael Avila de Espindola ---
Note that this bug is present once more when -fno-use-all-virtuals is used.
With the original testcase gcc again produces an undefined reference to
_ZN3barD0Ev.
Is -fno-use-all-virtuals intended
++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: hubicka at gcc dot gnu.org
It looks like an unintended consequence of r211434 wast that given
template struct foo { foo(); };
template foo::foo() {}
template class foo;
gcc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: jason at redhat dot com
Given
struct Option {
virtual ~Option() {}
};
template class opt : public Option {};
template class opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #2 from Rafael Avila de Espindola ---
This is again visible on trunk now that pr62302 has been fixed (thanks!).
It doesn't seem profitable to ever put D0 in the D5 comdat. It cannot be equal
to D1 or D2, so putting it there just cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #4 from Rafael Avila de Espindola ---
So it looks like the reason was
My thinking was that the ABI change should also support implementations
that implement D0 as another entry point into the destructor
jason: leav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #6 from Rafael Avila de Espindola ---
OK, so should we declare r206182 an "unintentional bug fix" and mark this bug
wontfix?
To be clear, the ABI then is
For any class an implementation has the option of using one comdat per
constru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #7 from Rafael Avila de Espindola ---
(In reply to Rafael Avila de Espindola from comment #6)
> OK, so should we declare r206182 an "unintentional bug fix" and mark this
> bug wontfix?
>
One thing to keep in mind. If r206182 was the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #10 from Rafael Avila de Espindola ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Jason Merrill from comment #8)
> > I think I'm sympathetic to Rafael's argument that we should stick with the
> > 4.7 behavior since tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
Summary: vrp2 + -fstrict-enums incorrectly remove predicate
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #2 from Rafael Avila de Espindola 2011-07-31 13:38:54 UTC ---
I got it on 32 bit linux. Doing a git pull to check if it has just been fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #3 from Rafael Avila de Espindola 2011-07-31 13:57:17 UTC ---
I was able to reproduce it on 176972. I did a 64 bit build on linux. It
reproduces with -m32, but not without.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #10 from Rafael Avila de Espindola 2011-08-04 18:59:20 UTC ---
Created attachment 24919
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24919
test patch
I ported
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00741.html
to gcc 4.5
58 matches
Mail list logo
