https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #4 from Andrew Pinski ---
(In reply to Feng Xue from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Note on aarch64 with SVE, you should be able to generate those constants
> > without a load, using the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111003
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #3 from Feng Xue ---
(In reply to Andrew Pinski from comment #1)
> Note on aarch64 with SVE, you should be able to generate those constants
> without a load, using the index instruction.
Ok. Thanks for the note. This still requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
--- Comment #2 from Andrew Pinski ---
Basically this requires an "un-shift" pass and most likely should be done at
the RTL level though that might be too late.
Maybe isel?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113328
Bug ID: 113328
Summary: Some fixed length vector constants can be generated
using SVE index instruction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113327
Bug ID: 113327
Summary: std::sleep_for(std::chrono::hours::max()) returns
immediately
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #3 from john.harper at vuw dot ac.nz ---
I suspect that valgrind complained because I had not given an else part
for the variable cmd. In my system the valgrind error message went away
when I declared and evaluated cmd as follows:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113326
Bug ID: 113326
Summary: Optimize vector shift with constant delta on
shifting-count operand
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #2 from john.harper at vuw dot ac.nz ---
Thank you! You may wish to know that in my Ubuntu system the program
runs properly if the function iam is used in an assignment statement not a
print statement. (Fortran Discourse gave me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113325
Bug ID: 113325
Summary: unnecessary byte swap for memory clear
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113324
Bug ID: 113324
Summary: internal compiler error: in reload_combine_note_use,
at postreload.c:1534
Product: gcc
Version: 10.5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113323
Bug ID: 113323
Summary: ICE: tree check: expected none of vector_type, have
vector_type in bitint_precision_kind, at
gimple-lower-bitint.cc:131 with _BitInt()
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #10 from H. Peter Anvin ---
Right, is there such an attribute (that's what I'm asking for in bug 103503)?
All I see in the gcc documentation is no_calle*R*_saved_registers, which,
again, is the exact opposite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250
Ken Matsui changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113250
Ken Matsui changed:
What|Removed |Added
CC||kmatsui at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
--- Comment #2 from Andrew Pinski ---
`-O3 -g0 -march=sapphirerapids`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #8 from Andrew Pinski ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642582.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #9 from H.J. Lu ---
(In reply to H.J. Lu from comment #8)
> (In reply to H.J. Lu from comment #7)
> > (In reply to H. Peter Anvin from comment #6)
> > > Of course. That's not what we want in the Linux kernel specifically,
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #8 from H.J. Lu ---
(In reply to H.J. Lu from comment #7)
> (In reply to H. Peter Anvin from comment #6)
> > Of course. That's not what we want in the Linux kernel specifically, though.
> > It's really up to the OS.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #7 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #6)
> Of course. That's not what we want in the Linux kernel specifically, though.
> It's really up to the OS.
no_callee_saved_registers attribute is sufficient. One can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
--- Comment #8 from Fangrui Song ---
I've encountered another use case related to metadata sections (establish an
artificial reference for linker garbage collection purposes)
namespace ns { extern int var; } // defined in another translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113322
Bug ID: 113322
Summary: [14 Regression] internal compiler error: tree check:
expected none of vector_type, have vector_type in
expand_single_bit_test, at expr.cc:13375
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103503
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113010
--- Comment #7 from Greg McGary ---
(In reply to Greg McGary from comment #6)
> I agree that it pertains to WORD_REGISTER_OPERATIONS. However, the check
> needs to happen.
... needs to happen *earlier*.
(I wish comments were editable)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113010
--- Comment #6 from Greg McGary ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Greg McGary from comment #3)
> > > This fixes it, though I would like second look from someone more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #6 from H. Peter Anvin ---
Of course. That's not what we want in the Linux kernel specifically, though.
It's really up to the OS.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197
Andrew Pinski changed:
What|Removed |Added
Target Milestone|14.0|12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #5 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #3)
> Created attachment 57032 [details]
> FRED assembly entry stub (example, slightly modified from the Linux kernel)
Can you do
asm_fred_entry_\type:
endbr64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
--- Comment #2 from H. Peter Anvin ---
Right. The only thing I'm suggesting is that for the cost of one extra
instruction we can make it robust against the programmer picking the wrong
type, or wanting to use the same handler.
It isn't a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #4 from H. Peter Anvin ---
(In reply to H.J. Lu from comment #2)
> (In reply to H. Peter Anvin from comment #1)
> > This is actually a specific use case of the feature requested in bug 103503.
>
> This covers #1. Should FRED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #3 from H. Peter Anvin ---
Created attachment 57032
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57032=edit
FRED assembly entry stub (example, slightly modified from the Linux kernel)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
--- Comment #1 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #0)
> __attribute__((interrupt)) on x86 has two prototypes, and picking the wrong
> type "probably will cause a system crash." It turns out that this is
> unavoidable on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2024-01-11
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113321
Bug ID: 113321
Summary: x86-64: Make __attribute__((interrupt)) more robust
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113312
--- Comment #1 from H. Peter Anvin ---
This is actually a specific use case of the feature requested in bug 103503.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113247
--- Comment #10 from Li Pan ---
(In reply to Robin Dapp from comment #9)
> I also noticed this (likely unwanted) vector snippet and wondered where it
> is being created. First I thought it's a vec_extract but doesn't look like
> it. I'm going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401
Hongtao Liu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104401
--- Comment #7 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:6686e16fda419067b91614835dd743ebb82717ea
commit r14-7124-g6686e16fda419067b91614835dd743ebb82717ea
Author: liuhongt
Date: Tue Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113320
Bug ID: 113320
Summary: libstdc++ accepts std::format(std::move(runtime_fmt),
42);
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #35 from JuzheZhong ---
(In reply to Vineet Gupta from comment #33)
> cam4 failure is a bug in vsetvl pass which I'm debugging atm.
> An erroneous vsetvl insn is getting generated, clobbering a live register
> used subsequently in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #34 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #32)
> (In reply to JuzheZhong from comment #31)
> > You are using -Ofast which will have precision issue on floating-point.
> >
> > You can reference it:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110841
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110941
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=108007
--- Comment #19 from Andrew Pinski ---
*** Bug 110294 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110294
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110705
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319
Andrew Pinski changed:
What|Removed |Added
Keywords||lto, testsuite-fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110450
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946
--- Comment #8 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:96a9355a3d5b24f010fa6ad0b51bba5cc3f334f1
commit r14-7123-g96a9355a3d5b24f010fa6ad0b51bba5cc3f334f1
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113319
Bug ID: 113319
Summary: Random LTO test failures
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823
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=113087
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #32 from Patrick O'Neill ---
(In reply to JuzheZhong from comment #31)
> You are using -Ofast which will have precision issue on floating-point.
>
> You can reference it:
>
> https://godbolt.org/z/zzG8xbx95
>
> O3 result:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
--- Comment #11 from Andrew Pinski ---
So the problem is avr_option_optimization_table sets the default
mlong-double/mdouble size but if you don't have save on the option, it changes
back to the default which then errors out.
Other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
--- Comment #4 from Jonathan Wakely ---
(In reply to Michael Levine from comment #2)
> Should it not require including
No, I don't see why. It's specified to be in .
This looks like a simple bug, that's all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113318
Bug ID: 113318
Summary: [C++23] Implement P1185R12, Naming text encodings to
demystify them
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #31 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #30)
> (In reply to Li Pan from comment #29)
> > Thanks a lot for the summary. Could you please help to share some more
> > information about the spec2017 for above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
--- Comment #5 from Jonathan Wakely ---
Since the set of locales that get this encoding conversion is impl-defined, we
*could* just say that for libstdc++ the set is empty. Done, feature implemented
:-P
That's cheating though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Jonathan Wakely from comment #0)
> > https://wg21.link/P2419R2 localized chrono formatting (also p2372r3)
>
> I think this this requires using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
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=113305
--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-January/060110.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:8415bceea9d3ca86adc00ae8ad92deaec0457dd1
commit r14-7117-g8415bceea9d3ca86adc00ae8ad92deaec0457dd1
Author: Antoni Boucher
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #30 from Patrick O'Neill ---
(In reply to Li Pan from comment #29)
> Thanks a lot for the summary. Could you please help to share some more
> information about the spec2017 for above data? Like data set (test, train,
> or ref), the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Even then, I wonder why ranger doesn't figure this out.
> > (x+1u) <= 2 ? x : 0
> > must have a range [-1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314
--- Comment #1 from David Malcolm ---
Indeed, if this is a single-threaded program, then this code:
63 void
64 fd_add_to_fd_list(volatile struct fdlist* list, int fd)
65 {
66int next;
67int new;
68int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
--- Comment #1 from Peter Bergner ---
(In reply to seurer from comment #0)
> g:1413af02d62182bc1e19698aaa4dae406f8f13bf, r14-7033-g1413af02d62182
>
> Note I only saw this failure on one powerpc64 LE system. It works OK on
> others.
You tend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113317
Bug ID: 113317
Summary: New test case libgomp.c++/ind-base-2.C fails with ICE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113315
--- Comment #2 from Zdenek Sojka ---
Created attachment 57031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57031=edit
probably related testcase, ICEing elsewhere at -O0
Compiler output for testcase3.c:
$ x86_64-pc-linux-gnu-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113316
Bug ID: 113316
Summary: during GIMPLE pass: bitintlower ICE: SIGSEGV in
var_to_partition (tree-ssa-live.h:163) at -O with
uninitialized _BitInt() function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113315
--- Comment #1 from Zdenek Sojka ---
Created attachment 57029
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57029=edit
probably related testcase, ICEing elsewhere at -O1
Compiler output with the other testcase at -O1:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113307
--- Comment #1 from waffl3x ---
I'm on it.
el: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240110 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113314
Bug ID: 113314
Summary: -Wanalyzer-infinite-loop false positive seen on
haproxy's fd.c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
--- Comment #6 from anlauf at gcc dot gnu.org ---
Created attachment 57026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57026=edit
Draft patch
Draft patch that passes annotations to DO CONCURRENT loops.
Needs testing and feedback.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
--- Comment #7 from Tom Tromey ---
(In reply to David Blaikie from comment #6)
> Ideally that'd be detected by looking at the abbreviation table, rather than
> the augmentation string - if parent info is necessary for a usage of the
> table,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
Bug ID: 113313
Summary: execute_command_line hangs at run time
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112946
--- Comment #7 from Gaius Mulley ---
Created attachment 57025
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57025=edit
Proposed fix v2
The proposed patch fixes the expression type mismatch case presented above. It
also fixes a number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
--- Comment #5 from Steve Kargl ---
On Wed, Jan 10, 2024 at 06:24:40PM +, ivan.pribec at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
>
> --- Comment #3 from Ivan Pribec ---
> In the mail archive
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
--- Comment #3 from Daniel Krügler ---
(In reply to Michael Levine from comment #2)
> (In reply to Daniel Krügler from comment #1)
> > (In reply to 康桓瑋 from comment #0)
> > > It seems wrong that libstdc++ needs to include for
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
--- Comment #12 from Jan Hubicka ---
I think this is a problem with two meanings of always_inline. One is "it must
be inlined or otherwise we will not be able to generate code" other is
"disregard inline limits".
I guess practical solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113300
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-01-10
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
--- Comment #6 from David Blaikie ---
(In reply to Tom Tromey from comment #5)
> (In reply to David Blaikie from comment #4)
>
> I don't remember filing this bug. At the time maybe I thought it
> would be worthwhile to have "end to end"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Michael Levine changed:
What|Removed |Added
CC||mlevine55 at bloomberg dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #14 from Andrew Pinski ---
Note for GCC 15, I think it might be best if single_set moves away from
REG_UNUSED to use df directly, like Steve provided a similar function in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209#c6 . That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
--- Comment #3 from Ivan Pribec ---
In the mail archive
(https://gcc.gnu.org/legacy-ml/fortran/2014-02/msg00077.html) I've read a
message implying that do concurrent gets translated into a regular for-loop
annotated with "#pragma ivdep", which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113308
--- Comment #3 from waffl3x ---
I meant to post this link instead of one of the others.
https://godbolt.org/z/oMP8185Yh
I guess I shouldn't be replying to things while still waking up, sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113305
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113298
--- Comment #4 from Jason Merrill ---
GCC trunk now lets us associate permerrors with a -W flag, so this would be
pretty trivial to do. It's a matter of adding an option to c-family/c.opt and
doc/invoke.texi and changing the relevant permerror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113298
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-01-10
Ever confirmed|0
1 - 100 of 212 matches
Mail list logo
