https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84608
Bug ID: 84608
Summary: Hang in cxx_eval_constant_expression() with
-fsanitize=undefined
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84593
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84443
--- Comment #3 from Nicholas Piggin ---
(In reply to Segher Boessenkool from comment #2)
> If you want some specific machine code for something complex like this, it
> is much easier to write the machine code than to fight the compiler.
Yes, und
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005
--- Comment #4 from Alexandre Oliva ---
I guess this is a case of adding xfails or target requirements to the dg
comments, but I'm not sufficiently familiar with the various vector-related
pseudo-target names to tell which ones would be right, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66433
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66433
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79005
Leslie Zhai changed:
What|Removed |Added
CC||lesliezhai at llvm dot org.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #24 from Alexandre Oliva ---
Author: aoliva
Date: Wed Feb 28 05:25:34 2018
New Revision: 258053
URL: https://gcc.gnu.org/viewcvs?rev=258053&root=gcc&view=rev
Log:
[PR81611] turn inc-and-use-of-dead-orig into auto-inc
When the addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82248
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982
--- Comment #7 from Arseny Solokha ---
OK, the original issue still reproduces for the powerpc-e500v2-linux-gnuspe
target as of r257975, so the change that affected this issue must have been
local to the rs6000 backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84607
Bug ID: 84607
Summary: Side effects discarded in address computation inside
'if'
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84604
--- Comment #2 from Craig Schroeder ---
I was under the impression I was allowed to call the destructor just like any
other function. On further investigation, this is undefined behavior, so this
bug report is invalid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
Marc Glisse changed:
What|Removed |Added
Last reconfirmed|2015-12-16 00:00:00 |2018-2-28
--- Comment #8 from Marc Glisse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84604
--- Comment #1 from Marc Glisse ---
(In reply to Craig Schroeder from comment #0)
> this->~S();
> a=b+2;
What do you expect this to do? You destruct the object, then access its member
b...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84606
Martin Sebor changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84606
Bug ID: 84606
Summary: internal compiler error: Segmentation fault
(enclosing_instantiation_of())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84605
Martin Sebor changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84605
Bug ID: 84605
Summary: internal compiler error: in xref_basetypes, at
cp/decl.c:13818
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Z1fv
call_Z1fv
movl$2, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE7:
.size _Z3foov, .-_Z3foov
.ident "GCC: (GNU) 8.0.1 20180227 (experimental)"
.section.note.GNU-stack,"",@pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
Martin Sebor changed:
What|Removed |Added
Target Milestone|6.5 |8.0
--- Comment #8 from Martin Sebor ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84158
Bug 84158 depends on bug 83871, which changed state.
Bug 83871 Summary: wrong code for attribute const and pure on distinct template
specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
Bug 83503 depends on bug 83871, which changed state.
Bug 83871 Summary: wrong code for attribute const and pure on distinct template
specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Tue Feb 27 22:28:21 2018
New Revision: 258045
URL: https://gcc.gnu.org/viewcvs?rev=258045&root=gcc&view=rev
Log:
PR c++/83871 - wrong code for attribute const and pure on distinct templat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
--- Comment #20 from Martin Sebor ---
Author: msebor
Date: Tue Feb 27 22:28:21 2018
New Revision: 258045
URL: https://gcc.gnu.org/viewcvs?rev=258045&root=gcc&view=rev
Log:
PR c++/83871 - wrong code for attribute const and pure on distinct templa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82982
--- Comment #6 from Will Schmidt ---
(In reply to Will Schmidt from comment #4)
> Tried to re-create locally, I've gotten two ICE's using the provided
> testcode snippet, neither look quite like the originally reported issue.
> (thus I don't kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84207
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84207
--- Comment #3 from Martin Sebor ---
Author: msebor
Date: Tue Feb 27 22:06:03 2018
New Revision: 258044
URL: https://gcc.gnu.org/viewcvs?rev=258044&root=gcc&view=rev
Log:
PR translation/84207 - Hard coded plural in gimple-fold.c
gcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84597
Nathan Sidwell changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #31 from Jakub Jelinek ---
Thanks for the hint.
So:
#include
struct S {
int a : 2;
__declspec(align(8)) int b : 2;
int c : 28;
__declspec(align(16)) int d : 2;
int e : 30;
} s;
int a = sizeof (struct S);
void f1 (int x) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489
Jason Merrill changed:
What|Removed |Added
Known to work||8.0
Summary|[6/7/8 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #19 from Marc Glisse ---
(In reply to Aldy Hernandez from comment #16)
> It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
> design (because of signed overflows):
[...]
> So instead of whacking tree-ssa-reas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 71546, which changed state.
Bug 71546 Summary: lambda capture fails with "was not declared in this scope"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71546
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71546
Jason Merrill changed:
What|Removed |Added
Keywords||rejects-valid
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71546
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Tue Feb 27 20:57:35 2018
New Revision: 258043
URL: https://gcc.gnu.org/viewcvs?rev=258043&root=gcc&view=rev
Log:
PR c++/71546 - lambda init-capture with qualified-id.
* p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #18 from Jeffrey A. Law ---
A couple more notes. It could also well be the case that reassociating in a
way that encourages lea could be good for x86, but bad for other targets.
I also suspect this is closely related to other BZs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84426
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #17 from Jeffrey A. Law ---
It could well end up being a case where we need to look to see if the
expressions are likely to CSE to determine which is better.
I'm not sure if reassoc has that kind of capability.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84426
--- Comment #2 from Nathan Sidwell ---
Author: nathan
Date: Tue Feb 27 20:52:15 2018
New Revision: 258042
URL: https://gcc.gnu.org/viewcvs?rev=258042&root=gcc&view=rev
Log:
[PR c++/84426] ICE after conflicting member decl
https://gcc.gnu.org/ml
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84602
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84602
David Malcolm changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84603
Bug ID: 84603
Summary: -finline-limit not accepted in attribute and #pragma
optimize
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84602
Bug ID: 84602
Summary: internal compiler error: in search_anon_aggr, at
cp/name-lookup.c:1218
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84600
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84443
--- Comment #2 from Segher Boessenkool ---
If you want some specific machine code for something complex like this, it
is much easier to write the machine code than to fight the compiler.
That said:
1) "flags" is stored in the same register ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
--- Comment #20 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #18)
> > After several people including have gone down rabbit
> > holes trying to fix this bug, I have found a patch!
>
> The patch at https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #30 from Benjamin Robin ---
The test cases bf-ms-layout.c and bf-ms-layout-2.c are valid.
You can test it with an online compiler, for example:
http://rextester.com/l/c_online_compiler_visual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84597
--- Comment #1 from seurer at gcc dot gnu.org ---
I missed that timevar1.C is also failing.
> FAIL: g++.dg/ext/timevar1.C -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/ext/timevar1.C -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/e
--- Comment #10 from Vegard Nossum ---
Original test case still causes a crash in trunk (8.0.1 20180227), here 8.0.1
20180204:
:5:1: error: types may not be defined in template arguments
:6:4: error: ISO C++ forbids declaration of 'f' with no type
[-fpermissive]
:6:6: error: expected '}&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84601
Bug ID: 84601
Summary: std::optional> is not assignment
copyable
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #29 from Jakub Jelinek ---
Created attachment 43522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43522&action=edit
gcc8-pr52991.patch
Full untested patch (except for
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84598
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
--- Comment #7 from Jason Merrill ---
(In reply to Marek Polacek from comment #6)
> So do you think that we don't want the patch in Comment 3?
Correct, that patch is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Tue Feb 27 17:26:47 2018
New Revision: 258039
URL: https://gcc.gnu.org/viewcvs?rev=258039&root=gcc&view=rev
Log:
PR c++/84489 - dependent default template argument
* pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534
--- Comment #3 from Vladimir Makarov ---
Actually, it is not a failure. I believe it is an improvement. We have less
move insns now. The easiest way to fix is to change the expected move insns to
the current number.
I'd prefer changing the ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84600
Bug ID: 84600
Summary: function inlining is confused by char * type cast
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534
--- Comment #2 from seurer at gcc dot gnu.org ---
xxlor counting failures are really common for powerpc test cases. Perhaps we
should look at all the ones that do that to see if those xxlor count checks are
actually testing for anything useful?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
--- Comment #6 from Marek Polacek ---
(In reply to Jason Merrill from comment #5)
> (In reply to Jakub Jelinek from comment #2)
> > Given:
> > class C {
> > static const long b = 0;
> > static const unsigned c = (b);
> > };
> > class D {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599
--- Comment #1 from Marc Glisse ---
Did you try -fsanitize=undefined before reporting?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84599
Bug ID: 84599
Summary: following code gives different output for normal
compilation and -O2 compiler.
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84582
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84578
Martin Sebor changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #2 from M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84598
Bug ID: 84598
Summary: internal compiler error: Segmentation fault
(cp_default_conversion())
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84597
Bug ID: 84597
Summary: [8 regression] test case g++.dg/ext/timevar2.C fails
starting with r258029
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
--- Comment #28 from Jakub Jelinek ---
Trying:
--- gcc/stor-layout.c.jj2018-02-22 14:35:33.135216198 +0100
+++ gcc/stor-layout.c 2018-02-27 17:32:17.934820133 +0100
@@ -1038,7 +1038,7 @@ update_alignment_for_field (record_layou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588
--- Comment #2 from David Malcolm ---
Both testcases used to ICE with -std=c++11, but that was fixed sometime between
r218865 (ICE) and r218948 (no ICE).
Both testcases ICE on trunk with -std=c++14, in both cases starting with
r208426.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #5 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Daniel Gutson from comment #3)
> > OK. That was my second suggested alternative.
> > BTW I didn't see __builtin_trap documented as noreturn in the do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84485
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #4 from Andrew Pinski ---
(In reply to Daniel Gutson from comment #3)
> OK. That was my second suggested alternative.
> BTW I didn't see __builtin_trap documented as noreturn in the documentation.
Depends on the reading of __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84588
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #2 from Andrew Pinski ---
https://github.com/scottt/debugbreak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #3 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #1)
> What you want is __builtin_breakpoint (if that existed). Trap is considered
> as noreturn just like abort/exit.
OK. That was my second suggested alternative.
BT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595
--- Comment #1 from Andrew Pinski ---
What you want is __builtin_breakpoint (if that existed). Trap is considered as
noreturn just like abort/exit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to rsand...@gcc.gnu.org from comment #5)
> Created attachment 43519 [details]
> Alternative fix
>
> Here's an alternative fix that I'll run through multi-target testing.
> It's more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Created attachment 43519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43519&action=edit
Alternative fix
Here's an alternative fix that I'll run through multi-target testing.
It's more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84563
torvald at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470
--- Comment #4 from Martin Sebor ---
When p is null p->a is not valid if it's evaluated. offsetof (along with
sizeof and alignof and the like) don't evaluate their operands so they are
exempt.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84496
Jason Merrill changed:
What|Removed |Added
Depends on||81045
Summary|[6/7 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84596
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84596
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 84512, which changed state.
Bug 84512 Summary: [8 Regression] Missed optimization: should be precalculated
in compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84512
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84482
--- Comment #6 from Richard Biener ---
So we vectorize less. Given the caused revision I wonder if this is the same
issue as in PR84512 where I just committed a fix for? So ... fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51434
--- Comment #19 from Steve Kargl ---
On Tue, Feb 27, 2018 at 01:54:11PM +, dominiq at lps dot ens.fr wrote:
>
> In addition, I don't understand why
>
> type t
> character :: z
> end type t
> type(t), parameter :: s(5) = t('a')
>
1 - 100 of 213 matches
Mail list logo
