[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-21
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
-mpower9-minmax enables VSX support, and we end up with carnage (during
expand already).  No big surprise when targeting 405.

[Bug target/80107] ICE in final_scan_insn, at final.c:2964

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-21
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
float2_internal uses gen_extendhidi2 on a VSX
register here, but extendhidi2 only supports GPRs if CBE ucode insns
are disabled.

[Bug target/80103] ICE in output_1144, at config/rs6000/vsx.md:2298

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-21
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed.  vsx_extract_ does not support Power9 with direct move
disabled.
This isn't a sensible combination, we should not allow it.

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
power6.md defines a bypass:

; define the bypass for the case where the value written
; by a fixed point op is used as the source value on a
; store.
(define_bypass 1 "power6-integer,\
  power6-exts,\
  power6-shift,\
  power6-insert,\
  power6-insert-dword"
 "power6-store,\
  power6-store-update,\
  power6-store-update-indexed,\
  power6-fpstore,\
  power6-fpstore-update"
  "store_data_bypass_p")

where power6-integer is defined as:

(define_insn_reservation "power6-integer" 1
  (and (ior (eq_attr "type" "integer")
(and (eq_attr "type" "add,logical")
 (eq_attr "dot" "no")))
   (eq_attr "cpu" "power6"))
  "FXU_power6")

and the default for "type" is "integer".  The instruction on which we
crash is:

(define_insn "blockage"
  [(unspec_volatile [(const_int 0)] UNSPECV_BLOCK)]
  ""
  "")

(which does not have a SET in it, which however is required by
store_data_bypass_p).

"blockage" should not have type "integer" for this to work.

To fix it more generally, maybe we can teach bypass_p to ignore insns
without outputs?

[Bug target/80101] ICE in store_data_bypass_p, at recog.c:3737

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-21
 Ever confirmed|0   |1

[Bug c++/35878] [LWG 2302] Useless NULL pointer check when constructing object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #9 from Ville Voutilainen  ---
Patch available: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01064.html

[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Author: segher
Date: Mon Mar 20 23:08:16 2017
New Revision: 246297

URL: https://gcc.gnu.org/viewcvs?rev=246297=gcc=rev
Log:
combine: Fix 79910

If the dest of an I0 or I1 is used in an insn before I2, as can happen
in various uncommon cases, and we manage to do the combination, the set
is moved to I2, which is wrong.  Don't allow combining the insns in this
case.


PR rtl-optimization/79910
* combine.c (can_combine_p): Do not allow combining an I0 or I1
if its dest is used by an insn before I2 (other than the combined
insns themselves, which are properly handled already).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Minimal patch submitted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01062.html

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
The initialization of flexible array members is still broken in various ways. 
For some examples, see pr69338, pr69696, and pr69697.

The initialization in flexary11.C is a special case of a general C++ pattern of
initializing a non-static struct with a flexible array member which, for better
or worse, is accepted by GCC is most forms.  For example, all but the last
return statement in the test case below are accepted (though they all generate
wrong code).

I think at this late stage it's safest just to avoid the ICE (see below) defer
until GCC 8 changes to the front end that could cause breakage either in GCC
itself or in other code.

$ cat t.C && gcc -O2 -S -Wall -Wextra -xc++ t.C
int f0 ()
{
  struct A { char n, a[]; };

  return ((struct A){ 1, "123" }).a[0];   // wrong code
}

int f1 ()
{
  struct B { int n; char a[]; };

  return ((struct B){ 1, "123" }).a[0];   // wrong code
}

int f2 ()
{
  struct A { char n, a[]; };

  return ((struct A){ 1, "" }).a[0];   // wrong code
}

int f3 ()
{
  struct B { int n; char a[]; };

  return ((struct B){ 1, "" }).a[0];   // rejected
}

t.C: In function ‘int f3()’:
t.C:26:21: error: invalid use of array with unspecified bounds
   return ((struct B){ 1, "" }).a[0];   // rejected
  ~~~^~
t.C:26:21: error: invalid use of array with unspecified bounds


The following change avoids the ICE by having CHKP give up on checking flexible
array members:

diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index b1ff218..bbaa3a1 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -4092,6 +4092,9 @@ chkp_process_stmt (gimple_stmt_iterator *iter, tree node,
  expression to compute it.  */
   if (!addr_last)
 {
+  if (!size)
+   return;
+
   addr_last = fold_build_pointer_plus_loc (loc, addr_first, size);
   addr_last = fold_build_pointer_plus_hwi_loc (loc, addr_last, -1);
 }

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
Sent a kernel patch to avoid the problem:
http://www.spinics.net/lists/intel-gfx/msg123586.html

[Bug fortran/38573] Missing markers for translation

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
intrinsic.c contains a similar error message:

  if (!gfc_check_intrinsic_standard (isym, , false, loc)
  && !sym->attr.artificial)
{
  if (sym->attr.proc == PROC_UNKNOWN && warn_intrinsics_std)
gfc_warning_now (OPT_Wintrinsics_std, "The intrinsic %qs at %L is not "
 "included in the selected standard but %s and %qs
will"
 " be treated as if declared EXTERNAL.  Use an"
 " appropriate -std=* option or define"
 " -fall-intrinsics to allow this intrinsic.",
 sym->name, , symstd, sym->name);

  return false;

The use of the word 'but' here probably should be the start of a new sentence.
In this example parenthesis were not used to enclose the -std= and the
-fall-intrinsics.

Also in this same source file we have:

  switch (isym->standard)
{
case GFC_STD_F77:
  symstd_msg = "available since Fortran 77";
  break;

case GFC_STD_F95_OBS:
  symstd_msg = "obsolescent in Fortran 95";
  break;

case GFC_STD_F95_DEL:
  symstd_msg = "deleted in Fortran 95";
  break;

case GFC_STD_F95:
  symstd_msg = "new in Fortran 95";
  break;

case GFC_STD_F2003:
  symstd_msg = "new in Fortran 2003";
  break;

case GFC_STD_F2008:
  symstd_msg = "new in Fortran 2008";
  break;

case GFC_STD_F2008_TS:
  symstd_msg = "new in TS 29113/TS 18508";
  break;

case GFC_STD_GNU:
  symstd_msg = "a GNU Fortran extension";
  break;

case GFC_STD_LEGACY:
  symstd_msg = "for backward compatibility";
  break;

default:
  gfc_internal_error ("Invalid standard code on intrinsic %qs (%d)",
  isym->name, isym->standard);
}

 --- snip ---

  /* Otherwise, fail.  */
  if (symstd)
*symstd = _(symstd_msg);
  return false;

Where the mark is on the symstd_msg after it is set to one of the above cases. 
Are you saying this does not work?  Does the translation mark need to be on all
and not in one place?

[Bug fortran/38573] Missing markers for translation

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Frederic Marchal from comment #5)
> This issue is still present in gcc 7.
> 
> The strings assigned to symstd_msg in gfc_check_intrinsic_standard() should
> be marked for translation.
> 
> As it is, the current code in fortran/resolve.c at line 1709 outputs an
> error message containing one untranslated fragment:
> 
>   /* Check it is actually available in the standard settings.  */
>   if (!gfc_check_intrinsic_standard (isym, , false, sym->declared_at))
> {
>   gfc_error ("The intrinsic %qs declared INTRINSIC at %L is not "
>  "available in the current standard settings but %s. Use "
>  "an appropriate %<-std=*%> option or enable "
>  "%<-fall-intrinsics%> in order to use it.",
>  sym->name, >declared_at, symstd);
>   return false;
> }
> 
> I don't know how many languages could work around that string concatenation
> and still present a meaningful message to the user but none can output a
> legible message if %s isn't translated. Therefore, I recommend to mark the
> strings for translation as a stopgap until a full i18n compatible solution
> is available.
> 
> I also suggest to write a comment for translators stating that %s is a
> string such as "available since Fortran 77".

It looks wrong to me here. The "but %s" makes no sense in English. There are
two sentences in the above error message. Do you need the strings split like
this?

   gfc_error ("The procedure %qs declared INTRINSIC at %L is not "
  "available with the current standard setting of %s. "
  "Try a different standard setting option (-std= ) or enable "
  "all intrinsics (-fall-intrinsics).",
  sym->name, >declared_at, symstd);

[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 #1 from acsawdey at gcc dot gnu.org ---
Changing the final constraint of vsx_splat_ from "wr" to "b" allows this
to compile and pass the execution test. 

This isn't really a correct fix as "b" is not NO_REGS if 64-bit instructions
are disabled.

;; V2DF/V2DI splat
(define_insn_and_split "vsx_splat_"
  [(set (match_operand:VSX_D 0 "vsx_register_operand"
"=,,we,")
(vec_duplicate:VSX_D
 (match_operand: 1 "splat_input_operand"
",Z,b, wr")))]

[Bug c++/79519] [5/6 Regression] ICE deleting template friend function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] ICE  |[5/6 Regression] ICE
   |deleting template friend|deleting template friend
   |function|function
  Known to fail|7.0 |

--- Comment #4 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/80096] [7 Regression] [c++1z] ICE with auto template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/68354] -Warray-bounds on a flexible array member in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0
 Blocks||69698
 Resolution|--- |FIXED
  Known to fail||5.3.0, 6.3.0

--- Comment #3 from Martin Sebor  ---
With GCC 7.0 and 6 the -Warray-bounds warning is gone.  With GCC 7 and 5 (but
not 6) the flexible array member is diagnosed with -Wpedantic.

The internal representation of flexible array members has also changed with
r231665: such members have a null domain, which is likely what has eliminated
the  -Warray-bounds warning.

With this, although there still are many outstanding problems with flexible
array members (see the meta-bug 69698), I think this bug can be resolved as
fixed.

$ cat y.c && gcc -O2 -S -Wall -Wextra -Wpedantic -xc++ y.c
struct S {
int n;
int a[];
} s;

int i;

void f ()
{
i = s.a [0];
}
y.c:3:11: warning: ISO C++ forbids flexible array member ‘a’ [-Wpedantic]
 int a[];
   ^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug c++/69698] [meta-bug] flexible array members

[msebor at gcc dot gnu.org]

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

Bug 68354 Summary: -Warray-bounds on a flexible array member in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68354

   What|Removed |Added

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

[Bug c++/68354] -Warray-bounds on a flexible array member in C++

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #2 from Martin Sebor  ---
No working on the patch anymore.

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[reichelt at gcc dot gnu.org]

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

--- Comment #11 from Volker Reichelt  ---
Hi Marek, thanks for the fix!
However, the ChangeLog entry is wrong.

In the final version you didn't call instantiate_non_dependent_expr_sfinae,
but instantiate_non_dependent_expr instead.

Would you mind fixing that? Thanks!

[Bug tree-optimization/55985] Misleading message about which variable 'may be used uninitialized in this function'

[jonathan.leffler at gmail dot com]

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

--- Comment #2 from Jonathan Leffler  ---
This problem has been mostly resolved in 5.3.0 (and quite possibly earlier):

$ gcc -O3 -Werror -Wall -g -std=c99   -c -o gccbug.o gccbug.c
gccbug.c: In function ‘updtypes’:
gccbug.c:20:18: error: ‘savtupstart’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 tupstart += colsize;
  ^
cc1: all warnings being treated as errors
make: *** [gccbug.o] Error 1
$ gcc  -Werror -Wall -g -std=c99 -c gccbug.c
gccbug.c: In function ‘updtypes’:
gccbug.c:28:22: error: ‘savtupstart’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 tupstart = savtupstart;
  ^
cc1: all warnings being treated as errors
rmk: error code 1
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$

These warnings are correctly identifying savtupstart (instead of tupstart) as
the uninitialized variable.  We can argue about the line that's identified in
the first invocation, but the main message is identifying the correct variable.

This test was conducted on the same machine referenced in the original bug
report; the version information from 'uname -a' hasn't changed.  The machine is
behind multiple layers of firewall and was last booted 'system boot  2015-08-23
21:35'.

The -v output for the non-optimized test was:

$ gcc -v -Werror -Wall -g -std=c99 -c gccbug.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.3.0/configure --prefix=/usr/gcc/v5.3.0
--with-as=/usr/gnu64/bin/as --with-ld=/usr/gnu64/bin/ld CC=/usr/bin/gcc
CXX=/usr/bin/g++ : (reconfigured) ../gcc-5.3.0/configure
--prefix=/usr/gcc/v5.3.0 --with-as=/usr/gnu64/bin/as
--with-ld=/usr/gnu64/bin/ld CC=/usr/bin/gcc CXX=/usr/bin/g++
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Werror' '-Wall' '-g' '-std=c99' '-c'
'-mtune=generic' '-march=x86-64'
 /work5/gcc/v5.3.0/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1 -quiet
-v -iprefix /work5/gcc/v5.3.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/
gccbug.c -quiet -dumpbase gccbug.c -mtune=generic -march=x86-64 -auxbase gccbug
-g -Werror -Wall -std=c99 -version -o /tmp/cc6Q2aEc.s
GNU C99 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/work5/gcc/v5.3.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/work5/gcc/v5.3.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include"
ignoring duplicate directory
"/work5/gcc/v5.3.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed"
ignoring nonexistent directory
"/work5/gcc/v5.3.0/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /work5/gcc/v5.3.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /work5/gcc/v5.3.0/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/local/include
 /work5/gcc/v5.3.0/bin/../lib/gcc/../../include
 /usr/include
End of search list.
GNU C99 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 981b21321de4233d53ef0e051a81a41f
gccbug.c: In function ‘updtypes’:
gccbug.c:28:22: error: ‘savtupstart’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 tupstart = savtupstart;
  ^
cc1: all warnings being treated as errors
$

If you require a test with 6.3.0 or a similar more modern version of GCC,
please let me know.

[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 #3 from cesar at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> That doesn't work, it is too early.
> With:
> --- gimplify.c.jj 2017-03-08 18:19:24.0 +0100
> +++ gimplify.c2017-03-20 07:22:05.587913531 +0100
> @@ -9261,6 +9261,8 @@ gimplify_oacc_declare (tree *expr_p, gim
>omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
>  }
>  
> +  gimplify_adjust_omp_clauses (pre_p, NULL, , OACC_DECLARE);
> +
>stmt = gimple_build_omp_target (NULL, GF_OMP_TARGET_KIND_OACC_DECLARE,
> clauses);
>  
> we don't ICE on it, but still no idea what is the right thing to do.
> From what I understand, #pragma acc declare is active for all code from the
> directive till end of function (unless the variables mentioned in its
> clauses go out of scope earlier), so in theory perhaps the right thing is to
> move the gimplify omp context structure up in the gimplify context tree so
> that they are just children of the function (what happens if you put #pragma
> acc declare inside
> the body of some other acc region?).

You are correctly describing the behavior of declare in OpenACC. Declared
variables live throughout the scope specified by the user. However, I believe
the scope must be global or function, i.e. I don't think you can declare
variables inside nested blocks in C/C++.

> Though on the other side, e.g. for #pragma omp target enter data we adjust
> the omp clauses right away, but that doesn't really affect the handling of
> variables later on.  So, the important question is do you need the variables
> mentioned in acc declare clauses to be in the hash tables as GOMP_MAP after
> gimplify_oacc_declare returns or not?  If not, then the above patch might
> DTRT, otherwise we need to figure out something different.

I don't think this memory leak is present in gomp-4_0-branch. The patch that
resolves this issue was posted back in September 2016 here
. I'll rebuild trunk
with that patch to see if it resolves the memory leak there.

[Bug target/80083] libgomp doacross2.f90 regtest fails with -mcpu=power9 -O1

[acsawdey at gcc dot gnu.org]

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Mar 20 20:43:44 2017
New Revision: 246293

URL: https://gcc.gnu.org/viewcvs?rev=246293=gcc=rev
Log:

2017-03-20  Aaron Sawdey  

PR target/80083
* config/rs6000/rs6000.md (*movsi_internal1): Fix constraints for
alternatives 13/14.


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

[Bug c++/80096] [7 Regression] [c++1z] ICE with auto template parameter

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Mar 20 20:36:54 2017
New Revision: 246292

URL: https://gcc.gnu.org/viewcvs?rev=246292=gcc=rev
Log:
PR c++/80096 - ICE with C++17 non-type auto.

* pt.c (tsubst): Delay tsubst of type of template non-type
parameter.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto10.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/79519] [5/6/7 Regression] ICE deleting template friend function

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Mar 20 20:36:46 2017
New Revision: 246291

URL: https://gcc.gnu.org/viewcvs?rev=246291=gcc=rev
Log:
PR c++/79519 - ICE with deleted template friend.

* decl.c (grokdeclarator): Complain about misplaced function
definition using =, as well.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/deleted13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c

[Bug target/80124] Possible bug in _mm_cmpeq_ps

[guille at berkeley dot edu]

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

--- Comment #6 from Guille  ---
Thanks.

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

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bill Schmidt  ---
Fixed.

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

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Mar 20 20:04:25 2017
New Revision: 246290

URL: https://gcc.gnu.org/viewcvs?rev=246290=gcc=rev
Log:
[gcc]

2017-03-20  Bill Schmidt  

PR tree-optimization/80054
* gimple-ssa-strength-reduction.c (all_phi_incrs_profitable): Fail
the optimization if a PHI or any of its arguments is not dominated
by the candidate's basis.  Use gphi* rather than gimple* as
appropriate.
(replace_profitable_candidates): Clean up a gimple* variable that
should be a gphi* variable.

[gcc/testsuite]

2017-03-20  Bill Schmidt  

PR tree-optimization/80054
* g++.dg/torture/pr80054.C: New file.


Added:
trunk/gcc/testsuite/g++.dg/torture/pr80054.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80124] Possible bug in _mm_cmpeq_ps

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Andrew Pinski  ---
NaN == NaN is always false.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse  ---
NaN (all-ones is a NaN) is not equal to itself, that's normal behavior.

[Bug c/80116] Warn about macros expanding to multiple statements

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #1)
> Confirmed.  The CERT C Coding Standard outlines a number of common problems
> with macros that might be worth considering for inclusion in the proposed
> warning.   The following is the subject of this enhancement request:
> 
>   PRE10-C. Wrap multistatement macros in a do-while loop
>   https://www.securecoding.cert.org/confluence/x/jgL7
> 
> Some other checkers:
> 
>   PRE01-C. Use parentheses within macros around parameter names
>   https://www.securecoding.cert.org/confluence/x/CgU
> 
>   PRE02-C. Macro replacement lists should be parenthesized
>   https://www.securecoding.cert.org/confluence/x/HAs
> 
>   PRE11-C. Do not conclude macro definitions with a semicolon
>   https://www.securecoding.cert.org/confluence/x/wgBlAQ
> 
>   PRE12-C. Do not define unsafe macros
>   https://www.securecoding.cert.org/confluence/x/TIF3Ag
> 
>   PRE31-C. Avoid side effects in arguments to unsafe macros
>   https://www.securecoding.cert.org/confluence/x/agBi

Many of these are also in the CPP manual at:
https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html#Macro-Pitfalls
(even though no actual warning is output for any of them yet)

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[arnd at linaro dot org]

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

--- Comment #8 from Arnd Bergmann  ---
Looking at the kernel code again, I came up with an alternative that avoids the
large stack size and produces good executable code in all configurations I
found with the file that showed up a -Wframe-larger-than= warning for me, with
slightly larger .rodata and .data sections

-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
+#define _PICK(__index, ...) ({static const u32 __arr[] = { __VA_ARGS__ };
__arr[__index];})

Unfortunately this requires a constant argument set, and a number of other
files contain callers with non-constant arguments. We'd have to see if those
can be changed to use constant arguments instead.

[Bug fortran/38573] Missing markers for translation

[fmarchal at perso dot be]

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

Frederic Marchal  changed:

   What|Removed |Added

 CC||fmarchal at perso dot be

--- Comment #5 from Frederic Marchal  ---
This issue is still present in gcc 7.

The strings assigned to symstd_msg in gfc_check_intrinsic_standard() should be
marked for translation.

As it is, the current code in fortran/resolve.c at line 1709 outputs an error
message containing one untranslated fragment:

  /* Check it is actually available in the standard settings.  */
  if (!gfc_check_intrinsic_standard (isym, , false, sym->declared_at))
{
  gfc_error ("The intrinsic %qs declared INTRINSIC at %L is not "
 "available in the current standard settings but %s. Use "
 "an appropriate %<-std=*%> option or enable "
 "%<-fall-intrinsics%> in order to use it.",
 sym->name, >declared_at, symstd);
  return false;
}

I don't know how many languages could work around that string concatenation and
still present a meaningful message to the user but none can output a legible
message if %s isn't translated. Therefore, I recommend to mark the strings for
translation as a stopgap until a full i18n compatible solution is available.

I also suggest to write a comment for translators stating that %s is a string
such as "available since Fortran 77".

[Bug c++/80096] [7 Regression] [c++1z] ICE with auto template parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/80120] [7 Regression] Incorrect error with associate construct and character array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||rejects-valid
   Last reconfirmed||2017-03-20
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Incorrect error with|[7 Regression] Incorrect
   |associate construct and |error with associate
   |character array |construct and character
   |(regression)|array
  Known to fail||7.0

--- Comment #1 from Dominique d'Humieres  ---
The change occurred between revisions r241793 (2016-11-02, compiles) and
r241883 (2016-11-06, error), likely r241860 (pr64933).

[Bug c++/78345] [5/6 Regression] ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: in cxx_eval_outermost_constant_expr, at cp/constexpr.c:4464)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] ICE on   |[5/6 Regression] ICE on
   |invalid c++ code on |invalid c++ code on
   |x86_64-linux-gnu (internal  |x86_64-linux-gnu (internal
   |compiler error: in  |compiler error: in
   |cxx_eval_outermost_constant |cxx_eval_outermost_constant
   |_expr, at   |_expr, at
   |cp/constexpr.c:4464)|cp/constexpr.c:4464)
  Known to fail|7.0 |

--- Comment #7 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

[guille at berkeley dot edu]

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

--- Comment #3 from Guille  ---
Apologies, this maybe should've gone in the 'C bugs' section, not the C++
section.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

[guille at berkeley dot edu]

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

--- Comment #2 from Guille  ---
Created attachment 41008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41008=edit
the code that triggers possible bug

Compile with 'c++ t.c' (or maybe 'c++ -msse -msse2 t.c').

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

[guille at berkeley dot edu]

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

--- Comment #1 from Guille  ---
I forgot to mention that a while back (~1year) I had a similar problem with
_mm256_cmp_ps(a,b, _CMP_EQ_OQ) (the AVX equivalent of _mm_cmpeq_ps), but I
wasn't able to isolate the problem back then.

[Bug c++/79519] [5/6/7 Regression] ICE deleting template friend function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/79640] [5/6 Regression] ICE with generic lambda expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||7.0
Summary|[5/6/7 Regression] ICE with |[5/6 Regression] ICE with
   |generic lambda expression   |generic lambda expression
  Known to fail|7.0 |

--- Comment #5 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/80124] New: Possible bug in _mm_cmpeq_ps

[guille at berkeley dot edu]

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

Bug ID: 80124
   Summary: Possible bug in _mm_cmpeq_ps
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at berkeley dot edu
  Target Milestone: ---

The following code (below) seems to trigger a gcc bug because the following:

(A) * _mm_cmpeq_ps(r, r)
(B) * _mm_castsi128_ps(_mm_cmpeq_epi32(_mm_castps_si128(r),
_mm_castps_si128(r)))

which should give the same result, don't. 
In particular (B) seems to give the correct result, but (A) doesn't. 

* I tested it on:
"gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/lto-wrapper
Target: x86_64-apple-darwin16.4.0
Configured with: ../configure --without-multilib --enable-languages=c,c++
Thread model: posix
gcc version 7.0.1 20170129 (experimental) (GCC)"

* no flags are necessary (other than maybe '-msse -msse2')



#include 
#include 
#include 
#include 


#if !defined(__SSE__) || !defined(__SSE2__)
#error "needs SSE+SSE2"
#else

static void helper_print(const char name[], const __m128 v)
{
for (int i = 0; i < 4; ++i)
{
std::cerr << name << "[" << i << "] = ";
for (int j = 31; j >= 0; --j) std::cerr << const unsigned int
*))[i] >> j) & 1);
std::cerr << ";\n";
}
}

static __m128 ones()
{
const __m128 u = _mm_undefined_ps();
const __m128 r = _mm_cmpeq_ps(u, u);

if (_mm_movemask_ps(_mm_cmpeq_ps(r, r)) != 0xf)//
in case of error, print debugging info
{
helper_print("r", r);
const __m128 cmp = _mm_cmpeq_ps(r, r);
helper_print("cmp", cmp);  //
<-- this should be all 1s, but is all 0s
std::cerr << "_mm_movemask_ps(cmp)=" << _mm_movemask_ps(cmp) << "\n";
}
// 
assert(_mm_movemask_ps(_mm_castsi128_ps(_mm_cmpeq_epi32(_mm_castps_si128(r),
_mm_castps_si128(r == 0xf);// <-- this passes
assert(_mm_movemask_ps(_mm_cmpeq_ps(r, r)) == 0xf);
// <-- this breaks!

return r;
}
#endif

int main()
{
[[maybe_unused]] const __m128 r = ones();
return 0;
}

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
"String literals, and compound literals with const-qualified types, need 
not designate distinct objects.".  (This is different from named 
variables, which can't be merged without -fmerge-all-constants unless it 
can be shown there are no address comparisons that would allow the merging 
to be detected.)

[Bug c++/79640] [5/6/7 Regression] ICE with generic lambda expression

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Mon Mar 20 18:49:10 2017
New Revision: 246289

URL: https://gcc.gnu.org/viewcvs?rev=246289=gcc=rev
Log:
PR c++/79640 - infinite recursion with generic lambda.

* pt.c (tsubst_copy) [VAR_DECL]: Register the dummy instantiation
before substituting its initializer.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
r246288 updates the manual for GCC 7 and documents the limitation (as per
commetn #6) but the issue itself remains unresolved.

[Bug c++/52477] Wrong initialization order? __attribute__((constructor)) vs static data access

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Mon Mar 20 18:33:31 2017
New Revision: 246288

URL: https://gcc.gnu.org/viewcvs?rev=246288=gcc=rev
Log:
PR c++/52477 - Wrong initialization order __attribute__((constructor)) vs
static data access

* doc/extend.texi (attribute constructor): Document present limitation.

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

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tavianator at gmail dot com]

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

--- Comment #10 from Tavian Barnes  ---
> I think it is - __cancel_arg is assigned inside a while loop

Specifically a do { } while(0); loop, which obviously has only one iteration.

[Bug c++/79416] Internal compiler error for recursive template expansion

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Priority|P2  |P3
 CC||jason at gcc dot gnu.org
Summary|[5/6/7 Regression] Internal |Internal compiler error for
   |compiler error for  |recursive template
   |recursive template  |expansion
   |expansion   |

--- Comment #3 from Jason Merrill  ---
This is about running out of stack, instantiating a ridiculous number of
functions that call each other.  The error Martin sees in comment 1 is because
the old default instantiation limit of 500 was lower than the 800
instantiations the testcase wants to make of the 'nops' functions; since the
limit was raised to 900, we succeed in instantiating them, but then crash
running out of stack during ggc_collect.  Comment 2 demonstrates that we can
get the same crash on older GCC by lowering the number of instantiations the
testcase requires, so this really isn't a regression.

A simple fix for the crash would be to raise the stack limit; doubling the
amount requested in the call to stack_limit_increase from toplev::main (from
64MB to 128MB) allows the testcase to proceed.

A difficult fix for the crash would be to reduce the stack consumption of the
GGC machinery.

[Bug target/79963] vec_eq_any extracts wrong CR bit when compiling with -mcpu=power9

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
patch has been committed.

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Let me look into this (sorry, for the delay).

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||torvald at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to Dmitry Vyukov from comment #8)
> We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
> bits, right? It's only an optimization and we can pretend that elision never
> succeeds under tsan.

CCing Torvald on this.

> What is sync special bit (0x4000)?

See PR65697 for details.

[Bug target/79963] vec_eq_any extracts wrong CR bit when compiling with -mcpu=power9

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon Mar 20 18:05:00 2017
New Revision: 246287

URL: https://gcc.gnu.org/viewcvs?rev=246287=gcc=rev
Log:
gcc/testsuite/ChangeLog:

2017-03-20  Kelvin Nilsen  

PR target/79963
* gcc.target/powerpc/vsu/vec-any-eq-10.c: Add scan-assembler
directive to assure selection of proper bit using rlwinm insn.
* gcc.target/powerpc/vsu/vec-any-eq-14.c: Likewise.
* gcc.target/powerpc/vsu/vec-any-eq-7.c: Likewise.
* gcc.target/powerpc/vsu/vec-any-eq-8.c: Likewise.
* gcc.target/powerpc/vsu/vec-any-eq-9.c: Likewise.

gcc/ChangeLog:

2017-03-20  Kelvin Nilsen  

PR target/79963
* config/rs6000/altivec.h (vec_all_ne): Under __cplusplus__ and
__POWER9_VECTOR__ #ifdef control, change template definition to
use Power9-specific built-in function.
(vec_any_eq): Likewise.
* config/rs6000/vector.md (vector_ae_v2di_p): Change the flag used
to control outcomes from this test.
(vector_ae_p): For VEC_F modes, likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/altivec.h
trunk/gcc/config/rs6000/vector.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eq-10.c
trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eq-14.c
trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eq-7.c
trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eq-8.c
trunk/gcc/testsuite/gcc.target/powerpc/vsu/vec-any-eq-9.c

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

[dvyukov at google dot com]

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

--- Comment #8 from Dmitry Vyukov  ---
We need to modify tsan runtime to ignore (zero) __ATOMIC_HLE_ACQUIRE/RELEASE
bits, right? It's only an optimization and we can pretend that elision never
succeeds under tsan.

What is sync special bit (0x4000)?

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Sometimes it might be beneficial to use array in .rodata section rather than
automatic compound literal, i.e. try
const int j = ({ const int myarr[] = {0, 1, 2, 3, 4, 5}; myarr[i]; });
The question is if the gcc should do this as an optimization and when.
Don't remember right now the C requirements, but I bet
int
foo (const int *q)
{
  const int *p = (const int []){0, 1, 2, 3};
  if (q == 0)
return foo (p);
  else
return p == q;
}
should return 0, so we probably can't turn into TREE_STATIC all compound
literals, only if we can analyze all their uses.  So either do it only for
limited cases during gimplification, or do it in some later pass, determine if
const variables are initialized and then used in a way where promotion to
TREE_STATIC would be possible and beneficial.

[Bug c++/79640] [5/6/7 Regression] ICE with generic lambda expression

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[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 #12 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Mon Mar 20 16:50:00 2017
New Revision: 246284

URL: https://gcc.gnu.org/viewcvs?rev=246284=gcc=rev
Log:

2017-03-12 Nicolas Koenig 

PR fortran/39239
* symbol.c (check_conflict): report an error if an EQUIVALENCE variable
is BIND(C).

2017-03-12 Nicolas Koenig 

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


Modified:
trunk/gcc/fortran/symbol.c

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at gcc dot gnu.org]

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

--- Comment #18 from palmer at gcc dot gnu.org ---
Author: palmer
Date: Mon Mar 20 16:43:21 2017
New Revision: 246283

URL: https://gcc.gnu.org/viewcvs?rev=246283=gcc=rev
Log:
RISC-V: Don't prefer FP_REGS for integers

On RISC-V we can't store integers in floating-point registers as this is
forbidden by the ISA.  We've always disallowed this, but we were
setting the preferred mode to FP_REGS for some integer modes.  This
caused the LRA to blow up with some hard to read error messages.

This patch removes the prefered mode hook, as the right thing to do here
is nothing.

Thanks to Kito for finding the bug, and mpf for the fix.  See also
.

PR target/79912

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

[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 #7 from Jakub Jelinek  ---
Or the sync special bit (0x4000)?
That said,
if (!tree_fits_uhwi_p (last_arg)
|| memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
actually just ignores the higher bits (all 3 I've mentioned), it is a compile
time if (last_arg & 0x3fff) >= 6, and if that is false, it actually passes the
argument through unmodified.  So it depends on what the library will do with
those bits, and the check only guards for the not yet implemented other values,
so indeed I could perhaps leave that out for now.

Then there is the weak cas case, the GCC builtins have a bool argument whether
the cas is weak or strong, while tsan has separate libcalls for strong vs.
weak.
The way this is implemented in tsan.c actually is that if the argument is
compile time known non-zero (i.e. true), then the weak tsan atomics are used,
otherwise the strong tsan atomics are used (even when it is a variable which
evaluates to true).  As the documentation says that the weak argument is just
an optimization hint and can be ignored, this is probably the right thing.

[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 #6 from Jakub Jelinek  ---
Does it support e.g.
__ATOMIC_HLE_ACQUIRE (1 << 16) and
__ATOMIC_HLE_RELEASE (1 << 17) bits ored into the memory model?

[Bug c++/80091] [6 Regression] gcc-6 branch segfaults while compiling firefox

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
I'll take a whack at this

[Bug middle-end/77383] -fcheck-pointer-bounds -mmpx ICE with VLA struct return type

[zeccav at gmail dot com]

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

--- Comment #3 from Vittorio Zecca  ---
Still in 7.0.1

[Bug c/67410] [5 Regression] c/c-typeck.c references out of bounds array

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Fixed on 7.0.1

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[jani.nikula at intel dot com]

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

--- Comment #5 from Jani Nikula  ---
(In reply to Martin Liška from comment #4)
> How common is such situation and why do you use volatile keyword in
> combination with a constant index?

I didn't write the sample, I think the goal of 'volatile' was to ensure the
compiler doesn't optimize it all away.

The sample comes from a trick in kernel code to pick a constant based on a
limited range variable. For example, you have one hardware register per port,
the register offsets aren't uniformly distributed, and you want to have macros
of the form FOO(port) to give you the right register offset based on the port.

So you could have:

#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])

#define FOO(x) _PICK(x, 1, 2, 3)

instead of things like:

#define _PICK(__index, a, b, c) ((__index) == 0 ? (a) : (__index) == 1 ? (b) :
(c))

If you have clever ideas how to neatly handle this otherwise, expecially when
the number of ports increases, I'm all ears!

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

[dvyukov at google dot com]

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

--- Comment #5 from Dmitry Vyukov  ---
I may be missing something, but can't we just always emit calls into tsan
runtime under tsan? They accept the memory order value and can work with
constants and  runtime values.

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Okay, I'll test a combination of mine & your patch and post it to the ML.  We
can discuss it further there.

[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

Jakub Jelinek  changed:

   What|Removed |Added

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

[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 #4 from Jakub Jelinek  ---
That is clearly due to bugs in tsan.c, in my PR55439 r194133 changes.
At -O0 the code is not optimized, so we end up with e.g.
  __m_6 = 5;
  __b_7 = std::operator& (__m_6, 65535);
  __m.10_8 = (int) __m_6;
  _9 = _5->_M_i;
  _10 = __atomic_load_1 (_9, __m.10_8);
or
  __m_12 = __m_7(D);
  _13 = std::__cmpexch_failure_order (__m_12);
  _14 = (int) __i2_11;
  this_15 = this_9;
  __i1_16 = __i1_10;
  __i2_17 = (__int_type) _14;
  __m1_18 = __m_12;
  __m2_19 = _13;
  __b2_20 = std::operator& (__m2_19, 65535);
  __b1_21 = std::operator& (__m1_18, 65535);
  __m2.16_22 = (int) __m2_19;
  __m1.17_23 = (int) __m1_18;
  _24 = (int) __i2_17;
  _25 = _15->_M_i;
  _26 = __atomic_compare_exchange_1 (_25, __i1_16, _24, 0, __m1.17_23,
__m2.16_22);
and then we run into instrument_builtin_call:

  case check_last:
  case fetch_op:
last_arg = gimple_call_arg (stmt, num - 1);
if (!tree_fits_uhwi_p (last_arg)
|| memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
  return;  //  HERE
...
  case weak_cas:
if (!integer_nonzerop (gimple_call_arg (stmt, 3)))
  continue;  //  HERE
/* FALLTHRU */
  case strong_cas:
gcc_assert (num == 6);
for (j = 0; j < 6; j++)
  args[j] = gimple_call_arg (stmt, j);
if (!tree_fits_uhwi_p (args[4])
|| memmodel_base (tree_to_uhwi (args[4])) >= MEMMODEL_LAST)
  return;  //  HERE
if (!tree_fits_uhwi_p (args[5])
|| memmodel_base (tree_to_uhwi (args[5])) >= MEMMODEL_LAST)
  return;  //  HERE
...
if (!tree_fits_uhwi_p (last_arg)
|| memmodel_base (tree_to_uhwi (last_arg)) >= MEMMODEL_LAST)
  return;  //  HERE

If last_arg or gimple_call_arg (stmt, 3) is not an integer, but SSA_NAME, we
could for some very limited cases try to iterate over SSA_NAME definition
statements and see if we can figure out a constant, but as can be seen on the
snippets above, that is not really useful here, there are function calls which
at -O0 are not inlined.
Thus I think what we need to do is when we can't check the memory model value
at compile time, emit a runtime check which does the same thing, and use the
tsan builtins if the runtime test(s) pass, otherwise fall through into the
__atomic_* builtins.

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Marek is already a step ahead of me.  (Please go ahead with your patch.  I
submitted my suggestion only because I had typed it up before I saw your
update.)

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 CC||aldyh at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
It also ICEs with a native compiler.  The test case is invalid: it calls
alloca() with a pointer argument.  A smaller test case is:

$ cat z.c && gcc -S -Wall -Wextra -O2 -Walloca-larger-than=126812070 z.c
void g (int *p)
{
  extern void f (void*);

  void *q = __builtin_alloca (p);
  f (q);
}

z.c: In function ‘g’:
z.c:5:31: warning: passing argument 1 of ‘__builtin_alloca’ makes integer from
pointer without a cast [-Wint-conversion]
   void *q = __builtin_alloca (p);
   ^
z.c:5:31: note: expected ‘long unsigned int’ but argument is of type ‘int *’
z.c:1:6: internal compiler error: in get_range_info, at tree-ssanames.c:375
 void g (int *p)
  ^

0x11ac2f9 get_range_info(tree_node const*, generic_wide_int*,
generic_wide_int*)
/src/gcc/svn/gcc/tree-ssanames.c:375
0x190908e alloca_call_type
/src/gcc/svn/gcc/gimple-ssa-warn-alloca.c:334
0x1909637 pass_walloca::execute(function*)
/src/gcc/svn/gcc/gimple-ssa-warn-alloca.c:466
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


The bug seems to be in the following block in the alloca_call_type function
that passes the pointer (len_casted) to get_range_info:

  gimple *def = SSA_NAME_DEF_STMT (len);
  if (gimple_assign_cast_p (def)
  && TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (def
{
  len_casted = gimple_assign_rhs1 (def);
  range_type = get_range_info (len_casted, , );
}

The following otherwise untested patch avoids the ICE.  I CC'd Aldy for hits
thoughts.

diff --git a/gcc/gimple-ssa-warn-alloca.c b/gcc/gimple-ssa-warn-alloca.c
index b940efa..50b35f6 100644
--- a/gcc/gimple-ssa-warn-alloca.c
+++ b/gcc/gimple-ssa-warn-alloca.c
@@ -327,11 +327,20 @@ alloca_call_type (gimple *stmt, bool is_vla, tree
*invalid_casted_type)
  // away with better range information.  But it gets
  // most of the cases.
  gimple *def = SSA_NAME_DEF_STMT (len);
- if (gimple_assign_cast_p (def)
- && TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (def
+ if (gimple_assign_cast_p (def))
{
- len_casted = gimple_assign_rhs1 (def);
- range_type = get_range_info (len_casted, , );
+ tree rhs = gimple_assign_rhs1 (def);
+ tree rhstype = TREE_TYPE (rhs);
+
+ // Bail if the argument type is not valid.
+ if (!INTEGRAL_TYPE_P (rhstype))
+   return alloca_type_and_limit (ALLOCA_OK);
+
+ if (TYPE_UNSIGNED (rhstype))
+   {
+ len_casted = rhs;
+ range_type = get_range_info (len_casted, , );
+   }
}
  // An unknown range or a range of the entire domain is
  // really no range at all.

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
I have a patch.

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Jani Nikula from comment #3)
> (In reply to Martin Liška from comment #2)
> > Well, just adding the param and -fsanitize-address-use-after-scope does not
> > enable any sanitization. One has to add -fsanitize=address to trigger real
> > sanitization. With Address Sanitizer, the code really grows, which is kind
> > of expected.
> 
> Yes, of course. The full options (in the godbolt link) are: -O2 -std=c11 -x
> c -fsanitize=kernel-address -fasan-shadow-offset=0xdfff9000 --param
> asan-stack=1 --param asan-globals=1 --param
> asan-instrumentation-with-call-threshold=1
> -fsanitize-address-use-after-scope
> 
> I fully expect asan to grow code; I'm just not sure whether such a huge
> growth particularly with the combination of --param asan-stack=1 and
> -fsanitize-address-use-after-scope is expected.

Yep, it's kind of expected overhead coming from
-fsanitize-address-use-after-scope. It's caused by fact that the compound
literal is going to live as a stack variable. I can imagine better sanitization
of ASAN_CHECK builtins when a variable is unpoisoned in a BB and there are
array references.

How common is such situation and why do you use volatile keyword in combination
with a constant index?

[Bug c/80116] Warn about macros expanding to multiple statements

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Confirmed.  The CERT C Coding Standard outlines a number of common problems
with macros that might be worth considering for inclusion in the proposed
warning.   The following is the subject of this enhancement request:

  PRE10-C. Wrap multistatement macros in a do-while loop
  https://www.securecoding.cert.org/confluence/x/jgL7

Some other checkers:

  PRE01-C. Use parentheses within macros around parameter names
  https://www.securecoding.cert.org/confluence/x/CgU

  PRE02-C. Macro replacement lists should be parenthesized
  https://www.securecoding.cert.org/confluence/x/HAs

  PRE11-C. Do not conclude macro definitions with a semicolon
  https://www.securecoding.cert.org/confluence/x/wgBlAQ

  PRE12-C. Do not define unsafe macros
  https://www.securecoding.cert.org/confluence/x/TIF3Ag

  PRE31-C. Avoid side effects in arguments to unsafe macros
  https://www.securecoding.cert.org/confluence/x/agBi

[Bug target/80123] New: 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

Bug ID: 80123
   Summary: libgomp tests pr66199-2.c and pr66199-5.c fail with
-mcpu=power9
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: dje at gcc dot gnu.org, meissner at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64*-*-* power9

Both of these fail in the same way with 246224:

gcc/xgcc -Bgcc ../trunk/libgomp/testsuite/libgomp.c/pr66199-2.c
-Bpowerpc64le-unknown-linux-gnu/libgomp/
-Bpowerpc64le-unknown-linux-gnu/libgomp/.libs
-Ipowerpc64le-unknown-linux-gnu/libgomp
-I../trunk/libgomp/testsuite/../../include -I../trunk/libgomp/testsuite/..
-fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa
-fdiagnostics-color=never -fopenmp -O2
-L/home/sawdey/work/gcc/trunk/build4/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-lm -o ./pr66199-2.exe -mcpu=power9
../trunk/libgomp/testsuite/libgomp.c/pr66199-2.c: In function ‘f2._omp_fn.3’:
../trunk/libgomp/testsuite/libgomp.c/pr66199-2.c:21:11: error: could not split
insn
(insn 70 61 188 (set (reg:V2DI 86 9 [orig:206 vect_cst__132 ] [206])
(vec_duplicate:V2DI (reg/v:DI 0 0 [orig:163 c ] [163]))) 1235
{vsx_splat_v2di}
 (nil))
../trunk/libgomp/testsuite/libgomp.c/pr66199-2.c:21:11: internal compiler
error: in final_scan_insn, at final.c:3025
0x108bc1d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../trunk/gcc/rtl-error.c:108
0x1053fa5b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../trunk/gcc/final.c:3025
0x1053fe37 final(rtx_insn*, _IO_FILE*, int)
../../trunk/gcc/final.c:2051
0x10540497 rest_of_handle_final
../../trunk/gcc/final.c:4489
0x10540497 execute
../../trunk/gcc/final.c:4562


gcc/xgcc -Bgcc ../trunk/libgomp/testsuite/libgomp.c/pr66199-5.c
-Bpowerpc64le-unknown-linux-gnu/libgomp/
-Bpowerpc64le-unknown-linux-gnu/libgomp/.libs
-Ipowerpc64le-unknown-linux-gnu/libgomp
-I../trunk/libgomp/testsuite/../../include -I../trunk/libgomp/testsuite/..
-fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa
-fdiagnostics-color=never -fopenmp -O2
-L/home/sawdey/work/gcc/trunk/build4/powerpc64le-unknown-linux-gnu/./libgomp/.libs
-lm -o ./pr66199-5.exe -mcpu=power9
../trunk/libgomp/testsuite/libgomp.c/pr66199-5.c: In function ‘f2._omp_fn.3’:
../trunk/libgomp/testsuite/libgomp.c/pr66199-5.c:24:11: error: could not split
insn
(insn 75 66 200 (set (reg:V2DI 86 9 [orig:209 vect_cst__140 ] [209])
(vec_duplicate:V2DI (reg/v:DI 0 0 [orig:162 c ] [162]))) 1235
{vsx_splat_v2di}
 (nil))
../trunk/libgomp/testsuite/libgomp.c/pr66199-5.c:24:11: internal compiler
error: in final_scan_insn, at final.c:3025
0x108bc1d3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../trunk/gcc/rtl-error.c:108
0x1053fa5b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../trunk/gcc/final.c:3025
0x1053fe37 final(rtx_insn*, _IO_FILE*, int)
../../trunk/gcc/final.c:2051
0x10540497 rest_of_handle_final
../../trunk/gcc/final.c:4489
0x10540497 execute
../../trunk/gcc/final.c:4562

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
But also ICEs on x86_64.  Started with:

commit da6cf191f748d879f8be3c00d745b3bfe6e5495b
Author: aldyh 
Date:   Tue Oct 18 21:40:58 2016 +

* Makefile.in (OBJS): Add gimple-ssa-warn-alloca.o.
* passes.def: Add two instances of pass_walloca.
* tree-pass.h (make_pass_walloca): New.
* gimple-ssa-warn-walloca.c: New file.
* doc/invoke.texi: Document -Walloca, -Walloca-larger-than=, and
-Wvla-larger-than= options.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241318
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar 20 15:02:09 2017
New Revision: 246279

URL: https://gcc.gnu.org/viewcvs?rev=246279=gcc=rev
Log:
PR c++/80059 - ICE with noexcept and __transaction_atomic
* except.c (build_must_not_throw_expr): Call
instantiate_non_dependent_expr_sfinae.

* g++.dg/tm/pr80059-2.C: New test.
* g++.dg/tm/pr80059.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tm/pr80059-2.C
trunk/gcc/testsuite/g++.dg/tm/pr80059.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/except.c
trunk/gcc/testsuite/ChangeLog

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

[andrew at fluidgravity dot co.uk]

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

Bug ID: 80121
   Summary: Memory leak when allocating a component derived type
in a recursive subroutine (gfortran)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

Created attachment 41006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41006=edit
Fortran code with memory leak when compiled with gfortran

I'm getting a memory leak when I compile and run the attached code with
gfortran.
No such problem occurs when I use the Intel or Portland compilers.

> gfortran -g -O0 -std=f2008 code.f90
> valgrind --leak-check=yes ./a.out
...
==32283== HEAP SUMMARY:
==32283== in use at exit: 8 bytes in 1 blocks
==32283==   total heap usage: 28 allocs, 27 frees, 13,784 bytes allocated
==32283== 
==32283== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==32283==at 0x4C29160: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32283==by 0x400C66: __m1_MOD_s1 (code.f90:14)
==32283==by 0x400E0F: __m1_MOD_s1 (code.f90:18)
==32283==by 0x400F1F: MAIN__ (code.f90:26)
==32283==by 0x400F56: main (code.f90:23)
==32283== 
==32283== LEAK SUMMARY:
==32283==definitely lost: 8 bytes in 1 blocks
==32283==indirectly lost: 0 bytes in 0 blocks
==32283==  possibly lost: 0 bytes in 0 blocks
==32283==still reachable: 0 bytes in 0 blocks
==32283== suppressed: 0 bytes in 0 blocks

[Bug c/80122] New: __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly

[rpirrera at aitek dot it]

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

Bug ID: 80122
   Summary: __builtin_va_arg_pack() and
__builtin_va_arg_pack_len() does not work correctly
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rpirrera at aitek dot it
  Target Milestone: ---

Created attachment 41007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41007=edit
test __builtin_va_arg_pack()

__builtin_va_arg_pack() has changed behavior from version 4.4.7.
In case of only an always inline function all work correctly but if the always
inline function passes the __builtin_va_arg_pack() to another always inline
function the computed __builtin_va_arg_pack_len() is 0 instead of the number of
variable arguments.

In attachment you will find a test program reproducing the issue.

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed.

[Bug fortran/80120] New: Incorrect error with associate construct and character array (regression)

[mrestelli at gmail dot com]

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

Bug ID: 80120
   Summary: Incorrect error with associate construct and character
array (regression)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

Recent gfortran does not compile the following valid code:

program p
 implicit none

 type :: t
  character(len=25) :: text(2)
 end type t
 type(t) :: x

 x%text(1) = "ABC"
 x%text(2) = "defgh"

 associate( c => x%text )
 write(*,*) c(:)(:maxval(len_trim(c)))
 end associate

end program p


The error message is

$ gfortran test.f90 -o test
test.f90:13:16:

  write(*,*) c(:)(:maxval(len_trim(c)))
1
Error: Syntax error in WRITE statement at (1)


I see the problem with

$ gfortran --version
GNU Fortran (GCC) 7.0.1 20170317 (experimental)

while this version works:

$ gfortran --version
GNU Fortran (Gentoo 4.9.4 p1.0, pie-0.6.4) 4.9.4

The expected output is

$ ./test
 ABC  defgh

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
Since the testcase is ill-formed, I think the solution is to reject it earlier,
in the front end, rather than wait until RTL expansion; that should avoid the
need to touch chkp.

[Bug c++/80119] -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[julian.pfeifle at upc dot edu]

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

--- Comment #1 from Julian Pfeifle  ---
The error occurs with -O0 and -O3.

[Bug c++/80119] New: -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[julian.pfeifle at upc dot edu]

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

Bug ID: 80119
   Summary: -Wmaybe-uninitialized wrongly flags the body of a
short-circuited if-clause
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julian.pfeifle at upc dot edu
  Target Milestone: ---

Consider

#include 

template 
void failing_function(std::integral_constant)
{
   int i;
   if (b && (i=4)) {
  ++i;
   } 
}

int main (void)
{
   failing_function(std::false_type());
}

Compiling with -Wall gives 

test.cc: In function `void failing_function(std::integral_constant)
[with bool b = false]`:
test.cc:8:7: error: `i` may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   ++i;
   ^~

even though b is false, for which reason the body of the if-clause shouldn't
even be considered.

Calling failing_function(std::true_type()) compiles, as expected.

The `i=4` originally was a more complicated function call.

The error is important because it precludes compiling with -Werror.

gcc versions up to 6.1.0 handled this fine, I don't know about 6.2.*.

[Bug fortran/80118] New: ICE with zero size parameter array

[mrestelli at gmail dot com]

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

Bug ID: 80118
   Summary: ICE with zero size parameter array
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

The following code produces an internal compiler error when
referring to "empty2".

module m
implicit none

  integer, parameter :: not_empty(1) = 0
  integer, parameter :: empty1(0) = (/integer :: /)
  integer, parameter :: empty2(0) = 0

contains

 subroutine sub(v)
  integer, allocatable, intent(out) :: v(:)
   v = 2*not_empty ! works
   v = 2*empty1! works
   v = 2*empty2 ! internal compiler error
 end subroutine sub

end module m



$ gfortran -c test.f90 -o test.o
test.f90:14:0:

v = 2*empty2 ! internal compiler error

internal compiler error: Errore di segmentazione
0xa6f07f crash_signal
.././../gcc-trunk-source/gcc/toplev.c:337
0x5c9519 gfc_get_full_arrayspec_from_expr(gfc_expr*)
.././../gcc-trunk-source/gcc/fortran/expr.c:4496
0x6700c6 gfc_alloc_allocatable_for_assignment(gfc_loopinfo*, gfc_expr*,
gfc_expr*)
.././../gcc-trunk-source/gcc/fortran/trans-array.c:9127
0x69b0c3 gfc_trans_assignment_1
.././../gcc-trunk-source/gcc/fortran/trans-expr.c:10131
0x66051f trans_code
.././../gcc-trunk-source/gcc/fortran/trans.c:1817
0x6856f7 gfc_generate_function_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans-decl.c:6332
0x6641b1 gfc_generate_module_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans.c:2195
0x61a36b translate_all_program_units
.././../gcc-trunk-source/gcc/fortran/parse.c:6061
0x61a36b gfc_parse_file()
.././../gcc-trunk-source/gcc/fortran/parse.c:6274
0x65d05f gfc_be_parse_file
.././../gcc-trunk-source/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.



gfortran --version
GNU Fortran (GCC) 7.0.1 20170317 (experimental)

[Bug target/80106] ICE on an invalid code in tree_to_uhwi, at tree.c:7344

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Krebbel  ---
Duplicate of:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893

I have a fix for this and will commit it.

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

[Bug ada/80117] New: [7 regression] a-cfinve.ads:245:04: warning: types for unchecked conversion have different sizes

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

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

Bug ID: 80117
   Summary: [7 regression] a-cfinve.ads:245:04: warning: types for
unchecked conversion have different sizes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

Created attachment 41005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41005=edit
Full build log

When building an ada-enabled compiler for aarch64 with
--with-multilib-list=lp64,ilp32 the ilp32 adalib fails to build:

/home/abuild/rpmbuild/BUILD/gcc-7.0.1-r246083/obj-aarch64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-7.0.1-r246083/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
-c -g -O2 -mabi=ilp32 -fPIC  -W -Wall -gnatpg -nostdinc -mabi=ilp32 
a-finve.adb -o a-cfinve.o
a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55
a-cfinve.ads:245:04: warning: types for unchecked conversion have different
sizes
make[9]: *** [../gcc-interface/Makefile:296: a-cfinve.o] Error 1

[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
*** Bug 80106 has been marked as a duplicate of this bug. ***

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
I created PR80116 to track the warning addition.

[Bug target/80102] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/80116] New: Warn about macros expanding to multiple statements

[mpolacek at gcc dot gnu.org]

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

Bug ID: 80116
   Summary: Warn about macros expanding to multiple statements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See PR80063:

  #define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
  decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM,   \
   BUILT_IN_NORMAL, NAME, NULL_TREE);   \
  set_call_expr_flags (decl, ATTRS);\
  set_builtin_decl (ENUM, decl, true);

  #include "sanitizer.def"

  /* -fsanitize=object-size uses __builtin_object_size, but that might
 not be available for e.g. Fortran at this point.  We use
 DEF_SANITIZER_BUILTIN here only as a convenience macro.  */
  if ((flag_sanitize & SANITIZE_OBJECT_SIZE)
  && !builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
DEF_SANITIZER_BUILTIN (BUILT_IN_OBJECT_SIZE, "object_size", // <=
   BT_FN_SIZE_CONST_PTR_INT,
   ATTR_PURE_NOTHROW_LEAF_LIST)

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar 20 13:31:28 2017
New Revision: 246278

URL: https://gcc.gnu.org/viewcvs?rev=246278=gcc=rev
Log:
PR sanitizer/80063
* asan.c (DEF_SANITIZER_BUILTIN): Use do { } while (0).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c

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

[dvyukov at google dot com]

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

--- Comment #3 from Dmitry Vyukov  ---
Also reported on stackoverflow:
http://stackoverflow.com/questions/37552866/why-does-threadsanitizer-report-a-race-with-this-lock-free-example

I've checked with
gcc version 7.0.1 20170307 (experimental) (GCC)
with -O0 false race is reported
with -O1 no false races reported.
Again atomic operation somehow end up being non-instrumented with -O0.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
As for the warning, we should open an enhancement request, though not sure it
is something for -Wmisleading-indentation.  I'd say that we just should warn
whenever a macro defines several statements and the macro is used as a body of
a conditional, so only the first statement from the macro is conditional.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Please reformat it properly:
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
  do {  \
decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM, \
 BUILT_IN_NORMAL, NAME, NULL_TREE); \
set_call_expr_flags (decl, ATTRS);  \
set_builtin_decl (ENUM, decl, true);\
  } while (0);
Ok with that change.

[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
This is from systemtap 3.0, didn't try with 3.1 which seems to be available
since a few weeks.

[Bug tree-optimization/80113] [6/7 Regression] ICE in set_var_live_on_entry at tree-ssa-live.c:1018

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 20 13:06:58 2017
New Revision: 246277

URL: https://gcc.gnu.org/viewcvs?rev=246277=gcc=rev
Log:
2017-03-20  Richard Biener  

PR tree-optimization/80113
* graphite-isl-ast-to-gimple.c (copy_loop_phi_nodes): Do not
allocate extra SSA name for PHI def.
(add_close_phis_to_outer_loops): Likewise.
(add_close_phis_to_merge_points): Likewise.
(copy_loop_close_phi_args): Likewise.
(copy_cond_phi_nodes): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[jani.nikula at intel dot com]

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

--- Comment #3 from Jani Nikula  ---
(In reply to Martin Liška from comment #2)
> Well, just adding the param and -fsanitize-address-use-after-scope does not
> enable any sanitization. One has to add -fsanitize=address to trigger real
> sanitization. With Address Sanitizer, the code really grows, which is kind
> of expected.

Yes, of course. The full options (in the godbolt link) are: -O2 -std=c11 -x c
-fsanitize=kernel-address -fasan-shadow-offset=0xdfff9000 --param
asan-stack=1 --param asan-globals=1 --param
asan-instrumentation-with-call-threshold=1
-fsanitize-address-use-after-scope

I fully expect asan to grow code; I'm just not sure whether such a huge growth
particularly with the combination of --param asan-stack=1 and
-fsanitize-address-use-after-scope is expected.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Guess we should
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -2566,11 +2566,12 @@ initialize_sanitizer_builtins (void)
 #undef DEF_BUILTIN_STUB
 #define DEF_BUILTIN_STUB(ENUM, NAME)
 #undef DEF_SANITIZER_BUILTIN
-#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
+#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) do {\
   decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM,  \
   BUILT_IN_NORMAL, NAME, NULL_TREE);   \
   set_call_expr_flags (decl, ATTRS);   \
-  set_builtin_decl (ENUM, decl, true);
+  set_builtin_decl (ENUM, decl, true); \
+} while (0);

 #include "sanitizer.def"

[Bug plugins/80094] GCC plugin hash table corruption on hash table expansion (>10 plugins) on GCC 4.5+

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Brad Spengler from comment #2)
> I've added an alternative fix at
> https://grsecurity.net/~spender/plugin_hash_fix2.diff
> 
> It's a bit smaller/cleaner and should fit in better with the existing code
> style.  Untested, but I believe it will work.
> 
> -Brad

Looks good, please send patches to gcc-patc...@gcc.gnu.org

[Bug tree-optimization/80105] [6/7 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com