https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108334
Bug ID: 108334
Summary: Strange message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106459
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #5 from Andrew Pinski ---
So basically from what I understand is buildroot is doing this so they can
hardcode supporting only 4k pages. THIS IS BROKEN. Someone could build a kernel
and try to use a buildroot built sysroot and it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #4 from Sagi Mor ---
created a bug report on buildroot as a workaround for the time being:
https://bugs.busybox.net/show_bug.cgi?id=15231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995
Andrew Pinski changed:
What|Removed |Added
Target Milestone|11.4|10.5
Summary|[11/12/13 Regres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98995
Andrew Pinski changed:
What|Removed |Added
CC||yronglin777 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108333
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108333
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|[10.3/10.4/11/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108333
Bug ID: 108333
Summary: [10.3/10.4/11/12/13/trunk Regression] The behavior of
direct-non-list-initialized is not correct, parsing
error on valid code
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #5 from Andrew Pinski ---
(In reply to jon_y from comment #4)
> Is Nightstrike's patch OK?
I think it is correct but patches should goto gcc-patches@ really.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
jon_y <10walls at gmail dot com> changed:
What|Removed |Added
CC||10walls at gmail dot c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150
--- Comment #3 from jon_y <10walls at gmail dot com> ---
Created attachment 54211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54211&action=edit
Fix attempt 1
Makes errors emitted same as on Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
--- Comment #3 from Eric Botcazou ---
> Eric, can we add a new macro to gthr-win32.h that says "this is the win32
> thread model" which libstdc++ can then use like so:
Sure, but can't we define a __GTHREAD_TYPE_FOR_HISTORICAL_MUTEX macro instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332
--- Comment #4 from cqwrteur ---
(In reply to Andrew Pinski from comment #3)
> cygwin was improved here:
> https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;
> h=801120c1f402f9b0f72b5a231bf9e1cf82614cac
>
> It might be the case mingw li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332
--- Comment #3 from Andrew Pinski ---
cygwin was improved here:
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=801120c1f402f9b0f72b5a231bf9e1cf82614cac
It might be the case mingw linker script is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332
--- Comment #2 from Andrew Pinski ---
https://sourceware.org/pipermail/binutils-cvs/2021-March/056031.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332
--- Comment #1 from Andrew Pinski ---
This seems like a binutils ld bug rather than a libstdc++ bug ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332
Bug ID: 108332
Summary: dynamic link libstdc++ with win32 thread model's gcc
for windows native toolchain would cause .rdata_r:
section below image base
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108327
--- Comment #2 from Jakub Jelinek ---
Yes, I wrote:
on --with-long-double-128 --with-long-double-format=ieee powerpc64le-linux.
above. It was a Fedora package build actually:
https://kojipkgs.fedoraproject.org/packages/gcc/13.0.0/0.4.fc38/
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108327
--- Comment #1 from Jonathan Wakely ---
I assume this is with --with-long-double-format=ieee ? I don't see it when
testing without that. I'm building with that option now and re-testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> --- a/libstdc++-v3/config/io/c_io_stdio.h
> +++ b/libstdc++-v3/config/io/c_io_stdio.h
> @@ -39,7 +39,17 @@ namespace std _GLIBCXX_VISIBILITY(default)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Jonathan Wakely changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
Jonathan Wakely changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #20 from cqwrteur ---
(In reply to cqwrteur from comment #19)
> (In reply to cqwrteur from comment #18)
> > (In reply to cqwrteur from comment #17)
> > > (In reply to Eric Botcazou from comment #16)
> > > > > #if _WIN32_WINNT >= 0x06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108327
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #19 from cqwrteur ---
(In reply to cqwrteur from comment #18)
> (In reply to cqwrteur from comment #17)
> > (In reply to Eric Botcazou from comment #16)
> > > > #if _WIN32_WINNT >= 0x0600
> > > > #define __GTHREAD_HAS_COND 1
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #18 from cqwrteur ---
(In reply to cqwrteur from comment #17)
> (In reply to Eric Botcazou from comment #16)
> > > #if _WIN32_WINNT >= 0x0600
> > > #define __GTHREAD_HAS_COND 1
> > > #define __GTHREADS_CXX0X 1
> > > #endif
> > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
cqwrteur changed:
What|Removed |Added
Status|RESOLVED|WAITING
Resolution|WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
cqwrteur changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108331
Bug ID: 108331
Summary: ABI break of std::__c_file and std::fstream for win32
thread model of GCC for windows
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783
--- Comment #12 from Marc Glisse ---
(In reply to Marc Glisse from comment #11)
> Since I had forgotten where it was, let me write here that it is git branch
> /users/glisse/fenv
Since it became impossible (hooks) to push to that branch a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108249
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108249
John Lind changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #11 from Arsen Arsenović ---
(In reply to LIU Hao from comment #10)
> I think Jonathan's proposal makes it unnecessarily complex. Renaming `abort`
> to `gcc_fancy_abort`, as well as all invocations accordingly, should be much
> simpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108330
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107616
--- Comment #2 from John David Anglin ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609536.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108326
--- Comment #3 from Jonathan Wakely ---
(In reply to Jamaika from comment #0)
> Amateur questions
> I know that creating exe files two years ago with , with
> _GLIBCXX_HAS_GTHREADS definition was impossible.
This is just nonsense, so I assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108326
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #10 from LIU Hao ---
(In reply to Arsen Arsenović from comment #9)
> (In reply to LIU Hao from comment #8)
> > The commit above just lets GCC bootstrap on Windows. The cause of this issue
> > is still there.
> >
> > Maybe it's possi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
--- Comment #2 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #1)
> As long as PR 36678
That should be PR 34678 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #9 from Arsen Arsenović ---
(In reply to LIU Hao from comment #8)
> The commit above just lets GCC bootstrap on Windows. The cause of this issue
> is still there.
>
> Maybe it's possible to replace all direct calls to `abort()` in g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #8 from LIU Hao ---
The commit above just lets GCC bootstrap on Windows. The cause of this issue is
still there.
Maybe it's possible to replace all direct calls to `abort()` in gcc and libcpp
with `fancy_abort (__FILE__, __LINE__, _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108330
Bug ID: 108330
Summary: [13 Regression] ICE in add, at hash-set.h:64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89098
--- Comment #3 from Arseny Solokha ---
While the C testcase in comment 2 is definitely much shorter, current gcc 13
snapshot ICEs on gcc/testsuite/gcc.target/i386/pr63448.c w/ -O1
-fkeep-gc-roots-live --param max-slsr-cand-scan=1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Thomas Koenig changed:
What|Removed |Added
Version|unknown |13.0
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329
Bug ID: 108329
Summary: IEEE_SET_ROUNDING_MODE ineffective with common
subexpression elimination
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #49 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #48)
> Clang gets this right, even without the pragma;
The "even without the pragma" part is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #3 from Sagi Mor ---
I agree that the python check is broken, but I do think that the current
behavior is incorrect. it doesn't make sense that for N input file, the help
will be displayed N times. and that linker options suppress th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108324
--- Comment #1 from Andrew Pinski ---
MSVC rejects it for the same reason as GCC:
(15): error C2131: expression did not evaluate to a constant
(11): note: a non-constant (sub-)expression was encountered
(16): error C2369: 'k': redefinition; dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #2 from Andrew Pinski ---
I think this behavior is correctly documented too:
If the -v option is also specified then --help is also passed on to the various
processes invoked by gcc, so that they can display the command-line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
--- Comment #1 from Andrew Pinski ---
Considering -fwrapv has been there since GCC 3.4.0, I think python should just
change how their configuring.
-fwrapv was added in r0-50210-g4fa26a60791ec3 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108328
Bug ID: 108328
Summary: gcc --help -v doesn't work correctly in some
circumstances in gcc>=10
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108326
Andrew Pinski changed:
What|Removed |Added
Target||*-*-mingw
--- Comment #1 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #48 from Thomas Koenig ---
Clang gets this right, even without the pragma; the original test case is
compiled to
pushq %r14
pushq %rbx
subq$24, %rsp
movq%rsi, %r14
movq%rdi, %rb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108327
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108327
Bug ID: 108327
Summary: [13 Regression] Lots of libstdc++ FAILs on
powerpc64le-linux
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #7 from niXman ---
(In reply to CVS Commits from comment #6)
> The master branch has been updated by Jonathan Yong :
>
> https://gcc.gnu.org/g:902c755930326cb4405672aa3ea13c35c653cbff
>
> commit r13-5055-g902c755930326cb4405672aa3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #12 from Jonathan Wakely ---
The std::span default constructor that's causing problems has been there for a
few years, but nobody pointed out it didn't work for this mode. For a target to
remain usable we need test results and regula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192
--- Comment #3 from nightstrike ---
Created attachment 54209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54209&action=edit
Patch to change printf to puts so it works everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108229
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106726
--- Comment #3 from Zdenek Sojka ---
This can now be also observed on the x86_64 target, with -mlam=u57:
$ x86_64-pc-linux-gnu-gcc -fsanitize=hwaddress -fstack-check=generic
-fexceptions -mlam=u57 testcase.c
testcase.c: In function 'foo':
testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #11 from Jan Dubiec ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Jan Dubiec from comment #6)
> > Please note -mn -mint32 options –
> > normal mode (aka 16-bit mode) with 32-bit integers.
>
> Has this bizarre mode
65 matches
Mail list logo
