https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89531
Bug ID: 89531
Summary: Possible memory corruption in the gfortran front-end
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: GC
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89531
--- Comment #1 from Arseny Solokha ---
Created attachment 45848
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45848&action=edit
Backtraces
Various backtraces observed during testcase minimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89482
--- Comment #8 from Ciro Santilli ---
Thanks for the reply, David.
Do you have the doc patch uploaded anywhere to serve as a starting point?
Quick things that we might need to change / clarify:
- is the x constraint documented somewhere? Menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Bug ID: 89532
Summary: internal compiler error: in
type_has_nontrivial_copy_init, at cp/tree.c:4024
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #22 from Mark Wielaard ---
(In reply to Eric Gallager from comment #21)
> (In reply to Mark Wielaard from comment #20)
> > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html
>
> Did this make it in? If not, have you pinged it l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89526
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89531
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #1 from Jonathan Wakely ---
(In reply to Baykov Nikita from comment #0)
> 4. pptr() is a null pointer. Paragraphs [stringbuf.cons]/3,
> [streambuf.cons]/1, [stringbuf. members]/3 guarantee it.
That's no longer true, see PR 80676. It'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89446
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89452
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> This was changed many years ago by https://wg21.link/lwg453
... and clarified a few months ago by
https://github.com/cplusplus/draft/commit/af40423574aa8e3a4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89513
Jakub Jelinek changed:
What|Removed |Added
Attachment #45837|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89522
--- Comment #1 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Thu Feb 28 10:27:03 2019
New Revision: 269275
URL: https://gcc.gnu.org/viewcvs?rev=269275&root=gcc&view=rev
Log:
2019-02-28 Paolo Carlini
PR c++/89522
* g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89522
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
--- Comment #5 from Tamar Christina ---
Author: tnfchris
Date: Thu Feb 28 10:43:41 2019
New Revision: 269276
URL: https://gcc.gnu.org/viewcvs?rev=269276&root=gcc&view=rev
Log:
AArch64: Have empty HWCAPs string ignored during native feature detec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530
Tamar Christina changed:
What|Removed |Added
Summary|[8/9 Regression] AArch64|[8 Regression] AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542
--- Comment #10 from Dominique d'Humieres ---
> Yep, done.
Do you mean that the PR can be closed as FIXED?
I am wondering if the tests are valid Fortran.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625
--- Comment #7 from Dominique d'Humieres ---
> Yes, can this please be back-ported? Still broken on at least 8.
This is not a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89434
--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 45839 [details]
> gcc9-pr89434.patch
>
> I'm testing this separately.
This patch is preapproved for trunk if testing is succes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #22 from Andrey Drobyshev ---
Created attachment 45851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45851&action=edit
Work-in-progress fix considering relocations
I'm a bit stuck. I managed to precompute reloc value for the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89533
Bug ID: 89533
Summary: G++ incorrectly generates noexcept assignment operator
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89534
Bug ID: 89534
Summary: mingw is not declarting MAKE_DECL_ONE_ONLY macro
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89535
Bug ID: 89535
Summary: [9 Regression] ICE when building 416.gamess in
prepare_load_store_mask
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791
--- Comment #24 from Kewen Lin ---
(In reply to bin cheng from comment #23)
> (In reply to Kewen Lin from comment #22)
> > As the discussion above, on Power any IV should have an extend (sign/zero)
> > if its width is less than the GPR width (POI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85899
--- Comment #4 from Alexander Monakov ---
It appears that fallthru edges to the exit block are unusual in that they don't
obey the invariant e->dest == e->src->next_bb (i.e. next_bb may be anything).
If so, the assert in haifa-sched needs to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89434
Jakub Jelinek changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89527
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89151
--- Comment #5 from Csaba Ráduly ---
Appears to be fixed in GCC 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89434
--- Comment #14 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 28 13:13:33 2019
New Revision: 269277
URL: https://gcc.gnu.org/viewcvs?rev=269277&root=gcc&view=rev
Log:
PR target/89434
* config/arm/arm.md (*subsi3_carryin_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
--- Comment #19 from Martin Liška ---
(In reply to Richard Biener from comment #18)
> GIMPLE testcase that doesn't fail, possibly because of NOPs or because of
> missing range info or whatever...
>
> typedef struct {
> char array[81];
> } cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89441
--- Comment #2 from Martin Liška ---
Author: marxin
Date: Thu Feb 28 13:17:09 2019
New Revision: 269278
URL: https://gcc.gnu.org/viewcvs?rev=269278&root=gcc&view=rev
Log:
Fix test-case visibility (PR testsuite/89441).
2019-02-28 John David Ang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89441
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89535
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89521
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 28 13:49:38 2019
New Revision: 269280
URL: https://gcc.gnu.org/viewcvs?rev=269280&root=gcc&view=rev
Log:
PR c/89521
* gcc.dg/pr89521-1.c: New test.
* gcc.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89521
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89520
--- Comment #7 from Jakub Jelinek ---
*** Bug 89521 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89535
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89456
--- Comment #3 from H.J. Lu ---
Created attachment 45853
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45853&action=edit
A patch
/gcc/x86_64-pc-linux-gnu/9.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190228 (experimental) [trunk revision 269278] (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60875
--- Comment #5 from Jakub Jelinek ---
Those pragmas are all extensions, so the standard doesn't cover them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455
--- Comment #1 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Thu Feb 28 14:24:52 2019
New Revision: 269281
URL: https://gcc.gnu.org/viewcvs?rev=269281&root=gcc&view=rev
Log:
i386: Identify Westmere from PCLMUL
Since AES has been removed fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89455
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Summary|[9 Regression] wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #3 from Jakub Jelinek ---
I wonder if we shouldn't do:
--- gcc/tree-ssa-dom.c.jj 2019-02-26 14:13:08.296824100 +0100
+++ gcc/tree-ssa-dom.c 2019-02-28 15:46:52.285495060 +0100
@@ -346,6 +346,9 @@ edge_info::derive_equivalences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89533
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Bug ID: 89537
Summary: missing location for error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #1 from Jonathan Wakely ---
Created attachment 45855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45855&action=edit
gzipped unreduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
Damian Rouson changed:
What|Removed |Added
CC||damian at sourceryinstitute
dot or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #11 from Jakub Jelinek ---
Any progress on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #10 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #9)
> So, shall we never try ck_list conversion for CONSTRUCTORs with any
> designators (while for -std=c++2a we'll complain if there is a mix of
> designated initiali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #11 from Jakub Jelinek ---
So like (untested):
--- gcc/call.c.jj 2019-02-28 08:14:58.251562934 +0100
+++ gcc/call.c 2019-02-28 17:04:49.697357298 +0100
@@ -819,7 +819,7 @@ build_list_conv (tree type, tree ctor, i
conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88235
--- Comment #4 from Jan Hubicka ---
I think you can add cgraph predicate
former_thunk_p which tests that
return !thunk_p && (thunk_info.fixed_offset || virtual_offset_p ||
indirect_offset)
Every thunk should set one of those (it may be good to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #12 from Jakub Jelinek ---
#c2 with it still fails though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89532
--- Comment #2 from Marek Polacek ---
struct tuple;
template
struct S { };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88585
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88585
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Thu Feb 28 16:45:44 2019
New Revision: 269282
URL: https://gcc.gnu.org/viewcvs?rev=269282&root=gcc&view=rev
Log:
PR lto/88585
* tree.c (find_atomic_core_type): Move ahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #13 from Jakub Jelinek ---
Created attachment 45856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45856&action=edit
WIP
For that test the following helps, but guess I'm still not handling anonymous
aggregates right there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #3 from Marek Polacek ---
template class A {};
template class B;
class C {
using mapped_type = int;
public:
template
C(B, A> *p1, unsigned)
: keys(p1->keys), values(p1->values) {}
A keys;
A values;
};
class D {
pub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #4 from Marek Polacek ---
loc is UNKNOWN_LOCATION:
(gdb) up
#1 0x00b98003 in invalid_nonstatic_memfn_p (loc=0, expr=,
complain=3) at /home/mpolacek/src/gcc/gcc/cp/typeck.c:1896
1896 error_at (loc, "inva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #7 from Jan Hubicka ---
I am happy with the patch in #5, so you can consider it pre-approved. It is
probably your call whether to declare the code invalid at first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #5 from Eric Botcazou ---
> I wonder if we shouldn't do:
> --- gcc/tree-ssa-dom.c.jj 2019-02-26 14:13:08.296824100 +0100
> +++ gcc/tree-ssa-dom.c2019-02-28 15:46:52.285495060 +0100
> @@ -346,6 +346,9 @@ edge_info::derive_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #5 from Marek Polacek ---
With this patch
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index fb67d905acd..d9073d7c23d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4246,7 +4246,7 @@ resolve_args (vec *args, tsubst_flags_t
complain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #6 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #5)
> There is very likely the same issue in the BIT_AND_EXPR case then.
Isn't that different though? I mean, even if we have int type and have [0, 1]
range and have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Thu Feb 28 17:29:48 2019
New Revision: 269283
URL: https://gcc.gnu.org/viewcvs?rev=269283&root=gcc&view=rev
Log:
PR c++/88049 - ICE with undefined destructor and anon namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
Jason Merrill changed:
What|Removed |Added
Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542
--- Comment #11 from G. Steinmetz ---
Well, the ICEs are gone for all posted test cases above.
Assuming that different shapes are not supported as an extension
(aka feature), as such they are not standard-conforming.
F2018 7.5.10 item 2 says
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #7 from Eric Botcazou ---
> Isn't that different though? I mean, even if we have int type and have [0,
> 1] range and have a check that the value isn't 0, then it must be 1.
Then I don't understand the problem in the BIT_NOT_EXPR ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
Jakub Jelinek changed:
What|Removed |Added
Attachment #45856|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #8 from Eric Botcazou ---
> Isn't that different though? I mean, even if we have int type and have [0,
> 1] range and have a check that the value isn't 0, then it must be 1.
Then I don't understand the problem in the BIT_NOT_EXPR ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #9 from Eric Botcazou ---
> Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> deduce that it must be 1 too.
So the problem is in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #10 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #9)
> > Then I don't understand the problem in the BIT_NOT_EXPR case: we have int
> > type and [0, 1] range for rhs; if we know that BIT_NOT_EXPR is zero, we can
> > d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #11 from Jakub Jelinek ---
The [0, 1] range in that case (if not boolean or prec==1) is not the property
of the type, but just that optimizations figured out the SSA_NAME will not have
other values. In tree-ssa-dom.c it goes in the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #12 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
Right, an annoying ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #13 from Eric Botcazou ---
> On the testcase, value is -2 and before your change it would derive
> correctly that if BIT_NOT_EXPR is -2, then rhs must be ~-2, i.e. 1, but
> after the patch it says rhs must be 0.
The oversight is actu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #14 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #12)
> > Adding integer_onep wouldn't be
> > correct IMHO, if you have some non-boolean non-prec==1 integral type, even
> > if you know rhs has range [0, 1], if BIT_NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #15 from Jakub Jelinek ---
How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
normal QImode or SImode etc. one's complement, then I'd say it is a bug if
match.pd generates such BIT_NOT_EXPRs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #16 from Eric Botcazou ---
> So, for BIT_AND_EXPR we only handle the case where the result of
> BIT_AND_EXPR is known to be non-zero. That means both operands have to be
> non-zero (and have at least one common bit). Now, if say the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #17 from Eric Botcazou ---
> How is BIT_NOT_EXPR expanded for the prec > 1 BOOLEAN_TYPEs btw? If it is
> normal QImode or SImode etc. one's complement, then I'd say it is a bug if
> match.pd generates such BIT_NOT_EXPRs.
No idea abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89536
--- Comment #18 from Jakub Jelinek ---
We do take the range as granted in both cases. If for BIT_NOT_EXPR on say int
the result is -2 or -1, then your TREE_INT_CST_LOW fix would DTRT, sure. If
the result is any other value, then we run into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544
--- Comment #13 from Thomas Koenig ---
This looks like it does the trick (test case passes):
Index: trans-types.c
===
--- trans-types.c (Revision 269260)
+++ trans-types.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #9 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285&root=gcc&view=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'rout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #1 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:01 2019
New Revision: 269285
URL: https://gcc.gnu.org/viewcvs?rev=269285&root=gcc&view=rev
Log:
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'rout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89433
--- Comment #2 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287&root=gcc&view=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #10 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:23 2019
New Revision: 269286
URL: https://gcc.gnu.org/viewcvs?rev=269286&root=gcc&view=rev
Log:
[PR72741] For all Fortran OpenACC 'routine' directive variants chec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72741
--- Comment #11 from Thomas Schwinge ---
Author: tschwinge
Date: Thu Feb 28 20:31:36 2019
New Revision: 269287
URL: https://gcc.gnu.org/viewcvs?rev=269287&root=gcc&view=rev
Log:
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
--- Comment #1 from Taewook Oh ---
And I confirmed that this bug doesn't reproduce with GCC5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89538
Bug ID: 89538
Summary: [7.3.0] GCC miscompiling LLVM because of wrong
vectorization
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544
--- Comment #9 from Harald Anlauf ---
(In reply to kargl from comment #8)
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c (revision 266281)
> +++ gcc/fortran/res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89537
--- Comment #6 from Jonathan Wakely ---
(In reply to Marek Polacek from comment #5)
> 89537.C:9:18: error: invalid use of non-static member function ‘void B<
> , ,
> , >::keys() [with _Tp =
> int; = int; = A;
> = A]’
> 9 | : keys(p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77604
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4 from
1 - 100 of 138 matches
Mail list logo
