https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
Jonathan Wakely changed:
What|Removed |Added
Summary|Preprocessor tokens should |[C++20] Preprocessor tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Andrew Pinski changed:
What|Removed |Added
Attachment #60826|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107892
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
Andrew Pinski changed:
What|Removed |Added
CC||ebiggers3 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97286
--- Comment #6 from Andrew Pinski ---
*** Bug 111829 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119384
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401
Andrew Pinski changed:
What|Removed |Added
Known to work||14.2.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397
--- Comment #1 from Andrew Pinski ---
>There should be a COPYING.*
Huh? No there does not need to be.
The notice is inside the source and all still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390
--- Comment #2 from Sam James ---
I don't see it either with glibc-2.41 (tip of stable branch). I do see
PR119377.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615
--- Comment #28 from Jakub Jelinek ---
I've managed to reproduce the aarch64-linux bootstrap miscompilation with
r15-2810, and
verified it is the
- if (before_p)
+ if (before_p && PREV_INSN (curr_insn) != prev_insn)
part of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #6 from Neil Booth ---
Yes, the problem isn't that evaluation isn't in intmax_t (so the subject is now
incorrect). That clearly happens as there are hundreds of tests that would
fail.
The problem is that cpp thinks it's undefined b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119397
Bug ID: 119397
Summary: missing license file for SunPro covered sources
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Simon Martin
:
https://gcc.gnu.org/g:f86d274ab76fdd89d7afd9b2eab28f3a61749cfb
commit r14-11426-gf86d274ab76fdd89d7afd9b2eab28f3a61749cfb
Author: Simon Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118600
--- Comment #4 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:d286ece094ca52f41bf71096aa1de0a0cd954dfb
commit r15-8475-gd286ece094ca52f41bf71096aa1de0a0cd954dfb
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
Bug ID: 119396
Summary: libgcc: Shared objects are being built for target that
doesn't support shared libs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118600
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114292
Simon Martin changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 119388, which changed state.
Bug 119388 Summary: [12/13/14/15 Regression] -isystem does not disable warnings
coming from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #4 from Andrew Pinski ---
Created attachment 60837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60837&action=edit
This works if you don't want an uninitialized variable warning from the header
file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115983
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #26 from Ard Biesheuvel ---
(In reply to Alexander Monakov from comment #25)
> (In reply to Ard Biesheuvel from comment #24)
> > - never emit 'call mcount'
> > - emit 'call *mcount@GOTPCREL(%rip)' if -fno-plt
> > - emit 'call mcount@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119392
Bug ID: 119392
Summary: ICE: in build_if_in_charge, at cp/class.cc:230
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Bug ID: 119393
Summary: [15 Regression] Worse vectorization of imagick_r hot
loop on aarch64 since r15-5024-g2a2e6784074e1f
Product: gcc
Version: 15.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #23 from Alexander Monakov ---
That's probably just copying existing behavior from 32-bit x86.
Can we preserve previous behavior that under -fpic -mno-direct-extern-access
mcount is called via GOT (and else emit mcount@PLT if -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #4 from Jakub Jelinek ---
And
#if 1U << 63
#endif
or
#if 1ULL << 63
#endif
is accepted with no diagnostics.
So, isn't this valid in C++20 and above since wg21.link/p1236 and invalid
otherwise (C++98 .. C++17 and any C)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
--- Comment #2 from Andrew Pinski ---
>I've attached a reduced reproducer which (unfortunately) still requires LTO,
>but it is at least fairly well reduced (only two small TUs).
One thing you could do is combine the 2 TUs (since they are small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615
--- Comment #27 from Jakub Jelinek ---
So the -fcompare-debug issue is because curr_insn is a JUMP_INSN:
(call_insn 10013 3 4 3 (parallel [
(call (mem:DI (symbol_ref:DI ("g") [flags 0x41] ) [0 g S8 A8])
(const_int 0 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393
Alex Coplan changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119394
Bug ID: 119394
Summary: Add fixit hint suggesting adding () to [] noexcept {}
in C++ < 23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #27 from Franz Sirl ---
Maybe silly question, but since the changelog is only talking about __fentry__,
why couldn't you make the decision based on flag_fentry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:607f92597c3047d7813a981450a7493bca014324
commit r15-8471-g607f92597c3047d7813a981450a7493bca014324
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119394
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119395
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119402
Bug ID: 119402
Summary: [14/15 Regression] `((-bool) & _6) & (~_6)` is not
optimized to 0 on some targets
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119402
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #29 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #21)
> GOT indirection for mcount has been there from the very beginning:
> https://gcc.gnu.org/cgit/gcc/tree/gcc/config/i386/i386.
> h?id=c98f874233428d7e6ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504
--- Comment #9 from Andrey Vihrov ---
Thanks, I agree this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119371
--- Comment #2 from Tobias Burnus ---
BTW: It seems as if none of the testcases in libgomp actually
calls expand_GOMP_SIMT_XCHG_IDX!
* * *
The expansion happens in internal-fn.cc's
static void
expand_GOMP_SIMT_XCHG_IDX (internal_fn, gcall *st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119376
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Bug ID: 119389
Summary: [15 Regression] tree FRE very slow when dealing with
big switch statements
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> So the problem was introduced
> somewhere before that.
... or by that commit, shouldn't discount that possibility.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
--- Comment #1 from Filip Kastl ---
This is how it looks on r15-6120-g56946c801a7cf3a831a11870b7e11ba08bf9bd87
> gcc bugreport.c -O1 -c -ftime-report
Time variable wall GGC
phase setup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> Created attachment 60834 [details]
> functional patch with bugs
>
> So this is a functional patch ontop of prerequesites that were posted for
> review. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.3
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #1 from Jonathan Wakely ---
I think this was an intentional change, but I'm failing to find the details
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119390
Bug ID: 119390
Summary: cobol compiler crashes with buffer overflow
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: cobo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #2 from Robin Dapp ---
I looked into this some more and it points to a general deficiency in how we
handle the split between VLA and VLS modes.
With ...bits=zvl the RVVM1SI etc modes. become VLS modes. In turn, this means
that whene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Patrick Palka changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #11 from Michael Matz ---
The binutils in our (SUSEs) enterprise codestreams revert certain behaviour
changes from upstream in relation to rewriting PC32 to PLT32 relocs (as some
old
tooling doesn't cope with that). So, our binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #13 from H.J. Lu ---
(In reply to Michael Matz from comment #11)
> access to the respective GOT slot). Upstream binutils now silently do emit a
> route via PLT, our binutils complain. I'm not sure that upstream behaviour
> is
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #7 from Marek Polacek ---
Huh. I guess I should take a look then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #12 from Michael Matz ---
(clicked send too soon)
...
Either way, I think GCC should emit a PIC sequence under -fPIC, also for
the function profiler, either by direct GOT access, or by using the @plt
decoration, depending on if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544
--- Comment #23 from Thomas Schwinge ---
(In reply to myself from comment #22)
> We "simply" need to transform any symbol aliases into thunks calling the
> aliasee (or duplicate the bodies, if we must).
Also no luck implementing that as a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386
--- Comment #14 from Michael Matz ---
(In reply to H.J. Lu from comment #13)
> (In reply to Michael Matz from comment #11)
>
> > access to the respective GOT slot). Upstream binutils now silently do emit
> > a
> > route via PLT, our binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
Andre Vehreschild changed:
What|Removed |Added
CC||vehre at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #2 from Jonathan Wakely ---
I can't bisect this because r14-386 (for PR109666) fixed an ICE that this code
hits, and r14-386 is already slow. So the problem was introduced somewhere
before that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241
Richard Biener changed:
What|Removed |Added
Attachment #60819|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #4 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119389
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399
Bug ID: 119399
Summary: Overlap check in vectorized code may invoke UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #9 from Andrew Pinski ---
It would be better if you have an example of a false positive from the system
headers rather than the current one you showed of a true positive.
Yes there are a few in gcc bug system already dealing with -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119391
--- Comment #8 from Jakub Jelinek ---
Most of arithmetics is still UB on signed overflow even in C++20, there are
just small exceptions like the left shift.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #12 from Giuseppe D'Angelo ---
The testcase was just meant to show that a warning originating in a system
header was still be emitted, not that the specific warning didn't make sense :)
Of course it was silly/extreme.
But I understa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119375
--- Comment #2 from Andi Kleen ---
I already had that commit in my tree, since it was already on trunk.
Or did you think of something different?
commit cfdb961588ba318a78e995d2e2cde43130acd993
Author: Alex Coplan
Date: Tue Nov 26 17:48:14 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118914
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:e8a5f747cfa9c79ab7d95ff95d17d3e31afede50
commit r15-8478-ge8a5f747cfa9c79ab7d95ff95d17d3e31afede50
Author: Andrew Pinski
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119398
Bug ID: 119398
Summary: partial ordering of nested class template
specializations fails with NTTP of nested class type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #3 from Andrew Pinski ---
mingw defaults to -fms-extensions. If you don't want these extensions then use
-fno-ms-extensions.
Note the definition of the extensions has changed over time and GCC has not
kept up to date with them; look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119383
--- Comment #3 from Sam James ---
I couldn't reproduce with the script as Boost failed to build (`ERROR: rule
"version.boost-build" unknown in module "build-system".`). I've dealt with b2
(the Boost build system before) and I'm not a fan :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
--- Comment #3 from Jerry DeLisle ---
Works for me on gcc version 12.3.1 20230805 (GCC)
The last commit there is commit a3931bf6093dbeda637601da07cdbbd07e57ccbd (HEAD
-> releases/gcc-12)
This was a cherry pick from commit 03fb35f8753d87148b. M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119396
--- Comment #1 from Andrew Pinski ---
>From libgcc/Makefile.in:
```
enable_shared = @enable_shared@
...
# Only handle shared libraries if both:
# - the user requested them
# - we know how to build them
ifeq ($(SHLIB_LINK),)
enable_shared :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107352
Andrew Pinski changed:
What|Removed |Added
CC||rush102333 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119392
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Bug ID: 119400
Summary: Windows-targeted builds of GCC allow -fpermissive
-Wimplicit-int behaviour in C++
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #7 from Andrew Pinski ---
Note yes there are a bunch of false positives for some system headers but many
of the warnings have actually helped adding hints to compiler to both remove
the false positives and improve code quality.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #11 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #8)
> Well, that's a laudable goal, but I'm very afraid it'll just cause the
> corresponding warnings to be entirely disabled instead -- since in many
> cases t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119375
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #1 from Andrew Pinski ---
-fms-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #2 from Andrew Pinski ---
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-c4430?view=msvc-170
This error might be generated due to compiler conformance work done for Visual
Studio 2005: all d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-03-21
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119401
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #5 from Giuseppe D'Angelo ---
Hi,
Thanks for the link. However this isn't just about -Wuninitialized, but also
about a bunch of other (middle-end?) warnings, as I wrote in the first message.
(To add insult to injury, they're also fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119361
--- Comment #3 from Edwin Lu ---
(In reply to Robin Dapp from comment #2)
> I looked into this some more and it points to a general deficiency in how we
> handle the split between VLA and VLS modes.
> With ...bits=zvl the RVVM1SI etc modes. beco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119392
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #8 from Giuseppe D'Angelo ---
Well, that's a laudable goal, but I'm very afraid it'll just cause the
corresponding warnings to be entirely disabled instead -- since in many cases
the end-user can't upgrade the system header, nor the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118545
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119400
--- Comment #5 from Ilya Zylev ---
Thank you very much, that clarifies original post.
-fms-extensions
-fno-ms-extensions
options work as intended.
Is it possible to configure these options from inside the source code being
compiled by GCC? P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118765
--- Comment #17 from Hime Haieto ---
I'm not entirely sure what I should be doing/commenting on at the moment
considering that the current patches are clearly marked as being
temporary/partial fixes. However, I did still mess around with it a b
1 - 100 of 188 matches
Mail list logo
