https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178
--- Comment #13 from roland at gnu dot org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > OK.
> >
> > FWIW Clang seems to create two different sections called foo, one C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184
roland at gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184
roland at gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This might belong in a different component. The test case here is in C++ but
the same thing probably arises with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This code:
```
void crash(void) {
volatile int* ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993
roland at gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
GCC 11 has a regression with:
```
#pragma GCC visibility push(hidden)
int
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
```
struct S {
union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96238
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This is a regression from 9.3.1. Using --target=aarch64-elf built from git
commit 6fedf28c7921f125be75a9f688a7b845a1b5663b.
aarch64-elf-g++ -mgeneral-regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
roland at gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
--- Comment #6 from roland at gnu dot org ---
Thanks for the fix. What's the status on backporting this to 8 and/or 7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
--- Comment #4 from roland at gnu dot org ---
That fix (applied to trunk) works for my test case and for the original
real-world case I reduced it from.
Will it be backported to 7 and 8?
Thanks for the quick work as usual, Jakub!
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
This code was accepted by GCC 6 but is rejec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80298
--- Comment #4 from roland at gnu dot org ---
I'd assumed it would be fixed just with more #pragma push_options,
target("sse"), pop_options, sequences.
It seems like a separate issue about automagically allowing things in
alwa
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
For any x86_64 target, try:
gcc -mno-sse -S -o - -xc <(echo '#include ')
It fails with various errors about SSE being disabled.
Many of the components of x86intrin.h make speci
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
CC: rth at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-elf
Given this test code:
void bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79609
--- Comment #1 from roland at gnu dot org ---
Note Clang uses __attribute__((address_space(N))) for this. That automagically
handles the parsing issues in a well-known fashion, and gets C++ support for
free to boot.
Unfortunately they use per
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
CC: rth at gcc dot gnu.org
Target Milestone: ---
It's impossible to use __seg_fs et al under -fno-asm, whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609
--- Comment #3 from roland at gnu dot org ---
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00981.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609
--- Comment #1 from roland at gnu dot org ---
Created attachment 39626
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39626&action=edit
trunk fix
This is the fix that shows the behavior difference reported above.
NCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
When __attribute__((section("name"))) is used, GCC insists on setting the
section t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758
--- Comment #1 from roland at gnu dot org ---
Created attachment 33903
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33903&action=edit
proposed patch
This patch fixes it on OSX. I haven't verified it on a wide variety of
configurations.
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Host: x86_64-apple-darwin
Build: x86_64-apple-darwin11.4.2
Failure mode:
.../bin/../lib/gcc/.../4.9.2/../../../../.../bin/ld:
.../bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #5 from roland at gnu dot org ---
(In reply to baoshan from comment #4)
> This should be a duplication to Bug 57431.
That report is for 4.9.x. The bug remains on 4.8.x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #3 from roland at gnu dot org ---
Oops! Meant to paste that:
gcc/cc1 -fpreprocessed ref_vld1_dup.i -quiet -dumpbase ref_vld1_dup.i
-mfloat-abi=softfp -mfpu=neon -mtls-dialect=gnu -auxbase ref_vld1_dup -O1
-std=gnu99 -version -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622
--- Comment #1 from roland at gnu dot org ---
Created attachment 33013
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33013&action=edit
test case preprocessed source
I had to gzip the file to make bugzilla accept it.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabihf
This is with gcc-4_8-branch tip (98985e7). It also happens with 4.8.3.
It does not happen with 4.7 or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
roland at gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
--- Comment #2 from roland at gnu dot org ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00753.html
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabihf
Created attachment 31382
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31382&action=edi
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabi
I think this bug exists in trunk and in all past versions (seen in 4.6, at
least), but I did the detailed testing on today's gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #9 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #8)
> (In reply to roland from comment #7)
> > -static-libstdc++ is important
> > to avoid DSO dependencies specific to the GCC version, whic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #7 from roland at gnu dot org ---
(In reply to Jakub Jelinek from comment #6)
> Note also that libstdc++.a can be used together with libpthread.so or
> libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.).
If libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #5 from roland at gnu dot org ---
So my draft fix actually breaks the dynamic case. For the unconditional calls,
weak is right in the shared library but strong is right in the static library.
But unlike normal libraries, libstdc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #4 from roland at gnu dot org ---
weakrefs are right for the conditional cases.
For the functions that underlie std::thread et al, it can never be meaningful
to use those interfaces and fail to link with -lpthread.
The Fedora hack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740
--- Comment #2 from roland at gnu dot org ---
(In reply to Andrew Pinski from comment #1)
> I think it is bad form to use static linking with pthreads.
Nonsense. There is code specifically to ensure it works.
The additions for C++11 thr
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Host: x86_64-linux-gnu
Created attachment 30398
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30398&action=edit
test case
This bug goes back at least to 4.6, but I don&#
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659
--- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC ---
I have been using a straightforward revert of r190487 to build on mingw with
--disable-nls. It works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147
roland at gnu dot org changed:
What|Removed |Added
CC||rguenther at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147
Bug #: 57147
Summary: [4.9 Regression]: setjmp call and if body wrongly
elided (function runs off early end)
Classification: Unclassified
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659
--- Comment #19 from roland at gnu dot org 2013-03-26 22:03:44 UTC ---
r190487 is the breaking change. I tested reverting that (relative to 4.8
branch) and it solved the problem.
Note I'm more concerned with having this fixed on th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54055
Bug #: 54055
Summary: spurious(?) "invalid use of incomplete type" warning
in template definition
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51886
--- Comment #1 from roland at gnu dot org 2012-01-17 18:59:18 UTC ---
Created attachment 26357
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26357
C++ test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51886
Bug #: 51886
Summary: __alignof__ on uninstantiated template type
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Prio
48 matches
Mail list logo
