[Bug fortran/38573] Missing markers for translation

[fmarchal at perso dot be]

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

--- Comment #13 from Frederic Marchal  ---
(In reply to Roland Illig from comment #12)
> (In reply to Frederic Marchal from comment #11)
> > I suspect a misunderstanding here. Forgive me if I state the obvious.
> > 
> > The fix is not to move the translation mark around.
> 
> I think moving the translation mark "_(...)" into each case of the switch
> statement would solve the problem, so maybe I misunderstood you here.

Ah yes, I see your point. The string literal may be translated with _() when it
is assigned to symstd_msg. It doesn't have to be translated later when
symstd_msg is assigned to symstd.

So moving _() is fine:

  symstd_msg = _("available since Fortran 77");
  if (symstd)
*symstd = symstd_msg;

Sorry, the misunderstanding was on my side. I was stuck with this pattern:

  symstd_msg = N_("available since Fortran 77");
  if (symstd)
*symstd = _(symstd_msg);

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #28 from Xi Ruoyao  ---
Created attachment 41028
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41028=edit
testcase

[Bug c++/80038] Random segfault using local vectors in Cilk function [Regression 6/7]

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #27 from Xi Ruoyao  ---
Created attachment 41027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41027=edit
patch proposal

Now I've prepared a patch.  It reverted r227423 (but preserved its testcase)
and used a more conforming way to resolve pr60586.

It seems this patch fixed Florent's testcase, and NumericMonoid code as well.

I'll run a complete dejaGNU regression test.  If it's OK I'll submit the patch.

[Bug target/79509] m68k/coldfire: Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded

[wbx at openadk dot org]

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

Waldemar Brodkorb  changed:

   What|Removed |Added

 CC||wbx at openadk dot org

--- Comment #2 from Waldemar Brodkorb  ---
Created attachment 41026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41026=edit
asplib ii

[Bug c++/80157] New: Spurious "Wsign-conversion" warning with const, size_t, array.

[ian at geometrian dot com]

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

Bug ID: 80157
   Summary: Spurious "Wsign-conversion" warning with const,
size_t, array.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at geometrian dot com
  Target Milestone: ---

Minimal example (compile GCC >= ~6.1 with -Wsign-conversion):

#include 
bool f(size_t const xy[2], int z) {
return xy[0] + xy[1] < static_cast(z);
}

Produces an erroneous warning:

: In function 'bool f(const size_t*, int)':
:3:25: warning: conversion to 'long unsigned int' from 'int' may
change the sign of the result [-Wsign-conversion]
  return xy[0] + xy[1] < static_cast(z);
 ^~
Compiler exited with result code 0

Taking the const out, using unsigned, or passing x and y separately rather than
as an array resolves the warning.  Doesn't occur on Clang, MSVC, or earlier
GCC.

May be related to bug 66170.

[Bug fortran/38573] Missing markers for translation

[roland.illig at gmx dot de]

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

--- Comment #12 from Roland Illig  ---
(In reply to Frederic Marchal from comment #11)
> I suspect a misunderstanding here. Forgive me if I state the obvious.
> 
> The fix is not to move the translation mark around.

I think moving the translation mark "_(...)" into each case of the switch
statement would solve the problem, so maybe I misunderstood you here.

[Bug tree-optimization/80153] ivopt generate wrong code

[palmer at dabbelt dot com]

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

--- Comment #3 from Palmer Dabbelt  ---
Thanks for looking at this.

If there's anything I can do to help feel free to ask, but from my understand
this isn't a RISC-V backend problem so I'm not going to put this on my TODO
list unless something changes (or someone corrects me).

[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

   Assignee|bergner at gcc dot gnu.org |meissner at gcc dot 
gnu.org

--- Comment #17 from Michael Meissner  ---
While Peter is away, I looked into this.

The bug happens when the RELOAD register allocator tries to do a bswap
operation.  I believe in the original test case, the compiler identifies the
case as something that could be optimized to __builtin_bswap16.  In the second
case, the code has an explicit __builtin_bswap32 call.

This bug shows up on little endian systems and not on big endian systems.  This
is due to the bswap instruction being called with a SUBREG.  Reload gets
confused with this, and LRA decides to do a store, so that it can then do a
LWBRX instruction.

If we copy the SUBREG to a new register, it works for the second case provided.
 I can't get the first case to fail.

[Bug fortran/79838] inconsistent trailing dot in diagnostic "The name %qs has already been used"

[dominiq at gcc dot gnu.org]

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

--- Comment #1 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 22:04:27 2017
New Revision: 246409

URL: https://gcc.gnu.org/viewcvs?rev=246409=gcc=rev
Log:
Also fixed by revision r246391.

2017-03-22  Dominique d'Humieres  

PR fortran/79838
* module.c: Remove trailing period.


Modified:
trunk/gcc/fortran/ChangeLog

[Bug fortran/79838] inconsistent trailing dot in diagnostic "The name %qs has already been used"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Closing.

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 21:52:13 2017
New Revision: 246408

URL: https://gcc.gnu.org/viewcvs?rev=246408=gcc=rev
Log:
PR tree-optimization/80072
* tree-ssa-reassoc.c (struct operand_entry): Change id field type
to unsigned int.
(next_operand_entry_id): Change type to unsigned int.
(sort_by_operand_rank): Make sure to return the right return value
even if unsigned fields are bigger than INT_MAX.
(struct oecount): Change cnt and id type to unsigned int.
(oecount_hasher::equal): Formatting fix.
(oecount_cmp): Make sure to return the right return value
even if unsigned fields are bigger than INT_MAX.
(undistribute_ops_list): Change next_oecount_id type to unsigned int.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug target/79509] m68k/coldfire: Internal error, aborting at dw2gencfi.c:214 in emit_expr_encoded

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-22
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #1 from Jeffrey A. Law  ---
Waldemar,

You don't need to produce a simple testcase, but we do need the preprocessed
sources along with the command line used to trigger the bug.

The easiest way to get the preprocessed sources is to add "-save-temps" switch
to the gcc/g++ invocation that causes the ICE.  That will create a .i (C) or
.ii file (C++) which contains the c-preprocessed output.

Without the CPP output it is unlikely this bug will be addressed.

[Bug fortran/79853] diagnostics: double space in "Assumed or deferred"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Closing.

[Bug fortran/80011] diagnostics: trailing space in "Implicitly declared"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79602] translation: globally replace '%s' with %qs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79844] diagnostics: extra space at end of line

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Closing.

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #7 from Dominique d'Humieres  ---
Closing.

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Confirmed. This a regression which appeared between revisions r245767
> (2017-02-28, compiles) and r246000 (2017-03-09, error),
> likely r245596 (pr79382).
 ^^^obviously wrong!-(

I did not find any obvious candidate in the range.

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-22
 CC||jvdelisle at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
Summary|Generic DTIO interface  |[7 Regression] Generic DTIO
   |reported missing if public  |interface reported missing
   |statement preceeds the  |if public statement
   |interface block |preceeds the interface
   ||block
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. This a regression which appeared between revisions r245767
(2017-02-28, compiles) and r246000 (2017-03-09, error), likely r245596
(pr79382).

[Bug fortran/80156] New: Generic DTIO interface reported missing if public statement preceeds the interface block

[pedsxing at gmx dot net]

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

Bug ID: 80156
   Summary: Generic DTIO interface reported missing if public
statement preceeds the interface block
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pedsxing at gmx dot net
  Target Milestone: ---

Created attachment 41025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41025=edit
Module that fails to compile with gfortran 7.0.1 (r152875)

gfortran 7.0.1 (r152875) fails to compile the attached module that uses derived
type IO. The error message is:

ftlString.F90:10:31:

public :: write(unformatted) ! has to be after the interface block for
gfortran 7 ... compiler bug?
   1
Error: The GENERIC DTIO INTERFACE at (1) is not present in the MODULE
'stringmodule'

Moving the reported line below the definition of the interface block fixes the
problem, but I believe that the order should be irrelevant.

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at gcc dot gnu.org]

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

--- Comment #14 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Wed Mar 22 19:12:24 2017
New Revision: 246406

URL: https://gcc.gnu.org/viewcvs?rev=246406=gcc=rev
Log:
2017-03-12 Nicolas Koenig 

PR fortran/39239
fortran/Changelog:  Add entry for rev. 246284.

Modified:
trunk/gcc/fortran/ChangeLog

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at gcc dot gnu.org]

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

--- Comment #13 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Wed Mar 22 19:08:36 2017
New Revision: 246405

URL: https://gcc.gnu.org/viewcvs?rev=246405=gcc=rev
Log:
2017-03-22 Nicolas Koenig 

PR fortran/39239
* gfortran.dg/equiv_constraint_bind_c.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/equiv_constraint_bind_c.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79864] Implicit type conversion on assignment of unallocated array to unallocated array variable segfaults.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-22
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Following Steve's comment from pr78963

> ssi is unallocated.  It shall not be referenced.  This
> is no a numbered constraint, so a compiler need not issue
> an error.  It is a restriction on the programmer.

this PR is probably also invalid.

[Bug fortran/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to vehre from comment #0)
> The following simple test code:
> 
>   integer, allocatable :: si(:)
>   integer, allocatable :: ssi(:)
> 
>   si = ssi
> end
> 
> is IMHO valid Fortran (2003+ at least), but when run in valgrind will show
> access to unallocated memory. Without valgrind it most of the time executes
> without error.

Why do you think that the above code is valid.  From F2003, p113

An allocatable variable has a status of unallocated if it is
not allocated.  The status of an allocatable variable becomes
unallocated if it is deallocated (6.3.3) or if it is given that
status by the allocation transfer procedure.  An allocatable
variable with this status shall not be referenced or defined.

ssi is unallocated.  It shall not be referenced.  This
is no a numbered constraint, so a compiler need not issue
an error.  It is a restriction on the programmer.

[Bug middle-end/47344] [5/6/7 Regression][meta-bug] GCC gets slower and uses more memory

[jakub at gcc dot gnu.org]

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

Bug 63191 Summary: [5/6 Regression] 32-bit gcc uses excessive memory during 
dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191

   What|Removed |Added

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

[Bug rtl-optimization/63191] [5/6 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
Summary|[5/6/7 Regression] 32-bit   |[5/6 Regression] 32-bit gcc
   |gcc uses excessive memory   |uses excessive memory
   |during dead store   |during dead store
   |elimination with -fPIC  |elimination with -fPIC

--- Comment #17 from Jakub Jelinek  ---
Fixed.  Not planning to backport.

[Bug sanitizer/80110] [6 Regression] error: statement marked for throw, but doesn’t w/ -fsanitize=thread

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] error: |[6 Regression] error:
   |statement marked for throw, |statement marked for throw,
   |but doesn’t w/  |but doesn’t w/
   |-fsanitize=thread   |-fsanitize=thread

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/80129] wrong code with ternary struct assignment to const

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/80141] ICE with pragma omp declare

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/80141] ICE with pragma omp declare

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:53:47 2017
New Revision: 246403

URL: https://gcc.gnu.org/viewcvs?rev=246403=gcc=rev
Log:
PR c++/80141
* semantics.c (finish_omp_clause) : Call maybe_constant_value only when not
processing_template_decl.

* g++.dg/gomp/pr80141.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr80141.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:46:54 2017
New Revision: 246402

URL: https://gcc.gnu.org/viewcvs?rev=246402=gcc=rev
Log:
PR sanitizer/78158
* tsan/tsan_interface_atomic.cc: Cherry-pick upstream r298378.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/tsan/tsan_interface_atomic.cc

[Bug c++/80129] wrong code with ternary struct assignment to const

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:45:48 2017
New Revision: 246401

URL: https://gcc.gnu.org/viewcvs?rev=246401=gcc=rev
Log:
PR c++/80129
* gimplify.c (gimplify_modify_expr_rhs) : Clear
TREE_READONLY on result if writing it more than once.

* g++.dg/torture/pr80129.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr80129.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80110] [6/7 Regression] error: statement marked for throw, but doesn’t w/ -fsanitize=thread

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:35:43 2017
New Revision: 246400

URL: https://gcc.gnu.org/viewcvs?rev=246400=gcc=rev
Log:
PR sanitizer/80110
* doc/invoke.texi (-fsanitize=thread): Document that with
-fnon-call-exceptions atomics are not able to throw
exceptions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug sanitizer/80110] [6/7 Regression] error: statement marked for throw, but doesn’t w/ -fsanitize=thread

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:34:44 2017
New Revision: 246399

URL: https://gcc.gnu.org/viewcvs?rev=246399=gcc=rev
Log:
PR sanitizer/80110
* tsan.c: Include tree-eh.h.
(instrument_builtin_call): Call maybe_clean_eh_stmt or
maybe_clean_or_replace_eh_stmt where needed.
(instrument_memory_accesses): Add cfg_changed argument.
Call gimple_purge_dead_eh_edges on each block and set *cfg_changed
if it returned true.
(tsan_pass): Adjust caller.  Return TODO_cleanup_cfg if cfg_changed.

* g++.dg/tsan/pr80110.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tsan/pr80110.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tsan.c

[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar 22 18:33:37 2017
New Revision: 246398

URL: https://gcc.gnu.org/viewcvs?rev=246398=gcc=rev
Log:
PR rtl-optimization/63191
* config/i386/i386.c (ix86_delegitimize_address): Turn into small
wrapper function, moved the whole old content into ...
(ix86_delegitimize_address_1): ... this.  New inline function.
(ix86_find_base_term): Use ix86_delegitimize_address_1 with
true as last argument instead of ix86_delegitimize_address.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug target/80088] ICE: declaration and definition of function with __attribute__((target("thumb"))) and inlined assembler, with debug symbols enabled

[wojtek.golf at interia dot pl]

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

--- Comment #2 from Wojciech Migda  ---
It might be that this is Linaro-only bug. Please do what you feel is best.

[Bug target/80123] libgomp tests pr66199-2.c and pr66199-5.c fail with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Wed Mar 22 17:47:55 2017
New Revision: 246394

URL: https://gcc.gnu.org/viewcvs?rev=246394=gcc=rev
Log:
2017-03-21  Aaron Sawdey  

PR target/80123
* doc/md.texi (Constraints): Document wA constraint.
* config/rs6000/constraints.md (wA): New.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Add wA reg_class.
(rs6000_init_hard_regno_mode_ok): Init wA constraint.
* config/rs6000/rs6000.h (RS6000_CONSTRAINT_wA): New.
* config/rs6000/vsx.md (vsx_splat_): Use wA constraint.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/constraints.md
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.h
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/doc/md.texi

[Bug target/80123] libgomp tests pr66199-2.c and pr66199-5.c fail with -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Fixed in 246394.

[Bug target/80088] ICE: declaration and definition of function with __attribute__((target("thumb"))) and inlined assembler, with debug symbols enabled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I can't reproduce with gcc 5 x86_64-linux -> armv7hl-linux-gnu cross (target
attribute isn't supported on arm, does Ubuntu have some backports thereof?)
Even in the current gcc-5-branch I see only i386, rs6000 and nios2 ports with
target attrbute support.

And on the trunk, again using a cross-compiler, I don't get ICE either (though
the attribute is supported there also on aarch64, arm and s390 in addition to
the above 3).

So, is there any upstream gcc you can reproduce it on?  If not, file it with
ubuntu.

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
Hmm, for tree affine:
(gdb) call debug_aff()
{
  type = unsigned int
  offset = 6
  elements = {
[0] = "oops!\n" * 1,
[1] = ivtmp.37_10 * 0x
  }
}

aff_combination_to_tree returns a pointer_plus expression with chanr * type:

(gdb) call debug_generic_expr(arg)
"oops!\n" + (6 - (sizetype) ivtmp.37_10)

(gdb) call debug_tree(arg)
 
BLK
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x76ce5dc8 domain

pointer_to_this >
public unsigned SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x76ce5e70>

arg 0 
readonly constant
arg 0 
readonly constant static "oops!\012\000">>
arg 1  unit size 
align 32 symtab 0 alias set -1 canonical type 0x76c32000
precision 32 min  max >

arg 0 
arg 1 

arg 0 
var 
def_stmt ivtmp.37_10 = PHI 
version 10

But, it really should be:
(unsigned int)"oops!\n" + (6 - (sizetype) ivtmp.37_10)

So, when the expression should be ZERO, GCC proves "oops!\n" + (6 - (sizetype)
ivtmp.37_10) can never be ZERO based on pointer semantics.

CCing Richard for further comments.
In function add_elt_to_tree, there is:
  if (!expr)
{
  if (POINTER_TYPE_P (TREE_TYPE (elt)))
return elt;
  else
return fold_convert (type1, elt);
}
which means we return pointer type expr even it is requested to generate
unsigned type expr.

[Bug lto/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
It is actually the *-lib.c files that should be -fno-lto.
But it seems all the source files are compiled/linked using one driver
invocation, so I have no idea how to do -fno-lto just for one file.

[Bug lto/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

[jakub at gcc dot gnu.org]

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

--- Comment #31 from Jakub Jelinek  ---
So, is there a way to request -fno-lto compilation of the
gcc.c-torture/execute/builtins/lib/*.c TUs?  The rest probably can stay -flto
when testing lto.

[Bug fortran/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-22
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.3.1 up to trunk (7.0). Compiling the test with
-fsanitize=address gives at run time

ASAN:DEADLYSIGNAL
=
==66411==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00010f411c16 bp 0x7fff507ee360 sp 0x7fff507ee220 T0)
==66411==The signal is caused by a READ memory access.
==66411==Hint: address points to the zero page.
#0 0x10f411c15 in MAIN__
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10c15)
#1 0x10f411d8e in main
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10d8e)
#2 0x7fffe1349254 in start (/usr/lib/system/libdyld.dylib+0x5254)

Note that I didn't find any explicit rule saying the code is invalid, I suspect
it is based on the forbidden use of unallocated variable.

[Bug tree-optimization/80153] ivopt generate wrong code

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-22
 CC||amker at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from amker at gcc dot gnu.org ---
I can reproduce the issue on AArch64 if specific candidate is chosen. 
Something is wrong, I will investigate it.

[Bug middle-end/80152] Not warning anymore about usage of uninitialized variables

[slomo at coaxion dot net]

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

--- Comment #5 from Sebastian Dröge  ---
Because the value of uninitialized variables is implementation-defined, and as
such gcc can freely set it to anything that it wants? That would explain it
then, yes. Thanks

[Bug middle-end/80152] Not warning anymore about usage of uninitialized variables

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
(In reply to Sebastian Dröge from comment #3)
> But even after optimization, there would be the argc!=1 code path left,
> which uses the uninitialized foo.

No, the optimization sets foo to 1 always, and argc is not tested anymore.

[Bug c++/80141] ICE with pragma omp declare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41024=edit
gcc7-pr80141.patch

Untested fix.

[Bug fortran/79853] diagnostics: double space in "Assumed or deferred"

[dominiq at gcc dot gnu.org]

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

--- Comment #3 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 16:29:30 2017
New Revision: 246391

URL: https://gcc.gnu.org/viewcvs?rev=246391=gcc=rev
Log:
2017-03-22  Dominique d'Humieres  

PR fortran/79602
* decl.c: Replace '%s' with %qs.
* expr.c: Likewise.
* interface.c: Likewise.
* match.c: Likewise.
* primary.c: Likewise.
* resolve.c: Likewise.

PR fortran/79844
PR fortran/80011
* io.c: Remove trailing spaces.
* match.c: Likewise.
* openmp.c: Likewise.
* resolve.c: Likewise.
* trans-intrinsic.c: Likewise.

PR fortran/79853
* expr.c: Remove a double spaces.

PR fortran/79859
* primary.c: Remove spurious quotes around %qs.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 16:29:30 2017
New Revision: 246391

URL: https://gcc.gnu.org/viewcvs?rev=246391=gcc=rev
Log:
2017-03-22  Dominique d'Humieres  

PR fortran/79602
* decl.c: Replace '%s' with %qs.
* expr.c: Likewise.
* interface.c: Likewise.
* match.c: Likewise.
* primary.c: Likewise.
* resolve.c: Likewise.

PR fortran/79844
PR fortran/80011
* io.c: Remove trailing spaces.
* match.c: Likewise.
* openmp.c: Likewise.
* resolve.c: Likewise.
* trans-intrinsic.c: Likewise.

PR fortran/79853
* expr.c: Remove a double spaces.

PR fortran/79859
* primary.c: Remove spurious quotes around %qs.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/79844] diagnostics: extra space at end of line

[dominiq at gcc dot gnu.org]

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

--- Comment #3 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 16:29:30 2017
New Revision: 246391

URL: https://gcc.gnu.org/viewcvs?rev=246391=gcc=rev
Log:
2017-03-22  Dominique d'Humieres  

PR fortran/79602
* decl.c: Replace '%s' with %qs.
* expr.c: Likewise.
* interface.c: Likewise.
* match.c: Likewise.
* primary.c: Likewise.
* resolve.c: Likewise.

PR fortran/79844
PR fortran/80011
* io.c: Remove trailing spaces.
* match.c: Likewise.
* openmp.c: Likewise.
* resolve.c: Likewise.
* trans-intrinsic.c: Likewise.

PR fortran/79853
* expr.c: Remove a double spaces.

PR fortran/79859
* primary.c: Remove spurious quotes around %qs.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/80011] diagnostics: trailing space in "Implicitly declared"

[dominiq at gcc dot gnu.org]

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

--- Comment #2 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 16:29:30 2017
New Revision: 246391

URL: https://gcc.gnu.org/viewcvs?rev=246391=gcc=rev
Log:
2017-03-22  Dominique d'Humieres  

PR fortran/79602
* decl.c: Replace '%s' with %qs.
* expr.c: Likewise.
* interface.c: Likewise.
* match.c: Likewise.
* primary.c: Likewise.
* resolve.c: Likewise.

PR fortran/79844
PR fortran/80011
* io.c: Remove trailing spaces.
* match.c: Likewise.
* openmp.c: Likewise.
* resolve.c: Likewise.
* trans-intrinsic.c: Likewise.

PR fortran/79853
* expr.c: Remove a double spaces.

PR fortran/79859
* primary.c: Remove spurious quotes around %qs.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/79602] translation: globally replace '%s' with %qs

[dominiq at gcc dot gnu.org]

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

--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Mar 22 16:29:30 2017
New Revision: 246391

URL: https://gcc.gnu.org/viewcvs?rev=246391=gcc=rev
Log:
2017-03-22  Dominique d'Humieres  

PR fortran/79602
* decl.c: Replace '%s' with %qs.
* expr.c: Likewise.
* interface.c: Likewise.
* match.c: Likewise.
* primary.c: Likewise.
* resolve.c: Likewise.

PR fortran/79844
PR fortran/80011
* io.c: Remove trailing spaces.
* match.c: Likewise.
* openmp.c: Likewise.
* resolve.c: Likewise.
* trans-intrinsic.c: Likewise.

PR fortran/79853
* expr.c: Remove a double spaces.

PR fortran/79859
* primary.c: Remove spurious quotes around %qs.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/io.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/openmp.c
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-intrinsic.c

[Bug fortran/71796] Link error referencing compiler generated symbol __vtab_xxx

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|dominiq at lps dot ens.fr  |unassigned at gcc dot 
gnu.org

--- Comment #5 from Dominique d'Humieres  ---
No help, thus unassigned myself!-(

[Bug fortran/80011] diagnostics: trailing space in "Implicitly declared"

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Patch posted at https://gcc.gnu.org/ml/fortran/2017-03/msg00086.html.

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Patch posted at https://gcc.gnu.org/ml/fortran/2017-03/msg00086.html.

[Bug fortran/79844] diagnostics: extra space at end of line

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Patch posted at https://gcc.gnu.org/ml/fortran/2017-03/msg00086.html.

[Bug fortran/79853] diagnostics: double space in "Assumed or deferred"

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
Patch posted at https://gcc.gnu.org/ml/fortran/2017-03/msg00086.html.

[Bug fortran/79602] translation: globally replace '%s' with %qs

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Patch posted at https://gcc.gnu.org/ml/fortran/2017-03/msg00086.html.

[Bug target/80154] sizeof(long double) == 16 even with -mlong-double-80

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Storing into 10 bytes is not possible.  For 80bit precision, only 96 or 128 bit
as the storage unit is available.

[Bug target/80154] sizeof(long double) == 16 even with -mlong-double-80

[daniel.gutson at intel dot com]

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

--- Comment #3 from Daniel Gutson  ---
Documentation is confusing:
  -m96bit-long-double
  -m128bit-long-double
   These switches control the size of "long double" type. 

...
   -mlong-double-64
   -mlong-double-80
   -mlong-double-128
   These switches control the size of "long double" type. 


Note that both option families are referred the same in the man page (didn't
check the manual).

None of these options refer to storage.

I guess what I would need is something like -m80bit-long-double. Anyway I
suggest to clarify the differences of these two families of options, and if at
ever possible, add new ones with more distinct names turning the existing ones
obsolete for future versions.

In short, please confirm that requiring gcc to store 80-bits precision floating
point types into 10 bytes is not possible.
Thanks.

[Bug target/79804] ICE in print_reg, at config/i386/i386.c:17637

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|inline-asm  |target
   Target Milestone|--- |7.0

[Bug inline-asm/79804] ICE in print_reg, at config/i386/i386.c:17637

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #3 from Uroš Bizjak  ---
Created attachment 41023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41023=edit
Proposed patch

Patch in testing.

[Bug target/80154] sizeof(long double) == 16 even with -mlong-double-80

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
You are misunderstanding what this option does.
-mlong-double-64
-mlong-double-80
-mlong-double-128

80 here means the precision (80bit vs 128bit IEEE) and not storage unit.
You want:
-m96bit-long-double
for that.

[Bug c/80154] sizeof(long double) == 16 even with -mlong-double-80

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Not being i386 target expect, however this tells that it should be 12B on IA-32
and 16B on x86_64 target:

https://software.intel.com/en-us/node/693859

$ gcc pr80154.c -mlong-double-80 && ./a.out 
sizeof(long double): 16
sizeof(__float80): 16

$ gcc pr80154.c -mlong-double-80 -m32 && ./a.out 
sizeof(long double): 12
sizeof(__float80): 12

[Bug fortran/80142] [7 Regression] Warning: No location in expression ... with -O / -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC|thopre01 at gcc dot gnu.org|

--- Comment #13 from Thomas Preud'homme  ---
Ack, thanks Richard. Opened PR80155

[Bug tree-optimization/80155] New: [7 regression] Performance regression with code hoisting enabled

[thopre01 at gcc dot gnu.org]

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

Bug ID: 80155
   Summary: [7 regression] Performance regression with code
hoisting enabled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: avieira at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Created attachment 41022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41022=edit
Reproducers for Cortex-M0+ and Cortex-M7

Hi,

Performance of a popular embedded benchmark regress in GCC 7 at -O2
optimization level on arm-none-eabi targets (at least on Cortex-M0+ or
Cortex-M7). They key to trigger it is to have -fcode-hoisting enabled. If
disabled, performance is improved.

Attached to this bug report are reduced testcase for Cortex-M0+ and Cortex-M7.
Compile respectively with:

arm-none-eabi-gcc -S -O2 -mcpu=cortex-m0plus
arm-none-eabi-gcc -S -O2 -mcpu=cortex-m7

and compare to the same command line with the extra -fno-code-hoisting option
added to see the amount of register push decrease.

[Bug fortran/80142] [7 Regression] Warning: No location in expression ... with -O / -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 22 15:20:17 2017
New Revision: 246388

URL: https://gcc.gnu.org/viewcvs?rev=246388=gcc=rev
Log:
2017-03-22  Thomas Koenig  

PR fortran/80142
* frontend-passes.c (combine_array_constructor): Take
location of new expression from constructor expression instead
of constructor.

2017-03-22  Thomas Koenig  

PR fortran/80142
* gfortran.dg/any_loc.f90: New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/any_loc.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80152] Not warning anymore about usage of uninitialized variables

[slomo at coaxion dot net]

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

--- Comment #3 from Sebastian Dröge  ---
But even after optimization, there would be the argc!=1 code path left, which
uses the uninitialized foo.

[Bug c/80154] New: sizeof(long double) == 16 even with -mlong-double-80

[daniel.gutson at intel dot com]

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

Bug ID: 80154
   Summary: sizeof(long double) == 16 even with -mlong-double-80
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at intel dot com
  Target Milestone: ---

On a x86_64 linux machine, both sizeof(long double) and sizeof(__float80)
return 16, despite specifying -mlong-double-80 (x86 gcc). 
Other options that did not change the result: 
-std=c99 (despite -m is backend), 
-msoft-float

[Bug tree-optimization/80153] New: ivopt generate wrong code

[npickito at gmail dot com]

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

Bug ID: 80153
   Summary: ivopt generate wrong code
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npickito at gmail dot com
CC: amker.cheng at gmail dot com, andrew at sifive dot com,
palmer at dabbelt dot com
  Target Milestone: ---
Target: riscv32-unknown-elf

Created attachment 41021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41021=edit
test.c

GCC configure: --target=riscv32-elf

What's happen:

IVOPT seen optimize induction variable into wrong thins and then make program
became a infinite loop. 

How to reproduce:

riscv32-elf-gcc test.c -Os


Before ivopt (test.c.161t.cunroll):

main ()
{
  int c;
  int i;
  unsigned int ivtmp_1;
  char _2;
  const char * _4;
  char _5;
  int _6;
  _Bool _7;
  int _8;
  unsigned int ivtmp_9;
  unsigned int i.13_11;

   [15.00%]:
  _fputs ("oops!\n");
  goto ; [100.00%]

   [85.00%]:
  _2 = _fgetc ();
  c_17 = (int) _2;
  _4 = "oops!\n" + i.13_11;
  _5 = *_4;
  _6 = (int) _5;
  _7 = _2 == _5;
  _8 = (int) _7;
  check (c_17, _6, _8);
  i_19 = i_12 + 1;

   [100.00%]:
  # i_12 = PHI <0(2), i_19(3)>
  # ivtmp_9 = PHI <7(2), ivtmp_1(3)>
  i.13_11 = (unsigned int) i_12;
  ivtmp_1 = ivtmp_9 - 1;
  if (ivtmp_1 != 0)
goto ; [85.00%]
  else
goto ; [15.00%]

   [15.00%]:
  return 0;

}

After ivopt (test.c.164t.ivopts):

main ()
{
...
   [85.00%]:
  _2 = _fgetc ();
  c_17 = (int) _2;
  _24 = (void *) ivtmp.37_10;
  _5 = MEM[base: _24, offset: 0B];
  _6 = (int) _5;
  _7 = _2 == _5;
  _8 = (int) _7;
  check (c_17, _6, _8);
  ivtmp.37_3 = ivtmp.37_10 + 1;

   [100.00%]:
  # ivtmp.37_10 = PHI 
  _21 = 6 - ivtmp.37_10;
  _22 = "oops!\n" + _21;* IVOPT optimize i to to this
  _23 = (unsigned int) _22; * and just cast pointer to unsigned int
  if (_23 != 0) * and compare to 0
goto ; [85.00%]
  else
goto ; [15.00%]

   [15.00%]:
  return 0;

}

And then forwprop optimize to infinite loop (test.c.185t.forwprop4):
...
;; Function main (main, funcdef_no=3, decl_uid=1434, cgraph_uid=3,
symbol_order=7) (executed once)

  Replaced '_22 != 0B' with '1'
Removing basic block 5
Merging blocks 4 and 3
main ()
...
   [100.00%]:
  # ivtmp.37_10 = PHI 
  _21 = 6 - ivtmp.37_10;
  _22 = "oops!\n" + _21;
  _23 = (unsigned int) _22;
  _2 = _fgetc ();
  c_17 = (int) _2;
  _24 = (void *) ivtmp.37_10;
  _5 = MEM[base: _24, offset: 0B];
  _6 = (int) _5;
  _7 = _2 == _5;
  _8 = (int) _7;
  check (c_17, _6, _8);
  ivtmp.37_3 = ivtmp.37_10 + 1;
  goto ; [100.00%]

[Bug c++/79604] attribute noreturn inconsistent between C and C++, undocumented for function pointers

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Another inconsistency is that when the noreturn attributes decorates a function
parameter that is a pointer to a function, C considers it to be a part of the
function's type while C++ does not.  That means that some otherwise valid code
that's accepted in C++ is rejected in C.

$ (set -x && cat z.c && for lang in c c++; do gcc -S -Wall -Wunused -Wpedantic
-x$lang z.c; done)
+ cat z.c
int f_ptr_noreturn (void (*fp)(void) __attribute__((noreturn)));

int f_ptr_noreturn (void (*fp)(void))
{
  fp (); 
}
+ for lang in c c++
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -S -Wall -Wunused
-Wpedantic -xc z.c
z.c:3:5: error: conflicting types for ‘f_ptr_noreturn’
 int f_ptr_noreturn (void (*fp)(void))
 ^~
z.c:1:5: note: previous declaration of ‘f_ptr_noreturn’ was here
 int f_ptr_noreturn (void (*fp)(void) __attribute__((noreturn)));
 ^~
z.c: In function ‘f_ptr_noreturn’:
z.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
+ for lang in c c++
+ /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -S -Wall -Wunused
-Wpedantic -xc++ z.c
z.c: In function ‘int f_ptr_noreturn(void (*)())’:
z.c:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Wed Mar 22 14:59:44 2017
New Revision: 246387

URL: https://gcc.gnu.org/viewcvs?rev=246387=gcc=rev
Log:
Backport r245647

2017-03-22  Martin Liska  

Backport from mainline
2017-02-22  Martin Liska  

PR lto/79587
* data-streamer-in.c (streamer_read_gcov_count): Remove assert.
* data-streamer-out.c (streamer_write_gcov_count_stream):
Likewise.
* value-prof.c (stream_out_histogram_value): Make assert more
precise based on type of counter.
2017-03-22  Martin Liska  

Backport from mainline
2017-02-22  Martin Liska  

PR lto/79587
* gcc.dg/tree-prof/pr79587.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/tree-prof/pr79587.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/data-streamer-in.c
branches/gcc-5-branch/gcc/data-streamer-out.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/value-prof.c

[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Liška  ---
Fixed on both active branches.

[Bug fortran/80046] [5/6/7 Regression] Explicit interface required for at (1): pointer argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-22
 CC||janus at gcc dot gnu.org
  Known to work||4.8.5
Summary|Explicit interface required |[5/6/7 Regression] Explicit
   |for  at (1): pointer|interface required for  at
   |argument|(1): pointer argument
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0, 7.0

--- Comment #1 from Dominique d'Humieres  ---
The code compiles with gfortran 4.8.5. The change occurred between revisions
r197920 (2013-04-12, compiles) and r197969 (2013-04-15, error), likely r197922:
the error occurs in gcc/fortran/expr.c.

Note that the errors has been introduced in order to satisfy F08:7.2.2.4

4 If the characteristics of the pointer object or the pointer target are such
  that an explicit interface is required, both the pointer object and
  the pointer target shall have an explicit interface.

Note that the code compiles if I replace

  procedure(), pointer :: cloneProc => null()

with

  procedure(NodeCloner), pointer :: cloneProc => null()

So I wonder if the test in comment 0 is a valid F08 code.

[Bug tree-optimization/18501] [5/6/7 Regression] Missing 'used uninitialized' warning (CCP)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||slomo at coaxion dot net

--- Comment #78 from Richard Biener  ---
*** Bug 80152 has been marked as a duplicate of this bug. ***

[Bug fortran/80142] [7 Regression] Warning: No location in expression ... with -O / -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #2 from Thomas Koenig  ---
Mine.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[rguenth at gcc dot gnu.org]

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

Bug 80152 Summary: Not warning anymore about usage of uninitialized variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80152

   What|Removed |Added

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

[Bug middle-end/80152] Not warning anymore about usage of uninitialized variables

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Dup.

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

[Bug middle-end/80152] Not warning anymore about usage of uninitialized variables

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||24639

--- Comment #1 from Richard Biener  ---
I think this is a commonly reported bug, conditional constant propagation
optimizes away the conditional uninitialized use (substituting 1 for foo)
and thus there is nothing to warn about left.  The warning code before
any optimization happened does not warn about conditional uninitializations
because of too many false positives.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/80152] New: Not warning anymore about usage of uninitialized variables

[slomo at coaxion dot net]

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

Bug ID: 80152
   Summary: Not warning anymore about usage of uninitialized
variables
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slomo at coaxion dot net
  Target Milestone: ---

See below simple testcase

#include 

int main(int argc, char ** argv)
{
  int foo;

  if (argc == 1) {
foo = 1;
  }

  foo += 1;

  printf("%d\n", foo);

  return 0;
}

foo is only initialized if argc==1, but gcc does not warn about the increment
of it or the usage as a printf() argument. This is with gcc 6.3.0, but the same
happens with 5.4.1 and 7.0.1.

I'm quite sure that in the past gcc warned about such cases and even more
complicated ones, and clang still does. There were false positives sometimes,
but those are less of a problem (just initialize the variable needlessly then)
than actual undetected usage of uninitialized variables.


Might be related to bug #78370, but the explanation there does not work here.
Before usage of foo no other function is called (and the explanation in that
bug seems rather far-fetched: while that would certainly be possible, whoever
writes such code will also be able to handle a wrong compiler warning... while
having that warning prevents mistakes in normal code).

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.3.0
 Resolution|--- |FIXED
  Known to fail|6.3.0   |

--- Comment #14 from Martin Liška  ---
Fixed on trunk add gcc 6 branch.

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Wed Mar 22 14:32:42 2017
New Revision: 246385

URL: https://gcc.gnu.org/viewcvs?rev=246385=gcc=rev
Log:
Backport r246119

2017-03-22  Martin Liska  

Backport from mainline
2017-03-14  Martin Liska  

PR lto/66295
* multiple_target.c (expand_target_clones): Drop local.local
flag for default implementation.
2017-03-22  Martin Liska  

Backport from mainline
2017-03-14  Martin Liska  

PR lto/66295
* gcc.dg/tree-prof/pr66295.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/multiple_target.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/79587] ICE in streamer_write_gcov_count_stream, at data-streamer-out.c:343 while building Python 3.6.0 with PGO and LTO

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
Author: marxin
Date: Wed Mar 22 14:32:24 2017
New Revision: 246384

URL: https://gcc.gnu.org/viewcvs?rev=246384=gcc=rev
Log:
Backport r245647

2017-03-22  Martin Liska  

Backport from mainline
2017-02-22  Martin Liska  

PR lto/79587
* data-streamer-in.c (streamer_read_gcov_count): Remove assert.
* data-streamer-out.c (streamer_write_gcov_count_stream):
Likewise.
* value-prof.c (stream_out_histogram_value): Make assert more
precise based on type of counter.
2017-03-22  Martin Liska  

Backport from mainline
2017-02-22  Martin Liska  

PR lto/79587
* gcc.dg/tree-prof/pr79587.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/tree-prof/pr79587.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/data-streamer-in.c
branches/gcc-6-branch/gcc/data-streamer-out.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/value-prof.c

[Bug lto/66295] [5/6/7 Regression] LTO generates incorrect resolver call for function multiversioning

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Author: marxin
Date: Wed Mar 22 14:31:55 2017
New Revision: 246383

URL: https://gcc.gnu.org/viewcvs?rev=246383=gcc=rev
Log:
Backport r245155

2017-03-22  Martin Liska  

Backport from mainline
2017-02-03  Martin Liska  

PR lto/66295
* multiple_target.c (create_dispatcher_calls): Redirect edge
from a caller of a dispatcher.
(expand_target_clones): Make the clones local.
(ipa_target_clone): Do both target clones and resolvers.
(ipa_dispatcher_calls): Remove the pass.
(pass_dispatcher_calls::gate): Likewise.
(make_pass_dispatcher_calls): Likewise.
* passes.def (pass_target_clone): Put as very first IPA early
pass.
2017-03-22  Martin Liska  

Backport from mainline
2017-02-03  Martin Liska  

PR lto/66295
* gcc.target/i386/mvc9.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/mvc9.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/multiple_target.c
branches/gcc-6-branch/gcc/passes.def
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug go/80128] [7 regression] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:2002

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #8 from Ian Lance Taylor  ---
Thanks for testing.  Should be fixed now.

[Bug target/80148] operand has impossible constraints

[dvyukov at google dot com]

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

--- Comment #3 from Dmitry Vyukov  ---
> Why doesn't the kernel use atomic builtins instead?

There was a recent discussion here:
https://groups.google.com/forum/#!topic/kasan-dev/3sNHjjb4GCI

In short:
---
Trivially, The C++ model doesn't feature I/O ordering [1]...
+
https://lwn.net/Articles/691295/
+
rmb()/wmb() are not remotely similar to
atomic_thread_fenc_{acquire,release}, even if you restrict ordering to
coherent CPUs (i.e. the smp_* variants). Please don't do that :)
+
I'm also terrified of the optimisations that the compiler is theoretically
allowed to make to C11 atomics given the assumptions of the language
virtual machine, which are not necessarily valid in the kernel environment.
We would at least need well-supported compiler options to disable these
options, and also to allow data races with things like READ_ONCE.

[Bug fortran/80121] Memory leak when allocating a component derived type in a recursive subroutine (gfortran)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-22
 Blocks||68800
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> All releases I have (4.5.0) do leak memory.

Present also in 4.3.1.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800
[Bug 68800] Fortran FE produces many memory leaks

[Bug target/80148] operand has impossible constraints

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
With just -m32 slub1.c -O2 -mpreferred-stack-boundary=2 -march=i686 this
started with r246059.  Why doesn't the kernel use atomic builtins instead?
The asm uses %eax/%ebx/%ecx/%edx and needs to use up to 2 other registers to
hold the addresses of mems (unless any of them can be sp relative), if %ebp is
used for frame pointer then there are no other registers left, but it still
ought to be reloadable.

[Bug c++/80029] [6/7 Regression] valgrind error in new_omp_context(omp_region_type) (gimplify.c:400)

[cesar at gcc dot gnu.org]

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

cesar at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from cesar at gcc dot gnu.org ---
Fixed in trunk.

[Bug go/80128] [7 regression] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:2002

[ian at gcc dot gnu.org]

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

--- Comment #7 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Mar 22 13:59:01 2017
New Revision: 246382

URL: https://gcc.gnu.org/viewcvs?rev=246382=gcc=rev
Log:
PR go/80128
compiler: check backend alignment for memequalNN functions

The code was assuming the usual required alignment for the memequalNN
functions (16 bits for int16, 32 for int32, etc.). However, on m68k
the required alignment of int32 is only 16 bits. Assuming the
memequalNN alignment caused the compiler to incorrectly decide that
int32 required a specially generated function rather than calling
memequal32. This then crashed if the type descriptor were generated
after type-specific functions had been written.

Fixes GCC PR 80128.

Reviewed-on: https://go-review.googlesource.com/38433

Modified:
trunk/gcc/go/gofrontend/types.cc
trunk/gcc/go/gofrontend/types.h

[Bug c++/80150] [6/7 Regression] Internal compiler error when in in try_one_overload, at cp/pt.c:18903

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Target Milestone|--- |6.4
Summary|Internal compiler error |[6/7 Regression] Internal
   |when in in  |compiler error when in in
   |try_one_overload, at|try_one_overload, at
   |cp/pt.c:18903   |cp/pt.c:18903

[Bug c++/80029] [6/7 Regression] valgrind error in new_omp_context(omp_region_type) (gimplify.c:400)

[cesar at gcc dot gnu.org]

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

--- Comment #4 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Wed Mar 22 13:52:10 2017
New Revision: 246381

URL: https://gcc.gnu.org/viewcvs?rev=246381=gcc=rev
Log:
PR c++/80029

gcc/
* gimplify.c (is_oacc_declared): New function.
(oacc_default_clause): Use it to set default flags for acc declared
variables inside parallel regions.
(gimplify_scan_omp_clauses): Strip firstprivate pointers for acc
declared variables.
(gimplify_oacc_declare): Gimplify the declare clauses.  Add the
declare attribute to any decl as necessary.

libgomp/
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/declare-vla.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/libgomp/ChangeLog

[Bug go/80128] [7 regression] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:2002

[sch...@linux-m68k.org]

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

--- Comment #6 from Andreas Schwab  ---
Works with a cross compiler.

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Comment on attachment 41020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41020
gcc7-pr80072.patch

Looks good.

[Bug tree-optimization/80136] [7 Regression] ICE in gimplify_modify_expr, at gimplify.c:5627

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
Jakub, thanks for the confirmation that force_gimple_operand is unnecessary. 
Christophe, thanks for testing.  Thus I am now regstrapping:

Index: gcc/testsuite/gcc.dg/torture/pr79908.c   
===
--- gcc/testsuite/gcc.dg/torture/pr79908.c  (revision 246334)   
+++ gcc/testsuite/gcc.dg/torture/pr79908.c  (working copy)  
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+   
+/* Used to fail in the stdarg pass before fix for PR79908.  */ 
+   
+typedef __builtin_va_list __gnuc_va_list;  
+typedef __gnuc_va_list va_list;
+   
+void testva (int n, ...)   
+{  
+  va_list ap;  
+  _Complex int i = __builtin_va_arg (ap, _Complex int);
+}  
Index: gcc/tree-stdarg.c
===
--- gcc/tree-stdarg.c   (revision 246334)   
+++ gcc/tree-stdarg.c   (working copy)  
@@ -1058,7 +1058,7 @@ expand_ifn_va_arg_1 (function *fun)
gimplify_assign (lhs, expr, );  
  } 
else
- gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);  
+ gimplify_and_add (expr, );

input_location = saved_location;
pop_gimplify_context (NULL);

Would appreciate any additional testing from James and Andrew -- thanks!

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[vogt at linux dot vnet.ibm.com]

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

--- Comment #8 from Dominik Vogt  ---
The patch has a performance regression on s390x.

  .L1
lr  %r3,%r1
cs  %r1,%r4,0(%r2)
jne .L1

becomes

  .L1
cs %r1,%r3,0(%r2)
ipm %r4
sra %r4,28
cijne %r4,0,.L1

Although this can be fixed on s390/s390x in a follow-up patch, I cannot really
prove that something similar won't happen on other targets without testing
them.

[Bug tree-optimization/80072] [7 Regression] ICE in gimple_build_assign_1 with -O3 -march=broadwell/skylake-avx512

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 41020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41020=edit
gcc7-pr80072.patch

Full untested patch.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de  ---
On Wed, 22 Mar 2017, thopre01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
> 
> --- Comment #11 from Thomas Preud'homme  ---
> (In reply to Thomas Preud'homme from comment #9)
> > Sadly I could not come up with a minimal testcase so far. What I can see
> > from the code is that tree code hoisting increases the live range of some
> > values which then translates into more spilling in reload.
> > 
> > As an approximation I'm wondering if the maximum distance (computer in
> > number of blocks traversed) from the definition to the use could be used to
> > limit when the optimization is applied when optimizing for speed.
> 
> I finally managed. The bug can be reproduced by building the following for
> arm-none-eabi with -S -O2 -mcpu=cortex-m7 and looking for the push in the
> resulting assembly code.
> 
> fn1() {
>   char *a;
>   char b;
>   for (; *a; a++) {
> if (b)
>   a++;
> fn2();
>   }
> }
> 
> With -O2: r3, r4, r5 and lr and pushed.
> With -O2 -fno-code-hoisting: r4 and lr are pushed only.
> 
> 
> Similarly for -mcpu=cortex-m0plus:
> 
> enum { ENUM1, ENUM2, ENUM3 } a;
> fn1() {
>   char *b;
>   for (; *b && a != ENUM2; b++)
> switch (a) {
>   case ENUM1: a = ENUM3;
> }
> }

But that's not caused by r239414 so please open a new bug for this.
(confirmed with a cross)

Transform:

   [85.00%]:
  # a_14 = PHI 
  if (b_7(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [42.50%]:
  goto ; [100.00%]

   [42.50%]:
  a_8 = a_14 + 1;

   [85.00%]:
  # a_2 = PHI 
  fn2 ();
  a_10 = a_2 + 1;

to

   [85.00%]:
  # a_14 = PHI 
  _4 = a_14 + 1;
  if (b_7(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [42.50%]:
  _3 = _4 + 1;

   [85.00%]:
  # a_2 = PHI 
  # prephitmp_12 = PHI <_4(3), _3(4)>
  fn2 ();

that's because the hoisting (which itself isn't a problem) makes
a_2 + 1 partially redundant over the latch.  We see this issue
in related testcases where PRE can compute a constant for the
first iteration value of expressions and thus inserts IVs for
them.  So it's nothing new and a fix would hopefully fix those
cases as well.