>> gcc/
>> PR tree-optimization/98598
>> * Makefile.in (OBJS): Add tree-ssa-loop-mgo.o.
>> * common.opt (-ftree-loop-mgo): New option.
>
> Just a quick comment - -ftree-loop-mgo is user-facing and it isn't really a
> good
> name. -floop-mgo would be better but still I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #4 from Daniel Starke ---
Created attachment 50772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50772=edit
rdtsc.c
Please find attached the mingw-w64 file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #16 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #15)
> (In reply to Hongtao.liu from comment #14)
> > (In reply to Hongtao.liu from comment #12)
> > > (In reply to Jakub Jelinek from comment #10)
> > > > Last touched
>> To simplify explanation of this memory gathering optimization, pseudo
>> code on original nested loops is given as:
>>
>> outer-loop ( ) { /* data in inner loop are also invariant in outer loop.
>> */
>> ...
>> inner-loop (iter, iter_count) { /* inner loop to apply MGO */
>>
>>
A change to check glvalue_p rather than specifically for TARGET_EXPR
revealed issues with the coroutines code's use of the 'rvalue' function,
which shouldn't be used on class glvalues, so I've removed those calls.
In build_co_await I just dropped them, because I don't see anything in the
co_await
PowerPC64 ELFv2 dual entry point functions have a couple of problems
with -fpatchable-function-entry. One is that the nops added after the
global entry land in the global entry code which is constrained to be
a power of two number of instructions, and zero global entry code has
special meaning
This reverts commit b680b9049737198d010e49cf434704c6a6ed2b3f now
that the PowerPC64 ELFv1 regression is fixed properly.
PR testsuite/98125
* targhooks.h (default_print_patchable_function_entry_1): Delete.
* targhooks.c (default_print_patchable_function_entry_1): Delete.
On PowerPC64 ELFv1 function symbols are defined on function
descriptors in an .opd section rather than in the function code.
.opd is not split up by the PowerPC64 backend for comdat groups or
other situations where per-function sections are required. Thus
SECTION_LINK_ORDER can't use the function
This series of patches fixes -fpatchable-function-entry on PowerPC64
ELFv1 so that SECTION_LINK_ORDER (.section 'o' arg) is now supported,
and on PowerPC64 ELFv2 to not break the global entry code.
Bootstrapped powerpc64le-linux and x86_64-linux all langs. I did see
one regression on both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
--- Comment #1 from Ramchandra Apte ---
(In reply to Ramchandra Apte from comment #0)
> Created attachment 50771 [details]
> Minimal example
>
> Adding an templated function overload for operator+= and including
> causes a compilation error
Hi Segher,
>>
>> I think this should be postponed to stage 1 though? Or is there
>> anything very urgent in it?
>>
>
> Yeah, I agree that this belongs to stage1, and there isn't anything
> urgent about it. Thanks for all further comments above!
>
Gentle ping this:
Hi,
This patch is to teach forwprop to optimize some cases where the
permutated operands of vector permutation are from two same type
CTOR and CTOR or one CTOR and one VECTOR CST. It aggressively
takes VIEW_CONVERT_EXPR as trivial copies and transform the vector
permutation into vector CTOR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100465
Bug ID: 100465
Summary: Overloading operator+= and including filesystem causes
conflicting overload compilation error
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Gentle ping.
Original message:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html
Thanks,
Jiufu Guo.
Hi,
For some cases that when we load unsigned char/short values from
the appropriate unsigned char/short memories and convert them to
double/single precision floating point value, there would be
implicit conversions to int first. It makes GCC not leverage the
P9 instructions lxsibzx/lxsihzx.
Hi,
We noticed that SPEC2017 503.bwaves_r run time degrades by about 8%
on P8 and P9 if we enabled vectorization at O2 fast-math.
Comparing to Ofast, compiler doesn't do the loop interchange on the
innermost loop, it's not profitable to vectorize it then. Since
with loop vectorization, the loop
Hi,
When I was investigating density_test heuristics, I noticed that
the current rs6000_density_test could be used for single scalar
iteration cost calculation, through the call trace:
vect_compute_single_scalar_iteration_cost
-> rs6000_finish_cost
-> rs6000_density_test
It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98348
--- Comment #22 from Hongtao.liu ---
(In reply to Dávid Bolvanský from comment #20)
> Some small regression (missed opportunity to use vptestnmd):
>
> Current trunk
>
> compare(unsigned int __vector(16)):
> vpxor xmm1, xmm1, xmm1
> vpcmpd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680
--- Comment #5 from Hongtao.liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568571.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99908
--- Comment #4 from Hongtao.liu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568785.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100310
--- Comment #1 from Hongtao.liu ---
a patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569248.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100267
--- Comment #6 from Hongtao.liu ---
a patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569248.html
Building the last several gcc releases I get the warning:
warning: gcc/cc1obj-checksum.o differs
This seems harmless but I am curious what causes it.
--Sidney Marshall
On 5/6/21 8:32 AM, Aldy Hernandez wrote:
On 5/5/21 9:26 AM, Richard Biener wrote:
On Wed, May 5, 2021 at 1:32 AM Martin Sebor via Gcc-patches
wrote:
With no optimization, -Wformat-overflow and -Wformat-truncation
runs early to detect a subset of simple bugs. But as it turns out,
the pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435
--- Comment #2 from Tom Tromey ---
(In reply to Richard Biener from comment #1)
> I think it's just an omission and indeed a bug.
I can write a patch easily enough, but I don't have a good way to test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97604
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873
Joseph S. Myers changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
When the preprocessor lexes preprocessing numbers in lex_number, it
accepts digit separators in more cases than actually permitted in
pp-numbers by the standard syntax.
One thing this accepts is adjacent digit separators; there is some
code to reject those later, but as noted in bug 83873 it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97604
--- Comment #1 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:8f51cf38bb9628546effe66c070188d10f80b5ca
commit r12-580-g8f51cf38bb9628546effe66c070188d10f80b5ca
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873
--- Comment #2 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:8f51cf38bb9628546effe66c070188d10f80b5ca
commit r12-580-g8f51cf38bb9628546effe66c070188d10f80b5ca
Author: Joseph Myers
Date: Thu
algorithms: zlib
gcc version 12.0.0 20210506 (experimental) [master revision
:60f7b28fb:e1fcf14f33e4f371aae8ae497ca58a760d53ca6d] (GCC)
$
$ gcc-trunk small.c -O3 -w ; objdump --disassemble a.out > "no-g.txt"
$ gcc-trunk small.c -O3 -w -g ; objdump --disassemble a.out > "g.txt&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #3 from H.J. Lu ---
What is in mingw-w64-crt/intrincs/rdtsc.c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #3 from Steve Kargl ---
On Thu, May 06, 2021 at 09:31:49PM +, David.Smith at lmu dot edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
>
> --- Comment #2 from David.Smith at lmu dot edu ---
> > With neither
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #2 from Andrew Pinski ---
Running GCC under strace (with -f option since GCC forks off to exec cc1plus).
Should be able to see where the files are being tested for.
Snapshot gcc-9-20210506 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210506/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-05-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #5 from Martin Sebor ---
Created attachment 50770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50770=edit
Patch to complete GTY support for hash_map.
Patch to add support for GTY hash_map for all integer types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440
--- Comment #2 from David.Smith at lmu dot edu ---
> With neither access to the actual code nor a reduced testcase,
> it will be virtually impossible to debug this problem.
Right, I have enclosed a small program pulled out of my real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #4 from Martin Sebor ---
So besides the hash_map GTY support being incomplete it also seems like ggc.h
support is missing something. The following change to the header lets the
whole patch below compile:
diff --git a/gcc/ggc.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #3 from Martin Sebor ---
As it turns out, the hash_map primary template is incomplete. Defining the
following member fixes that error only to expose another:
index 0779c930f0a..c07bd04704f 100644
--- a/gcc/hash-map.h
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #2 from Martin Sebor ---
But suppose I change my mind and want to define a map from HWI_INT to int:
diff --git a/gcc/except.c b/gcc/except.c
index a7902bbd555..a47841cf395 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -149,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
--- Comment #1 from Martin Sebor ---
Adding the two missing function like below fixes the errors.
diff --git a/gcc/except.c b/gcc/except.c
index a7902bbd555..913632f5199 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -149,6 +149,21 @@ static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463
Bug ID: 100463
Summary: many errors using GTY and hash_map
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
liblfds admin changed:
What|Removed |Added
CC||liblfds_gccbz at winterflaw
dot ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
--- Comment #1 from Marco Trevisan ---
Some verbose logging:
unstable /data/GNOME/gjs
❯ echo $PWD
/data/GNOME/gjs
unstable /data/GNOME/gjs
❯ ls _build/libgjs.so.0.0.0.p -lht
total 119M
-rw-rw-r-- 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100462
Bug ID: 100462
Summary: g++ fails to find the a pre-compiled header
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
Bug ID: 100461
Summary: [11/12 Regression] mingw build broken due to change of
rdtsc implementation
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100460
Bug ID: 100460
Summary: [11/12 Regression] mingw build broken due to use of
unsupported open() flags
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Hi
Considering your feedback on backtrace in debug mode is going to
take me some time so here is another one.
Compared to latest submission I've added a _Hash_arg_t partial
specialization for std::hash<>. It is not strictly necessary for the
moment but when we will eventually remove
> "Ulrich" == Ulrich Weigand via Gcc writes:
Ulrich> If we do want to byte-swap pointer types, then I guess we need
Ulrich> to still fix the debug info problem, which I guess would at a
Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an
Ulrich> attribute to
On Thu, 6 May 2021, Jakub Jelinek via Gcc-patches wrote:
Though, (x&1) == x is equivalent to both (x&~1)==0 and to x < 2U
and from the latter two it isn't obvious which one is better/more canonical.
On aarch64 I don't see differences in number of insns nor in their size:
10:13001c00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #31 from Andrew Pinski ---
(In reply to Niall Douglas from comment #30)
> I got bit by this GCC regression today at work. Consider
> https://godbolt.org/z/M9fd7nhdh where std::atomic<__int128> is compare
> exchanged with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #4 from Jakub Jelinek ---
Created attachment 50769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50769=edit
gcc12-pr100450.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
--- Comment #19 from Jason Merrill ---
(In reply to Patrick Palka from comment #18)
> ever since Nathan's r11-2876. As this commit mentions, should we enable the
> maybe_save_operator_binding / push_operator_binding mechanism for all
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Niall Douglas changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100459
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453
Jakub Jelinek changed:
What|Removed |Added
Version|unknown |12.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100459
Bug ID: 100459
Summary: [10/11 regression] constexpr decltype(auto) variable
declaration bogus cv qual error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443
--- Comment #6 from gnzlbg ---
>From [basic.scope.scope]/p3.3.2 http://eel.is/c++draft/basic.scope.scope#3.3.2
I think that A::f and B::f don't correspond because they are function templates
but their return types differ.
Since they don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #5 from Jakub Jelinek ---
Yeah, I've noticed that when looking at combined constructs because otherwise
the 2.14 rule that in_reduction when on target shall be also
map(always,tofrom:) doesn't make any sense.
Anyway, we have some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
Alex Coplan changed:
What|Removed |Added
Summary|[ICE] |[8/9 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #4 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #3)
> I think we should start by checking what we are missing from the handling of
> the harder clauses on combined/composite constructs against the 5.0 2.14
>
It's 46991 of course.
Many thanks
Paul
On Thu, 6 May 2021 at 17:15, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Blast! Thanks for pointing it out. The testcase is in a directory
> ~/prs/pr46691, which I then took from the editor. Original sin and all
> that.
>
> Paul
>
>
Blast! Thanks for pointing it out. The testcase is in a directory
~/prs/pr46691, which I then took from the editor. Original sin and all
that.
Paul
On Thu, 6 May 2021 at 17:06, Jonathan Wakely wrote:
> PR 46691 is the wrong PR number:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100458
Alex Coplan changed:
What|Removed |Added
Target||arm
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100458
Bug ID: 100458
Summary: [10 Regression] arm: ICE in change_address_1 with
-march=armv7-m -fstack-protector-all -mpure-code
Product: gcc
Version: 10.3.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #3 from Jakub Jelinek ---
Created attachment 50768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50768=edit
pr99928.tar.xz
I think we should start by checking what we are missing from the handling of
the harder clauses on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100442
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
--- Comment #5 from Jonathan Wakely ---
The CWG issue is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 and the C++20
standard even calls it out as an incompatibility with C++17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100455
H.J. Lu changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
--- Comment #3 from H.J. Lu ---
*** Bug 100455 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100450
--- Comment #1 from Tobias Burnus ---
Likewise with g++ - nonsurprising as it is common code
in c-ppoutput.c's token_streamer::stream. First called with
token->type == CPP_PRAGMA
fprintf (print.outf, "%s %s", space, name);
is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
--- Comment #2 from dominik.stras...@onespin-solutions.com ---
Created attachment 50767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50767=edit
Test source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100445
--- Comment #10 from Uroš Bizjak ---
Following patch fixes the failures:
--cut here--
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 4dfe7d6c282..61b2f921f41 100644
--- a/gcc/config/i386/i386-expand.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100457
Bug ID: 100457
Summary: [meta bug] Enabling O2 vectorization in GCC 12
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937
--- Comment #3 from CVS Commits ---
The master branch has been updated by Bernd Edlinger :
https://gcc.gnu.org/g:e69ac0203725fb8da83a1cc88d32191b7a0b2c0c
commit r12-574-ge69ac0203725fb8da83a1cc88d32191b7a0b2c0c
Author: Bernd Edlinger
Date:
On Thu, May 06, 2021 at 04:21:40PM +0200, Tobias Burnus wrote:
> * omp-low.c (lower_rec_simd_input_clauses): Set max_vf = 1 if
> a truth_value_p reduction variable is nonintegral.
> (lower_rec_input_clauses): Also handle SIMT part
> for complex/float recution with && and
On 5/5/21 9:26 AM, Richard Biener wrote:
On Wed, May 5, 2021 at 1:32 AM Martin Sebor via Gcc-patches
wrote:
With no optimization, -Wformat-overflow and -Wformat-truncation
runs early to detect a subset of simple bugs. But as it turns out,
the pass runs just a tad too early, before SSA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
Back in February I wrote an article about GCC 11 features designed
to help detect common dynamic memory management bugs. The article
just published in two parts in the Red Hat Developer Blog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100441
--- Comment #7 from Alex Coplan ---
So I'd guess the PR99037 fix just needs backporting to GCC 9, but we'll need to
confirm that it's the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454
--- Comment #2 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:0f442f1378f4e9866793309504e38467f34c5d61
commit r12-573-g0f442f1378f4e9866793309504e38467f34c5d61
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100439
--- Comment #3 from Florin Iucha ---
Tried it with current HEAD of https://github.com/google/googletest
(f5e592d8ee5ffb1d9af5be7f715ce3576b8bf9c4), with the cmake patched to add
"-fsanitize=undefined -fno-omit-frame-pointer -std=c++2a" and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
PR 46691 is the wrong PR number:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691
The comment in the testcase is wrong, and the ChangeLog file will get
auto-updated with the wrong number overnight (you can manually edit it
and push the fix tomorrow after it's been generated).
On 06.05.21 15:12, Tom de Vries wrote:
WIP patch below tries that approach and fixes the ICE,
Thanks!
but this simple example still doesn't work:
...
#pragma omp target parallel reduction(&&: andf)
Try: map(andf). [Cf. PR99928 with pending patch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100456
Bug ID: 100456
Summary: [11 regression] Obsolete Template parameter Causes
Compile Error
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100454
Bug ID: 100454
Summary: gnat.dg/opt93.adb FAILs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100455
Bug ID: 100455
Summary: [11 regression9 Obsoltee Template paraeter Cann
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
1 - 100 of 272 matches
Mail list logo
