: 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
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=edit
testcase
If a function with hidden visibil
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
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=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
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=edit
testcase
If the attached file is compiled with "g++ test.cpp -fPIC -g
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=edit
testcase
If the attached file is compiled with "g++ test.cpp -fPIC -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
Rafael Avila de Espindola rafael.espindola at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986
--- Comment #3 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #10 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #4 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
So it looks like the reason was
jason My thinking was that the ABI change should also support implementations
that implement D0 as another entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #6 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #7 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
--- Comment #2 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
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 DataType class opt : public Option {};
template
++
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 typename T struct foo { foo(); };
template typename T fooT::foo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #12 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #15 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
(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
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 class DataType
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
The undefined is still present with -fno-devirtualize-speculatively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61555
Rafael Avila de Espindola rafael.espindola at gmail dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
--- Comment #4 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
Rafael Avila de Espindola rafael.espindola at gmail dot com changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469
--- Comment #26 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59300
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
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 trunk r205392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59236
--- Comment #2 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
(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.cpp
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #4 from Rafael Avila de Espindola rafael.espindola at gmail dot
com ---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
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 rafael.espindola at gmail dot
com 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=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=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
--- Comment #3 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
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 rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #22 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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=49911
--- Comment #19 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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 rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #4 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
Rafael Avila de Espindola rafael.espindola at gmail dot com changed:
What|Removed |Added
Attachment #25188|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #17 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #10 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #2 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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 rafael.espindola at gmail dot
com 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
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=47980
Summary: Inefficient code for local const char arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47980
--- Comment #2 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #18 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #21 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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=47247
--- Comment #14 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #16 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #12 from Rafael Avila de Espindola rafael.espindola at gmail dot
com 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
58 matches
Mail list logo
