https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
--- Comment #2 from Jakub Jelinek ---
The convert_arg_to_ellipsis call that converts in this case the non-POD class
to its address is done very shortly before calling the -Wformat check, but most
of the stuff the function is doing is needed for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #2 from Tom de Vries ---
Minimal version:
...
! { dg-do run }
module vars
implicit none
integer z
!$acc declare create (z)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84096
Bug ID: 84096
Summary: Wrong prototype for omp_init_nest_lock_with_hint() in
"omp.h.in"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84080
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496
Laurent GUERBY changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #14 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
--- Comment #5 from PaX Team ---
(In reply to Andrew Pinski from comment #4)
> Because debug information happens early on and has many interactions with
> the front end.
FINISH_TYPE happens early on too and the API promise gcc makes is that it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83176
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #2 from Jakub Jelinek ---
build_functional_cast here creates CAST_EXPR with NULL TREE_TYPE as well as
TREE_OPERAND (, 0) and cp_parser_constant_expression ->
potential_rvalue_constant_expression -> potential_constant_expression_1 is
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84057
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84057
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Jan 29 09:16:09 2018
New Revision: 257139
URL: https://gcc.gnu.org/viewcvs?rev=257139&root=gcc&view=rev
Log:
2018-01-29 Richard Biener
PR tree-optimization/84057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84076
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84084
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Jakub Jelinek ---
> I can't think of how the self-test failure could be related, unless it just
> results in miscompiled stage2 or stage3 compiler.
It seems that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #3 from Jakub Jelinek ---
To be precise, the CAST_EXPR doesn't have NULL TREE_TYPE initially, it has A
type, just NULL operand.
But then r245223 comes with:
if (processing_template_decl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> So any hint on whether the code after r257077 is better or worse than before?
Looks worse unfortunately:
For aarch64 at -O2 it generates:
foo:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84085
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> (In reply to Richard Biener from comment #2)
> > So any hint on whether the code after r257077 is better or worse than
> > before?
>
> Looks worse unfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
--- Comment #4 from Jakub Jelinek ---
As that PR was a workaround for buggy code and the intent was to not reject
code that has been accepted before, perhaps we could only do the pedwarn rather
than error and clearing of TREE_TYPE (postfix_expres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Version|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84090
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Version|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086
--- Comment #3 from Richard Biener ---
Released by
#0 release_ssa_name_fn (fn=0x76a5f160, var=)
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-ssanames.c:536
#1 0x013735fe in release_ssa_name (name=)
at /space/rguenth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #32 from rguenther at suse dot de ---
On Fri, 26 Jan 2018, sergey.shalnov at intel dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
>
> --- Comment #31 from sergey.shalnov at intel dot com ---
> Richard,
> Thank y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #5 from rguenther at suse dot de ---
On Mon, 29 Jan 2018, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
>
> --- Comment #3 from ktkachov at gcc dot gnu.org ---
> (In reply to Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #5)
> On Mon, 29 Jan 2018, ktkachov at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
> >
> > --- Comment #3 from kt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84060
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #9 from Richard Biener ---
(In reply to Martin Liška from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Is it really r256643 and not r256644 that is causing this though?
>
> Yes, I can verify that it's r256644 that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|2018-01-29 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84097
Bug ID: 84097
Summary: [8 regression] Incorrect -Wunused-but-set-variable
warning
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: diagnostic
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
Tom de Vries changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84087
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
arser.c:11075
0x8e683d cp_parser_statement
../../gcc/gcc/cp/parser.c:10879
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ g++ --version
g++ (GCC) 8.0.1 20180129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #14 from Jonathan Wakely ---
Yes that's expected. It's the same issue. Libstdc++ still follows the C++98
spec which means there is no such thing as a hex float, and so "0x" cannot be
the start of a floating point value, it's just "0".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
--- Comment #2 from Marek Polacek ---
Started with r257093.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84098
--- Comment #3 from Marek Polacek ---
The new assert says
8955 /* Lambda closures are regenerated in tsubst_lambda_expr, not
8956 instantiated here. */
8957 gcc_assert (!LAMBDA_TYPE_P (template_type));
but her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84088
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #3)
> Will reconfirm with full build.
Did clean builds of r257064 and r257065. Minimal test passes at r257064, fails
at r257065. Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #10 from Richard Biener ---
So strided stores are costed as
/* Costs of the stores. */
if (memory_access_type == VMAT_ELEMENTWISE
|| memory_access_type == VMAT_GATHER_SCATTER)
{
/* N scalar stores plus extracting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83658
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #31 from Wilco ---
(In reply to Qing Zhao from comment #30)
> (in reply to Wilco from comment #29)
> >
> > The new test is better, however it uses i % 15 which means an expensive
> > division by constant every loop iteration. It's be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83658
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 12:33:32 2018
New Revision: 257141
URL: https://gcc.gnu.org/viewcvs?rev=257141&root=gcc&view=rev
Log:
PR libstdc++/83658 fix exception-safety in std::any::emplace
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84099
Bug ID: 84099
Summary: Dynamic initialization is performed in case when
constant initialization is permitted
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100
Bug ID: 84100
Summary: Function __attribute__((optimize(align-loops=32)))
gives spurious warning
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #11 from Richard Biener ---
So probably the big slowdown is because the vectorized loop body is so much
larger. Unvectorized:
.L61:
vmulss __solv_cap_MOD_d1(%rip), %xmm4, %xmm0
incl%ecx
vmulss (%rdx), %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84085
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #7 from rguenther at suse dot de ---
On Mon, 29 Jan 2018, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
>
> --- Comment #6 from ktkachov at gcc dot gnu.org ---
> (In reply to rguent...@suse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84101
Bug ID: 84101
Summary: -O3 and -ftree-vectorize trying too hard for function
returning trivial pair-of-uint64_t-structure
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083
--- Comment #4 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #3)
> Yes, we don't currently implement restrict disambiguation for calls.
So, would that account for the different compilation result for test1() and
test2() in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
--- Comment #5 from Wilco ---
(In reply to Eric Botcazou from comment #3)
> > PR59461 changed nonzero_bits1 incorrectly for subregs:
> >
> > /* On many CISC machines, accessing an object in a wider mode
> > causes the high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84102
Bug ID: 84102
Summary: Fails to disambiguate Fortran (non-addressable?)
global with array descriptor data
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84087
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086
--- Comment #7 from jsberg at bnl dot gov ---
As to why I think this is a bug (and why I think Intel's compiler is doing the
right thing), referencing the 2008 standard (N1830):
10.11.2, paragraph 2:
Each object designator shall begin with a nam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84103
Bug ID: 84103
Summary: Dynamic initialization is performed for non-local
variables in case when constant initialization is
permitted
Product: gcc
Version: 8.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84104
Bug ID: 84104
Summary: Minval gives incorrect results for certain compiler
options
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
--- Comment #12 from Richard Biener ---
I have opened PR84102 for the missed optimizations in this particular loop. I
believe now the interesting one is the other.
30.25% a.outa.out [.] __solv_cap_MOD_fourir2d
24.83% a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Matthias Hochsteger changed:
What|Removed |Added
CC||matthias.hochsteger@tuwien.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84092
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84090
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
--- Comment #8 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 13:58:49 2018
New Revision: 257144
URL: https://gcc.gnu.org/viewcvs?rev=257144&root=gcc&view=rev
Log:
PR libstdc++/83833 fix chi_squared_distribution::param(const param&)
Bac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83658
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83658
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 13:58:54 2018
New Revision: 257145
URL: https://gcc.gnu.org/viewcvs?rev=257145&root=gcc&view=rev
Log:
PR libstdc++/83658 fix exception-safety in std::any::emplace
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 14:07:27 2018
New Revision: 257146
URL: https://gcc.gnu.org/viewcvs?rev=257146&root=gcc&view=rev
Log:
PR libstdc++/83833 fix failing test on ia32
PR libstdc++/83833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83942
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
--- Comment #7 from amker at gcc dot gnu.org ---
While I am understanding the issue. The dump of ifcvt pass is as below:
;; basic block 2, loop depth 0, count 118111601 (estimated locally), maybe
hot
;;prev block 0, next block 3, flags: (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I was reminded of ld's -z relaxreloc option (more on that separately).
> While it doesn't help in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83831
--- Comment #3 from Oleg Endo ---
Created attachment 43270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43270&action=edit
Patch for GCC 7
Tested with "make -k check" on rx-sim for c and c++ with no new failures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #7)
> On Mon, 29 Jan 2018, ktkachov at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84067
> >
> > --- Comment #6 from kt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
--- Comment #10 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 14:44:48 2018
New Revision: 257149
URL: https://gcc.gnu.org/viewcvs?rev=257149&root=gcc&view=rev
Log:
PR libstdc++/83833 fix chi_squared_distribution::param(const param&)
Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
--- Comment #11 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 14:45:00 2018
New Revision: 257150
URL: https://gcc.gnu.org/viewcvs?rev=257150&root=gcc&view=rev
Log:
PR libstdc++/83833 fix failing test on ia32
PR libstdc++/83833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833
--- Comment #10 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 29 14:44:48 2018
New Revision: 257149
URL: https://gcc.gnu.org/viewcvs?rev=257149&root=gcc&view=rev
Log:
PR libstdc++/83833 fix chi_squared_distribution::param(const param&)
Ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84105
Bug ID: 84105
Summary: [8 regression] Segmentation fault in
pp_tree_identifier() during LTO
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84082
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093
--- Comment #2 from Neil Carlson ---
The forced cascade of keyword use is rather annoying, so perhaps someone was
thinking the current gfortran behavior is a useful extension, and it almost is.
But consider this example:
type :: parent
type(pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84037
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84091
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83008
--- Comment #33 from sergey.shalnov at intel dot com ---
Richard,
I'm not sure is it a regression or not. I see code has been visibly refactored
in this commit
https://github.com/gcc-mirror/gcc/commit/ee6e9ba576099aed29f1097195c649fc796ecf5e
in 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Mon Jan 29 15:22:55 2018
New Revision: 257152
URL: https://gcc.gnu.org/viewcvs?rev=257152&root=gcc&view=rev
Log:
2018-01-29 Richard Biener
PR tree-optimization/84086
1 - 100 of 238 matches
Mail list logo
