[Bug target/82767] [8 regression] gcc.target/i386/pr71321.c scan-assembler-times fail

[sebastian.peryt at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82767

--- Comment #3 from Sebastian Peryt  ---
As per Uros's suggestion
(https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00329.html ) I checked
-mtune=generic idea and this works without additional changes either in
testcase or in cost model.

>From what I gathered the cause of this test failing is below change in core
cost model:
/gcc/config/i386/x86-tune-costs.h
@@ -2253,7 +2253,7 @@ struct processor_costs core_cost = {
COSTS_N_INSNS (4),  /*   DI */
COSTS_N_INSNS (4)}, /*other */
   0,   /* cost of multiply per each bit set */
+  {COSTS_N_INSNS (8),  /* cost of a divide/mod for QI */
-  {COSTS_N_INSNS (18), /* cost of a divide/mod for QI */
COSTS_N_INSNS (8),  /*  HI */
/* 8-11 */
COSTS_N_INSNS (11), /*  SI */

Because most of Intel's CPUs are using core_cost model (including haswell) this
testcase is failing without additional tuning to generic cost model, which is
still using old cost values.

[Bug tree-optimization/82847] [8 regression] gcc.dg/vect/slp-perm-9.c fail

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82847

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-06
  Component|middle-end  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Doesn't fail for me on x86_64-linux.  What extra flags are you using?  Even
-m32 -mfpmath=sse passes for me.

Ah, looks like -march=slm is it.

I will have a look - the test is somewhat bogus.

[Bug fortran/80554] [f08] variable redefinition in submodule

[tamas.bela.feher at ipp dot mpg.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80554

--- Comment #9 from Tamas Bela Feher  ---
Thank you for fixing the problem!

[Bug middle-end/82404] Unnecessary instructions in switch table

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82404

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Mon Nov  6 09:02:15 2017
New Revision: 254437

URL: https://gcc.gnu.org/viewcvs?rev=254437&root=gcc&view=rev
Log:
Instrument function exit with __builtin_unreachable in C++

2017-11-06  Martin Liska  

PR middle-end/82404
* c-opts.c (c_common_post_options): Set -Wreturn-type for C++
FE.
* c.opt: Set default value of warn_return_type.
2017-11-06  Martin Liska  

PR middle-end/82404
* constexpr.c (cxx_eval_builtin_function_call): Handle
__builtin_unreachable call.
(get_function_named_in_call): Declare function earlier.
(constexpr_fn_retval): Skip __builtin_unreachable.
* cp-gimplify.c (cp_ubsan_maybe_instrument_return): Rename to
...
(cp_maybe_instrument_return): ... this.
(cp_genericize): Call the function unconditionally.
2017-11-06  Martin Liska  

PR middle-end/82404
* options.c (gfc_post_options): Set default value of
-Wreturn-type to false.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/options.c

[Bug middle-end/82404] Unnecessary instructions in switch table

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82404

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug fortran/69739] [6/7/8 Regression] ICE during array result, allocatable assignment

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Mon Nov  6 09:54:09 2017
New Revision: 254441

URL: https://gcc.gnu.org/viewcvs?rev=254441&root=gcc&view=rev
Log:
 2017-11-06  Paul Thomas  

PR fortran/69739
* trans-expr.c (gfc_map_intrinsic_function): Return false for
bounds without the DIM argument instead of ICEing.

2017-11-06  Paul Thomas  

PR fortran/69739
* gfortran.dg/pr69739.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr69739.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-06
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #12 from Martin Liška  ---
Let me take a look.

[Bug fortran/69739] [6/7/8 Regression] ICE during array result, allocatable assignment

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Mon Nov  6 10:14:29 2017
New Revision: 254442

URL: https://gcc.gnu.org/viewcvs?rev=254442&root=gcc&view=rev
Log:
 2017-11-06  Paul Thomas  

PR fortran/69739
* trans-expr.c (gfc_map_intrinsic_function): Return false for
bounds without the DIM argument instead of ICEing.

2017-11-06  Paul Thomas  

PR fortran/69739
* gfortran.dg/pr69739.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr69739.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/80955] Macros expanded in definition of user-defined literals

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Nov  6 10:33:41 2017
New Revision: 254443

URL: https://gcc.gnu.org/viewcvs?rev=254443&root=gcc&view=rev
Log:
/libcpp
2017-11-06  Mukesh Kapoor  

PR c++/80955
* lex.c (lex_string): When checking for a valid macro for the
warning related to -Wliteral-suffix (CPP_W_LITERAL_SUFFIX),
check that the macro name does not start with an underscore
before calling is_macro().

/gcc/testsuite
2017-11-06  Mukesh Kapoor  

PR c++/80955
* g++.dg/cpp0x/udlit-macros.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/udlit-macros.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug c++/80955] Macros expanded in definition of user-defined literals

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug fortran/78641] [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Mon Nov  6 10:40:11 2017
New Revision: 25

URL: https://gcc.gnu.org/viewcvs?rev=25&root=gcc&view=rev
Log:
2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/78641
* resolve.c (resolve_ordinary_assign): Do not add the _data
component for class valued array constructors being assigned
to derived type arrays.
* trans-array.c (gfc_trans_array_ctor_element): Take the _data
of class valued elements for assignment to derived type arrays.

2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/78641
* gfortran.dg/class_66.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_66.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-array.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82849] [8 Regression] ICE on valid code since r254379

[andrey.y.guskov at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82849

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #2 from Andrey Guskov  ---
r254379 also triggers this make check failure:

spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/
/source/gcc/testsuite/gcc.dg/tree-ssa/vrp101.c
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/work/x86_64-pc-linux-gnu/./libmpx/
-B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -fdump-tree-optimized -S -o vrp101.s
PASS: gcc.dg/tree-ssa/vrp101.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/vrp101.c scan-tree-dump optimized " \\[[0-9.]+%\\]
\\[count: [0-9INV]*\\]:[\n\r ]*return 0;"

Option set:
-with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared
--enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl
--enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell

[Bug target/67591] ARM v8 Thumb IT blocks deprecated

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67591

--- Comment #5 from Christophe Lyon  ---
Author: clyon
Date: Mon Nov  6 10:43:19 2017
New Revision: 254446

URL: https://gcc.gnu.org/viewcvs?rev=254446&root=gcc&view=rev
Log:
[ARM] PR 67591 ARM v8 Thumb IT blocks are deprecated part 2

2017-11-06  Christophe Lyon  

PR target/67591
* config/arm/arm.md (*sub_shiftsi): Add predicable_short_it
attribute.
(*cmp_ite0): Add enabled_for_depr_it attribute.
(*cmp_ite1): Likewise.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug target/67591] ARM v8 Thumb IT blocks deprecated

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67591

Christophe Lyon  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Christophe Lyon  ---
Should be fixed now.

[Bug other/82857] New: libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

[doko at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82857

Bug ID: 82857
   Summary: libbacktrace: please support binaries stripped with
dwz -m (following the .gnu_debugaltlink)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

 jakub: do you know if libbacktrace is working with dwz stripped debug
info?
 doko: no, somebody would need to write support for that (shouldn't be
very hard, I just don't have spare cycles for that right now)
 doko: pretty much one has to just write code to parse .gnu_debugaltlink
and find the other debug file, open it when it is needed
 doko: and handle the *_alt forms
 doko: to be precise, it works with dwz compressed debug info, but
doesn't with dwz -m

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065

Eric Gallager  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |oleg.e...@t-online.de

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> (In reply to Oleg Endo from comment #7)
> > (In reply to Eric Gallager from comment #6)
> > > 
> > > Can I change the status to SUSPENDED or assign them to you instead? I'm 
> > > not
> > > so much trying to reduce the number of open PRs as I am trying to just 
> > > move
> > > them out of the WAITING queue. https://gcc.gnu.org/bugs/management.html 
> > > says
> > > bugs are only ever supposed to stay in the WAITING state for 3 months, 
> > > after
> > > all.
> > 
> > Whatever, as long as it stays open.
> 
> OK, thanks.

Even though this one isn't in WAITING anymore, I guess I'll assign it to you,
too...

[Bug target/82858] New: __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

Bug ID: 82858
   Summary: __builtin_add_overflow() generates suboptimal code
with unsigned types on x86
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

The following function:

```
unsigned saturated_add(unsigned a, unsigned b){
unsigned c;
if(__builtin_add_overflow(a, b, &c)){
return -1;
}
return c;
}
```

, after being compiled with `gcc -O3 -Wall -Wextra -pedantic -pedantic-errors
-masm=intel`, results in:

```
saturated_add(unsigned int, unsigned int):
  add edi, esi
  jc .L3
  mov eax, edi
  ret
.L3:
  or eax, -1
  ret
```

This is suboptimal, as the branch can be simply eliminated as follows:

```
saturated_add(unsigned int, unsigned int):
  add edi, esi
  sbb eax, eax  // EAX = -1 if CF is set and 0 otherwise.
  or eax, edi
  ret
```

[Bug fortran/69739] [6/7/8 Regression] ICE during array result, allocatable assignment

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Mon Nov  6 11:48:32 2017
New Revision: 254448

URL: https://gcc.gnu.org/viewcvs?rev=254448&root=gcc&view=rev
Log:
2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/69739
* trans-expr.c (gfc_map_intrinsic_function): Return false for
bounds without the DIM argument instead of ICEing.

2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/69739
* gfortran.dg/pr69739.f90: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr69739.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-expr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/78641] [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Mon Nov  6 11:50:53 2017
New Revision: 254449

URL: https://gcc.gnu.org/viewcvs?rev=254449&root=gcc&view=rev
Log:
2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/78641
* resolve.c (resolve_ordinary_assign): Do not add the _data
component for class valued array constructors being assigned
to derived type arrays.
* trans-array.c (gfc_trans_array_ctor_element): Take the _data
of class valued elements for assignment to derived type arrays.

2017-11-06  Paul Thomas  

Backported from trunk
PR fortran/78641
* gfortran.dg/class_66.f90: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_66.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/resolve.c
branches/gcc-6-branch/gcc/fortran/trans-array.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/69739] [6/7/8 Regression] ICE during array result, allocatable assignment

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69739

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Paul Thomas  ---
Fixed on 6-, 7- and 8-branches.

Thanks for the report. Sorry that it took so long to fix.

Paul

[Bug fortran/78641] [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Paul Thomas  ---
Fixed on 6-, 7- and 8-branches.

Thanks for the report. Sorry that it took so long to fix.

Paul

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-06
 CC||trippels at gcc dot gnu.org
  Known to work||8.0
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.2.1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. Trunk is fine.

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

--- Comment #2 from Liu Hao  ---
Trunk on  produces the following code:

```
saturated_add(unsigned int, unsigned int):
  add edi, esi
  mov eax, -1
  cmovnc eax, edi
  ret
```

Condition moves are however, in my opinion, nothing better than branches, or
they could be something worse: 

[Bug fortran/82859] New: derived type character component, array comparison inconsistent

[simon.kluepfel at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82859

Bug ID: 82859
   Summary: derived type character component, array comparison
inconsistent
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon.kluepfel at gmail dot com
  Target Milestone: ---

Created attachment 42547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42547&action=edit
source code of test program

Inconsistency occurs when comparing arrays of derived types containing
character components. Success/Failure seems to depend on blank padding in
initialization of the array.

In the snippet from the attached program, A1 and A2 behave differently.

[...]
  INTEGER, PARAMETER :: MLEN=2

  TYPE A
CHARACTER(LEN=MLEN) :: STR
  END TYPE A

  TYPE(A), DIMENSION(*), PARAMETER :: A1= (/ &
A("AX") & 
  , A("B ") & 
  , A("C ") & 
  /)

  TYPE(A), DIMENSION(*), PARAMETER :: A2= (/ &
A("AX") & 
  , A("B") & 
  , A("C") & 
  /)
[...]

The attached program should give the same results for all cases in both of the
test sets. Results with gfortran 7.1.1 and 6.3.0 are unexpected, marked with
arrows below.

 A1 /A2  T T T
 SAP/SAA T T T
 SAP/A1  T T T
 SAA/A1  T T T
 SAP/A2  T T T
 SAA/A2  T F F  <--

 A1 /SP  F T F
 A2 /SP  F F F  <--
 SAP/SP  F T F
 SAA/SP  F T F
 A1 /SA  F T F
 A2 /SA  F F F  <--
 SAP/SA  F T F
 SAA/SA  F T F

[Bug target/82827] [8 regression] i386/pr82002-2a.c fail

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82827

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug jit/82826] [8 regression] jit.dg test-benchmark.c.exe fail

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82826

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Liu Hao from comment #2)
> Trunk on  produces the following code:
> 
> ```
> saturated_add(unsigned int, unsigned int):
>   add edi, esi
>   mov eax, -1
>   cmovnc eax, edi
>   ret
> ```
> 
> Condition moves are however, in my opinion, nothing better than branches, or
> they could be something worse: 

Linus is talking about the Pentium 4. Hardware has evolved since then.
On today's CPUs CMOV is fine.

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug bootstrap/82832] [8 Regression] Broken PGO LTO bootstrap on x86_64 after r254379

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82832

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug c++/82835] [8 Regression] ICE on valid code with -fopenmp

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82835

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #9 from Wilco  ---
(In reply to Andi Kleen from comment #8)
> I'm not sure if it works with other numbers too.
> 
> (need to dig through Hacker's delight & Matters Computational to see if they
> have anything on it)
> 
> But it could be extended for other word lengths at least
> 
> BTW there are some other cases, will file a bug shortly on those too.

It works for any C where (divisor*C) MOD 2^32 == 1 (or -1). You can support any
kind of comparison, it doesn't need to be with 0 (but zero is the easiest). I
forgot whether I made it work for signed too, but it's certainly possible to
skip the sign handling in x % 4 == 0 even if x is signed.

While this is faster in general than computing the full modulo result, it
wouldn't be if you need the division result as well. So this works best on
single-use modulos used in comparisons, at the same time as general divisions
are expanded.

[Bug c++/82836] [8 Regression] ICE on valid code

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82836

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug debug/82837] [8 Regression] ICE in output_operand: invalid expression as operand

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82837

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/82848] [8 Regression] ICE in expand_expr_real_2, at expr.c:8715

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82848

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug target/82852] [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82852

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

--- Comment #4 from Marc Glisse  ---
unsigned c;
unsigned d = __builtin_add_overflow(a, b, &c)?-1:0;
return c|d;

gives the expected asm. Ideally phiopt would recognize a saturing add pattern,
but we have nothing to model it in gimple. We could turn it into the branchless
BIT_IOR form though.

(the problem isn't with __builtin_add_overflow but with what comes afterwards)

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

--- Comment #10 from Richard Biener  ---
Might be even more special-cased with x % 3 == 0 ? C1 : C2 aka in if-conversion
context.

[Bug bootstrap/82856] [8 Regression] --enable-maintainter-mode broken by automake failure

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Version|unknown |8.0

--- Comment #1 from Richard Biener  ---
Likely all active branches are affected and it's likely not a regression.

Can you quickly figure what automake version fixed this?

[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-06
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 42548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42548&action=edit
gcc8-pr82855-1.patch

Untested patch, part 1.

[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855

--- Comment #2 from Jakub Jelinek  ---
Created attachment 42549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42549&action=edit
gcc8-pr82855-2.patch

Untested patch, part 2.

[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855

--- Comment #3 from Jakub Jelinek  ---
Created attachment 42550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42550&action=edit
gcc8-pr82855-1.patch

Untested patch, part 3.  With these 3, I get for the second function
with -O2 -mavx512{vl,dq} -mtune=intel:
vpxord  %xmm0, %xmm0, %xmm0
xorl%eax, %eax
vpcmpeqd(%rdi), %ymm0, %k1
ktestb  %k1, %k1
sete%al
With the generic tuning, the load is performed separately from the comparison.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

--- Comment #11 from Marc Glisse  ---
(In reply to Wilco from comment #9)
> It works for any C where (divisor*C) MOD 2^32 == 1 (or -1).

For x%3==0, i.e. z==0 for x==3*y+z with 0<=y<5556 and 0<=z<3. 
Indeed, x*0xaaab==y+z*0xaaab is in the right range precisely for z==0
and the same can be done for any odd number.

> You can support any kind of comparison, it doesn't need to be with 0 (but 
> zero is the easiest).

Any ==cst will yield a range test. It is less obvious that inequalities are
transformed to a contiguous range... (try x%7<3 maybe)

> I forgot whether I made it work for signed too, but it's certainly
> possible to skip the sign handling in x % 4 == 0 even if x is signed.

4 is a completely different story, as a power of 2.

[Bug target/82858] __builtin_add_overflow() generates suboptimal code with unsigned types on x86

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82858

--- Comment #5 from Uroš Bizjak  ---
Actually, -m32 -march=i386 -mtune=generic generates expected code:

movl8(%esp), %eax
addl4(%esp), %eax
sbbl%edx, %edx
orl %edx, %eax
ret

-march=i386 does not have cmove.

[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82783

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Paul Thomas  ---
Fixed on 7-branch and trunk.

Many thanks for the report.

Paul

[Bug target/82827] [8 regression] i386/pr82002-2a.c fail

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82827

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Uroš Bizjak  ---
Dup.

*** This bug has been marked as a duplicate of bug 82002 ***

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Uroš Bizjak  ---
Fixed.

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82002

Uroš Bizjak  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #12 from Uroš Bizjak  ---
*** Bug 82827 has been marked as a duplicate of this bug. ***

[Bug bootstrap/82832] [8 Regression] Broken PGO LTO bootstrap on x86_64 after r254379

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82832

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Mon Nov  6 13:45:41 2017
New Revision: 254452

URL: https://gcc.gnu.org/viewcvs?rev=254452&root=gcc&view=rev
Log:

PR bootstrap/82832
* ipa-inline-transform.c (update_noncloned_frequencies): Always
scale.
(inline_transform): Likewise.
* predict.c (counts_to_freqs): Remove useless conditional.
* profile-count.h (profile_count::apply_scale): Move sanity check.
* tree-inline.c (copy_bb): Always scale.
(copy_cfg_body): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-transform.c
trunk/gcc/predict.c
trunk/gcc/profile-count.h
trunk/gcc/tree-inline.c

[Bug tree-optimization/82860] New: [8 regression] gcc.dg/vect/pr79347.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82860

Bug ID: 82860
   Summary: [8 regression] gcc.dg/vect/pr79347.c FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: amker at gcc dot gnu.org
  Target Milestone: ---
  Host: sparc-sun-solaris2.11, ia64-suse-linux-gnu
Target: sparc-sun-solaris2.11, ia64-suse-linux-gnu
 Build: sparc-sun-solaris2.11, ia64-suse-linux-gnu

Created attachment 42551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42551&action=edit
32-bit sparc-sun-solaris2.11 pr79347.c.158t.vect

Between 20171103 (r254366) and 20171105 (r254430), a testcase regressed on
Solaris/SPARC and Linux/IA64, both 32 and 64-bit:

FAIL: gcc.dg/vect/pr79347.c -flto -ffat-lto-objects  scan-tree-dump-not vect "I
nvalid sum of "
FAIL: gcc.dg/vect/pr79347.c scan-tree-dump-not vect "Invalid sum of "

Dump attached.

  Rainer

[Bug tree-optimization/82860] [8 regression] gcc.dg/vect/pr79347.c FAILs

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82860

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844

--- Comment #7 from H.J. Lu  ---
(In reply to Eric Botcazou from comment #6)
> > The last good subversion checkin is r253135.
> 
> And the first revision for which you have the timeouts?

That is r253366. X32 failed to build between r253136 and r253365.

[Bug libgomp/38935] Openmp reduction with - (minus) does not produce correct result

[subc2 at wp dot pl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38935

Paweł Zacharek  changed:

   What|Removed |Added

 CC||subc2 at wp dot pl

--- Comment #1 from Paweł Zacharek  ---
I can confirm the behavior on GCC version 6.3.0 20170516 (Debian 6.3.0-18) and
also Clang version 5.0.0 for armv7a--linux-android.

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Eric Gallager  ---
[...]
> Apparently 10.6/Darwin 11 isn't supported either; see bug 82829. As I said

I couldn't find an explicit statement of support (or non-support) for
LLVM on Darwin.  However, we could either try to get patches upstream
or keep them gcc-local if they are as trivial as those two.

> there, it'd really be nice to have a --disable-libsanitizer configure flag for
> whenever upstream breaks stuff again

Your wish has already been granted: for most if not all target
libraries, there's already a --disable-libX/--enable-libX switch,
libsanitizer included.

However, this isn't the right way to handle this: if it's really
concluded that libsanitizer isn't supported on certain Darwin versions,
this should be handled in libsanitizer/configure.tgt so users don't get
failing bootstraps without non-default options.

Rainer

[Bug c++/82861] New: 'long double sqrtf128(long double)' conflicts with built-in declaration 'long double sqrtf128(long double)' [-Wbuiltin-declaration-mismatch]

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82861

Bug ID: 82861
   Summary: 'long double sqrtf128(long double)' conflicts with
built-in declaration 'long double sqrtf128(long
double)' [-Wbuiltin-declaration-mismatch]
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

on aarch64 i get nonsense warning when declaring f128 apis:

$ cat a.cc
extern "C" long double sqrtf128(long double) throw();
long double f(long double x) { return sqrtf128(x); }

$ g++ -Wall -S a.cc
a.cc:1:24: warning: declaration of 'long double sqrtf128(long double)'
conflicts with built-in declaration 'long double sqrtf128(long double)'
[-Wbuiltin-declaration-mismatch]
 extern "C" long double sqrtf128(long double) throw();
^~~~

glibc math tests fail to build because of this.

[Bug tree-optimization/82816] [8 Regression] ICE on valid code at -Os and above: in find_widening_optab_handler_and_mode, at optabs-query.c:414

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82816

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Mon Nov  6 14:47:43 2017
New Revision: 254454

URL: https://gcc.gnu.org/viewcvs?rev=254454&root=gcc&view=rev
Log:
PR82816: Widening multiplies of bitfields

In this PR we tried to create a widening multiply of two 3-bit numbers,
but that isn't a widening multiply at the optab/rtl level, since both
the input and output still have the same mode.

We could trap this either in is_widening_mult_p or (as the patch does)
in the routines that actually ask for an optab.  The latter seemed
more natural since is_widening_mult_p doesn't otherwise care about modes.

2017-11-03  Richard Sandiford  
Alan Hayward  
David Sherwood  

gcc/
PR tree-optimization/82816
* tree-ssa-math-opts.c (convert_mult_to_widen): Return false
if the modes of the two types are the same.
(convert_plusminus_to_widen): Likewise.

gcc/testsuite/
* gcc.c-torture/compile/pr82816.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82816.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug bootstrap/82831] [8 Regression] Broken PGO bootstrap on i586-linux-gnu after r254379

[hubicka at ucw dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82831

--- Comment #1 from Jan Hubicka  ---
This seems previously latent bug in bb-reorder. It produces order of blocks
which
has hot blocks, then some cold blocks and then hot blocks again. 

I am not sure why this happens though.

Honza

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809

--- Comment #20 from Qing Zhao  ---
design doc is at:
https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html

[Bug bootstrap/82832] [8 Regression] Broken PGO LTO bootstrap on x86_64 after r254379

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82832

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||hubicka at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jan Hubicka  ---
Fixed.

[Bug middle-end/82853] Optimize x % 3 == 0 without modulo

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853

--- Comment #12 from Wilco  ---
(In reply to Marc Glisse from comment #11)
> (In reply to Wilco from comment #9)
> > It works for any C where (divisor*C) MOD 2^32 == 1 (or -1).
> 
> For x%3==0, i.e. z==0 for x==3*y+z with 0<=y<5556 and 0<=z<3. 
> Indeed, x*0xaaab==y+z*0xaaab is in the right range precisely for
> z==0 and the same can be done for any odd number.

You can make it work for even numbers as well, eg. (x % 10) == 0 -> (x % 5) ==
0 && (x & 1) == 0. If you can avoid branches then it may still be faster.

> > You can support any kind of comparison, it doesn't need to be with 0 (but 
> > zero is the easiest).
> 
> Any ==cst will yield a range test. It is less obvious that inequalities are
> transformed to a contiguous range... (try x%7<3 maybe)

Indeed, expanding into x % 7 == 0 || x % 7 == 1 || x % 7 == 2 is unlikely to be
a good idea. However you can change x % 7 >= 1 into x % 7 != 0 or x % 7 < 6
into x % 7 != 6 which are single ranges.

[Bug tree-optimization/82862] New: [8 Regression] SPEC CPU2006 465.tonto performance regression with trunk@253975 (up to 40% drop for particular loop)

[alexander.nesterovskiy at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82862

Bug ID: 82862
   Summary: [8 Regression] SPEC CPU2006 465.tonto performance
regression with trunk@253975 (up to 40% drop for
particular loop)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.nesterovskiy at intel dot com
  Target Milestone: ---

Created attachment 42552
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42552&action=edit
reproducer

Regression is well noticeable when 465.tonto is compiled with:
-Ofast -march=core-avx2 -mfpmath=sse -funroll-loops

Changes in cost model leads to changes in unrolling and vectorizing of few
loops and causes increase of their execution time up to 60%.
Whole 465.tonto benchmark regression is not so big and is about 2-4% just
because the affected loops are less than 10% of all workload.

Compiling with "-fopt-info-all-optall=all.optimized" and grepping for
particular line:
r253973:
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 7 times
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 7 times

r253975:
 shell1quartet.fppized.f90:4086:0: note: loop vectorized
 shell1quartet.fppized.f90:4086:0: note: loop vectorized
 shell1quartet.fppized.f90:4086:0: note: loop with 6 iterations completely
unrolled
 shell1quartet.fppized.f90:4086:0: note: loop with 6 iterations completely
unrolled
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 3 times
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 1 times

There was a change introduced by r254012: 
 shell1quartet.fppized.f90:4086:0: note: loop vectorized
 shell1quartet.fppized.f90:4086:0: note: loop vectorized
 shell1quartet.fppized.f90:4086:0: note: loop with 3 iterations completely
unrolled
 shell1quartet.fppized.f90:4086:0: note: loop with 3 iterations completely
unrolled
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 3 times
 shell1quartet.fppized.f90:4086:0: note: loop unrolled 1 times

But still there is a degradation of these particular loops up to 40%.

Reproducer is attached.

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824

--- Comment #3 from Eric Gallager  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Eric Gallager  ---
> [...]
> > Apparently 10.6/Darwin 11 isn't supported either; see bug 82829. As I said
> 
> I couldn't find an explicit statement of support (or non-support) for
> LLVM on Darwin.  However, we could either try to get patches upstream
> or keep them gcc-local if they are as trivial as those two.
> 
> > there, it'd really be nice to have a --disable-libsanitizer configure flag
> > for whenever upstream breaks stuff again
> 
> Your wish has already been granted: for most if not all target
> libraries, there's already a --disable-libX/--enable-libX switch,
> libsanitizer included.

Really? It doesn't show up in the ./configure --help output:

Local-Admins-MacBook-Pro:gcc ericgallager$ ./configure --help=recursive | grep
-i sanit
Report bugs to .
Local-Admins-MacBook-Pro:gcc ericgallager$

> 
> However, this isn't the right way to handle this: if it's really
> concluded that libsanitizer isn't supported on certain Darwin versions,
> this should be handled in libsanitizer/configure.tgt so users don't get
> failing bootstraps without non-default options.
> 
>   Rainer

[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #3 from Eric Gallager  ---
[...]
> Really? It doesn't show up in the ./configure --help output:
>
> Local-Admins-MacBook-Pro:gcc ericgallager$ ./configure --help=recursive | grep
> -i sanit
> Report bugs to .

Sure: check for able_lib in configure.  Not everything that's not
documented doesn't exist ;-)

Rainer

[Bug target/82862] [8 Regression] SPEC CPU2006 465.tonto performance regression with r253975 (up to 40% drop for particular loop)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82862

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-linux-gnu
  Component|tree-optimization   |target
Version|unknown |8.0
   Target Milestone|--- |8.0

[Bug target/82788] wrong code with -fstack-clash-protection --param=stack-clash-protection-probe-interval=10 on simple code

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Mon Nov  6 15:51:16 2017
New Revision: 254456

URL: https://gcc.gnu.org/viewcvs?rev=254456&root=gcc&view=rev
Log:
PR target/82788
* config/i386/i386.c (PROBE_INTERVAL): Remove.
(get_probe_interval): New functions.
(ix86_adjust_stack_and_probe_stack_clash): Use get_probe_interval.
(ix86_adjust_stack_and_probe): Likewise.
(output_adjust_stack_and_probe): Likewise.
(ix86_emit_probe_stack_range): Likewise.
(ix86_expand_prologue): Likewise.

PR target/82788
* gcc.dg/pr82788.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr82788.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82850] g++ permits redefinition of default arguments

[ec13n at my dot fsu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850

Erik Cass  changed:

   What|Removed |Added

Version|4.8.5   |5.4.0

--- Comment #2 from Erik Cass  ---
Hi!

Understood that 4.8 isn't supported anymore, however wanted to point out that
this was on a Redhat instance, so whatever fixes should have been backported. 
That said, I performed the same test on a latest release of Amazon Linux and
Ubuntu 16.04, with the same results.  heres the results of g++ -v on the
Ubunutu test:

root@ip-172-31-37-6:~# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.5' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)

I'll try to install the lastest stable on a windows box and repeat the test. 
In the meantime, i've updated the version field of this bug report to 5.4.0.

[Bug ada/82844] [8 Regression] Many ada tests time out on x32

[derodat at adacore dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844

--- Comment #8 from Pierre-Marie de Rodat  ---
(In reply to H.J. Lu from comment #7)
> That is r253366. X32 failed to build between r253136 and r253365.

Ok, thanks! We still have patches in the pipeline in this area (s-taprop*
files), so I’ll try to port them. Hopefully this will fix the issue.

[Bug target/82863] New: [8 Regression] ICE in verify_flow_info building SH libgcc

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82863

Bug ID: 82863
   Summary: [8 Regression] ICE in verify_flow_info building SH
libgcc
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: sh4-linux-gnu

The following ICE building libgcc for sh4-linux-gnu was introduced by r254379. 
Compile the following with -O2:

typedef int SItype __attribute__ ((mode (SI)));
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef int DItype __attribute__ ((mode (DI)));
typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef float SFtype __attribute__ ((mode (SF)));
typedef float DFtype __attribute__ ((mode (DF)));
SFtype
__floatdisf (DItype u)
{
  if (! (- ((DItype) 1 << 53) < u
  && u < ((DItype) 1 << 53)))
{
  if ((UDItype) u & (((UDItype) 1 << (((4 * 8) * 2) - 53)) - 1))
 {
   u &= ~ (((UDItype) 1 << (((4 * 8) * 2) - 53)) - 1);
   u |= ((UDItype) 1 << (((4 * 8) * 2) - 53));
 }
}



  DFtype f = (SItype) (u >> (4 * 8));
  f *= 0x1p32f;
  f += (USItype)u;
  return (SFtype) f;
}

Resulting ICE seen:

floatdisf.i: In function '__floatdisf':
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 7->10
 }
 ^
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 7->8
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 5->11
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 5->6
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 2->11
floatdisf.i:26:1: error: verify_flow_info: Wrong probability of edge 2->4
during RTL pass: expand
floatdisf.i:26:1: internal compiler error: verify_flow_info failed
0x71a2c3 verify_flow_info()
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfghooks.c:265
0x10a37a2 checking_verify_flow_info
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfghooks.h:198
0x10a37a2 try_optimize_cfg
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgcleanup.c:3015
0x10a3aad cleanup_cfg(int)
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgcleanup.c:3179
0x7170b5 execute
/scratch/jmyers/glibc/many8/src/gcc/gcc/cfgexpand.c:6511
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/82838] [8 Regression] ICE in verify_ssa failed w/ store-merging

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82838

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  6 16:29:11 2017
New Revision: 254457

URL: https://gcc.gnu.org/viewcvs?rev=254457&root=gcc&view=rev
Log:
PR tree-optimization/82838
* gimple-ssa-store-merging.c
(imm_store_chain_info::output_merged_store): Call
force_gimple_operand_1
on a separate gimple_seq which is then appended to seq.

* gcc.c-torture/compile/pr82838.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82838.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82838] [8 Regression] ICE in verify_ssa failed w/ store-merging

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82838

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug jit/82826] [8 regression] jit.dg test-benchmark.c.exe fail

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82826

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Mon Nov  6 16:31:04 2017
New Revision: 254458

URL: https://gcc.gnu.org/viewcvs?rev=254458&root=gcc&view=rev
Log:
ipa-fnsummary.c: fix use-after-free crash (PR jit/82826)

gcc/ChangeLog:
PR jit/82826
* ipa-fnsummary.c (ipa_fnsummary_c_finalize): New function.
* ipa-fnsummary.h (ipa_fnsummary_c_finalize): New decl.
* toplev.c: Include "ipa-fnsummary.h".
(toplev::finalize): Call ipa_fnsummary_c_finalize.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-fnsummary.h
trunk/gcc/toplev.c

[Bug c++/82861] 'long double sqrtf128(long double)' conflicts with built-in declaration 'long double sqrtf128(long double)' [-Wbuiltin-declaration-mismatch]

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82861

--- Comment #1 from joseph at codesourcery dot com  ---
Should already have been fixed by r254277.

[Bug jit/82826] [8 regression] jit.dg test-benchmark.c.exe fail

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82826

--- Comment #4 from David Malcolm  ---
Should be fixed by r254458.

[Bug jit/82826] [8 regression] jit.dg test-benchmark.c.exe fail

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82826

David Malcolm  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from David Malcolm  ---
Should be fixed by r254458.

[Bug c++/82850] g++ permits redefinition of default arguments

[ec13n at my dot fsu.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850

Erik Cass  changed:

   What|Removed |Added

Version|5.4.0   |6.4.0

--- Comment #3 from Erik Cass  ---
Hello again... quick update:  I repeated the test on gcc 6.4.0 running inside
cigwin.  it is still possible to specify default arguments in both places as
described.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/6.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-6.4.0-2.x86_64/src/gcc-6.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-6.4.0-2.x86_64/src/gcc-6.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 6.4.0 (GCC)

I'll update the version again to Version 6.4.0.

[Bug fortran/82859] derived type character component, array comparison inconsistent

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82859

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-06
 CC||vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. Array specification required has been required up to revision
r224477.

[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846

--- Comment #2 from David Malcolm  ---
Works for me; I wasn't able to reproduce.

Does the fix for PR jit/82826 (r254458) help?

If I add this to set_options in harness.h:

  gcc_jit_context_set_bool_option (
ctxt,
GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE,
1);

it dumps the generated code.

Rerunning using:

  make check-jit RUNTESTFLAGS="-v -v -v jit.exp=test-alignment.c"

I get the following for test_aligned_reading_s2 and test_aligned_writing_s2:

.Ltext0:
.p2align 4,,15
.globl  test_aligned_reading_s2
.type   test_aligned_reading_s2, @function
test_aligned_reading_s2:
.LFB56:
.cfi_startproc
.LVL0:
movzbl  (%rdi), %eax
mulb2(%rdi)
ret
.cfi_endproc
.LFE56:
.size   test_aligned_reading_s2, .-test_aligned_reading_s2
.p2align 4,,15
.globl  test_aligned_writing_s2
.type   test_aligned_writing_s2, @function
test_aligned_writing_s2:
.LFB57:
.cfi_startproc
.LVL1:
movb$5, (%rdi)
movb$7, 2(%rdi)
jmp test_aligned_reading_s2@PLT

for the "_s2" case.

What do you get?  Thanks.

[Bug libgomp/82864] New: Stop using GOMP_OFFLOAD_openacc_async_set_async

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82864

Bug ID: 82864
   Summary: Stop using GOMP_OFFLOAD_openacc_async_set_async
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

When grepping for async_set_async_func in libgomp sources, we see a pattern
emerging:
...
libgomp.h:917:  __typeof (GOMP_OFFLOAD_openacc_async_set_async)
*async_set_async_func;
oacc-host.c:246:  .async_set_async_func = host_openacc_async_set_async,
oacc-init.c:432:  acc_dev->openacc.async_set_async_func (acc_async_sync);
oacc-parallel.c:156:  acc_dev->openacc.async_set_async_func (async);
oacc-parallel.c:191:  acc_dev->openacc.async_set_async_func (acc_async_sync);
oacc-parallel.c:289:  acc_dev->openacc.async_set_async_func (async);
oacc-parallel.c:395:  acc_dev->openacc.async_set_async_func (acc_async_sync);
oacc-parallel.c:448:  acc_dev->openacc.async_set_async_func (async);
oacc-parallel.c:474:  acc_dev->openacc.async_set_async_func (acc_async_sync);
oacc-plugin.c:39:  devicep->openacc.async_set_async_func (async);
oacc-plugin.c:41:  devicep->openacc.async_set_async_func (acc_async_sync);
...

F.i., lets look at the last pair:
...
void
GOMP_PLUGIN_async_unmap_vars (void *ptr, int async)
{
  struct target_mem_desc *tgt = ptr;
  struct gomp_device_descr *devicep = tgt->device_descr;

  devicep->openacc.async_set_async_func (async);
  gomp_unmap_vars (tgt, true);
  devicep->openacc.async_set_async_func (acc_async_sync);
}
...

This is an example of implicit parameter passing: instead of passing the async
argument to gomp_unmap_vars and beyond, we tell the target plugin to store the
async argument for the time being as attribute of the current thread, and let
the target plugin use that argument where appropriate while executing
gomp_unmap_vars.

It is a bit odd though that we're asking the target plugin to keep this state.
I think it would be more logical to have the attribute as a part of struct
goacc_thread, and extend the plugin interface with the async argument where
necessary. So f.i. alongside the existing
  extern bool GOMP_OFFLOAD_dev2host (int, void *, const void *, size_t);
we add an async variant 
  extern bool GOMP_OFFLOAD_dev2host_async (int, void *, const void *, size_t,
   int async);
and use that instead if the target plugin provides it.

[Bug c++/82850] g++ permits redefinition of default arguments

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #4 from Daniel Krügler  ---
This looks like a dup of bug 50370 to me.

[Bug fortran/56496] [OOP] [F08] ICE with TYPE(*) coarray and SELECT TYPE

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56496

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---
Update :


$ gfortran-8-20171105 -c pr56496.f90 -fcoarray=single
pr56496.f90:5:0:

   a= 5

internal compiler error: Segmentation fault
0xb60fdf crash_signal
../../gcc/toplev.c:324
0x737444 gfc_conv_array_data(tree_node*)
../../gcc/fortran/trans-array.c:2936
0x73797d gfc_conv_ss_descriptor
../../gcc/fortran/trans-array.c:2874
0x73a167 gfc_conv_ss_startstride(gfc_loopinfo*)
../../gcc/fortran/trans-array.c:4227
0x76af6b gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:9954
0x7301b7 trans_code
../../gcc/fortran/trans.c:1828
0x79b208 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1877
0x72ffd7 trans_code
../../gcc/fortran/trans.c:1924
0x79d4a7 gfc_trans_select_type_cases
../../gcc/fortran/trans-stmt.c:2475
0x79d4a7 gfc_trans_select_type(gfc_code*)
../../gcc/fortran/trans-stmt.c:3185
0x72ff47 trans_code
../../gcc/fortran/trans.c:1944
0x79b208 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1877
0x72ffd7 trans_code
../../gcc/fortran/trans.c:1924
0x756bfc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x6e8b90 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x6e8b90 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/56496] [OOP] [F08] ICE with TYPE(*) coarray and SELECT TYPE

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56496

--- Comment #3 from G. Steinmetz  ---

Further reduced :


$ cat z1.f90
program p
   class(*), allocatable :: a[:]
   allocate (integer :: a[*])
   select type (a)
   type is (integer)
   end select
end


$ gfortran-8-20171105 -c z1.f90 -fcoarray=single
z1.f90:1:0:

 program p

internal compiler error: in gfc_conv_array_ref, at fortran/trans-array.c:3512
0x739662 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3512
0x7667cd gfc_conv_variable
../../gcc/fortran/trans-expr.c:2680
0x79b575 trans_associate_var
../../gcc/fortran/trans-stmt.c:1769
0x79b575 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1884
0x72ffd7 trans_code
../../gcc/fortran/trans.c:1924
0x79d4a7 gfc_trans_select_type_cases
../../gcc/fortran/trans-stmt.c:2475
0x79d4a7 gfc_trans_select_type(gfc_code*)
../../gcc/fortran/trans-stmt.c:3185
0x72ff47 trans_code
../../gcc/fortran/trans.c:1944
0x79b208 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1877
0x72ffd7 trans_code
../../gcc/fortran/trans.c:1924
0x756bfc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x6e8b90 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x6e8b90 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82865] New: Option -fdec collides with PDT

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Bug ID: 82865
   Summary: Option -fdec collides with PDT
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Several testsuite files ./gcc/testsuite/gfortran.dg/pdt_*
are producing extra error messages when combined with option -fdec.
One short example :


$ cat z1.f90
program p
   type t(a)
  integer, len :: a
   end type
end


$ gfortran-8-20171105 -c z1.f90
$
$ gfortran-8-20171105 -c z1.f90 -fdec
z1.f90:3:18:

   integer, len :: a
  1
Error: Attribute at (1) is not allowed outside a TYPE definition
z1.f90:4:6:

end type
  1
Error: Expecting END PROGRAM statement at (1)
z1.f90:2:7:

type t(a)
   1
Error: FORMAT tag at (1) must be of type default-kind CHARACTER or of INTEGER

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[paolo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65579

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Nov  6 17:45:55 2017
New Revision: 254461

URL: https://gcc.gnu.org/viewcvs?rev=254461&root=gcc&view=rev
Log:
/cp
2017-11-06  Paolo Carlini  

PR c++/65579
* decl2.c (finish_static_data_member_decl): If there's an initializer,
complete the type and re-apply the quals.

/testsuite
2017-11-06  Paolo Carlini  

PR c++/65579
* g++.dg/cpp0x/constexpr-template11.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65579

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #7 from Paolo Carlini  ---
Fixed.

[Bug c++/55004] [meta-bug] constexpr issues

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 65579, which changed state.

Bug 65579 Summary: [C++11] gcc requires definition of a static constexpr member 
even though it is not odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65579

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/82866] New: [PDT] ICE in resolve_fl_derived0, at fortran/resolve.c:14004

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866

Bug ID: 82866
   Summary: [PDT] ICE in resolve_fl_derived0, at
fortran/resolve.c:14004
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With invalid code similar to pr82586 :


$ cat z1.f90
module m
   type t(*)
   end type
end


$ /gfortran-8-20171105 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb60fdf crash_signal
../../gcc/toplev.c:324
0x7056d8 resolve_fl_derived0
../../gcc/fortran/resolve.c:14004
0x70579b resolve_fl_derived
../../gcc/fortran/resolve.c:14075
0x70035f resolve_symbol
../../gcc/fortran/resolve.c:14434
0x71ae0b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x70371a resolve_types
../../gcc/fortran/resolve.c:16326
0x6ff04c gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16440
0x6e8ee4 gfc_parse_file()
../../gcc/fortran/parse.c:6232
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/82866] [PDT] ICE in resolve_fl_derived0, at fortran/resolve.c:14004

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866

G. Steinmetz  changed:

   What|Removed |Added

 Blocks||82173

--- Comment #1 from G. Steinmetz  ---

More testfiles (invalid) :


$ cat z2.f90
module m
   type t(*, *)
   end type
end


$ cat z3.f90
module m
   type t(*, a)
   end type
end


$ cat z4.f90
subroutine s
   type t(*)
   end type
end


$ cat z5.f90
subroutine s
   type t(*, a)
   end type
end


$ cat z6.f90
module m
   type t(*, a, *)
   end type
end


$ cat z6s.f90
subroutine s
   type t(*, a, *)
   end type
end


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173
[Bug 82173] [meta-bug] Parameterized derived type errors

[Bug fortran/82866] [PDT] ICE in resolve_fl_derived0, at fortran/resolve.c:14004

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866

--- Comment #2 from G. Steinmetz  ---

Slightly different :


$ cat z7.f90
module m
   type t(a, :, *)
   end type
end


$ cat z7s.f90
subroutine s
   type t(a, :, *)
   end type
end


$ cat z8.f90
module m
   type t(*, a, :)
   end type
end


$ cat z8s.f90
subroutine s
   type t(*, a, :)
   end type
end


$ gfortran-8-20171105 -c z7.f90
f951: internal compiler error: Segmentation fault
0xb60fdf crash_signal
../../gcc/toplev.c:324
0x66541b delete_root
../../gcc/fortran/bbt.c:150
0x6655ee gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/fortran/bbt.c:197
0x71dc88 gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc/fortran/symbol.c:2925
0x71f456 gfc_restore_last_undo_checkpoint()
../../gcc/fortran/symbol.c:3694
0x6ddfe7 reject_statement
../../gcc/fortran/parse.c:2546
0x6de0fc match_word_omp_simd
../../gcc/fortran/parse.c:98
0x6e20eb match_word
../../gcc/fortran/parse.c:565
0x6e20eb decode_statement
../../gcc/fortran/parse.c:565
0x6e35c4 next_free
../../gcc/fortran/parse.c:1225
0x6e35c4 next_statement
../../gcc/fortran/parse.c:1457
0x6e53ec parse_spec
../../gcc/fortran/parse.c:3651
0x6e84d8 parse_module
../../gcc/fortran/parse.c:5900
0x6e8ec9 gfc_parse_file()
../../gcc/fortran/parse.c:6213
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug middle-end/82867] New: missing warning on buffer overflow assigning to the result of mempcpy

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82867

Bug ID: 82867
   Summary: missing warning on buffer overflow assigning to the
result of mempcpy
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This test case was inspired by Glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22332.  Although the mempcpy
call in it doesn't overflow, the assignment via the pointer returned by it
does.  It seems that it should be possible to enhance the -Wstringop-overflow
warning to detect this case (perhaps in tree-ssa-strlen.c?) even though the
value of n is unknown, by saving the alloca/malloc argument for each allocated
block. checking it against the mempcpy byte counter in assignments through the
returned pointer, and diagnosing it if it's the same.

$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-strlen=/dev/stdout c.c

void* f (const char *s0, const char *s1)
{
  void *d = __builtin_malloc (s1 - s0);
  *(char*)__builtin_mempcpy (d, s0, s1 - s0) = '\0';
  return d;
}

void sink (void*);

void g (const char *s0, const char *s1)
{
  void *d = __builtin_alloca (s1 - s0);
  *(char*)__builtin_mempcpy (d, s0, s1 - s0) = '\0';
  sink (d);
}


;; Function f (f, funcdef_no=0, decl_uid=1888, cgraph_uid=0, symbol_order=0)

f (const char * s0, const char * s1)
{
  void * d;
  long int s1.0_1;
  long int s0.1_2;
  long int _3;
  long unsigned int _4;
  void * _5;

   [100.00%] [count: INV]:
  s1.0_1 = (long int) s1_6(D);
  s0.1_2 = (long int) s0_7(D);
  _3 = s1.0_1 - s0.1_2;
  _4 = (long unsigned int) _3;
  d_10 = __builtin_malloc (_4);
  _5 = __builtin_mempcpy (d_10, s0_7(D), _4);
  MEM[(char *)_5] = 0;
  return d_10;

}



;; Function g (g, funcdef_no=1, decl_uid=1895, cgraph_uid=1, symbol_order=1)

g (const char * s0, const char * s1)
{
  void * d;
  long int s1.4_1;
  long int s0.5_2;
  long int _3;
  long unsigned int _4;
  void * _5;

   [100.00%] [count: INV]:
  s1.4_1 = (long int) s1_6(D);
  s0.5_2 = (long int) s0_7(D);
  _3 = s1.4_1 - s0.5_2;
  _4 = (long unsigned int) _3;
  d_10 = __builtin_alloca (_4);
  _5 = __builtin_mempcpy (d_10, s0_7(D), _4);
  MEM[(char *)_5] = 0;
  sink (d_10);
  return;

}

[Bug middle-end/82867] missing warning on buffer overflow assigning to the result of mempcpy

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82867

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug fortran/82868] New: ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

[gs...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868

Bug ID: 82868
   Summary: ICE in generate_coarray_sym_init, at
fortran/trans-decl.c:5203
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With file ./gcc/testsuite/gfortran.dg/associate_26.f90 :


$ gfortran-8-20171105 -c associate_26.f90 -fcoarray=single
$
$ gfortran-8-20171105 -c associate_26.f90 -fcoarray=lib
associate_26.f90:13:0:

 associate (i => a(1:p, 1:p))

internal compiler error: in generate_coarray_sym_init, at
fortran/trans-decl.c:5203
0x74bcd9 generate_coarray_sym_init
../../gcc/fortran/trans-decl.c:5203
0x71ae0b do_traverse_symtree
../../gcc/fortran/symbol.c:4157
0x74b235 generate_coarray_init
../../gcc/fortran/trans-decl.c:5324
0x74ddd0 gfc_process_block_locals(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6721
0x79b1d0 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:1868
0x72ffd7 trans_code
../../gcc/fortran/trans.c:1924
0x756bfc gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6421
0x6e8b90 translate_all_program_units
../../gcc/fortran/parse.c:6091
0x6e8b90 gfc_parse_file()
../../gcc/fortran/parse.c:6294
0x72d3bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/82748] ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612

[meissner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82748

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Mon Nov  6 18:31:48 2017
New Revision: 254462

URL: https://gcc.gnu.org/viewcvs?rev=254462&root=gcc&view=rev
Log:
[gcc]
2017-11-06  Michael Meissner  

PR target/82748
* config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete
float128 helper macros, which are no longer used after deleting
the old 'q' built-in functions, and moving the round to odd
built-in functions to being special built-in functions.
(BU_FLOAT128_2): Likewise.
(BU_FLOAT128_1_HW): Likewise.
(BU_FLOAT128_2_HW): Likewise.
(BU_FLOAT128_3_HW): Likewise.
(FABSQ): Delete old 'q' built-in functions.
(COPYSIGNQ): Likewise.
(SQRTF128_ODD): Move round to odd built-in functions to be
special built-in functions, so that we can handle
-mabi=ieeelongdouble.
(TRUNCF128_ODD): Likewise.
(ADDF128_ODD): Likewise.
(SUBF128_ODD): Likewise.
(MULF128_ODD): Likewise.
(DIVF128_ODD): Likewise.
(FMAF128_ODD): Likewise.
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q'
built-in names to 'f128'.
* config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the
old 'q' built-in functions, as the machine independent code for
'f128' built-in functions handles this.
(rs6000_expand_builtin): Add expansion for float128 round to odd
functions, keying off on -mabi=ieeelongdouble of whether to use
the KFmode or TFmode variant.
(rs6000_init_builtins): Initialize the _Float128 round to odd
built-in functions.
* doc/extend.texi (PowerPC Built-in Functions): Document the old
_Float128 'q' built-in functions are now mapped into the new
'f128' built-in functions.

[gcc/testsuite]
2017-11-06  Michael Meissner  

PR target/82748
* gcc.target/powerpc/pr82748-1.c: New test.
* gcc.target/powerpc/pr82748-2.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr82748-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr82748-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-builtin.def
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug target/82848] [8 Regression] ICE in expand_expr_real_2, at expr.c:8715

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82848

Bill Schmidt  changed:

   What|Removed |Added

 CC||willschm at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org

--- Comment #2 from Bill Schmidt  ---
CCing Will (fallout from moving this function to gimple expansion).

[Bug fortran/82866] [PDT] ICE in resolve_fl_derived0, at fortran/resolve.c:14004

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-06
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Compiling the tests in comment 0 and 1 with an instrumented gfortran gives

../../work/gcc/fortran/resolve.c:14063:27: runtime error: member access within
null pointer of type 'struct gfc_symbol'

Using the same compiler for the tests in comment 2 gives

==46165==ERROR: AddressSanitizer: heap-use-after-free on address 0x61302800
at pc 0x0001004995e8 bp 0x7fff5fbfe610 sp 0x7fff5fbfe608
READ of size 8 at 0x61302800 thread T0
#0 0x1004995e7 in gfc_restore_last_undo_checkpoint() symbol.c:3647
#1 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#2 0x1002fefd5 in reject_statement() parse.c:2546
#3 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#4 0x10030cdd0 in decode_statement() parse.c:565
#5 0x10030e091 in next_free() parse.c:1225
#6 0x10030ea5e in next_statement() parse.c:1457
#7 0x100314a37 in parse_spec(gfc_statement) parse.c:3651
#8 0x10031d2f0 in parse_module() parse.c:5900
#9 0x10031e24d in gfc_parse_file() parse.c:6205
#10 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#11 0x1052de1b0 in compile_file() toplev.c:454
#12 0x1052e857d in do_compile() toplev.c:2059
#13 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#14 0x1075e2a87 in main main.c:39
#15 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

0x61302800 is located 320 bytes inside of 336-byte region
[0x613026c0,0x61302810)
freed by thread T0 here:
#0 0x155317e10 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x100489adb in gfc_free_symbol(gfc_symbol*) symbol.c:3061
#2 0x100489e27 in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#3 0x10048a2a6 in free_sym_tree(gfc_symtree*) symbol.c:3890
#4 0x10048905b in gfc_free_namespace(gfc_namespace*) symbol.c:4045
#5 0x100489a6c in gfc_free_symbol(gfc_symbol*) symbol.c:3054
#6 0x100489e27 in gfc_release_symbol(gfc_symbol*) symbol.c:3088
#7 0x10049a1c7 in gfc_restore_last_undo_checkpoint() symbol.c:3696
#8 0x10049aa2c in gfc_undo_symbols() symbol.c:3727
#9 0x1002fefd5 in reject_statement() parse.c:2546
#10 0x1002ff11d in match_word(char const*, match (*)(), locus*) parse.c:70
#11 0x10030cdd0 in decode_statement() parse.c:565
#12 0x10030e091 in next_free() parse.c:1225
#13 0x10030ea5e in next_statement() parse.c:1457
#14 0x100314a37 in parse_spec(gfc_statement) parse.c:3651
#15 0x10031d2f0 in parse_module() parse.c:5900
#16 0x10031e24d in gfc_parse_file() parse.c:6205
#17 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#18 0x1052de1b0 in compile_file() toplev.c:454
#19 0x1052e857d in do_compile() toplev.c:2059
#20 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#21 0x1075e2a87 in main main.c:39
#22 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

previously allocated by thread T0 here:
#0 0x15531746c in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x10746b354 in xcalloc xmalloc.c:162
#2 0x100480eb1 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3099
#3 0x1004833c0 in gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) symbol.c:3348
#4 0x100484a01 in gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**)
symbol.c:3401
#5 0x1000b162d in gfc_match_formal_arglist(gfc_symbol*, int, int, bool)
decl.c:5959
#6 0x1000cd42e in gfc_match_derived_decl() decl.c:9829
#7 0x1002ff09b in match_word(char const*, match (*)(), locus*) parse.c:65
#8 0x10030cdd0 in decode_statement() parse.c:565
#9 0x10030e091 in next_free() parse.c:1225
#10 0x10030ea5e in next_statement() parse.c:1457
#11 0x100314a37 in parse_spec(gfc_statement) parse.c:3651
#12 0x10031d2f0 in parse_module() parse.c:5900
#13 0x10031e24d in gfc_parse_file() parse.c:6205
#14 0x1004d36b3 in gfc_be_parse_file() f95-lang.c:204
#15 0x1052de1b0 in compile_file() toplev.c:454
#16 0x1052e857d in do_compile() toplev.c:2059
#17 0x1075dd23b in toplev::main(int, char**) toplev.c:2194
#18 0x1075e2a87 in main main.c:39
#19 0x7fffcb057234 in start (libdyld.dylib:x86_64+0x5234)

SUMMARY: AddressSanitizer: heap-use-after-free symbol.c:3647 in
gfc_restore_last_undo_checkpoint()
Shadow bytes around the buggy address:
  0x1c2604b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2604c0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x1c2604d0: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
  0x1c2604e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c2604f0: fd fd fd fd fd fd fd fd fd fd fd fd fd 

[Bug fortran/82866] [PDT] ICE in resolve_fl_derived0, at fortran/resolve.c:14004

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82866

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> With invalid code similar to pr82586 :
> 
> 
> $ cat z1.f90
> module m
>type t(*)
>end type
> end
> 
> 
> $ /gfortran-8-20171105 -c z1.f90
> f951: internal compiler error: Segmentation fault
> 0xb60fdf crash_signal
> ../../gcc/toplev.c:324
> 0x7056d8 resolve_fl_derived0
> ../../gcc/fortran/resolve.c:14004
> 0x70579b resolve_fl_derived
> ../../gcc/fortran/resolve.c:14075
> 0x70035f resolve_symbol
> ../../gcc/fortran/resolve.c:14434
> 0x71ae0b do_traverse_symtree
> ../../gcc/fortran/symbol.c:4157
> 0x70371a resolve_types
> ../../gcc/fortran/resolve.c:16326
> 0x6ff04c gfc_resolve(gfc_namespace*)
> ../../gcc/fortran/resolve.c:16440
> 0x6e8ee4 gfc_parse_file()
> ../../gcc/fortran/parse.c:6232
> 0x72d3bf gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:204

% svn diff resolve.c 
Index: resolve.c
===
--- resolve.c   (revision 254461)
+++ resolve.c   (working copy)
@@ -14001,13 +14001,19 @@ resolve_fl_derived0 (gfc_symbol *sym)
 {
   for (f = sym->formal; f; f = f->next)
{
- c = gfc_find_component (sym, f->sym->name, true, true, NULL);
- if (c == NULL)
+ if (!f->sym)
{
  gfc_error ("Parameterized type %qs does not have a component "
+"at %L", sym->name, &sym->declared_at);
+ return false;
+   }
+
+ if (!gfc_find_component (sym, f->sym->name, true, true, NULL))
+   {
+ gfc_error ("Parameterized type %qs does not have a component "
 "corresponding to parameter %qs at %L", sym->name,
 f->sym->name, &sym->declared_at);
- break;
+ return false;
}
}
 }

[Bug fortran/82868] ICE in generate_coarray_sym_init, at fortran/trans-decl.c:5203

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-06
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The test has been introduced in revision r253077. Compiling the test
with an older revision gives

Error: Variable 'i' at (1) is a coarray and is not ALLOCATABLE, SAVE nor a
dummy argument

[Bug fortran/82865] Option -fdec collides with PDT

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82865

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-06
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed: never mix f77 extensions with post f90 syntax!-(

[Bug tree-optimization/82816] [8 Regression] ICE on valid code at -Os and above: in find_widening_optab_handler_and_mode, at optabs-query.c:414

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82816

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Patch applied.