https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07
Alex Henrie changed:
What|Removed |Added
CC||alexhenrie24 at gmail dot com
---
Hi!
The following testcase is miscompiled in GCC 14 because the
*jcc_bt_mask and *jcc_bt_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #5 from Bruno Haible ---
(In reply to Andrew Pinski from comment #3)
> Also did you add -fvar-tracking-assignments ?
No, I haven't. I have specified CFLAGS=-ggdb, indicating that
- I don't care about the optimization level,
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #17 from Artem S. Tashkinov ---
Terrific results, thanks a ton!
Maybe this bug report could be closed now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #4 from Bruno Haible ---
(In reply to Andrew Pinski from comment #1)
> Is this with or without optimization?
Since in step 5, I specified CFLAGS=-ggdb, it is without optimization.
(configure sets CFLAGS="-O2 -g" only if CFLAGS is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112709
Bug ID: 112709
Summary: ICE verify_flow_info failed during GIMPLE pass: asan0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #3 from Andrew Pinski ---
Also did you add -fvar-tracking-assignments ? (there are other reports asking
to turn on -fvar-tracking-assignments for -O0 except it is a big compile time
increase in many cases).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #2 from Andrew Pinski ---
>Which means that the culprit is gcc.
Not always ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
--- Comment #1 from Andrew Pinski ---
Is this with or without optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112708
Bug ID: 112708
Summary: "gcc -fsanitize=address" produces wrong debug info for
variables in function prologue
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #2 from Christopher Fore ---
Created attachment 56684
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56684=edit
assembly output of sharedbook.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
--- Comment #1 from Christopher Fore ---
Created attachment 56683
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56683=edit
trimmed file with cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112707
Bug ID: 112707
Summary: gcc 14 outputs invalid assembly on ppc: Error:
unrecognized opcode: `fctid'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
While looking at the various targets, I found that the m32r
target has two options implemented as opposites:
-mbranch-cost=1 and -mbranch-cost=2, that have a bug that
makes them yield their functionally opposite effect;
i.e. -mbranch-cost=$arg, arg={1, 2} yields BRANCH_COST(x, y)
3-$arg. Anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102341
--- Comment #6 from CVS Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:9dd8be6fc2debc4fbd0950386d4e98878af27a45
commit r14-5838-g9dd8be6fc2debc4fbd0950386d4e98878af27a45
Author: Nathaniel Shead
OKAY, I figured out SOMETHING, I think this should be fine. As noted in
the comments, this might be a better way of handling the static lambda
case too. This is still a nasty hack so it should probably be done
differently, but I question if making a whole new fntype node in
tsubst_lambda_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812
--- Comment #20 from Jan Hubicka ---
On zen4 hardware I now get
GCC13 with -O3 -flto -march=native -fopenmp
2163
2161
2153
Average: 2159 Iterations Per Minute
clang 17 with -O3 -flto -march=native -fopenmp
Okay within about half an hour today I think I've figured out what the
main issue is for my problem. For the static lambda case, while I don't
like the hack that's currently present, I reckon we just leave it as it
is, as it works just fine right now. For my issue, I'm not totally sure
how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #8 from Jan Hubicka ---
On ARM32 and other targets methods returns this pointer. Togher with making
return value escape this probably completely disables any chance for IPA
tracking of C++ data types...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #16 from Sam James ---
Thank you all for the effort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015
--- Comment #10 from Jan Hubicka ---
runtimes on zen4 hardware.
trunk -O3 -flto -march-native
42171
42964
42106
clang -O3 -flto -march=native
37393
37423
37508
gcc 13 -O3 -flto -march=native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #15 from Jan Hubicka ---
With SRA improvements r:aae723d360ca26cd9fd0b039fb0a616bd0eae363 we finally get
good performance at -O2. Improvements to push_back implementation also helps a
bit.
Mainline with default flags (-O2):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112660
--- Comment #2 from Andrew Pinski ---
(In reply to gooncreeper from comment #1)
> This could be further extended for signed integers as we can assume for left
> shifts that shifted out bits are always 0 else UB, and always combine x << a
> >>
On Fri, 24 Nov 2023, Tobias Burnus wrote:
> While I expect more changes, I want to cleanup my stashed changes.
Good approach!
+ The destory now optionally accepts the depend object as
+ argument.
Is "depend object" a well known technical term in that context? And is it
"the depend
Snapshot gcc-12-20231124 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20231124/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Fri, 24 Nov 2023, Tobias Burnus wrote:
> As in a set of benchmarks, an geometric-mean improvement of 9% (noise to
> 25%) was found, I think we should mention this improvement proudly.
Definitely!
> Comments?
The ", hence," broke my reading flow; maybe simply omit it? Either way,
okay.
Jakub Jelinek writes:
> Hi!
>
> The aarch64_simd_stp pattern uses w constraint in one alternative and
> r in another, but for the latter incorrectly uses iterator in %1
> which
> expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to
> the pattern) and %w1 for others, so it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112660
--- Comment #1 from gooncreeper ---
This could be further extended for signed integers as we can assume for left
shifts that shifted out bits are always 0 else UB, and always combine x << a >>
b.
On 11/10/23 17:52, Nathaniel Shead wrote:
I noticed while fixing PR106849 that we don't currently check validity
of exporting non-functions via using-declarations either; this patch
adds those checks factored out into a new function. I also tried to make
the error messages a bit more
On 11/23/23 21:10, Nathaniel Shead wrote:
On Thu, Nov 23, 2023 at 11:45:31AM -0500, Nathan Sidwell wrote:
On 11/13/23 01:09, Nathaniel Shead wrote:
I happened to be browsing the standard a bit later and noticed that we
incorrectly reject the example given below.
Bootstrapped on
On Fri, 24 Nov 2023 at 20:07, Jan Hubicka wrote:
> The vector.tcc change was regtested on x86_64-linux, OK?
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/vector.tcc (reserve): Copy _M_start and _M_finish
> to local variables to allow propagation across call to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
--- Comment #3 from Jan Hubicka ---
Thanks, new pattern looks like noticeable improvement :)
Base+offset is effective for alias analysis and I suppose it happens
reasonably enough for compares as well.
> _76 = _71 + 4;
> # .MEM_154 = VDEF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> That is:
> ```
> (for op (eq ne)
> (simplify
> (op (pointer_plus @0 @1) (pointer_plus @0 @2))
> (op @1 @2))
>
> ```
Note I am missing a extra `)` but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
Lewis Hyatt changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
--- Comment #3 from CVS Commits ---
The master branch has been updated by Lewis Hyatt :
https://gcc.gnu.org/g:5d4abd9219dfa53b52b341255e99139bb6cad302
commit r14-5836-g5d4abd9219dfa53b52b341255e99139bb6cad302
Author: Lewis Hyatt
Date: Wed
> With my changes at -O3 we now inline push_back, so we could optimize the
> first loop to the second. However with
> ~/trunk-install/bin/gcc -O3 auto.C -S -fdump-tree-all-details
> -fno-exceptions -fno-store-merging -fno-tree-slp-vectorize
> the fist problem is right at the begining:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #9 from Jakub Jelinek ---
Reproduced on powerpc64le-linux with just
../configure --enable-languages=c,c++ --enable-checking=yes,rtl,extra
--disable-libsanitizer --with-long-double-128; make -j160 profiledbootstrap
so fortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112706
Bug ID: 112706
Summary: missed simplification in FRE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
On Thu, 23 Nov 2023, Jonathan Wakely wrote:
That's why we need -fsane-operator-new
Although the standard forbids it, some of us just provide an inline
implementation
inline void* operator new(std::size_t n){return malloc(n);}
inline void operator delete(void*p)noexcept{free(p);}
inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112700
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Office Hours for the GNU Toolchain on 2023-11-30 at 11am EST5EDT.
Agenda:
* https://gcc.gnu.org/wiki/OfficeHours#Next
Meeting Link:
* https://bbb.linuxfoundation.org/room/adm-xcb-for-sk6
--
Cheers,
Carlos.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
--- Comment #3 from Jonathan Wakely ---
It's also documented in the release notes:
https://gcc.gnu.org/gcc-13/changes.html#c (see N2836, Identifier Syntax using
Unicode Standard Annex 31).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #48 from post+gcc at ralfj dot de ---
> Note, clang makes the same assumption apparently (while MSVC emits rep movs
> inline and ICC either that, or calls _intel_fast_memcpy).
MSVC does the same thing as clang and GCC, if godbolt is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112705
Bug ID: 112705
Summary: FAIL: gcc.dg/analyzer/pr94688.c (test for excess
errors)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Committed as r14-5835-g6eb1507107dee3
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112704
Bug ID: 112704
Summary: FAIL: gcc.dg/analyzer/data-model-20.c (test for
warnings, line 17)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110794
John David Anglin changed:
What|Removed |Added
Last reconfirmed|2023-11-17 00:00:00 |2023-11-24
--- Comment #1 from
On Wed, 22 Nov 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
>
> -- >8 --
>
> This patch implements C++23 class template argument deduction from
> inherited constructors, which is specified in terms of C++20 alias
> CTAD which we
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below modules testcase which otherwise tries to inspect
Hi!
The aarch64_simd_stp pattern uses w constraint in one alternative and
r in another, but for the latter incorrectly uses iterator in %1 which
expands to %d1 for V2DF and %s1 for V2SF and V4SF (this one not relevant to
the pattern) and %w1 for others, so it ICEs if the alternative is selected
On 24/11/2023 16:07, Tobias Burnus wrote:
Stumbled over this.
I wondered whether we should recommend newlib >= 12e3bac3c (31st Oct
2023), but
given that gfx1030 is not yet supported, I decided against it. We can
revisit
this once newlib 4.4 is available.
This makes sense to me. We can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5822-20231124121307-g3eb9cae6d37-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231124 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Sam James changed:
What|Removed |Added
Summary|[14 Regression] 30-40% exec |[14 Regression] 30-40% exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
This fixes a couple of places in pa_emit_move_sequence that should
be using the INT14_OK_STRICT macro.
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
hppa: Use INT14_OK_STRICT in a couple of places in pa_emit_move_sequence
64-bit Linux target has relocation issue and can't use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #25 from Martin Jambor ---
(In reply to Richard Biener from comment #7)
> There is nothing to sink really, loop header copying introduces a PHI and
> there's not partial redundancies but only partial-partial and those are not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:c2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
commit r14-5832-gc2dcfb6ba6e9a84a16e63ae73a822ae2a843170c
Author: Jan Hubicka
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #9 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:cc4cbf38e842cf023e2bdc63a51ef836d7726d8e
commit r13-8098-gcc4cbf38e842cf023e2bdc63a51ef836d7726d8e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:cc4cbf38e842cf023e2bdc63a51ef836d7726d8e
commit r13-8098-gcc4cbf38e842cf023e2bdc63a51ef836d7726d8e
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112269
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:dd57446bd90c3225ce45e8818c5b00f2e86a9607
commit r13-8097-gdd57446bd90c3225ce45e8818c5b00f2e86a9607
Author: Patrick Palka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111703
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:dd57446bd90c3225ce45e8818c5b00f2e86a9607
commit r13-8097-gdd57446bd90c3225ce45e8818c5b00f2e86a9607
Author: Patrick Palka
Hi Cuper.
Sorry, I missed this patch last week.
This is OK.
Thanks!
> This patch forces __builtin_memcmp calls upto data sizes of 1024 to
> become inline in caller.
> This is a requirement by BPF and it mimics the default behaviour of the
> clang BPF implementation.
>
> gcc/ChangeLog:
>
This problem here is that IPA is calling something like operator_minus
with 2 operands, one with precision 32 (int) and one with precision 64
(pointer). There are various ways this can happen as mentioned in the PR.
Regardless of whether IPA should be doing promoting types or not calling
into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #23 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:aae723d360ca26cd9fd0b039fb0a616bd0eae363
commit r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
For -mcmodel=large, we have to load function address to a register.
PR target/112686
gcc/ChangeLog:
* config/i386/i386.cc (ix86_expand_split_stack_prologue): Load
function address to a register for ix86_cmodel == CM_LARGE.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr112686.c:
On Fri, Nov 24, 2023 at 05:26:44PM +0100, Tobias Burnus wrote:
> @@ -65,8 +72,11 @@
>was extended. Additionally, the spec change has been implemented for
>default implicit mapping of C/C++ pointers pointing to unmapped
> storage.
> + The destory now optionally accepts the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112686
--- Comment #4 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:404ea4c1381398aee162415a88e5cb81c44f8c69
commit r14-5830-g404ea4c1381398aee162415a88e5cb81c44f8c69
Author: Uros Bizjak
Date: Fri
While I expect more changes, I want to cleanup my stashed changes.
Current version: https://gcc.gnu.org/gcc-14/changes.html#openmp
Comments?
Tobias
PS: stack variable support in C++ for 'allocate' is pending review;
I also expect a Fortran parser update for 'indirect'. Several more
features
Hi everyone,
The attached patch is a temporary solution for the lack of proper linker
and external library linking of the eBPF platform.
Any calls created by the compiler, that would usually be defined within
libgcc, will endup being undefined in bpftool, when GCC the compiled
code is passed.
Andrew Carlotti writes:
> This adds initial support for function multiversioning on aarch64 using
> the target_version and target_clones attributes. This loosely follows
> the Beta specification in the ACLE [1], although with some differences
> that still need to be resolved (possibly as
Comments before I commit it?
Current version: https://gcc.gnu.org/gcc-14/changes.html#general
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf;
As in a set of benchmarks, an geometric-mean improvement of 9% (noise to 25%)
was found, I think we should mention this improvement proudly.
(Kudos goes to two Andrews - Jenner and Stubbs!)
Current version: https://gcc.gnu.org/gcc-14/changes.html#amdgcn
Comments?
Tobias
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Stumbled over this.
I wondered whether we should recommend newlib >= 12e3bac3c (31st Oct 2023), but
given that gfx1030 is not yet supported, I decided against it. We can revisit
this once newlib 4.4 is available.
Current version is: https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112562
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Wed, Nov 01, 2023 at 05:54:57PM -0400, Lewis Hyatt wrote:
> Since r14-2893, the frontend parser object needs to exist when running in
> preprocess-only mode, because pragma_lex() is now called in that mode and
> needs to make use of it. This is handled by calling c_init_preprocess() at
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #2 from Andrew Macleod ---
It seems like we set 'e' to 3 immediately at the start:
[local count: 1073741824]:
e = 3;
goto ; [100.00%]
and it is never changed again. However, when we load from 'e' later in the IL
[local
On 24/11/2023 15:06, Thomas Schwinge wrote:
Hi!
On 2023-11-24T15:55:52+0100, I wrote:
OK to push the attached
"GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves
[PR112669]"?
With that in place, we may then "GCN: Remove 'last_arg' spec function",
see attached; OK to push?
On 24/11/2023 14:55, Thomas Schwinge wrote:
Hi!
On 2017-06-21T11:06:24+0100, Andrew Stubbs wrote:
--- a/gcc/config/gcn/gcn.opt
+++ b/gcc/config/gcn/gcn.opt
+march=
+Target RejectNegative Joined ToLower Enum(gpu_type) Var(gcn_arch)
Init(PROCESSOR_CARRIZO)
+Specify the name of the target
Hi!
As reported in the PR, mipsisa64r2-sde-elf doesn't build because
HEAP_TRAMPOLINES_INIT
macro isn't defined anywhere.
It is normally defined by
# Figure out if we need to enable heap trampolines by default
case ${target} in
*-*-darwin2*)
# Currently, we do this for macOS 11 and above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112300
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108351
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112701
--- Comment #1 from Andrew Pinski ---
Interesting is MSVC emits both. clang emits none.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
--- Comment #2 from Andrew Pinski ---
The answer is to is expected, the answer is YES.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109936
Andrew Pinski changed:
What|Removed |Added
CC||stammark at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
Richard Biener changed:
What|Removed |Added
Known to fail||13.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111465
--- Comment #13 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:152400decc8383aeff9a9ad8262b9e7e2fff61e0
commit r13-8096-g152400decc8383aeff9a9ad8262b9e7e2fff61e0
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:4649121c8e3bae1315e265ad2e205990e39573c5
commit r13-8095-g4649121c8e3bae1315e265ad2e205990e39573c5
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112702
Bug ID: 112702
Summary: C23, C++23: Extended characters not valid in an
identifier with -pedantic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
Hi!
On 2023-11-24T15:55:52+0100, I wrote:
> OK to push the attached
> "GCN: Tag '-march=[...]', '-mtune=[...]' as 'Negative' of themselves
> [PR112669]"?
With that in place, we may then "GCN: Remove 'last_arg' spec function",
see attached; OK to push?
Grüße
Thomas
-
Siemens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|14.0|11.5
--- Comment #9 from Uroš Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #8 from CVS Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:422e30e4d5ca2f26f77e7c90e09658408c07a23c
commit r11-1-g422e30e4d5ca2f26f77e7c90e09658408c07a23c
Author: Uros Bizjak
1 - 100 of 210 matches
Mail list logo
