[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|during GIMPLE pass, |[8 Regression] during
   |internal compiler error:|GIMPLE pass, internal
   |Segmentation fault (-O1 and |compiler error:
   |above)  |Segmentation fault (-O1 and
   ||above)
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r256164.  Looking into this.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
> Sure, that works for me.

OK, something like this is apparently sufficient:

===
--- cgraphunit.c(revision 259205)
+++ cgraphunit.c(working copy)
@@ -2700,7 +2700,14 @@ symbol_table::finalize_compilation_unit
   if (!in_lto_p && g->have_offload)
 flag_generate_offload = 1;

-  if (!seen_error ())
+  /* FIXME: Disable debug info generation during the LGEN phase of LTO for
+ PE-COFF targets because the copy_lto_debug_sections operation of the
+ simple object support in libiberty is not implemented yet.  */
+  enum debug_info_levels saved_debug_info_level = debug_info_level;
+  if (TARGET_PECOFF && (flag_generate_lto || flag_generate_offload))
+debug_info_level = DINFO_LEVEL_NONE;
+
+  if (debug_info_level > DINFO_LEVEL_NONE && !seen_error ())
 {
   /* Emit early debug for reachable functions, and by consequence,
 locally scoped symbols.  */
@@ -2716,6 +2723,8 @@ symbol_table::finalize_compilation_unit
   /* Finally drive the pass manager.  */
   compile ();

+  debug_info_level = saved_debug_info_level;
+
   timevar_pop (TV_CGRAPH);
 }

[Bug gcov-profile/85336] [GCOV] wrong coverage for builtin functions and "||" logic operators in return statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug gcov-profile/85333] [GCOV] Builtin function is wrongly marked as "-" in gcov

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug gcov-profile/85332] [GCOV] wrong coverage with do-while in swith-case statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 10 Apr 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
> 
> --- Comment #5 from Martin Sebor  ---
> (In reply to rguent...@suse.de from comment #4)
> ...
> > If you eventually expect a true result then please no - this should be
> > undefined.
> 
> The second test case in comment #4 is currently well-defined in C17 (by 6.5.9,
> p6) and requires the function to return true if x and y are adjacent and i is
> +/-1.  (I'm not defending the requirement.)
> 
> There is a proposal for C2X to make the result of the equality comparison
> between a past-the-end pointer and another pointer unspecified instead 
> (N2219).
>  Would you prefer it to be undefined?  (Making it undefined would be a rather
> drastic departure from the historical requirement and likely objectionable to
> the authors.)

Yes, it should be undefined.  GCC treats it as undefined at the moment
because otherwise points-to analysis cannot be used to optimize pointer
equality tests at all which would be a major showstopper.

Also consider the following:

int main()
{
  int a, b = 0;
  int *p = &a+1;
  if (p == &b)
*p = 1;
  return b;
}

is that now valid and required to return 1 if b appens to be adjacent
to a?  points-to says p points to a and thus cannot be used to modify
b.  And IIRC *(&a+1) isn't valid but if &a+1 == &b isn't undefined
but is required to return true if they are adjacent what sense does
it make to _not_ allow a pointer that is equal to &b to access b?

> See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm
> (Scroll down to the Proposed Technical Corrigendum section at the end of the
> paper to read the proposed changes.)

It's not clear to me how "happens to immediately follow the first array 
object in the address space" not always contradicts "single provenance".
&a+1 and &b have different provenance, no?

Given GCC has leeway to pad declarations an implementation could
choose to always pad variables by at least one byte and thus
never making "happens to immediately follow the first array object in the 
address space" true?

What's the intended use of that special case?  Is it to make the
access via p above valid?  If not how is it useful to allow this
kind of comparison?  Users can always go via [u]intptr_t if they
want to compare pointers of different "provenance" so why's it
necessary to add an ability to do so without???  That just
needessly complicates implementations IMHO.

So that -f[no-]provenance stuff is bollocks IMHO, whoever invented
it must be making sth up on a sheet of paper rather than addressing
a real problem.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenther at suse dot de]

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

--- Comment #14 from rguenther at suse dot de  ---
On Wed, 11 Apr 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238
> 
> --- Comment #13 from Eric Botcazou  ---
> > Sure, that works for me.
> 
> OK, something like this is apparently sufficient:

I think we do need to run dwarf2out_early_finish for the FAT part
of the object file so please move this to dwarf2out_early_finish,
like for example with

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 259308)
+++ gcc/dwarf2out.c (working copy)
@@ -31807,7 +31808,11 @@ dwarf2out_early_finish (const char *file
   early_dwarf_finished = true;

   /* Do not generate DWARF assembler now when not producing LTO bytecode.  
*/
-  if (!flag_generate_lto && !flag_generate_offload)
+  if (!flag_generate_lto && !flag_generate_offload
+  /* FIXME: Disable early debug sections for PE-COFF targets because the
+copy_lto_debug_sections operation of the simple object support in
+libiberty is not implemented yet.  */
+  || TARGET_PECOFF)
 return;

   /* Now as we are going to output for LTO initialize sections and labels

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I'll take a look.

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #2 from Martin Liška  ---
Started with r249365.

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
Version|unknown |8.0
 Ever confirmed|0   |1

[Bug target/85324] missing constant propagation on SSE/AVX conversion intrinsics

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
  _2 = __builtin_ia32_cvttps2dq ({ 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 });
  _3 = _2 + { 1, 1, 1, 1 };
..
  _2 = __builtin_ia32_cvttps2qq128_mask ({ 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 }, {
0, 0 }, 255);
  _3 = _2 + { 1, 1 };
..
  _2 = __builtin_ia32_cvttpd2dq ({ 1.0e+0, 1.0e+0 });
  _3 = _2 + { 1, 1, 1, 1 };
..
  _2 = __builtin_ia32_cvttpd2qq128_mask ({ 1.0e+0, 1.0e+0 }, { 0, 0 }, 255);
  _3 = _2 + { 1, 1 };
..
  _2 = __builtin_ia32_pmovdw128_mask ({ 1, 1, 1, 1 }, { 0, 0, 0, 0, 0, 0, 0, 0
}, 255);
  _3 = _2 + { 1, 1, 1, 1, 1, 1, 1, 1 };

the middle-end has representations for all of those and can constant-fold them.

I suggest to fold the builtins to middle-end codes in the targets
gimple_fold_builtin hook.  For the mask cases with a not always execute mask
the story may be different (exposing this to the middle-end requires a
two-vector "permutation" which might not combine back to the desired ops),
but maybe even then constant folding is beneficial in some cases (and then
good enough with the middle-end exposure?).

[Bug target/85317] missing constant propagation on _mm(256)_movemask_*

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Task for the gimple_fold_builtin hook.

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/85330] -Os generates bigger code than -O2 due to disabled strlen pass

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I guess individual parts of the pass should be guarded with
optimize_*_for_speed () rather than disabling it as whole.  IIRC some
transforms it does make code bigger, some don't.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> I think we do need to run dwarf2out_early_finish for the FAT part
> of the object file so please move this to dwarf2out_early_finish,
> like for example with

But then we also need the first kludge in the back-end, otherwise we ICE:

during IPA pass: fnsummary
t.c:6:1: internal compiler error: in dwarf2out_die_ref_for_decl, at
dwarf2out.c:5854

[Bug gcov-profile/85337] New: [GCOV] inconsistent coverage in swith-case statement

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85337
   Summary: [GCOV] inconsistent coverage in swith-case statement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

cat small.c

#include 

static int func(int i) {
  int a = 0;
  switch (i) {
case 8:
  printf("8\n");
  a = 6;
case 0:
  ;
case 3:
  ;
case 2:
  printf("2\n"); break;
case 1:
  ;
case 7: a = 7;
case 9: printf("9\n"); break;
default: printf("4 or 5 or 6\n"); a = 1;
  }
  return a;
}


int main() {
  int i;
  for (i = 0; i < 10; ++i)
func(i);
  return 0;
}
root@localhost:~/ccv# gcc --coverage small.c; ./a.out; gcov-8 small.c; cat
small.c.gcov
2
9
2
2
4 or 5 or 6
4 or 5 or 6
4 or 5 or 6
9
8
2
9
File 'small.c'
Lines executed:100.00% of 17
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
-:2:#include 
-:3:
   10:4:static int func(int i) {
   10:5:  int a = 0;
   10:6:  switch (i) {
1:7:case 8:
1:8:  printf("8\n");
1:9:  a = 6;
4:   10:case 0:
-:   11:  ;
-:   12:case 3:
-:   13:  ;
-:   14:case 2:
4:   15:  printf("2\n"); break;
2:   16:case 1:
-:   17:  ;
2:   18:case 7: a = 7;
3:   19:case 9: printf("9\n"); break;
3:   20:default: printf("4 or 5 or 6\n"); a = 1;
-:   21:  }
   10:   22:  return a;
-:   23:}
-:   24:
-:   25:
1:   26:int main() {
-:   27:  int i;
   11:   28:  for (i = 0; i < 10; ++i)
   10:   29:func(i);
1:   30:  return 0;
-:   31:}

Line #10, Line #12, Line #14 are respectively marked as "4", "-", "-". 
I am not claim that this is a bug since I am not sure whether it is the default
behavior of gcov.

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> gcc.target/arm/pr56184.C
> gcc.target/arm/pr59985.C
> gcc.target/arm/pr67989.C
> gcc.target/arm/pr54300.C
> gcc.target/arm/pr55073.C
> gcc.target/s390/pr77822-1.C
> gcc.target/x86_64/abi/ms-sysv/gen.cc
> gcc.target/i386/mpx/chkp-thunk-comdat-1.cc
> gcc.target/i386/mpx/pr66048.cc
> gcc.target/i386/mpx/chkp-thunk-comdat-2.cc
> gcc.target/i386/mpx/pr65531.cc
> gcc.target/powerpc/undef-bool-1.C
> gcc.target/aarch64/pr60675.C
> gcc.target/aarch64/pr81414.C
> gcc.target/aarch64/simd/pr67896.C
> gcc.target/aarch64/sve/const_pred_2.C
> gcc.target/aarch64/sve/vcond_1.C
> gcc.target/aarch64/sve/const_pred_4.C
> gcc.target/aarch64/sve/vcond_1_run.C
> gcc.target/aarch64/sve/const_pred_1.C
> gcc.target/aarch64/sve/tls_2.C
> gcc.target/aarch64/sve/const_pred_3.C
> gcc.target/aarch64/pr81422.C
> 
> tests are broken this way.  I think ms-sysv/gen.cc is probably ok, as it
> just a generator and built with $HOSTCXX rather than target g++.  mpx is
> deprecated and going to be removed in GCC 9, so there is no point trying to
> deal with it.
> arm, s390, aarch64 and powerpc should fix their testsuite.

I think some of the arm tests could well be C tests rather than C++. So maybe
just renaming the file to *.c will be enough.

For the ones that are truly C++ is the recommended approach moving them to
g++.dg and guarding them on the target?

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Wed, 11 Apr 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238
> 
> --- Comment #15 from Eric Botcazou  ---
> > I think we do need to run dwarf2out_early_finish for the FAT part
> > of the object file so please move this to dwarf2out_early_finish,
> > like for example with
> 
> But then we also need the first kludge in the back-end, otherwise we ICE:
> 
> during IPA pass: fnsummary
> t.c:6:1: internal compiler error: in dwarf2out_die_ref_for_decl, at
> dwarf2out.c:5854

Yes, I said we need that anyway...

Darwin should also avoid the work of writing out the early sections
(though it doesn't do any harm there but waste space and time...).
Looks like there's no TARGET_MACHO though.

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Looks obvious.  I wonder whether can_div_trunc_p is a bit too losely
templated...

[Bug testsuite/85326] `make check` fails with `--disable-bootstrap` and `--enable-languages=c`

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to ktkachov from comment #2)
> I think some of the arm tests could well be C tests rather than C++. So
> maybe just renaming the file to *.c will be enough.
> 
> For the ones that are truly C++ is the recommended approach moving them to
> g++.dg and guarding them on the target?

That is what we used to do for decades, e.g. I see around 150 x86 tests in
g++.dg/*/
As I wrote elsewhere, adding g++.target/*/ directories is another option, but
I'd say it should be GCC9 thing if we decide to do that.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
> Yes, I said we need that anyway...

Well, you also said that you were OK for a single kludge in the middle-end,
which seems rather contradictory with having half of it in the back-end.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #43893|0   |1
is obsolete||

--- Comment #18 from Eric Botcazou  ---
Created attachment 43906
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43906&action=edit
Tentative fix v2

[Bug gcov-profile/85338] New: [GCOV] Type conversion leads to incorrect coverage in printf

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85338
   Summary: [GCOV] Type conversion leads to incorrect coverage in
printf
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
#include 

void Test(long long Val, int Amt)
{
  printf("  lshr: 0x%llx \t\t shl: 0x%llx\n", Val >> Amt, Val << Amt);
  printf("  lshr: 0x%llx\t\tshl: 0x%llx\n",
Val >> Amt, Val << Amt);
  printf("  lshr: 0x%llx \t\t shl: 0x%llx\n",
(unsigned long long)Val >> Amt, Val << Amt);
}

int main()
{
  Test(10, 4);

  return 0;
}

$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
  lshr: 0x0  shl: 0xa0
  lshr: 0x0 shl: 0xa0
  lshr: 0x0  shl: 0xa0
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:void Test(long long Val, int Amt)
-:4:{
1:5:  printf("  lshr: 0x%llx \t\t shl: 0x%llx\n", Val >> Amt, Val
<< Amt);
1:6:  printf("  lshr: 0x%llx\t\tshl: 0x%llx\n",
-:7:Val >> Amt, Val << Amt);
2:8:  printf("  lshr: 0x%llx \t\t shl: 0x%llx\n",
1:9:(unsigned long long)Val >> Amt, Val << Amt);
1:   10:}
-:   11:
1:   12:int main()
-:   13:{
1:   14:  Test(10, 4);
-:   15:
1:   16:  return 0;
-:   17:}


Line #8 is wrongly marked as executed twice. 
As can be seen from Line #5 and Line #6, I think this incorrect coverage is
caused by type conversions.

[Bug lto/85339] New: [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Bug ID: 85339
   Summary: [8 Regression] With early LTO debug the early DWARF
misses line-info
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: lto, wrong-debug
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

dwz rightfully complains about bogus DW_AT_decl_file (and also _line/_column?)
beause the early debug doesn't contain .debug_line.  split-dwarf adds a
DW_AT_stmt_list pointing to the main files line tables but obviously
the early debug dwarf needs to stand on its own.

I'm not sure how to access line-info from gdb say for

 <1><19>: Abbrev Number: 2 (DW_TAG_structure_type)
<1a>   DW_AT_name: X
<1c>   DW_AT_byte_size   : 8
<1d>   DW_AT_decl_file   : 1
<1e>   DW_AT_decl_line   : 1
<1f>   DW_AT_decl_column : 8
<20>   DW_AT_sibling : <0x3b>
 <2><24>: Abbrev Number: 3 (DW_TAG_member)
<25>   DW_AT_name: a
<27>   DW_AT_decl_file   : 1
<28>   DW_AT_decl_line   : 1
<29>   DW_AT_decl_column : 16
<2a>   DW_AT_type: <0x3b>
<2e>   DW_AT_data_member_location: 0

maybe gdb just ignores that info (why do we output it then?).  Breakpoints
seem to work just fine beause the LTRANS unit will have a proper .debug_line.
So I'm really not sure what consumer uses the symbolic location attributes
on decls and types?

Note we already output .debug_line into the early debug at -g3 so the fix
might be as simple as enabling that also for -g.

Thus testing the following:

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 259308)
+++ gcc/dwarf2out.c (working copy)
@@ -31681,6 +31682,7 @@ static void
 dwarf2out_early_finish (const char *filename)
 {
   set_early_dwarf s;
+  char dl_section_ref[MAX_ARTIFICIAL_LABEL_BYTES];

   /* PCH might result in DW_AT_producer string being restored from the
  header compilation, so always fill it with empty string initially
@@ -31829,6 +31835,16 @@ dwarf2out_early_finish (const char *file
ctnode != NULL; ctnode = ctnode->next)
 add_sibling_attributes (ctnode->root_die);

+  /* AIX Assembler inserts the length, so adjust the reference to match the
+ offset expected by debuggers.  */
+  strcpy (dl_section_ref, debug_skeleton_line_section_label);
+  if (XCOFF_DEBUGGING_INFO)
+strcat (dl_section_ref, DWARF_INITIAL_LENGTH_SIZE_STR);
+
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
+add_AT_lineptr (comp_unit_die (), DW_AT_stmt_list,
+   dl_section_ref);
+
   if (have_macinfo)
 add_AT_macptr (comp_unit_die (), DEBUG_MACRO_ATTRIBUTE,
   macinfo_section_label);
@@ -31898,11 +31914,6 @@ dwarf2out_early_finish (const char *file
   output_macinfo (debug_skeleton_line_section_label, true);
   dw2_asm_output_data (1, 0, "End compilation unit");

-  /* Emit a skeleton debug_line section.  */
-  switch_to_section (debug_skeleton_line_section);
-  ASM_OUTPUT_LABEL (asm_out_file, debug_skeleton_line_section_label);
-  output_line_info (true);
-
   if (flag_fat_lto_objects)
{
  vec_free (macinfo_table);
@@ -31910,6 +31921,10 @@ dwarf2out_early_finish (const char *file
}
 }

+  /* Emit a skeleton debug_line section.  */
+  switch_to_section (debug_skeleton_line_section);
+  ASM_OUTPUT_LABEL (asm_out_file, debug_skeleton_line_section_label);
+  output_line_info (true);

   /* If we emitted any indirect strings, output the string table too.  */
   if (debug_str_hash || skeleton_debug_str_hash)

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
It's fishy as we have b::b that has create an alias to __ct_base:

#0  symtab_node::create_reference (this=, referred_node=,
use_type=IPA_REF_ALIAS, stmt=) at ../../gcc/symtab.c:604
#1  0x00a7048b in symtab_node::resolve_alias (this=, target=, transparent=false) at ../../gcc/symtab.c:1670
#2  0x00a86700 in symbol_table::process_same_body_aliases
(this=0x767aa100) at ../../gcc/cgraphunit.c:709
#3  0x0075d516 in c_parse_final_cleanups () at
../../gcc/cp/decl2.c:4683
#4  0x00ec25df in compile_file () at ../../gcc/toplev.c:455
#5  0x00646d45 in do_compile () at ../../gcc/toplev.c:2132
#6  toplev::main (this=this@entry=0x7fffd87e, argc=,
argc@entry=20, argv=, argv@entry=0x7fffd978) at
../../gcc/toplev.c:2267
#7  0x006492fb in main (argc=20, argv=0x7fffd978) at
../../gcc/main.c:39

Is it valid to clone the __ct_comp and redirect the alias for the clones?
Nathan?

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de  ---
On Wed, 11 Apr 2018, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238
> 
> --- Comment #17 from Eric Botcazou  ---
> > Yes, I said we need that anyway...
> 
> Well, you also said that you were OK for a single kludge in the middle-end,
> which seems rather contradictory with having half of it in the back-end.

Ah, I refered to not adding another target hook for the cut-off in
dwarf2out_early_finish, sorry for the confusion.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
(In reply to Eric Botcazou from comment #18)
> Created attachment 43906 [details]
> Tentative fix v2

Looks good to me, aka OK if it passes whatever testing you think is sufficient.

[Bug gcov-profile/85337] [GCOV] inconsistent coverage in swith-case statement

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[chefmax at gcc dot gnu.org]

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

--- Comment #7 from chefmax at gcc dot gnu.org ---
(In reply to Dmitry Vyukov from comment #6)
> Right!
> 
> Unpoisoning before restoring SP looks like a reasonable and simple solution
> to me. I don't see any potential downsides.
> 
> Do you mind submitting a fix for this?
> 
> Thanks

Sure, but it seems that it's not so simple as I thought... it can make some
time to cook a proper fix (although I can attach a dirty workaround for x86_64
here to unblock your progress on a kernel side).

[Bug gcov-profile/85338] [GCOV] Type conversion leads to incorrect coverage in printf

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug testsuite/85340] New: allocate_deferred_char_scalar_1.f03 dereferences null pointer

[zeccav at gmail dot com]

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

Bug ID: 85340
   Summary: allocate_deferred_char_scalar_1.f03 dereferences null
pointer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Testsuite program allocate_deferred_char_scalar_1.f03 at lines 68 and 69
dereferences pointer str4 which was nullified at line 66.
Same at lines 39 and 40.

This is wrong and should be detected by -fcheck=pointer option.

Putting "if(!s1)  runtime_error ("Dereferencing null pointer");" before line 90
of libgfortran/intrinsics/string_intrinsics_inc.c detects the bugs at lines 68
and 39.

On trunk 259205.

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
With this detailed location info on types one should be able to nearly re-build
a 1:1 source equivalent from debug info - for types ;)

Hunk missing in the patch:

@@ -31045,7 +31046,8 @@ dwarf2out_finish (const char *)
   /* Reset die CU symbol so we don't output it twice.  */
   comp_unit_die ()->die_id.die_symbol = NULL;

-  /* Remove DW_AT_macro from the early output.  */
+  /* Remove DW_AT_macro and DW_AT_stmt_list from the early output.  */
+  remove_AT (comp_unit_die (), DW_AT_stmt_list);
   if (have_macinfo)
remove_AT (comp_unit_die (), DEBUG_MACRO_ATTRIBUTE);

[Bug sanitizer/85230] asan: false positives in kernel on allocas

[dvyukov at google dot com]

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

--- Comment #8 from Dmitry Vyukov  ---
Depending on how long the proper fix will take. If we are talking about, say, a
week then I will just wait. We have to deal with hundreds of assorted kernel
crashes all over the place anyway.

[Bug target/85203] cmse_nonsecure_caller intrinsic returns incorrect results

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Apr 11 09:47:21 2018
New Revision: 259309

URL: https://gcc.gnu.org/viewcvs?rev=259309&root=gcc&view=rev
Log:
[ARM] Fix PR85203: cmse_nonsecure_caller returns wrong result

__builtin_cmse_nonsecure_caller implementation returns true in almost
all cases due to 2 separate bugs:

* gen_addsi is used instead of gen_andsi to retrieve the lsb
* the lsb boolean value is not negated but the specification [1] says
  the intrinsic should return true for a nonsecure caller and a
  nonsecure caller is characterized with LR's lsb being 0

This was not caught due to (1) lack of runtime test and (2) the existing
RTL scan not taking into account that '.' matches newline in Tcl regular
expressions.

This commit fixes the implementation issues and improves testing of
cmse_nonsecure_caller by (1) adding a runtime test for the secure caller
case and (2) looking for an SET insn of an AND expression in the right
function. This leaves the nonsecure caller case only partly tested
since the exact value being AND and the negation are not covered by the
scan and the existing test infrastructure does not allow 2 separate
compilation and link to be performed. It is enough though to catch the
current incorrect behavior.

The commit also reorganize the scan directives in cmse-1.c to more
easily identify what function they are intended to test in the file.

2018-04-11  Thomas Preud'homme  

Backport from mainline
2018-04-04  Thomas Preud'homme  

gcc/
PR target/85203
* config/arm/arm-builtins.c (arm_expand_builtin): Change
expansion to perform a bitwise AND of the argument followed by a
boolean negation of the result.

gcc/testsuite/
PR target/85203
* gcc.target/arm/cmse/cmse-1.c: Tighten cmse_nonsecure_caller RTL scan
to match a single insn of the baz function.  Move scan directives at
the end of the file below the functions they are trying to test for
better readability.
* gcc.target/arm/cmse/cmse-16.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/cmse/cmse-16.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/arm/arm-builtins.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gcc.target/arm/cmse/cmse-1.c

[Bug target/85341] New: [nvptx] Implement atomic load

[vries at gcc dot gnu.org]

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

Bug ID: 85341
   Summary: [nvptx] Implement atomic load
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Follow-up PR of PR84041 - "[nvptx] Hang in for-3.c" ]

Atm the nvptx port does not define an atomic load insn. Consequently, it goes
through the fallback scenario in expand_atomic_load, and ends up generating a
regular load insn combined with a membar.sys memory barrier.

[ Context:

The __atomic_load builtin is defined as:
...
Built-in Function: type __atomic_load_n (type *ptr, int memorder)

This built-in function implements an atomic load operation. It returns the
contents of *ptr.

The valid memory order variants are __ATOMIC_RELAXED, __ATOMIC_SEQ_CST,
__ATOMIC_ACQUIRE, and __ATOMIC_CONSUME.
...

The atomic_load insn pattern is described like this (with a local fix applied
for https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00517.html ):
...
‘atomic_loadmode’

This pattern implements an atomic load operation with memory model
semantics. Operand 1 is the memory address being loaded from. Operand 0 is the
result of the load. Operand 2 is the memory model to be used for the load
operation.

If not present, the __atomic_load built-in function will resort to a normal
load with memory barriers. 
...
]

If we'd define an atomic_load insn pattern, we could be able to use the pointer
operand to deduce a reduced scope (.gpu or .cta) for the memory barrier.

Say we define memory spaces __global and __shared, then we could used 
membar.gpu for __global and membar.cta for __shared.

Of course, we'd have to annotate libgomp/config/nvptx with the appropriate
namespaces, otherwise we keep generating the same code there.

[Bug target/84041] [nvptx] Hang in for-3.c

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> A conservative fix is to define the memory_barrier insn as membar.sys.

Filed PR85341 - "[nvptx] Implement atomic load" to fix this more optimally.

[Bug target/84041] [nvptx] Hang in for-3.c

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #7 from Tom de Vries  ---
Patch committed, test-case not required.

Marking resolved-fixed.

[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input

[thopre01 at gcc dot gnu.org]

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

--- Comment #4 from Thomas Preud'homme  ---
Author: thopre01
Date: Wed Apr 11 10:07:25 2018
New Revision: 259310

URL: https://gcc.gnu.org/viewcvs?rev=259310&root=gcc&view=rev
Log:
[ARM] Fix PR85261: ICE with FPSCR setter builtin

Instruction pattern for setting the FPSCR expects the input value to be
in a register. However, __builtin_arm_set_fpscr expander does not ensure
that this is the case and as a result GCC ICEs when the builtin is
called with a constant literal.

This commit fixes the builtin to force the input value into a register.
It also remove the unneeded volatile in the existing fpscr test and
fixes the function prototype.

2018-04-11  Thomas Preud'homme  

gcc/
PR target/85261
* config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
into register.

gcc/testsuite/
PR target/85261
* config/arm/arm-builtins.c (arm_expand_builtin): Force input operand
into register.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/fpscr.c

[Bug testsuite/85340] allocate_deferred_char_scalar_1.f03 dereferences null pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on at least gcc-7 and trunk (8.0).

[Bug target/85328] [8 Regression] accessing ymm16 with non-avx512 instruction form

[jakub at gcc dot gnu.org]

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

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

Many patterns rely on ix86_hard_regno_mode_ok not allowing < 512-bit vector
modes in xmm16+ registers.  Unfortunately, the vec_extract_lo_* splitters
provide a loophole for this, by creating e.g. on this testcase V32QImode xmm16
hard register which then is propagated into the vpand.  The patch fixes that by
avoiding that, essentially forcing the low half or quarter vector extraction
from the zmm16+ registers to be a 512-bit move into the other register (which
must be necessarily < xmm16.

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to Martin Liška from comment #3)
> It's fishy as we have b::b that has create an alias to __ct_base:
> 
> #0  symtab_node::create_reference (this= "__ct_comp "/2>, referred_node= "/4>, use_type=IPA_REF_ALIAS, stmt=) at ../../gcc/symtab.c:604
> #1  0x00a7048b in symtab_node::resolve_alias (this= const 0x769192e0 "__ct_comp "/2>, target= "__ct_base "/4>, transparent=false) at ../../gcc/symtab.c:1670
> #2  0x00a86700 in symbol_table::process_same_body_aliases
> (this=0x767aa100) at ../../gcc/cgraphunit.c:709
> #3  0x0075d516 in c_parse_final_cleanups () at
> ../../gcc/cp/decl2.c:4683
> #4  0x00ec25df in compile_file () at ../../gcc/toplev.c:455
> #5  0x00646d45 in do_compile () at ../../gcc/toplev.c:2132
> #6  toplev::main (this=this@entry=0x7fffd87e, argc=,
> argc@entry=20, argv=, argv@entry=0x7fffd978) at
> ../../gcc/toplev.c:2267
> #7  0x006492fb in main (argc=20, argv=0x7fffd978) at
> ../../gcc/main.c:39
> 
> Is it valid to clone the __ct_comp and redirect the alias for the clones?
> Nathan?

Forget about it, issue of this PR is somewhere else. I'm testing a patch
candidate.

[Bug target/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Matthias can you please point to source files of the project?
And can you please attach full preprocessed source file?
Thanks.

[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 11 10:22:36 2018
New Revision: 259311

URL: https://gcc.gnu.org/viewcvs?rev=259311&root=gcc&view=rev
Log:
PR debug/85302
* dwarf2out.c (skip_loc_list_entry): Don't call size_of_locs if
SIZEP is NULL.
(output_loc_list): Pass address of a dummy size variable even in the
locview handling loop.
(index_location_lists): Add comment on why skip_loc_list_entry can't
call size_of_locs.

* g++.dg/debug/dwarf2/pr85302.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr85302.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85302] [8 Regression] ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/85204] [nvptx] infinite loop generated

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
> Todo: revert r241652 on og7 and backport this patch.

Done: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00525.html


Patch with test-case committed to trunk, marking resolved-fixed.

[Bug target/85342] New: [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[zsojka at seznam dot cz]

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

Bug ID: 85342
   Summary: [8 Regression] ICE: SIGSEGV in
copyprop_hardreg_forward_1 (regcprop.c:995) with -O2
-mavx512vl
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 43908
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43908&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -mavx512vl testcase.c -wrapper valgrind,-q
==28884== Invalid read of size 8
==28884==at 0xCA0B0F: copyprop_hardreg_forward_1(basic_block_def*,
value_data*) [clone .isra.23] (regcprop.c:995)
==28884==by 0xCA19B2: (anonymous
namespace)::pass_cprop_hardreg::execute(function*) (regcprop.c:1303)
==28884==by 0xC3A783: execute_one_pass(opt_pass*) (passes.c:2497)
==28884==by 0xC3B0B7: execute_pass_list_1(opt_pass*) (passes.c:2586)
==28884==by 0xC3B0C9: execute_pass_list_1(opt_pass*) (passes.c:2587)
==28884==by 0xC3B0C9: execute_pass_list_1(opt_pass*) (passes.c:2587)
==28884==by 0xC3B114: execute_pass_list(function*, opt_pass*)
(passes.c:2597)
==28884==by 0x89CCDD: cgraph_node::expand() (cgraphunit.c:2139)
==28884==by 0x89E2EA: expand_all_functions (cgraphunit.c:2275)
==28884==by 0x89E2EA: symbol_table::compile() [clone .part.58]
(cgraphunit.c:2624)
==28884==by 0x8A0BE7: compile (cgraphunit.c:2683)
==28884==by 0x8A0BE7: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2717)
==28884==by 0xD67461: compile_file() (toplev.c:480)
==28884==by 0x6CEFC4: do_compile (toplev.c:2132)
==28884==by 0x6CEFC4: toplev::main(int, char**) (toplev.c:2267)
==28884==  Address 0xabababababababab is not stack'd, malloc'd or (recently)
free'd
==28884== 
during RTL pass: cprop_hardreg
testcase.c: In function 'foo':
testcase.c:26:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259308-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259308-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
gcc version 8.0.1 20180411 (experimental) (GCC)

[Bug rtl-optimization/84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |amonakov at gcc dot 
gnu.org
Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE:
   |Segmentation fault (stack   |Segmentation fault (stack
   |overflow in bb_note) w/ |overflow in bb_note) w/
   |selective scheduling|selective scheduling

--- Comment #3 from Alexander Monakov  ---
Fixed on the trunk. Unfortunately the Changelog entry had a typo in the PR#:

Author: amonakov
Date: Wed Apr 11 10:40:07 2018
New Revision: 259313

URL: https://gcc.gnu.org/viewcvs?rev=259313&root=gcc&view=rev
Log:
sel-sched: run cleanup_cfg just before loop_optimizer_init (PR 84659)

  PR rtl-optimization/84659
  * sel-sched-ir.c (sel_init_pipelining): Invoke cleanup_cfg.

testsuite/
  * gcc.dg/pr84659.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr84659.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sel-sched-ir.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84659] [6/7 Regression] ICE: Segmentation fault (stack overflow in bb_note) w/ selective scheduling

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Author: amonakov
Date: Wed Apr 11 10:48:42 2018
New Revision: 259314

URL: https://gcc.gnu.org/viewcvs?rev=259314&root=gcc&view=rev
Log:
fix PR 84659 references in ChangeLog files

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away

[julia.koval at intel dot com]

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

Julia Koval  changed:

   What|Removed |Added

 CC||julia.koval at intel dot com

--- Comment #3 from Julia Koval  ---
Can we just return if zero from the intrinsic code in the header file and
generate proper builtin if not zero? It won't work on O0, but it is an
optimization after all.

[Bug target/85281] [8 Regression] Assembler messages: Error: operand size mismatch for `vpbroadcastb' with -mavx512bw -masm=intel

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 11 11:37:01 2018
New Revision: 259316

URL: https://gcc.gnu.org/viewcvs?rev=259316&root=gcc&view=rev
Log:
PR target/85281
* config/i386/sse.md (iptr): Add V16SFmode and V8DFmode cases.
(_vec_dup): Use a single pattern for modes
other than V2DFmode using iptr mode attribute.
(_vec_dup): Use iptr mode attribute.

* gcc.target/i386/pr85281.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85281.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/85281] [8 Regression] Assembler messages: Error: operand size mismatch for `vpbroadcastb' with -mavx512bw -masm=intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.  The assorted fixes patch is still pending, but that is not known to be
a regression.

[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If you mean adding if (__builtin_constant_p (__B) && __B == 0) return __A; and
similar to all the various intrinsics, then that is not the right thing to do,
it will make the headers much larger and even the IL much larger for the common
case where people aren't using 0 constant.
Doing this in in the fold target hooks is easier and more effective.

Note, Matthias has filed a bunch of other PRs for similar issues recently,
perhaps we want some tracker PR for those.
The general rule is that foldings which result in VECTOR_CST or other constants
should probably go into ix86_fold_builtin, and other foldings should go into
ix86_gimple_fold_builtin.

[Bug libstdc++/85343] New: Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Bug ID: 85343
   Summary: Overload __throw_ios_failure to allow passing errno
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The standard says "When throwing ios_base::failure exceptions, implementations
should provide values of ec that identify the specific reason for the failure."

We currently always use an error_code containing io_errc::stream.

We can probably only expect errno to be set for filebuf operations, and in
practice only for failed reads. Failed writes from basic_filebuf::overflow
return -1 which might cause a stream object to set failbit and then throw, but
at that point we're too far away from the write to know if errno can be relied
on or not.

[Bug middle-end/85344] New: Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Bug ID: 85344
   Summary: Constant constraint check sign extends unsigned
constant  input operands
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: thopre01 at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

Compiling the following piece of code with -mthumb -mcpu=cortex-m0 generates an
"impossible constraint in 'asm' error"

void
foo (void)
{
  __asm( "%0" :: "I" ((unsigned char) 0x80));
}

It appears that although the operand is unsigned, it gets sign extended to
perform the constraint check.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.3.1, 8.0.1

--- Comment #1 from Thomas Preud'homme  ---
It believe that the problem is in expand_asm_stmt (). The code calls into
expand for the operand which will create a const_int of -128 with the
assumption that an outer RTX will tell how to interpret that constant (eg.
zero_extend:SI (const_int -128)). However the code uses that value directly
calling INTVAL on it. It should instead extend it according to the signedness
of the operand so that INTVAL returns the initial value.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
I have a patch, starting testing.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
More worrying is that this code compiles without error when it should error
out:

void
foo (void)
{
  __asm( "%0" :: "J" ((unsigned char) 0x80));
}

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #3)
> More worrying is that this code compiles without error when it should error
> out:
> 
> void
> foo (void)
> {
>   __asm( "%0" :: "J" ((unsigned char) 0x80));
> }

In which case we end up with #-128 in the assembly which is not what the user
wrote. Thus adding wrong-code tag.

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
(In reply to H.J. Lu from comment #18)
> (In reply to Jason Merrill from comment #16)
> > (In reply to Andreas Schwab from comment #15)
> > > Because the ABI says so.
> > 
> > Which ABI?  In https://www.uclibc.org/docs/psABI-i386.pdf I see
> > 
> > long long: sizeof 8, alignment 4.
> > 
> > That GCC chooses to give stronger alignment to long long variables isn't
> > part of the ABI, and shouldn't affect the value of alignof.
> 
> FYI, x86 psABIs are at
> 
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

And those also say that double and long long have alignment 4.

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Created attachment 43909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43909&action=edit
Patch to overload __throw_ios_failure

This patch is probably the best we can do. In theory we could capture errno as
soon as an error occurs and stash it somewhere in ios_base for later retrieval,
but that would be an ABI break.

With this patch this program:

#include 
int main()
{
  std::ifstream f(".");
  f.exceptions(std::ios::badbit);
  f.get();
}

Produces the more informative:
basic_filebuf::underflow error reading the file: Is a directory

instead of the generic:
basic_filebuf::underflow error reading the file: iostream error

[Bug target/85345] New: Missing ENDBR in IFUNC resolver

[hjl.tools at gmail dot com]

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

Bug ID: 85345
   Summary: Missing ENDBR in IFUNC resolver
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

[hjl@gnu-cet-1 gcc]$ /export/build/gnu/gcc-cet/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-cet/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c
-fcf-protection -mcet
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -g
[hjl@gnu-cet-1 gcc]$ gdb a.out 
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) r
Starting program:
/export/build/gnu/gcc-cet/build-x86_64-linux/gcc/testsuite/gcc/a.out 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.27-8.4.fc28.x86_64

Program received signal SIGSEGV, Segmentation fault.
resolve_do_it_right_at_runtime ()
at
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c:33
33srand (time (NULL));
(gdb) bt
#0  resolve_do_it_right_at_runtime ()
at
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c:33
#1  0x77ea01c8 in _dl_relocate_object ()
   from /lib64/ld-linux-x86-64.so.2
#2  0x77e9848f in dl_main () from /lib64/ld-linux-x86-64.so.2
#3  0x77eada2f in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#4  0x77e961b8 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#5  0x77e95108 in _start () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffda3c in ?? ()
#8  0x in ?? ()
(gdb) disass
Dump of assembler code for function resolve_do_it_right_at_runtime:
=> 0x00401220 <+0>: sub$0x8,%rsp   <<< Missing ENDBR
   0x00401224 <+4>: xor%edi,%edi
   0x00401226 <+6>: callq  0x4010a0 
   0x0040122b <+11>:mov%eax,%edi
   0x0040122d <+13>:callq  0x401090 
   0x00401232 <+18>:callq  0x4010b0 
   0x00401237 <+23>:addl   $0x1,0x2e1a(%rip)# 0x404058

   0x0040123e <+30>:mov$0x401260,%edx
   0x00401243 <+35>:test   $0x1,%al
   0x00401245 <+37>:mov$0x401210,%eax
   0x0040124a <+42>:cmove  %rdx,%rax
   0x0040124e <+46>:add$0x8,%rsp
   0x00401252 <+50>:retq   
End of assembler dump.
(gdb)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug fortran/85346] New: gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[segher at gcc dot gnu.org]

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

Bug ID: 85346
   Summary: gfortran.dg/do_concurrent_5.f90 FAILs with
--disable-libgomp
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

FAIL: gfortran.dg/do_concurrent_5.f90   -O  (test for excess errors)
Excess errors:
gfortran: error: libgomp.spec: No such file or directory

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 11 13:05:35 2018
New Revision: 259317

URL: https://gcc.gnu.org/viewcvs?rev=259317&root=gcc&view=rev
Log:
2018-04-11  Richard Biener  

PR lto/85339
* dwarf2out.c (dwarf2out_finish): Remove DW_AT_stmt_list attribute
from early DWARF output.
(dwarf2out_early_finish): Output line info unconditionally into
early DWARF and add reference to it.

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

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
  Component|fortran |testsuite
 Ever confirmed|0   |1

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

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Apr 11 13:10:16 2018
New Revision: 259318

URL: https://gcc.gnu.org/viewcvs?rev=259318&root=gcc&view=rev
Log:
PR c++/85032
* constexpr.c (potential_constant_expression_1): Consider conversions
from classes to literal types potentially constant.

* g++.dg/cpp0x/pr51225.C: Adjust error message.
* g++.dg/cpp1z/constexpr-if21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if21.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr51225.C

[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
WORKDFORME with

% gfc -O3 -ftree-parallelize-loops=2
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -v
Driving: gfc -O3 -ftree-parallelize-loops=2
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -v
-mmacosx-version-min=10.13.0 -asm_macosx_version_min=10.13 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/lto-wrapper
Target: x86_64-apple-darwin17.5.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc8w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7
Thread model: posix
gcc version 8.0.1 20180410 (experimental) [trunk revision 259304p8] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-shared-libgcc'
'-mtune=corei7' '-march=corei7'
 /opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/f951
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -fPIC -quiet
-dumpbase do_concurrent_5.f90 -mmacosx-version-min=10.13.0 -mtune=corei7
-march=corei7 -auxbase do_concurrent_5 -O3 -version -ftree-parallelize-loops=2
-fintrinsic-modules-path
/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/finclude -o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
GNU Fortran (GCC) version 8.0.1 20180410 (experimental) [trunk revision
259304p8] (x86_64-apple-darwin17.5.0)
compiled by GNU C version 8.0.1 20180409 (experimental) [trunk revision
259249p9], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl
version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 8.0.1 20180410 (experimental) [trunk revision
259304p8] (x86_64-apple-darwin17.5.0)
compiled by GNU C version 8.0.1 20180409 (experimental) [trunk revision
259249p9], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl
version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.13 -o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx10.13.0 -filetype obj -main-file-name
cchHk7Ph.s -target-cpu penryn -fdebug-compilation-dir
/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug -dwarf-debug-producer
Apple LLVM version 9.1.0 (clang-902.0.39.1) -dwarf-version=4 -mrelocation-model
pic -o /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
Reading specs from
/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
COMPILER_PATH=/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/
LIBRARY_PATH=/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../../
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
 /opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.13.0 -weak_reference_mismatches non-weak -o
a.out -L/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1
-L/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../..
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o -lgfortran -lgomp
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 8.0.1 20180410 (experimental) [trunk revision 259304p8]
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.13.0
-weak_reference_mismatches non-weak -o 

[Bug target/85347] New: New testcase vec-ldl-1.c FAILs on powerpc64-linux

[segher at gcc dot gnu.org]

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

Bug ID: 85347
   Summary: New testcase vec-ldl-1.c FAILs on powerpc64-linux
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

error: use of 'long long' in AltiVec types is invalid without '-mvsx'

This is without --with-cpu=, so defaulting to power4, so indeed no VSX.

[Bug ipa/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  ---
Created attachment 43910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43910&action=edit
preprocessed source

source package is https://launchpad.net/ubuntu/+source/i2pd

upstream is http://i2pd.website/

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Wed Apr 11 13:30:53 2018
New Revision: 259319

URL: https://gcc.gnu.org/viewcvs?rev=259319&root=gcc&view=rev
Log:
Improve IPA-CP handling of self-recursive calls

2018-04-11  Martin Jambor  

PR ipa/84149
* ipa-cp.c (propagate_vals_across_pass_through): Expand comment.
(cgraph_edge_brings_value_p): New parameter dest_val, check if it is
not the same as the source val.
(cgraph_edge_brings_value_p): New parameter.
(gather_edges_for_value): Pass destination value to
cgraph_edge_brings_value_p.
(perhaps_add_new_callers): Likewise.
(get_info_about_necessary_edges): Likewise and exclude values brought
only by self-recursive edges.
(create_specialized_node): Redirect only clones of self-calling edges.
(+self_recursive_pass_through_p): New function.
(find_more_scalar_values_for_callers_subset): Use it.
(find_aggregate_values_for_callers_subset): Likewise.
(known_aggs_to_agg_replacement_list): Removed.
(decide_whether_version_node): Re-calculate known constants for all
remaining context clones.


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

[Bug c++/85348] New: ostringstream with #pragma pack(1) causes stack smashing error

[crillion at tiscali dot it]

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

Bug ID: 85348
   Summary: ostringstream with #pragma pack(1) causes stack
smashing error
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crillion at tiscali dot it
  Target Milestone: ---

Hi.

  Using g++ version 7.2.0 on Windows 10 Enterprise N, installed with the
Mingw-w64 distribution, version x86_64-7.2.0-posix-seh-rt_v5-rev0, with the
following program

#pragma pack(1)

#include 

int main()
{
std::ostringstream{};
}

that I compile with the script (called from the normal windows console after
having added mingw-w64 bin path to the windows PATH variable)

g++ -pedantic -std=c++17 -Wall -Wextra -Werror=return-type -fdiagnostics-color
-s -Os program.cpp -o program_gpp.exe

the program compiles finely, but when I run it I get a crash without error
messages. The error occurs both if I don't use the -g option for debug or if I
use it.

On an older mingw-w64 version i686-510-win32-sjlj-rt_v4, used on a complex
cmake project in Debug Mode I get the crash too, with more detail in an
explicit console output as "   *** stack smashing detected ***:  terminated  ".
In release mode the error does not occur.

I understand that with #pragma pack(push,1) and #pragma pack(pop), and also by
including  BEFORE the #pragma pack(1) directive the crash does not
occur; 

But could you please issue a warning if someone uses simply #pragma pack(1)
with ostringstream ?

Thanks,

 Marco

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[pinskia at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I don't think you want to do this...   aka "doctor it hurts".

--- Comment #2 from Andrew Pinski  ---
#pragma pack(1)
causes an abi change so this is expected.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I don't think you want to do this...   aka "doctor it hurts".

--- Comment #2 from Andrew Pinski  ---
#pragma pack(1)
causes an abi change so this is expected.

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 11 13:35:13 2018
New Revision: 259320

URL: https://gcc.gnu.org/viewcvs?rev=259320&root=gcc&view=rev
Log:
PR tree-optimization/85331
* vec-perm-indices.h (vec_perm_indices::clamp): Change input type
from int to HOST_WIDE_INT.

* gcc.c-torture/execute/pr85331.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85331.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vec-perm-indices.h

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
So hopefully fixed.

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/3885] Incorrect "invalid suffix on integer constant" error

[zackw at panix dot com]

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

Zack Weinberg  changed:

   What|Removed |Added

 CC||zackw at panix dot com

--- Comment #14 from Zack Weinberg  ---
I think we should reopen this bug and treat it as a request to improve the
diagnostics.

GCC is correct to reject tokens of the form "0x000E-0x0001", but the
accumulation of duplicate bug reports suggests that we could do a better job of
explaining what is wrong.  Proposal: whenever we are about to issue the
"invalid suffix on (integer/floating) constant" error, if the first character
of the "invalid suffix" is + or -, we say instead something like

error: invalid numeric constant ""
note: ('+'/'-') after ('e'/'p'/'E'/'P') continues a pp-number
note: to perform (addition/subtraction), put a space before the ('+'/'-')

Printing the entire pp-number token instead of just the "suffix", mentioning
the standardese term "pp-number", and calling the token an "invalid numeric
constant" instead of an "invalid integer/floating constant" should clue people
in to _why_ this apparently perverse tokenization is happening.

[Bug gcov-profile/85349] New: [GCOV] struct varaible definition in while(1) will cause incorrect coverage

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85349
   Summary: [GCOV] struct varaible definition in while(1) will
cause incorrect coverage
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
struct F {int x;};

int main()
{
  int x = 0;
  while (1) // first while
  {
struct F f1 = {x};
if (f1.x > 0)
  break;
x++;
  }

  x = 0;
  while (1) // second while
  {
if (x > 0)
  break;
x++;
  }

  x = 0;
  while (x < 10) // third while
  {
struct F f2 = {x};
if (f2.x > 0)
  break;
x++;
  }

  x = 0;
  while (x < 10)
  {
if (x > 0)
  break;
x++;
  }
  return 0;
}


$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 23
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct F {int x;};
-:2:
1:3:int main()
-:4:{
1:5:  int x = 0;
-:6:  while (1) // first while
1:7:  {
2:8:struct F f1 = {x};
2:9:if (f1.x > 0)
1:   10:  break;
1:   11:x++;
-:   12:  }
-:   13:
1:   14:  x = 0;
-:   15:  while (1) // second while
-:   16:  {
2:   17:if (x > 0)
1:   18:  break;
1:   19:x++;
-:   20:  }
-:   21:
1:   22:  x = 0;
2:   23:  while (x < 10) // third while
-:   24:  {
2:   25:struct F f2 = {x};
2:   26:if (f2.x > 0)
1:   27:  break;
1:   28:x++;
-:   29:  }
-:   30:
1:   31:  x = 0;
2:   32:  while (x < 10)
-:   33:  {
2:   34:if (x > 0)
1:   35:  break;
1:   36:x++;
-:   37:  }
1:   38:  return 0;
-:   39:}


Line #7 is wrongly marked as "1". 

Line #16 and Line #33 are also the first braces of while statement. While they
are marked as "-". 

By comparing these three while-statements, I think the inconsistency is caused
by the struct variable definition inside the while(1) statement.

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r255268.

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
My patch doesn't fix g++.dg/eh/sighandle.C compiled with

-O2 -fcf-protection -mcet

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[crillion at tiscali dot it]

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

crillion at tiscali dot it changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from crillion at tiscali dot it ---
the point is that this directive was in a deeply included header of a library I
use. It took me some amount of time (I spent some work hours) to isolate the
problem which emerges just in the ostringstream creation. I wasn't aware of
this behaviour of the generated code before; if the compiler had warned me, I
would have resolved more quickly.

[Bug gcov-profile/85349] [GCOV] struct varaible definition in while(1) will cause incorrect coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The test should probably go to gcc/testsuite/gfortran.dg/gomp/.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou  ---
> Looks good to me, aka OK if it passes whatever testing you think is
> sufficient.

Thanks.  There is apparently another, preexisting issue visible in Ada:

$ gcc -o t t.c -flto -g 
lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument

$ gnatmake nested_controlled_alloc -flto
gcc -c -flto nested_controlled_alloc.adb
gnatbind -x nested_controlled_alloc.ali
gnatlink nested_controlled_alloc.ali -flto
lto-wrapper.exe: fatal error: file too short: No error

compilation terminated.
c:/home/botcazou/anod-wave/x86_64-windows/gcc-gcc-head.0/install/bin/../libexec/gcc/x86_64-pc-mingw32/8.0.1/ld.exe:
error: lto-wrapper failed

but adding -g0 makes it disappear:

$ gnatmake nested_controlled_alloc -flto -g0
gcc -c -flto -g0 nested_controlled_alloc.adb
gnatbind -x nested_controlled_alloc.ali
gnatlink nested_controlled_alloc.ali -flto -g0

Do you have any idea about what's going on here?

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Latent before that, actually started with my r109013.

[Bug rtl-optimization/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

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

Untested fix.  After failed apply_change_group, recog_data.insn is NULL and
rest of recog_data is garbage, so there is no need to update it.

[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Author: amonakov
Date: Wed Apr 11 14:32:32 2018
New Revision: 259321

URL: https://gcc.gnu.org/viewcvs?rev=259321&root=gcc&view=rev
Log:
sched-rgn: run add_branch_dependencies for sel-sched (PR 84301)

PR target/84301
* sched-rgn.c (add_branch_dependences): Move sel_sched_p check here...
(compute_block_dependences): ... from here.

testsuite/
* gcc.target/i386/pr84301.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr84301.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-rgn.c
trunk/gcc/testsuite/ChangeLog

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug gcov-profile/85350] New: [GCOV] wrong coverage when using constant variable in struct declaration

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85350
   Summary: [GCOV] wrong coverage when using constant variable in
struct declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
#include 

int main (void)
{
  const int t = 2;
  struct s1 {
int x;
int g[t];
  };

  struct s2 {
int x;
int g[2];
  };

  printf("Sucess!\n");
  return 0;
}

$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
Sucess!
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int main (void)
-:4:{
1:5:  const int t = 2;
2:6:  struct s1 {
-:7:int x;
1:8:int g[t];
-:9:  };
-:   10:
-:   11:  struct s2 {
-:   12:int x;
-:   13:int g[2];
-:   14:  };
-:   15:
1:   16:  printf("Sucess!\n");
1:   17:  return 0;
-:   18:}


Line #6 is wrongly marked as executed twice. 
The second struct declaration is not using constant variable t. By comparing
these two structs, we can know that constant variable should be the reason that
leads to the incorrect coverage.

[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Author: amonakov
Date: Wed Apr 11 14:36:04 2018
New Revision: 259322

URL: https://gcc.gnu.org/viewcvs?rev=259322&root=gcc&view=rev
Log:
sched-deps: respect deps->readonly in macro-fusion (PR 84566)

PR rtl-optimization/84566
* sched-deps.c (sched_analyze_insn): Check deps->readonly when invoking
sched_macro_fuse_insns.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c