[Bug middle-end/80422] New: ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[su at cs dot ucdavis.edu]

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

Bug ID: 80422
   Summary: ICE on valid code at -O3 in 32-bit mode on
x86_64-linux-gnu: in operator[], at vec.h:732
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a very recent regression. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170414 (experimental) [trunk revision 246923] (GCC)
$
$ gcc-trunk -m32 -O2 small.c
$
$ gcc-trunk -m32 -O3 small.c
small.c: In function ‘fn2’:
small.c:19:1: internal compiler error: in operator[], at vec.h:732
 }
 ^
0x12f1017 vec::operator[](unsigned int)
../../gcc-source-trunk/gcc/vec.h:732
0x12f46fe vec::operator[](unsigned int)
../../gcc-source-trunk/gcc/cfgcleanup.c:1635
0x12f46fe single_pred_edge
../../gcc-source-trunk/gcc/basic-block.h:362
0x12f46fe try_crossjump_to_edge
../../gcc-source-trunk/gcc/cfgcleanup.c:1979
0x12f4c16 try_crossjump_bb
../../gcc-source-trunk/gcc/cfgcleanup.c:2328
0x12f50fa try_optimize_cfg
../../gcc-source-trunk/gcc/cfgcleanup.c:3001
0x12f50fa cleanup_cfg(int)
../../gcc-source-trunk/gcc/cfgcleanup.c:3204
0x12f6d28 execute
../../gcc-source-trunk/gcc/cfgcleanup.c:
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


int a, c, f;
short b, d, e;

int fn1 (int h)
{ 
  return a > 2 || h > a ? h : h << a;
}

void fn2 ()
{ 
  int j, k;
  while (1)
{ 
  k = c && b;
  f &= e > (fn1 (k) && j);
  if (!d)
break;
}
}

int main ()
{ 
  fn2 ();
  return 0;
}

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[ma...@linux-mips.org]

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

--- Comment #6 from Maciej W. Rozycki  ---
Created attachment 41199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41199=edit
Possible fix

FYI, I think this has been caused by r227385, see how `_internal'
is used by `mips_expand_epilogue':

  /* simple_returns cannot rely on values that are only available
 on paths through the epilogue (because return paths that do
 not pass through the epilogue may nevertheless reuse a
 simple_return that occurs at the end of the epilogue).
 Use a normal return here instead.  */
  rtx reg = gen_rtx_REG (Pmode, GP_REG_FIRST + 7);
  pat = gen_return_internal (reg);

and what looks like an inadvertent addition of:

operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);

there:

@@ -6522,12 +6543,10 @@
   [(any_return)
(use (match_operand 0 "pmode_register_operand" ""))]
   ""
-{
-  if (TARGET_MICROMIPS)
-return "%*jr%:\t%0";
-  else
-return "%*j\t%0%/";
-}
+  {
+operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
+return mips_output_jump (operands, 0, -1, false);
+  }
   [(set_attr "type""jump")
(set_attr "mode""none")])

Patch attached may fix it, untested.

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-14
 Ever confirmed|0   |1

--- Comment #5 from Jeffrey A. Law  ---
So what's happening here is the compact-branch support broke mips16.

It's pretty obvious if we look at mips.md:

(define_insn "*"
  [(any_return)]
  ""
  {
operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
return mips_output_jump (operands, 0, -1, false);
  }
  [(set_attr "type" "jump")
   (set_attr "mode" "none")])

;; Normal return.

(define_insn "_internal"
  [(any_return)
   (use (match_operand 0 "pmode_register_operand" ""))]
  ""
  {
operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
return mips_output_jump (operands, 0, -1, false);
  }
  [(set_attr "type" "jump")
   (set_attr "mode" "none")])


Where RETURN_ADDR_REGNUM is always 31, even on mips16.  So no matter what if we
generate any of the return insns matching those patterns we'll emit a jr $31.

I'm not familiar with this aspect of the MIPS port (it's 15+ years since I've
done any serious MIPS work), but ISTM that at least for the _internal version
we shouldn't be overwriting operands[0] -- whatever generates that pattern
should be passing us the right register.

For return and simple_return, we might need to conditionalize the assignment to
operands[0] since the return register is not provided.

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[3dw4rd at verizon dot net]

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

--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Created attachment 41198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41198=edit
Testing a patch...

I'm testing the following:

2017-04-13  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/68397 std::tr1::expint fails ... long double arguments.
* include/tr1/exp_integral.tcc: Increase iteration limits.
* testsuite/tr1/5_numerical_facilities/special_functions/15_expint/
pr68397.cc: New test.
* testsuite/special_functions/14_expint/pr68397.cc: New test.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[babokin at gmail dot com]

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

--- Comment #11 from Dmitry Babokin  ---
I confirm that the latest patch fixes all UBSAN compile time problems that I
have. Thanks!

Though correctness issues remain - PR80386.

[Bug c/80421] Case dispatch is scrambled in switch-statement

[ivan_j_johnson at msn dot com]

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

--- Comment #2 from Ivan Johnson  ---
GCC seems to be dispatching to the wrong case in a switch-statement in the
attached source.  To see the problem, examine the first function in the
attached C file, which is copied below:

uint32_t to_cigar_int (char op_letter)
{
printf("op_letter %c\n", op_letter);
switch (op_letter) {
default:
printf("case default\n");
if (op_letter == 'D' || op_letter == 'I') {
printf("This should never be reached.\n");
}
return 0;
case 'D':
printf("case 'D'\n");
return 0;
case 'I':
printf("case 'I'\n");
return 0;
}
}

As you can see, control should never reach the printf call for "This should
never be reached" under the default case, because the switch has explicit cases
for 'D' and 'I'.  However, the actual output of the program is as follows:

op_letter D
case 'D'
op_letter M
case 'I'
op_letter I
case default
This should never be reached.
op_letter M
case 'D'
op_letter D
case default
This should never be reached.

Based on the output, the "unreachable printf" call has been executed.  This is
the problem.  It is only seen with optimization turned on.

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

Command line used:
gcc -O3 inline_switch.c

Compiler output: none

[Bug c/80421] Case dispatch is scrambled in switch-statement

[ivan_j_johnson at msn dot com]

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

--- Comment #1 from Ivan Johnson  ---
Created attachment 41197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41197=edit
Preprocessor output

[Bug c/80421] New: Case dispatch is scrambled in switch-statement

[ivan_j_johnson at msn dot com]

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

Bug ID: 80421
   Summary: Case dispatch is scrambled in switch-statement
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan_j_johnson at msn dot com
  Target Milestone: ---

Created attachment 41196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41196=edit
Source code to demonstrate the bug

the exact version of GCC;
the system type;
the options given when GCC was configured/built;
the complete command line that triggers the bug;
the compiler output (error messages, warnings, etc.); and
the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug
report for the GNAT front end, a complete set of source files (see below).

[Bug target/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #8 from Wilco  ---
Likely related to PR77455 which was backported to GCC6. Unwinding most
definitely doesn't require a frame pointer (on AArch64 the frame pointer is
completely unused unless you use eg. alloca).

[Bug c++/80415] [7 Regression] bogus "invalid initialization of reference" error

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #13 from Segher Boessenkool  ---
Yes exactly.  When pressure is removed the reg is on the reg_use_list
eight times, but when pressure was added it was just once.

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #5)
> This has been fixed by revision r230580 (pr59910). If there is no objection,
> I can back port the fix to the gcc5 branch.

Before doing this we need to understand if there will be any more 5 releases.
Looking here: https://gcc.gnu.org/develop.html#timeline it appears there may be
one or two more, guessing from the prior patterns of releases. So if you have
time, OK.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 13 19:52:58 2017
New Revision: 246917

URL: https://gcc.gnu.org/viewcvs?rev=246917=gcc=rev
Log:
PR sanitizer/80403
* fold-const.c (fold_ternary_loc): Revert
use op0 instead of fold_convert_loc (loc, type, arg0) part of
2017-04-12 change.

* g++.dg/ubsan/pr80403-2.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ubsan/pr80403-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #8)
> > > It does for me provided the patch is applied at the proper location:
> > > 
> > > @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
> > > 
> > > Applying the patch with patch -p0 -i patch-59910 put the fix in the wrong
> > > location
> > > 
> > > @@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul
> > > 
> > > Regtesting in progress. Any objection if I do the back port?
> >
> > This is a little confusing. The original patch is in
> > gfc_match_structure_constructor (). Is your new patch still in this function
> > for 5 or in a different function? Maybe post your clean diff
> > so we can understand better. Is the original patch in the wrong place?
> 
> Applying the patch
> 
> Index: gcc/fortran/primary.c
> ===
> --- gcc/fortran/primary.c (revision 230497)
> +++ gcc/fortran/primary.c (working copy)
> @@ -2722,6 +2722,12 @@ gfc_match_structure_constructor (gfc_sym
>return MATCH_ERROR;
>  }
>  
> +  /* If a structure constructor is in a DATA statement, then each entity
> + in the structure constructor must be a constant.  Try to reduce the
> + expression here.  */
> +  if (gfc_in_match_data ())
> +gfc_reduce_init_expr (e);
> +
>*result = e;
>return MATCH_YES;
>  }
> 
> to the gcc5 branch located it at
> 
> @@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul
> 
> Indeed this is surprising, but don't ask me what went wrong.
> 
> The correct patch for gcc5 is
> 
> --- ../5_clean/gcc/fortran/primary.c  2016-03-24 09:51:26.0 +0100
> +++ ../5_work/gcc/fortran/primary.c   2017-04-12 16:29:52.0 +0200
> @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
> return MATCH_ERROR;
>   }
>  
> +  /* If a structure constructor is in a DATA statement, then each entity
> + in the structure constructor must be a constant.  Try to reduce the
> + expression here.  */
> +  if (gfc_in_match_data ())
> +gfc_reduce_init_expr (e);
> +
> *result = e;
> return MATCH_YES;
>  }
> 
> which applies cleanly.

If regression tests OK and new test case. OK to commit to 5.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
Looks like we have many reg_use_datas for the same register.  I haven't looked
why yet (maybe that too is a bug), but the fallout shouldn't be as catastrophic
as this.

Testing a patch.

[Bug tree-optimization/80420] missing -Wformat-overfow on snprintf with excessive bound

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-13
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/80420] New: missing -Wformat-overfow on snprintf with excessive bound

[msebor at gcc dot gnu.org]

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

Bug ID: 80420
   Summary: missing -Wformat-overfow on snprintf with excessive
bound
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The -Wformat-overflow/truncation options fail to diagnose the buffer overflow
in calls to snprintf where the specified bound is greater than the size of the
destination object.  Both the overflow (when detected) and the excessive bound
(when the size of the function's output cannot be determined) should be
diagnosed.

$ cat c.c && gcc -c -O2 -Wall -Wextra -Wpedantic -Werror c.c
char d[4];

void f (void)
{
  __builtin_snprintf (d, 10, "%-s", "123456789");
}

void g (const char *s)
{
  __builtin_snprintf (d, 10, "%-s", s);
}
$

[Bug rtl-optimization/80343] [7 Regression] ICE in extract_constrain_insn, at recog.c:2213 (error: insn does not satisfy its constraints)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed, thanks.

[Bug rtl-optimization/80343] [7 Regression] ICE in extract_constrain_insn, at recog.c:2213 (error: insn does not satisfy its constraints)

[vmakarov at gcc dot gnu.org]

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

--- Comment #3 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Apr 13 18:08:51 2017
New Revision: 246914

URL: https://gcc.gnu.org/viewcvs?rev=246914=gcc=rev
Log:
2017-04-13  Vladimir Makarov  

PR rtl-optimization/80343
* lra-remat.c (update_scratch_ops): Assign original hard reg to
new scratch pseudo.

2017-04-13  Vladimir Makarov  

PR rtl-optimization/80343
* gcc.target/powerpc/pr80343.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80343.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
I actually think that for the test case in comment #4, the warning does
highlight a problem in the code: since the test (p < c) can never be true the
memset can never be called in a valid program.  At -O2 the problem is detected
by -Wstrict-overflow.  Unfortunately, because -Wstrict-overflow is only issued
when an optimization takes place that depends on the absence of an overflow, it
can't be issued at -O1 when the condition isn't removed.  I still think that
eliminating the memset call (or replacing it with a trap) when the size is
known to be excessive is a viable strategy.  (For memset perhaps under an
option to allow for the rare programs that make use of Physical Address
Extension and clear memory regions larger than 2GB.)

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres  ---
> Actually, the null pointer str4 is dereferenced four times:
> at lines 39, 40, 68, 69.

I agree for lines 39 and 68, but in lines it points to the strings 'ABCDEFGH'
and 4_'ABCDEFGH' AFAIU pointers.

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-13
 CC||meissner at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Michael Meissner  ---
While the underlying bug is due to an LRA change, the fix for each of these in
the rs6000 backend is likely to be different.

The first failure (dimode_off) is one of these tests that are so hard-wired to
the compiler that it likely needs to change every so often.

Yes, it can become a regression, but it only happens on a power8/power9 system
and the offset of a load/store is not divisible by 4.  Due to alignment issues,
the DImode load/store is almost always divisible by 4, unless you are loading
up unaligned memory, or specifically add odd numbers to a char * pointer and
convert it to a long pointer.  These should be rare in practice.

The underlying reason is the LD and STD instructions use the bottom 2 bits for
encoding the instruction, while the LFD and STFD instructions allows a full
16-bit offset.

The second failure listed is 79308-1.c that makes sure an optimization I put in
still works.  However, since the optimization is converting a char/short value
to __float128 on a Power9

[Bug target/71778] [6/7 Regression][ARM] ICE using non-constant argument to Neon intrinsic that requires constant arguments

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[zeccav at gmail dot com]

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

--- Comment #11 from Vittorio Zecca  ---
Actually, the null pointer str4 is dereferenced four times:
at lines 39, 40, 68, 69.

[Bug gcov-profile/71672] inlining indirect calls does not work with autofdo

[andi at firstfloor dot org]

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

--- Comment #2 from andi at firstfloor dot org ---
On Wed, Apr 12, 2017 at 12:15:26PM +, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71672
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  CC||marxin at gcc dot gnu.org
>Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
> gnu.org
> 
> --- Comment #1 from Martin Liška  ---
> I will take a look as soon as autofdo issues will be resolved:
> https://github.com/google/autofdo/issues/43

event 79 is an event generated by the perf tools. As a workaround
you can use a older version of the perf tool (it should work even
with newer kernels).

The quipper library autofdo relies on is notoriously bad in keeping
up with perf changes, it only supports whatever ancient version Chrome
is currently shipping.

-Andi

[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
I expect the instrumentation for local arrays is going to behind the majority
of the complaints for sprintf, like the calls in f0, f1, and f2 (and other
nonnull functions).  Local arrays are never allocated at address zero so there
is no value in ubsan instrumenting those.  

Another pointless case is instrumenting function arguments and member arrays
with non-zero offset:

  struct S { char a[4], b[4]; };

  void f4 (struct S s)
  {
__builtin_sprintf (s.a, s.b);
  }

Here ubsan inserts two tests: one for s.a being non-null and another for s.b. 
The second test is redundant given the first, but neither can be true in any
event.  Similarly for f5 (struct S *s) where s (and so s->a) may be null but
s->b cannot.

Since in the myalloc case there arguably is a non-negligible chance that a
returns_nonnull function might return a null pointer despite the attribute I
think that problem would be best dealt with separately from the others here.

[Bug gcov-profile/51975] ICE in gcc in convert_move, at expr.c:326 with fprofile-use when source changes from fprofile-generate

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Well, it's quite old issue and I hope we validate function checksum. Can you
please verify that the issue still exists?

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #13 from Martin Liška  ---
The issue is quite old, however it's probably still valid. Implementing similar
to what valgrind does with '%p' and '%q{VAR}' is elegant solution. I can work
on that for GCC8 when there's an interest?

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
I haven't looked at this the dumps for this failure, but I've just narrowed
down a very similar looking issue.

I've got a case where hard register propagation replaces the use of $2 with $sp
in a load in mips16 mode.  And (thankfully) the assembler flags it as an error.

Not sure if the propagator is failing to verify validity or if the MIPS backend
is returning that it's a valid change incorrectly, but I wouldn't at all be
surprised if the BZ is another instance of the same problem.

[Bug sanitizer/80414] [UBSAN] segfault with -fsanitize=undefined

[chefmax at gcc dot gnu.org]

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

--- Comment #1 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Thu Apr 13 14:52:23 2017
New Revision: 246909

URL: https://gcc.gnu.org/viewcvs?rev=246909=gcc=rev
Log:
PR sanitizer/80414
* ubsan.c (ubsan_expand_bounds_ifn): Pass original index
to ubsan_encode_value.

* c-c++-common/ubsan/bounds-15.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/bounds-15.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/ubsan.c

[Bug rtl-optimization/80343] [7 Regression] ICE in extract_constrain_insn, at recog.c:2213 (error: insn does not satisfy its constraints)

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
I've reproduced it.  It is a combination of scratches with rematerialization. 
I guess it will be fixed in a few days.

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-13
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Jan Hubicka  ---
There is only early inlining happening before instrumentation.  I suppose we
could block early inliner for functions where attribute mismatches (it would
need to block itself for both -fprofile-generate and -fprofile-use).

problem is that if we late inline it, we will end up with function w/o profile
within function with profile, but I plan to add better support for that anyway
because it happens quite frequently for comdats (where profiling is lost) and
for LTO where only some units has been profiled...

[Bug gcov-profile/80031] gcno files contain BB flags that are not used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2017-04-13 00:00:00 |

[Bug gcov-profile/80031] gcno files contain BB flags that are not used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-13
 Ever confirmed|0   |1

[Bug gcov-profile/71672] inlining indirect calls does not work with autofdo

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-13
 Ever confirmed|0   |1

[Bug gcov-profile/79392] MinGW-w64 backend: programs built with --coverage do not create *.gcda files

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I've just tried to reproduce that on openSUSE with mingw32-cross-gcc (6.3.0)
and it looks fine:

$ i686-w64-mingw32-gcc a.c --coverage
$ wine ./a.exe
$ gcov a.exe
File 'a.c'
Lines executed:75.00% of 4
Creating 'a.c.gcov'

$ cat a.c.gcov 
-:0:Source:a.c
-:0:Graph:a.gcno
-:0:Data:a.gcda
-:0:Runs:1
-:0:Programs:1
-:1:  #include 
1:2:  int main(int argc, char** argv) {
1:3:  if (argc >= 2) {
#:4:  printf("argv[1] = %s\n", argv[1]);
-:5:  }
1:6:  return 0;
-:7:  }

Can you please test version 6?

[Bug middle-end/79929] [7 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Well, with -O1 one asks only for cheap optimizations, so the question is if a
warning that relies on more optimizations as this should be enabled at -O1.

We have:
  p_18 = c_17(D) + 5;
...
  if (p_18 < c_17(D))
goto ; [0.00%]
  else
goto ; [0.00%]

   [0.00%]:
  c.2_7 = (long int) c_17(D);
  p.3_8 = (long int) p_18;
  _9 = c.2_7 - p.3_8;
  _10 = (long unsigned int) _9;
  _11 = n_16 + 5;
  __builtin_memset (_11, 32, _10);

and cpp1 pass manages to fold the _10 into the huge value, but doesn't
similarly fold the pointer comparison.  So either we should not do that at -O1,
or should also be able to fold (A + cst) < A for pointer type A into cst < 0
(only if POINTER_TYPE_OVERFLOW_UNDEFINED ?).

[Bug gcov-profile/47358] Decimal number formatting not localized

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Liška  ---
Confirmed, however very low priority.

[Bug sanitizer/80403] UBSAN: compile time crash with "type mismatch in binary expression" message in / and % expr

[jakub at gcc dot gnu.org]

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

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

Oops, thinko in the committed patch.  COND_EXPR/VEC_COND_EXPR op0's type
doesn't have to be the same as the result type (which needs to be equal to op1
and op2's type).  Will test this and commit as obvious if it passes.

[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Created attachment 41194
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41194=edit
Untested patch

[Bug gcov-profile/78783] gcov-tool fails in gcov_read_counter_mem

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Martin Liška  ---
(In reply to Opera Wang from comment #2)
> We have similar issues in our environment, and I found two situations can
> trigger it.
> 
> 1. When profile2 have more files than profile1, which is fixed in bug 67097

Great.

> 
> 2. When nftw has issues and can't remove all gcda files in output dir.

Well, it can happen when unlink_profile_dir does not have nftw:

static int
unlink_profile_dir (const char *path ATTRIBUTE_UNUSED)
{
#if HAVE_FTW_H
return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);
#else
return -1;
#endif
}

or it can happen that someone copies a gcov file after the function to the
destination
folder (that's ugly).

Anyhow, I've got patch which validates a destination file does not exist.
Can you please test it?

> 
> in gcov-tool.c, unlink_profile_dir:
> return nftw(path, unlink_gcda_file, 64, FTW_DEPTH | FTW_PHYS);
> 
> then later when call dump_one_gcov:
> tag = gcov_read_unsigned ();
> if (tag) // <= here tag would be valid because some gcda files still
> exist in output dir
> 
> nftw is in libc, and on machine1:
> ldd (GNU libc) 2.12, Linux 2.6.32-220.el6.x86_64, RedHat Enterprise Linux 6.2
> nftw can't remove all gcda files, but if I call nftw the 2nd time, then the
> left gcda files will be removed, so it's not a permission issue.
> 
> but on machine2:
> ldd (GNU libc) 2.5, Linux 2.6.18-371.9.1.el5 x86_64, RedHat Enterprise Linux
> 5.7
> nftw works without any problems.
> 
> We have to workaround the 2nd issue by output to a new dir, instead of reuse
> an existing dir.

[Bug c/80419] New: rpmbuild with rpmrc file crashed httpd rebuild

[d.kuc...@dk-software.org]

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

Bug ID: 80419
   Summary: rpmbuild with rpmrc file crashed httpd rebuild
   Product: gcc
   Version: unknown
   URL: http://https://bugzilla.redhat.com/show_bug.cgi
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.kuc...@dk-software.org
CC: d.kuc...@dk-software.org
  Target Milestone: ---
  Host: Fedora 25
Target: x86_64
 Build: 6.3.1

Created attachment 41193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41193=edit
gcc version

when i rebuild the src.rpm with my .rpmrc file i became the error "illegal
instruction", when i create the rpm without the .rpmrc file it works perfectly!
other builds with the rpmrc file (pure-ftpd, mpd, cantata) works!

i use the httpd-2.4.25-3.fc25.src.rpm file 

This is my .rpmrc file:

[builduser@buildsrv]: cat /home/builduser/.rpmrc 
optflags: x86_64 %{__global_cflags} -m64 -march=core2 -mtune=core2

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
This has been fixed by revision r230580 (pr59910). If there is no objection, I
can back port the fix to the gcc5 branch.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> > It does for me provided the patch is applied at the proper location:
> > 
> > @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
> > 
> > Applying the patch with patch -p0 -i patch-59910 put the fix in the wrong
> > location
> > 
> > @@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul
> > 
> > Regtesting in progress. Any objection if I do the back port?
>
> This is a little confusing. The original patch is in
> gfc_match_structure_constructor (). Is your new patch still in this function
> for 5 or in a different function? Maybe post your clean diff
> so we can understand better. Is the original patch in the wrong place?

Applying the patch

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 230497)
+++ gcc/fortran/primary.c   (working copy)
@@ -2722,6 +2722,12 @@ gfc_match_structure_constructor (gfc_sym
   return MATCH_ERROR;
 }

+  /* If a structure constructor is in a DATA statement, then each entity
+ in the structure constructor must be a constant.  Try to reduce the
+ expression here.  */
+  if (gfc_in_match_data ())
+gfc_reduce_init_expr (e);
+
   *result = e;
   return MATCH_YES;
 }

to the gcc5 branch located it at

@@ -245,6 +245,12 @@ match_integer_constant (gfc_expr **resul

Indeed this is surprising, but don't ask me what went wrong.

The correct patch for gcc5 is

--- ../5_clean/gcc/fortran/primary.c2016-03-24 09:51:26.0 +0100
+++ ../5_work/gcc/fortran/primary.c 2017-04-12 16:29:52.0 +0200
@@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym
return MATCH_ERROR;
  }

+  /* If a structure constructor is in a DATA statement, then each entity
+ in the structure constructor must be a constant.  Try to reduce the
+ expression here.  */
+  if (gfc_in_match_data ())
+gfc_reduce_init_expr (e);
+
*result = e;
return MATCH_YES;
 }

which applies cleanly.

[Bug libfortran/67540] string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> This test case is wrong.

Well, I don't if strings comparison is allowed or forbidden by the standard
when one string is a non-associated pointer as in

program test
  implicit none
  call source_check()
contains
  subroutine source_check()
character(len=:), pointer :: str4
str4 => null()
print *, (str4 < '1')
  end subroutine source_check
end program test

which gives

../../../p_work/libgfortran/intrinsics/string_intrinsics_inc.c:90:7: runtime
error: null pointer passed as argument 1, which is declared to never be null
 T

If this is forbidden by the standard, the test could be fixed with

---
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03  
2011-02-23 16:42:20.0 +0100
+++ allocate_deferred_char_scalar_1.f03 2017-04-13 14:49:35.0 +0200
@@ -36,7 +36,8 @@ contains
 if(.not.associated(str4, str)) call abort()
 str4 => null()
 str = '12a56b78'
-if(str4 == '12a56b78') call abort()
+!if(str4 == '12a56b78') call abort()
+if(associated(str4)) call abort()
 str4 = 'ABCDEFGH'
 if(str == 'ABCDEFGH') call abort()
 allocate(str5, source=str)
@@ -65,7 +66,8 @@ contains
 if(.not.associated(str4, str)) call abort()
 str4 => null()
 str = 4_'12a56b78'
-if(str4 == 4_'12a56b78') call abort()
+!if(str4 == 4_'12a56b78') call abort()
+if(associated(str4)) call abort()
 str4 = 4_'ABCDEFGH'
 if(str == 4_'ABCDEFGH') call abort()
 allocate(str5, source=str)

If it is allowed, then null pointers should be handled in

compare_string (gfc_charlen_type len1, const CHARTYPE *s1,
gfc_charlen_type len2, const CHARTYPE *s2)

> It dereferences thrice a NULL pointer str4.

I see it only twice.

[Bug ada/80418] libgnat_pic.a built but not installed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Ah, it's new in GCC 7 ...

[Bug gcov-profile/35038] GCOV - using "--coverage" results in libgcov.a(_gcov.o) is referenced by DSO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Martin Liška  ---
Very old issue with no reproducer, closing. Please reopen if you have a
test-case.

[Bug gcov-profile/53414] gcov does not generate 'Lines' record for final block of functions

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Martin Liška  ---
Closing as there's no reproducer and the GCC release is very old.

[Bug gcov-profile/59735] code coverage options generate corrupted gcno file

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
No test-case and as 4.8 is not support, I'm closing that as invalid. Please
reopen if you have a test-case.

[Bug gcov-profile/53915] gcov can call format_gcov with top > bottom, which is unexpected and gives 99.99%

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #7 from Martin Liška  ---
I've just tried to build latest release of mpfr with --coverage and make check.
But looks the problematic source file wasn't executed. Thus I'm planning to
commit assert to gcov that will ensure that top <= bottom and we hopefully find
a reproducer.

[Bug gcov-profile/60321] compiler error: in gcov_open, at gcov-io.c:82

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
Closing as invalid as 4.8 is not supported release. Apart from that a
reproducible test-case would be needed.

[Bug gcov-profile/67924] Gcov statistics branches error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
No reply, thus closing as invalid. Note that 4.1.1 is very old release. If the
issues is still present, please reopen the issue.

[Bug tree-optimization/70427] autofdo bootstrap generates wrong code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Hi Andi. Bit confused whether it's really a miscompilation or not? If yes, can
you please attach gcda file made from the fda file?

[Bug gcov-profile/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0
  Known to fail||5.4.0, 6.3.0

--- Comment #4 from Martin Liška  ---
Fixed on trunk, queued for active branches.

[Bug gcov-profile/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Apr 13 11:51:28 2017
New Revision: 246903

URL: https://gcc.gnu.org/viewcvs?rev=246903=gcc=rev
Log:
Do not call memcpy with a NULL argument (PR gcov-profile/80413).

2017-04-13  Martin Liska  

PR gcov-profile/80413
* gcov-io.c (gcov_write_string): Copy to buffer just when
allocated size is greater than zero.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcov-io.c

[Bug testsuite/80416] FAIL: g++.dg/torture/pr79671.C -O2 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug ada/80418] New: libgnat_pic.a built but not installed

[rguenth at gcc dot gnu.org]

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

Bug ID: 80418
   Summary: libgnat_pic.a built but not installed
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

> find . -name libgnat_pic.a
./gcc/ada/rts/libgnat_pic.a
./gcc/ada/rts_32/libgnat_pic.a

but make install doesn't install it.  When building GCC itself with -fPIE
linking fails because we link against static host libgnat which isn't PIC/PIE.

libgcc.a and libstdc++.a are PIC anyway, why isn't libgnat?

[Bug target/79712] Clang smarter about unrolling in fhourstones benchmark

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #11 from wilco at gcc dot gnu.org ---
Bin mentioned that the vectorizer could first try vectorizing loops and if that
fails unroll them given that vectorization is a special kind of unrolling. All
the infrastructure is already there given it can emit unrolled
alignment/trailing loops and has done the analysis already.

[Bug testsuite/80416] FAIL: g++.dg/torture/pr79671.C -O2 execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 13 11:17:38 2017
New Revision: 246902

URL: https://gcc.gnu.org/viewcvs?rev=246902=gcc=rev
Log:
2017-04-13  Richard Biener  

PR testsuite/80416
* g++.dg/torture/pr79671.C: Fix asm constraints.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/torture/pr79671.C

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] Using|[5/6 Regression] Using lto
   |lto causes gtkmm/gparted|causes gtkmm/gparted and
   |and gtkmm/inkscape compile  |gtkmm/inkscape compile to
   |to fail |fail

--- Comment #29 from Jakub Jelinek  ---
Fixed on the trunk so far, thanks Honza.

[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
There are two major reasons for the forcing of -fno-delete-null-pointer-checks
by the null pointer sanitizers.
One is to avoid relying too much on UB assumptions, where the optimizers say
that something can't be NULL e.g. based on nonnull/returns_nonnull attributes
and various other cases, which can't happen in valid code, but can happen in
invalid code the sanitizers are trying to help diagnose.
And the second reason is that the sanitization itself is performed by comparing
pointers against NULL and if -fdelete-null-pointer-checks is on, the optimizers
would often optimize those away.

One way to approach this is stop enabling -fno-delete-null-pointer-checks for
the sanitizers and start by replacing all flag_delete_null_pointer_checks with
that || ubsan_null_sanitization_active, then argue about if some of those could
be reverted one by one.

[Bug debug/80321] [7 regression] infinite recursion with inlining of nested function and debug info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug bootstrap/79255] [6 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[jakub at gcc dot gnu.org]

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

Bug 80321 Summary: [7 regression] infinite recursion with inlining of nested 
function and debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80321

   What|Removed |Added

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

[Bug debug/80321] [7 regression] infinite recursion with inlining of nested function and debug info

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Thu Apr 13 11:05:09 2017
New Revision: 246900

URL: https://gcc.gnu.org/viewcvs?rev=246900=gcc=rev
Log:
PR debug/80321
* dwarf2out.c (decls_for_scope): Ignore declarations of
current_function_decl in BLOCK_NONLOCALIZED_VARS.

* gcc.dg/debug/pr80321.c: New test.

2017-04-13  Eric Botcazou  

* gnat.dg/debug10.adb: New test.
* gnat.dg/debug10_pkg.ads: New helper.

Added:
trunk/gcc/testsuite/gcc.dg/debug/pr80321.c
trunk/gcc/testsuite/gnat.dg/debug10.adb
trunk/gcc/testsuite/gnat.dg/debug10_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Martin Liška from comment #2)
> One another observation, working sets are wrong as they do not respect # of
> runs:
> 
> 1 run:
> threshold = 1, sum_all=190579
> 
> 10 tuns:
> threshold = 10, sum_all=1905790

Ahh, no it's correct as the counters are also growing with multiple runs.

[Bug testsuite/80416] FAIL: g++.dg/torture/pr79671.C -O2 execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
or better

  asm volatile ("" : "=r" (q) : "0" (q));

[Bug testsuite/80416] FAIL: g++.dg/torture/pr79671.C -O2 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-13
  Component|rtl-optimization|testsuite
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
What DSE1 does is ok.  After DSE1 we have

(insn 11 2 13 2 (set (mem/j/c:SI (reg/f:DI 328 sfp) [0 y+0 S4 A128])
(const_int 0 [0]))
"/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C":14
5 {movsi_internal}
 (nil))
(insn 13 11 14 2 (set (reg:DI 347 [ q ])
(asm_operands/v:DI ("") ("=r") 0 [
(reg/f:DI 328 sfp)
]
 [
(asm_input:DI ("r")
/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C:16)
]
 []
/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C:16))
"/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C":16
-1
 (nil))
(insn 14 13 18 2 (set (reg:SI 341 [  ])
(mem:SI (reg:DI 347 [ q ]) [2 q_3->i+0 S4 A32]))
"/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C":17
5 {movsi_internal}
 (expr_list:REG_DEAD (reg:DI 347 [ q ])
(nil)))
(insn 18 14 19 2 (set (reg/i:SI 8 r8)
(reg:SI 341 [  ]))
"/space/rguenther/src/svn/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr79671.C":18
5 {movsi_internal}
 (expr_list:REG_DEAD (reg:SI 341 [  ])
(nil)))

but RA breaks it.  I think

  asm volatile ("" : "=r" (q) : "r" (q));

in the testcase is bogus.

  asm volatile ("" : "+r" (q) : "r" (q));

works.  The idea of the asm is to do nothing but allocate both input and output
to the same register...  I probably failed to express this.

[Bug rtl-optimization/80416] FAIL: g++.dg/torture/pr79671.C -O2 execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
  Component|target  |rtl-optimization

--- Comment #1 from Richard Biener  ---
Weird.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #24)
> Actually, the volatile attribute conflicts with the intent(in) of the final
> variable. But making the function result variable 'integral' volatile, does
> the job. Thanks for the suggestion. And sorry again for not producing a
> smaller case.

Could you maybe do the following:

- Use your normal sources

- Change the compilation options to add -fdump-tree-all to the relevant
  file

- Copy all the generated xxx.f90.whatever files (the tree dumps)
  to a different directory

- Change intent(in) to volatile

- Rerun the compilation

and then run diff on the tree dump files to the original ones?
If you see anything suspicious in the diffs, that might point
to something.  Maybe you could also attach the diffs, so somebody
else could take a look at it.

[Bug gcov-profile/77698] Unrolled loop not considered hot after profiling

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
One another observation, working sets are wrong as they do not respect # of
runs:

1 run:
threshold = 1, sum_all=190579

10 tuns:
threshold = 10, sum_all=1905790

[Bug c++/80417] New: GCC does not accept a well-formed code of using declaration with pack expansion results inheriting constructor

[boostcpp at gmail dot com]

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

Bug ID: 80417
   Summary: GCC does not accept a well-formed code of using
declaration with pack expansion results inheriting
constructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boostcpp at gmail dot com
  Target Milestone: ---

GCC does not accept a well-formed code of using declaration with pack expansion
results inheriting constructor.

Following code shall be well-formed but GCC reject it.

struct A
{
A( int ) { } 
} ;

template < typename ... Types >
struct B : Types ...
{
// Inheriting Constructor
// GCC reject it
/// Clang accept it
using Types::Types... ;
} ;

int main()
{
B obj(0) ; 
}

Although I have no practical application for this code, I see no wording in the
standard prohibit this so this shall be well-formed.

[Bug target/80416] New: FAIL: g++.dg/torture/pr79671.C -O2 execution test

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

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

Bug ID: 80416
   Summary: FAIL: g++.dg/torture/pr79671.C   -O2  execution test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: ia64-*-*

On ia64, pr79671.C fails with -O2, -O3 and -Os, but succeeds with -O1 and -O2
-flto.

When it fails foo looks like this:

   0x4800 <+0>: [MMI]   nop.m 0x0
   0x4801 <+1>: st4 [r12]=r0
   0x4802 <+2>: nop.i 0x0;;
   0x4810 <+16>:[MIB]   ld4 r8=[r14]
   0x4811 <+17>:nop.i 0x0
   0x4812 <+18>:br.ret.sptk.many b0;;

When it succeeds it looks like this:

   0x4720 <+0>: [MMI]   adds r14=4,r12;;
   0x4721 <+1>: st4 [r14]=r0
   0x4722 <+2>: nop.i 0x0;;
   0x4730 <+16>:[MIB]   ld4 r8=[r14]
   0x4731 <+17>:nop.i 0x0
   0x4732 <+18>:br.ret.sptk.many b0;;

Looks like the miscompilation happens during the dse1 pass.

[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Btw, for targets which default to -fno-delete-null-pointer-checks nonnull
sanitizing is of course pointless.

I think we should simply make sure to instrument early enough before things
are folded...  or should restore -fdelete-null-pointer-checks after
instrumentation.

We also instrument

   [0.00%]:
  if ("%%" == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data1);

instrumenting "%%" looks pointless (again, instrumentation itself can
rely on -fdelete-null-pointer-checks semantics when deciding to elide
null pointer checks).

[Bug gcov-profile/80413] sanitizer detects undefined behaviour in gcov-io.c using -ftest-coverage

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
I've got patch in testing.

[Bug sanitizer/79265] -fsanitize=undefined inserts unnecessary null pointer tests

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
Summary|[7 regression]  |-fsanitize=undefined
   |-fsanitize=undefined|inserts unnecessary null
   |inserts unnecessary null|pointer tests
   |pointer tests   |

--- Comment #7 from Richard Biener  ---
The bogus optimization is done via

 (simplify
  (cmp (convert? addr@0) integer_zerop)
  (if (tree_single_nonzero_warnv_p (@0, NULL))
   { constant_boolean_node (cmp == NE_EXPR, type); })))

and

bool
tree_single_nonzero_warnv_p (tree t, bool *strict_overflow_p)
{
...
case ADDR_EXPR:
  {
tree base = TREE_OPERAND (t, 0);

if (!DECL_P (base))
  base = get_base_address (base);

if (base && TREE_CODE (base) == TARGET_EXPR)
  base = TARGET_EXPR_SLOT (base);

if (!base)
  return false;

/* For objects in symbol table check if we know they are non-zero.
   Don't do anything for variables and functions before symtab is
built;
   it is quite possible that they will be declared weak later.  */
int nonzero_addr = maybe_nonzero_address (base);
if (nonzero_addr >= 0)
  return nonzero_addr;

/* Constants are never weak.  */
if (CONSTANT_CLASS_P (base))
  return true;

return false;

plus

static int
maybe_nonzero_address (tree decl)
{
  if (DECL_P (decl) && decl_in_symtab_p (decl))
if (struct symtab_node *symbol = symtab_node::get_create (decl))
  return symbol->nonzero_address ();

  /* Function local objects are never NULL.  */
  if (DECL_P (decl)
  && (DECL_CONTEXT (decl)
  && TREE_CODE (DECL_CONTEXT (decl)) == FUNCTION_DECL
  && auto_var_in_fn_p (decl, DECL_CONTEXT (decl
return 1;

so if we think that we have to handle the possibility of automatic vars
being at address zero with -fno-delete-null-pointer-checks we have to
guard that test.

More fine-grained control would be nice as well.

[Bug sanitizer/70878] [5/6 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7680

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |5.5

[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[hubicka at gcc dot gnu.org]

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

--- Comment #28 from Jan Hubicka  ---
Author: hubicka
Date: Thu Apr 13 08:04:52 2017
New Revision: 246899

URL: https://gcc.gnu.org/viewcvs?rev=246899=gcc=rev
Log:
PR lto/69953 
* ipa-visibility.c (non_local_p): Fix typos.
(localize_node): When localizing symbol in same comdat group,
dissolve the group only when we know external symbols are going
to be privatized.
(function_and_variable_visibility): Do not localize DECL_EXTERNAL.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-visibility.c

[Bug c++/80415] [7 Regression] bogus "invalid initialization of reference" error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

--- Comment #32 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #30)
> I didn't close it because I wanted to see updated benchmark numbers.  Either
> I'll grab the benchmark, or if somebody else posts the latest numbers, we
> can close it or keep open depending on that.

gcc7 -O3:LU  Mflops:  5444.74
gcc7 -Ofast: LU  Mflops:  5385.51
gcc6 -O3:LU  Mflops:  5515.91
gcc6 -Ofast: LU  Mflops:  5487.94

so there's a <2% regression remaining (noise level is ~0.5%).

[Bug other/79703] [meta-bug] SciMark 2.0 performance issues

[rguenth at gcc dot gnu.org]

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

Bug 79390 Summary: [7 Regression] 10% performance drop in SciMark2 LU after 
r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390

   What|Removed |Added

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

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #31 from Richard Biener  ---
Yep, looks fixed on the tester.

[Bug c++/80415] [7 Regression] bogus "invalid initialization of reference" error

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Started with r240819:

commit f3406a4b75137336c1b9d569d7602dd169cdb2ee
Author: jason 
Date:   Wed Oct 5 22:58:55 2016 +

PR c++/54293 - binding reference to member of temporary

[Bug target/79935] DJGPP: misaligned stack in static constructors

[andris.pavenis at iki dot fi]

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

Andris Pavenis  changed:

   What|Removed |Added

 CC||andris.pavenis at iki dot fi

--- Comment #6 from Andris Pavenis  ---
Failed to reproduce
- gcc-6.3.0
- Windows 10 32 bit VM (VirtualBox) under Fedora 25 x86_64
- DJGPP libc trunk version (should also work with DJGPP v2.05)

Alignments supported by GCC (up to 128 seems) to work OK for me.

[Bug c++/80415] New: [7 Regression] bogus "invalid initialization of reference" error

[trippels at gcc dot gnu.org]

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

Bug ID: 80415
   Summary: [7 Regression]  bogus "invalid initialization of
reference" error
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

LLVM trunk doesn't build anymore with gcc-7:

 % cat Arg.ii
struct A {
  A(int, int, const int (&)[0] = {});
};
A fn1() { return {0, 0}; }


 % g++ -c Arg.ii
Arg.ii: In function ‘A fn1()’:
Arg.ii:4:23: error: invalid initialization of reference of type ‘const int
(&)[0]’ from expression of type ‘const int [0]’
 A fn1() { return {0, 0}; }
   ^
Arg.ii:2:3: note: in passing argument 3 of ‘A::A(int, int, const int (&)[0])’
   A(int, int, const int (&)[0] = {});
   ^