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
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=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=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=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=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.
: 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=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
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 #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 #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 #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
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=54055
Bug #: 54055
Summary: spurious(?) "invalid use of incomplete type" warning
in template definition
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
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
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
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
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
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=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!
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
roland at gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
: 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=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
: 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
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
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
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=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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
roland at gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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=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.
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
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.
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 #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=94342
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
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
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
```
struct S {
union
: 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
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: 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=96868
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
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=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
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
`double x = (__extension__ 0x123p4);` when compiled under `-std=c++11
-pedantic` still emits `warning: use of C++17 hex
49 matches
Mail list logo