[Bug c++/61936] template template friends fail to compile.

2018-01-24 Thread hr.jonas.hansen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61936

hr.jonas.hansen at gmail dot com changed:

   What|Removed |Added

 CC||hr.jonas.hansen at gmail dot 
com

--- Comment #4 from hr.jonas.hansen at gmail dot com ---
The bug has been resolved with version 6.2

See:
https://godbolt.org/g/wrSDRG

[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.3

[Bug c++/83996] [6/7/8] Regression] ICE with zero-sized array

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug lto/83997] ICE with alias template and attribute

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83997

--- Comment #1 from Richard Biener  ---
bu11.cc:10:1: internal compiler error: tree code 'template_parm_index' is not
supported in LTO streams

this usually means FE tree codes leak somehow into the middle-end there's a
free_lang_data langhook for the FE to prune these from types/decls when needed.

[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/83998] [8 Regression] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4403

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83998

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/84000] [8 Regression] ICE in replace_loop_annotate, at tree-cfg.c:352

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84000

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-24
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
(gdb) p debug_gimple_stmt (stmt)
D.3772 = ANNOTATE (_1, 4, 0);

[Bug c++/84001] ICE in dependent_type_p cp/pt.c:23567 when using member type of template parameter in template list

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84001

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
  Known to work||8.0
 Ever confirmed|0   |1
  Known to fail||4.8.5, 6.4.1, 7.2.1

--- Comment #1 from Richard Biener  ---
Confirmed.  Works on trunk.

[Bug fortran/84000] [8 Regression] ICE in replace_loop_annotate, at tree-cfg.c:352

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84000

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/84000] [8 Regression] ICE in replace_loop_annotate, at tree-cfg.c:352

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84000

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 24 08:43:40 2018
New Revision: 257011

URL: https://gcc.gnu.org/viewcvs?rev=257011&root=gcc&view=rev
Log:
2018-01-24  Richard Biener  

PR middle-end/84000
* tree-cfg.c (replace_loop_annotate): Handle annot_expr_parallel_kind.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-cfg.c

[Bug rtl-optimization/84003] FAIL: g++.dg/torture/pr77745.C with noinline foo

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84003

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 CC||rguenth at gcc dot gnu.org
  Component|target  |rtl-optimization
Summary|FAIL:   |FAIL:
   |g++.dg/torture/pr77745.C|g++.dg/torture/pr77745.C
   |with -fpic  |with noinline foo
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Goes wrong during sched2 which re-orders the read and writes in
foo:

foo (char * c1, char * c2)
{
  long int _7;

   [local count: 1073741825]:
  MEM[(long int *)c1_1(D)] = 100;
  MEM[(long long int *)c2_4(D)] = 200;
  MEM[(long int *)c2_4(D)] = 200;
  _7 = MEM[(long int *)c1_1(D)];
  return _7;

compiles to

_Z3fooPcS_:
.LFB1:
.cfi_startproc
movl4(%esp), %eax
movl8(%esp), %edx
movl$100, (%eax)
movl(%eax), %eax
movl$200, (%edx)
movl$0, 4(%edx)
ret

note c1_1 == c2_4.  This must be a latent bug in scheduling somehow not
triggered without -fpic (inlining probably).  Indeed, marking foo as
noinline makes it trigger without -fpic.

[Bug testsuite/84004] [8 regression] gcc.dg/vect/vect-95.c XPASSes

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84004

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  This is fallout from cost model changes on x86, eventually
vect_element_align needs to be adjusted or just the testcase.

[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Needs investigation (alignment issue?).

[Bug c++/84012] [8 regression] error: cannot convert ‘const std::shared_ptr’ to ‘std::a*’ in return

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84012

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r253599.

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Somehow switch-conversion doesn't transform the switch with -f{PIE,PIC}. 
Without
we get

phy_modes (phy_interface_t interface)
{
  const char * _1;
  const char * _4;

   [local count: 1073741825]:
  if (interface_2(D) <= 22)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870912]:
  _4 = CSWTCH.0[interface_2(D)];

   [local count: 1073741825]:
  # _1 = PHI <_4(3), "unknown"(2)>
  return _1;

due to

Bailing out - value from a case would need runtime relocations

  reloc = initializer_constant_valid_p (val, TREE_TYPE (val));
  if ((flag_pic && reloc != null_pointer_node)
  || (!flag_pic && reloc == NULL_TREE))
{
  if (reloc)
reason
  = "value from a case would need runtime relocations";
  else
reason
  = "value from a case is not a valid initializer";
}

not sure why we need relocations for string constants?

[Bug c++/84012] [8 regression] error: cannot convert ‘const std::shared_ptr’ to ‘std::a*’ in return

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84012

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.0

[Bug target/84014] [6/7/8 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 CC||jakub at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
   Target Milestone|--- |6.5
Summary|ICE in  |[6/7/8 Regression] ICE in
   |setup_min_max_allocno_live_ |setup_min_max_allocno_live_
   |range_point, at |range_point, at
   |ira-build.c:2762|ira-build.c:2762
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reproduced with -m32 -mcpu=e300c3, seems to be very old ICE, even r208000 ICEs,
r206000 does not.

[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 CC||jakub at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r254936.

[Bug tree-optimization/84013] wrong __restrict clique with inline asm operand

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84013

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-24
Version|tree-ssa|8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yes, this is a known limitation:

  if (restrict_var)
{
  /* Now look at possible dereferences of ptr.  */
  imm_use_iterator ui;
  gimple *use_stmt;
  bool used = false;
  FOR_EACH_IMM_USE_STMT (use_stmt, ui, ptr)
{
  /* ???  Calls and asms.  */
  if (!gimple_assign_single_p (use_stmt))
continue;

[Bug rtl-optimization/84003] FAIL: g++.dg/torture/pr77745.C with noinline foo

2018-01-24 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84003

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
So running:

$ g++ pr77745.C -O2 -flto -fno-use-linker-plugin -m32 -fpic -mtune=native

for:

$ cat pr77745.C
// { dg-do run }
//
#include 
#include 

//inline void* operator new(__SIZE_TYPE__, void* __p) noexcept { return __p; }

long
__attribute__((noinline))
foo(char *c1, char *c2)
{
  long *p1 = new (c1) long;
  *p1 = 100;
  long long *p2 = new (c2) long long;
  *p2 = 200;
  long *p3 = new (c2) long;
  *p3 = 200;
  return *p1;
}
int main()
{
  union {
  char c;
  long l;
  long long ll;
  } c;
  if (foo(&c.c, &c.c) != 200)
  {
fprintf (stderr, "aborting\n");
__builtin_abort();
  }
}

Aborts for all GCC releases I have (4.5.0+).

[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
(In reply to Ian Lance Taylor from comment #4)
> Sure, we can fix the test case.  But in general Go is intended to provide
> accurate tracebacks, and this is a case where it is failing to do so.  This
> is independent of the fact that the loop is heavily optimized; that doesn't
> matter here.  The point is that anywhere in the loop should be in the same
> basic block.  I don't think that accurate tracebacks are an unreasonable
> goal so I'd like to push back a bit.
> 
> The problem with the statement with no location is that due to future
> optimizations it winds up at the start of the basic block.  The eventual
> effect is that the first statement of the basic block appears to be in the
> preceding block.  That makes no sense, as the block is a loop.  By the time
> we get to 232t.optimized, the block looks like this:
> 
>[local count: 1063004407]:
>   # ivtmp_7 = PHI <2147483647(3), ivtmp_1(4)>
>   # DEBUG j => (int) (2147483647 - ivtmp_7)
>   # DEBUG D#1 => (int) (2147483648 - ivtmp_7)
>   [foo.go:6:31] # DEBUG j => D#1
>   # DEBUG j => D#1
>   ivtmp_1 = ivtmp_7 + 18446744073709551615;
>   [foo.go:6:17] if (ivtmp_1 != 0)
> goto ; [98.99%]
>   else
> goto ; [1.01%]
> 
> Perhaps it is correct that the `ivtmp_1 =` line shouldn't have a location,
> but it does after all get a location in the end.  That location shouldn't be
> in an entirely differently basic block.

stmts with no location just get the location of whatever was there before.
This might not work very well for stmts at the beginning of a basic block.
Do we leave the "whatever was there before" to the assembler?  If so we
should probably have some heuristic, like setting the location of the
first stmt of a basic block to either its own or the first stmt with a
location?

Note that not assigning a location to "artificial" stmts is exactly to avoid
jumping around when those stmts move -- they are not supposed to influence
the experienced "debug flow".  But as said, this might not work as designed
for the start of a basic block.  What happens when there is no stmt with
a location in side a basic block?  Is there a way to tell the
debugger/assembler
"this stmt has no line information"?

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

2018-01-24 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

Bug ID: 84016
   Summary: Spec2000 regression around Jan 14 and Jan 19 2018
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

There is noticeable regression in specfp2000 in mgrid (4700-4600), facerec
(8000->6600), crafty 4520->4420 at Jan 19
Galgel 14450->14150, apsi 4700->4550, gamess (from 2016) 34->32 at Jan 14-16
On Haswell.

All visible at
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64/recent.html and
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/recent.html

[Bug c++/84015] [7/8 Regression] ICE with class template argument deduction

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84015

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.3

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||6.4.0
   Target Milestone|--- |7.3
Summary|Spurious "potential null|[7/8 Regression] Spurious
   |pointer dereference"|"potential null pointer
   |warning regression from 7.1 |dereference" warning
   |onwards |regression from 7.1 onwards

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

2018-01-24 Thread aoliva at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758

--- Comment #19 from Alexandre Oliva  ---
I was copied, presumably because the problem occurred in var-tracking.

I've tried to duplicate the problem on gcc112.  I bootstrapped the trunk
(without any --with-cpu flag), and then build attachment 43208 with stage3:

$ ./gccgo -B./ -I../../libgo/go -I../powerpc64le-unknown-linux-gnu/libgo
-I../powerpc64le-unknown-linux-gnu/libgo/go -O2 -g t.go -mcpu=power8 -c
[success]

Given this, I conclude that the problem only occurs if the compiler is
bootstrapped --with-cpu=power[89].  This suggests to me that, although the ICE
is triggered in var-tracking, the problem is unlikely to be there: the compiler
is getting miscompiled.  I suppose that, by now, you already knew that ;-)

[Bug tree-optimization/82819] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82819

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 24 09:31:56 2018
New Revision: 257012

URL: https://gcc.gnu.org/viewcvs?rev=257012&root=gcc&view=rev
Log:
2018-01-24  Richard Biener  

PR tree-optimization/82819
* graphite-isl-ast-to-gimple.c (binary_op_to_tree): Avoid
code generating pluses that are no-ops in the target precision.

* gcc.dg/graphite/pr82819.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr82819.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/83176] [8 Regression] [graphite] ICE in set_codegen_error, at graphite-isl-ast-to-gimple.c:206

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83176

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 24 09:37:41 2018
New Revision: 257013

URL: https://gcc.gnu.org/viewcvs?rev=257013&root=gcc&view=rev
Log:
2018-01-24  Richard Biener  

PR tree-optimization/83176
* tree-chrec.c (chrec_fold_plus_1): Handle (signed T){(T) .. }
operands.

* gcc.dg/graphite/pr83176.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr83176.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chrec.c

[Bug bootstrap/84017] New: [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017

Bug ID: 84017
   Summary: [6/7/8 regression] Bootstrap failure on Solaris 10/x86
with gas/ld
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10

Starting back in the GCC 6 days, Solaris 10/x86 bootstrap started to FAIL in a
very weird way compiling libgo:

/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
 func CompareAndSwapInt32(addr *int32, old, new int32) (swapped bool)
^
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
go1: internal compiler error: in register_builtin_type, at
go/gofrontend/export.cc:483
0x8242a31 Export::register_builtin_type(Gogo*, char const*, Builtin_code)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/export.cc:483
0x8242b7f Export::register_builtin_types(Gogo*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/export.cc:470
0x827c0f6 Gogo::do_exports()
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:4485
0x8279a41 go_parse_input_files(char const**, unsigned int, bool, bool)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/go.cc:118
0x8274f92 go_langhook_parse_file
/vol/gcc/src/hg/trunk/local/gcc/go/go-lang.c:312

The error is obviously completely bogus.  A reghunt identified this patch as
the culprit:

The first bad revision is:
changeset:   22378:b810ecbf30be
user:segher@138bc75d-0d04-0410-961f-82ee72b054a4
date:Thu May 07 15:51:01 2015 +
summary: PR middle-end/192

PR middle-end/192
PR middle-end/54303
* varasm.c (function_mergeable_rodata_prefix): New function.
(mergeable_string_section): Use it.
(mergeable_constant_section): Use it.

gcc/testsuite/
* gcc.dg/fdata-sections-2.c: New file.

The error vanishes if go1 is rebuilt with -g3 -O0.  It also only happens when
using the gas/ld combo, no problem with as/ld (or gas/gld).

At the same time, many warnings appear during the build like this one:

ld: warning: relocation warning: R_386_GOTOFF: file
/var/gcc/regression/trunk/10-gcc-gas/build/prev-i386-pc-solaris2.10/libstdc++-v3/src/.libs/libstdc++.a(wlocale-inst.o):
section [213].rel.gnu.linkonce.t._ZNSt17moneypunct_bynameIwLb0EEC2EPKcj: symbol
.LC72: relocation against discarded COMDAT section
[136].gnu.linkonce.r._ZSt16__convert_from_vRKPiPciPKcz.str1.1: symbol not
found, relocation ignored

Indeed full support for .gnu.linkonce sections (a non-standard gld extension)
only appeared in Solaris 11.

I've successfully been using this patch
diff --git a/gcc/varasm.c b/gcc/varasm.c
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -789,7 +789,7 @@ static const char *
 function_mergeable_rodata_prefix (void)
 {
   section *s = targetm.asm_out.function_rodata_section
(current_function_decl);
-  if (SECTION_STYLE (s) == SECTION_NAMED)
+  if (SECTION_STYLE (s) == SECTION_NAMED && HAVE_COMDAT_GROUP)
 return s->named.name;
   else
 return targetm.asm_out.mergeable_rodata_prefix;

to avoid the issue, which effectively restores to the situation before the
patch: HAVE_COMDAT_GROUP is 0 on Solaris 10, and 1 on Solaris 11+.  However,
it cannot be right since it is only needed with gas/ld, not with as/ld.

I long meant to investigate further, but neglected to do so,keeping the patch
above local.

When I recently reverted it to check, however, I ran into another (and much
earlier) failure:

/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:2128: test_pp_format: FAIL:
ASSERT_STREQ (expected, pp_formatted_text (&pp)) expected="-27 12345678"
actual=" 12345678"
cc1: internal compiler error: in fail_formatted, at selftest.c:62
0x900c345 selftest::fail_formatted(selftest::location const&, char const*, ...)
/vol/gcc/src/hg/trunk/local/gcc/selftest.c:62
0x900c3ab selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
/vol/gcc/src/hg/trunk/local/gcc/selftest.c:85
0x901ccc6 assert_pp_format_va
/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:2039
0x901cd7f assert_pp_format
/vol/gcc/src/hg/trunk/local/gcc/prett

[Bug target/84010] [sparc64] Problematic TLS code generation

2018-01-24 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 CC||ebotcazou at gcc dot gnu.org
Summary|[sparc64] Bad TLS code  |[sparc64] Problematic TLS
   |generation  |code generation
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou  ---
Ouch.

[Bug bootstrap/84018] New: [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84018

Bug ID: 84018
   Summary: [6/7/8 regression] Bootstrap failure on Solaris 10/x86
with gas/ld
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10

Starting back in the GCC 6 days, Solaris 10/x86 bootstrap started to FAIL in a
very weird way compiling libgo:

/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
 func CompareAndSwapInt32(addr *int32, old, new int32) (swapped bool)
^
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
/vol/gcc/src/hg/trunk/local/libgo/go/sync/atomic/doc.go:74:64: error: use of
undefined type 'bool'
go1: internal compiler error: in register_builtin_type, at
go/gofrontend/export.cc:483
0x8242a31 Export::register_builtin_type(Gogo*, char const*, Builtin_code)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/export.cc:483
0x8242b7f Export::register_builtin_types(Gogo*)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/export.cc:470
0x827c0f6 Gogo::do_exports()
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/gogo.cc:4485
0x8279a41 go_parse_input_files(char const**, unsigned int, bool, bool)
/vol/gcc/src/hg/trunk/local/gcc/go/gofrontend/go.cc:118
0x8274f92 go_langhook_parse_file
/vol/gcc/src/hg/trunk/local/gcc/go/go-lang.c:312

The error is obviously completely bogus.  A reghunt identified this patch as
the culprit:

The first bad revision is:
changeset:   22378:b810ecbf30be
user:segher@138bc75d-0d04-0410-961f-82ee72b054a4
date:Thu May 07 15:51:01 2015 +
summary: PR middle-end/192

PR middle-end/192
PR middle-end/54303
* varasm.c (function_mergeable_rodata_prefix): New function.
(mergeable_string_section): Use it.
(mergeable_constant_section): Use it.

gcc/testsuite/
* gcc.dg/fdata-sections-2.c: New file.

The error vanishes if go1 is rebuilt with -g3 -O0.  It also only happens when
using the gas/ld combo, no problem with as/ld (or gas/gld).

At the same time, many warnings appear during the build like this one:

ld: warning: relocation warning: R_386_GOTOFF: file
/var/gcc/regression/trunk/10-gcc-gas/build/prev-i386-pc-solaris2.10/libstdc++-v3/src/.libs/libstdc++.a(wlocale-inst.o):
section [213].rel.gnu.linkonce.t._ZNSt17moneypunct_bynameIwLb0EEC2EPKcj: symbol
.LC72: relocation against discarded COMDAT section
[136].gnu.linkonce.r._ZSt16__convert_from_vRKPiPciPKcz.str1.1: symbol not
found, relocation ignored

Indeed full support for .gnu.linkonce sections (a non-standard gld extension)
only appeared in Solaris 11.

I've successfully been using this patch
diff --git a/gcc/varasm.c b/gcc/varasm.c
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -789,7 +789,7 @@ static const char *
 function_mergeable_rodata_prefix (void)
 {
   section *s = targetm.asm_out.function_rodata_section
(current_function_decl);
-  if (SECTION_STYLE (s) == SECTION_NAMED)
+  if (SECTION_STYLE (s) == SECTION_NAMED && HAVE_COMDAT_GROUP)
 return s->named.name;
   else
 return targetm.asm_out.mergeable_rodata_prefix;

to avoid the issue, which effectively restores to the situation before the
patch: HAVE_COMDAT_GROUP is 0 on Solaris 10, and 1 on Solaris 11+.  However,
it cannot be right since it is only needed with gas/ld, not with as/ld.

I long meant to investigate further, but neglected to do so,keeping the patch
above local.

When I recently reverted it to check, however, I ran into another (and much
earlier) failure:

/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:2128: test_pp_format: FAIL:
ASSERT_STREQ (expected, pp_formatted_text (&pp)) expected="-27 12345678"
actual=" 12345678"
cc1: internal compiler error: in fail_formatted, at selftest.c:62
0x900c345 selftest::fail_formatted(selftest::location const&, char const*, ...)
/vol/gcc/src/hg/trunk/local/gcc/selftest.c:62
0x900c3ab selftest::assert_streq(selftest::location const&, char const*, char
const*, char const*, char const*)
/vol/gcc/src/hg/trunk/local/gcc/selftest.c:85
0x901ccc6 assert_pp_format_va
/vol/gcc/src/hg/trunk/local/gcc/pretty-print.c:2039
0x901cd7f assert_pp_format
/vol/gcc/src/hg/trunk/local/gcc/prett

[Bug bootstrap/84018] [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84018

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #1 from Rainer Orth  ---
Duplicate, timeout during submission.

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

[Bug bootstrap/84017] [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017

--- Comment #1 from Rainer Orth  ---
*** Bug 84018 has been marked as a duplicate of this bug. ***

[Bug bootstrap/84017] [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977

--- Comment #3 from Jakub Jelinek  ---
Another related example:
struct S { int a, b, c; };

#pragma omp declare simd uniform(z) linear(v:1)
__attribute__((noinline)) static int
foo (int x, int y, struct S z, int u, int v)
{
  return x + y + z.a;
}

int
bar (int x, int y, int z)
{
  struct S s = { z, 1, 1 };
  return foo (x, y, s, 0, 0);
}

[Bug c++/83921] [7 Regression] GCC rejects constexpr initialization of empty aggregate.

2018-01-24 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83921

Paolo Carlini  changed:

   What|Removed |Added

Summary|[7/8 Regression] GCC|[7 Regression] GCC rejects
   |rejects constexpr   |constexpr initialization of
   |initialization of empty |empty aggregate.
   |aggregate.  |

--- Comment #5 from Paolo Carlini  ---
Fixed for 8.1.0 so far.

[Bug c++/83947] [8 Regression] ICE on invalid C++ code with auto: in tsubst_decl, at cp/pt.c:13046

2018-01-24 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83947

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jason at gcc dot gnu.org   |
 Resolution|--- |FIXED

--- Comment #3 from Paolo Carlini  ---
Thus fixed, right?

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

2018-01-24 Thread guez at lmd dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207

--- Comment #8 from Lionel GUEZ  ---
It does not seem completely true that gfortran makes no distinction between
qNaN and sNaN. There is the option -finit-real of gfortran with the different
possible values nan and snan. Also, there is the option -mnan of gcc which
describes different encodings for qnan and snan.

Furthermore, I think that, with the present behaviour of gfortran concerning
qnan, the function ieee_support_nan(0.) should return false.

[Bug c++/83996] [6/7/8] Regression] ICE with zero-sized array

2018-01-24 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83996

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-01-24
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Sure.

[Bug target/81352] [nvptx] trap placement for non-returning function call in vector-single mode

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81352

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Wed Jan 24 11:27:10 2018
New Revision: 257014

URL: https://gcc.gnu.org/viewcvs?rev=257014&root=gcc&view=rev
Log:
[nvptx, PR81352] Add exit insn after noreturn call for neutered threads in warp

2018-01-24  Tom de Vries  

PR target/81352
* config/nvptx/nvptx.c (nvptx_single): Add exit insn after noreturn
call
for neutered threads in warp.
* config/nvptx/nvptx.md (define_insn "exit"): New insn.

* testsuite/libgomp.oacc-fortran/pr81352.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-fortran/pr81352.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/nvptx/nvptx.md
trunk/libgomp/ChangeLog

[Bug middle-end/84019] New: [7/8 regression] ICE under fold-const

2018-01-24 Thread linux at carewolf dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

Bug ID: 84019
   Summary: [7/8 regression] ICE under fold-const
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

ICE when compiling Chromium in QtWebEngine under certain conditions.

With gcc 8:
during GIMPLE pass: fre
../../../../../qtwebengine/src/3rdparty/chromium/third_party/WebKit/Source/platform/audio/IIRFilter.cpp:
In member function ‘void blink::IIRFilter::GetFrequencyResponse(int, const
float*, float*, float*)’:
../../../../../qtwebengine/src/3rdparty/chromium/third_party/WebKit/Source/platform/audio/IIRFilter.cpp:221:1:
internal compiler error: Aborted
 }  // namespace blink
 ^
0xe6e39f crash_signal
../../gcc/toplev.c:325
0xa49596 do_mpc_arg2(tree_node*, tree_node*, tree_node*, int, int
(*)(__mpc_struct*, __mpc_struct const*, __mpc_struct const*, int))
../../gcc/builtins.c:10478
0xbb51f4 const_binop
../../gcc/fold-const.c:1405
0xbb5ee7 const_binop(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/fold-const.c:1705
0x11daa14 gimple_resimplify2(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:133
0x12ad258 gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:643
0xbf904a gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../gcc/gimple-fold.c:6117
0x101a604 try_to_simplify
../../gcc/tree-ssa-sccvn.c:3982
0x101a604 visit_use
../../gcc/tree-ssa-sccvn.c:4033
0x101c736 process_scc
../../gcc/tree-ssa-sccvn.c:4363
0x101c736 extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:4434
0x101c736 DFS
../../gcc/tree-ssa-sccvn.c:4484
0x101cbd3 sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:4917
0x15ad907 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:308
0x101d6ca run_scc_vn(vn_lookup_kind)
../../gcc/tree-ssa-sccvn.c:5033
0x101deea execute
../../gcc/tree-ssa-sccvn.c:6015


The same happens with system gcc (7.2 from Debian), but not with system gcc-6

[Bug middle-end/84019] [7/8 regression] ICE under fold-const

2018-01-24 Thread linux at carewolf dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

--- Comment #1 from Allan Jensen  ---
First line of the ICE (the only line reported by system gcc)

../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))

[Bug middle-end/84019] [7/8 regression] ICE under fold-const

2018-01-24 Thread linux at carewolf dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

--- Comment #2 from Allan Jensen  ---
I can provide the intermediate code, but I haven't created a reduced test-case,
so it would be big.

[Bug libgomp/84020] New: [nvptx] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84020

Bug ID: 84020
   Summary: [nvptx] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp
plugin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

patch submitted at https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02004.html and
approved for gcc 9 stage 1, and approved here:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02005.html .

Filing this PR to remember to commit in stage1.

[Bug libgomp/84020] [nvptx] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84020

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openacc, openmp, patch
   Target Milestone|--- |9.0

[Bug bootstrap/84021] New: [8 Regression] bootstrap fails in libgo on powerpc64le-linux-gnu

2018-01-24 Thread doko at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84021

Bug ID: 84021
   Summary: [8 Regression] bootstrap fails in libgo on
powerpc64le-linux-gnu
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

trunk 20180124 fails to build libgo on powerpc64le-linux-gnu:

libtool: compile:  /<>/build/./gcc/gccgo
-B/<>/build/./gcc/
-B/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/bin/ -B/usr/lib/gcc
-snapshot/powerpc64le-linux-gnu/lib/ -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/include -isystem
/usr/lib/gcc-snapshot/powerpc64le-linux-gnu/
sys-include -O2 -g -I . -c -fgo-pkgpath=crypto/tls
../../../src/libgo/go/crypto/tls/alert.go
../../../src/libgo/go/crypto/tls/cipher_suites.go ../../..
/src/libgo/go/crypto/tls/common.go ../../../src/libgo/go/crypto/tls/conn.go
../../../src/libgo/go/crypto/tls/handshake_client.go ../../../src/libgo/go/
crypto/tls/handshake_messages.go
../../../src/libgo/go/crypto/tls/handshake_server.go
../../../src/libgo/go/crypto/tls/key_agreement.go ../../../src/li
bgo/go/crypto/tls/prf.go ../../../src/libgo/go/crypto/tls/ticket.go
../../../src/libgo/go/crypto/tls/tls.go -o crypto/tls.o >/dev/null 2>&1
during RTL pass: vartrack
../../../src/libgo/go/cmd/go/internal/work/gccgo.go: In function
'work.gc.N35_cmd_go_internal_work.gccgoToolchain':
../../../src/libgo/go/cmd/go/internal/work/gccgo.go:54:1: internal compiler
error: in vt_expand_var_loc_chain, at var-tracking.c:8331
 func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string,
importcfg []byte, asmhdr bool, gofiles []string) (ofile string, output []byte,
e
rr error) {
 ^
0x10ddbf2f vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8331
0x10ddbf2f vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1042293f cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1714
0x104227a7 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1752
0x104227a7 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1752
0x1042541f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10ddb607 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8364
0x10ddb607 vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1042293f cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1714
0x104227a7 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1752
0x1042541f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10ddb607 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8364
0x10ddb607 vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1042293f cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1714
0x1042541f cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10dd28cf vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8364
0x10dd28cf vt_expand_1pvar
../../src/gcc/var-tracking.c:8640
0x10dd28cf emit_note_insn_var_location(variable**, emit_note_data*)
../../src/gcc/var-tracking.c:8695
0x10ddc36f void hash_table::traverse_noresize(emit_note_data*)
../../src/gcc/hash-table.h:969
0x10ddc36f void hash_table::traverse(emit_note_data*)
../../src/gcc/hash-table.h:990
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:3331: recipe for target 'cmd/go/internal/work.lo' failed
make[6]: *** [cmd/go/internal/work.lo] Error 1
make[6]: *** Waiting for unfinished jobs

seeing that on powerpc-linux-gnu as well

https://buildd.debian.org/status/package.php?p=gcc-snapshot

[Bug testsuite/84022] New: Run nvptx accel tests with GOMP_NVPTX_JIT=-O0

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84022

Bug ID: 84022
   Summary: Run nvptx accel tests with GOMP_NVPTX_JIT=-O0
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

With GOMP_NVPTX_JIT=-O[0-4] (see PR84020) approved, we can think of using this
in the libgomp testing matrix in a more elaborate way that the occasional "{
dg-set-target-env-var GOMP_NVPTX_JIT "-O0" }".

F.i., we can run offloading tests both:
- as is (implying the default GOMP_NVPTX_JIT=-O4), and
- with GOMP_NVPTX_JIT=-O0.

[Bug testsuite/84022] Run nvptx accel tests with GOMP_NVPTX_JIT=-O0

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84022

--- Comment #1 from Tom de Vries  ---
Created attachment 43231
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43231&action=edit
Tentative patch, running nvptx accel tests with GOMP_NVPTX_JIT=-O0 in
libgomp.{c,c++}

[Bug middle-end/84023] New: gcc.dg/ipa/inline-8.c fail with -fpic

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84023

Bug ID: 84023
   Summary: gcc.dg/ipa/inline-8.c fail with -fpic
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On x86-64 and i686, I got

[hjl@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/ipa/inline-8.c
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/ 
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt 
-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxrt/.libs
 -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/ 
-B/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap

-L/export/build/gnu/gcc/build-x86_64-linux/x86_64-pc-linux-gnu/32/libmpx/mpxwrap/.libs
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O2  -lm  -o
./inline-8.exe -fpic
[hjl@gnu-6 gcc]$ ./inline-8.exe
Aborted
[hjl@gnu-6 gcc]$

[Bug c++/84012] [8 regression] error: cannot convert ‘const std::shared_ptr’ to ‘std::a*’ in return

2018-01-24 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84012

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
The code is invalid, it only works with older versions of GCC and Clang because
you never instantiate the function template and so the bug isn't detected.
Obviously if you try to use the function then it won't compile, because there's
no conversion. Why do you expect it to compile?

See https://gcc.gnu.org/gcc-7/porting_to.html#hypothetical-instantiation

[Bug target/81352] [nvptx] trap placement for non-returning function call in vector-single mode

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81352

Tom de Vries  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug target/81352] [nvptx] trap placement for non-returning function call in vector-single mode

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81352

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #4 from Tom de Vries  ---
Patch with test-case committed, marking resolved-fixed.

[Bug bootstrap/84021] [8 Regression] bootstrap fails in libgo on powerpc64le-linux-gnu

2018-01-24 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84021

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bergner at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Bergner  ---
This is being tracked in PR83758.

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

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

2018-01-24 Thread bergner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758

Peter Bergner  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #20 from Peter Bergner  ---
*** Bug 84021 has been marked as a duplicate of this bug. ***

[Bug middle-end/84024] New: internal compiler error: in operator>, at profile-count.h:855

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84024

Bug ID: 84024
   Summary: internal compiler error: in operator>, at
profile-count.h:855
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 gcc]$ ./xgcc -B./
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c
 -O2 -freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE
-fpic
during IPA pass: profile
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/tree-prof/comp-goto-1.c:166:1:
internal compiler error: in operator>, at profile-count.h:855
 }
 ^
0x9b7c10 profile_count::operator>(long) const
/export/gnu/import/git/sources/gcc/gcc/profile-count.h:855
0xe84a80 handle_missing_profiles()
/export/gnu/import/git/sources/gcc/gcc/predict.c:3379
0x10e3151 tree_profiling
/export/gnu/import/git/sources/gcc/gcc/tree-profile.c:754
0x10e31a6 execute
/export/gnu/import/git/sources/gcc/gcc/tree-profile.c:784
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[hjl@gnu-6 gcc]$

[Bug c++/84001] ICE in dependent_type_p cp/pt.c:23567 when using member type of template parameter in template list

2018-01-24 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84001

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Marek Polacek  ---
Fixed by r255430 which was backported to gcc-7.

[Bug middle-end/84024] [8 Regression] internal compiler error: in operator>, at profile-count.h:855

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84024

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|internal compiler error: in |[8 Regression] internal
   |operator>, at   |compiler error: in
   |profile-count.h:855 |operator>, at
   ||profile-count.h:855

[Bug testsuite/84023] gcc.dg/ipa/inline-8.c fail with -fpic

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84023

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
  Component|middle-end  |testsuite
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think that's probably spurious:

void
set ()
{
 a=nan("");
}
...
  float a = move (1);
  if (!__builtin_constant_p (a))
__builtin_abort ();


given set doesn't bind locally with -fpic we don't inline it and thus
the result cannot be constant.

-> testsuite issue

A fix is probably to make set static.  That change is pre-approved.

[Bug bootstrap/84017] [6/7/8 regression] Bootstrap failure on Solaris 10/x86 with gas/ld

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84017

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.0 |6.5

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-24
 CC||rguenth at gcc dot gnu.org
Version|unknown |7.2.1
   Target Milestone|--- |7.3
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Given it fails in mpfr this is maybe a bug in mpfr?  What mpfr version are you
using?

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> Somehow switch-conversion doesn't transform the switch with -f{PIE,PIC}. 
> Without
> we get
> 
> phy_modes (phy_interface_t interface)
> {
>   const char * _1;
>   const char * _4;
> 
>[local count: 1073741825]:
>   if (interface_2(D) <= 22)
> goto ; [50.00%]
>   else
> goto ; [50.00%]
> 
>[local count: 536870912]:
>   _4 = CSWTCH.0[interface_2(D)];
> 
>[local count: 1073741825]:
>   # _1 = PHI <_4(3), "unknown"(2)>
>   return _1;
> 
> due to
> 
> Bailing out - value from a case would need runtime relocations
> 
>   reloc = initializer_constant_valid_p (val, TREE_TYPE
> (val));
>   if ((flag_pic && reloc != null_pointer_node)
>   || (!flag_pic && reloc == NULL_TREE))
> {
>   if (reloc)
> reason
>   = "value from a case would need runtime
> relocations";
>   else
> reason
>   = "value from a case is not a valid initializer";
> }
> 
> not sure why we need relocations for string constants?

They do need run-time relocations:

/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2  -fpic -S -o f.s f.i
[hjl@gnu-skl-1 pr82303]$ cat f.s
.file   "f.i"
.text
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "unknown"
.text
.p2align 4,,15
.globl  phy_modes
.type   phy_modes, @function
phy_modes:
.LFB0:
.cfi_startproc
leaq.LC0(%rip), %rax
cmpl$22, %edi
ja  .L1
movl%edi, %edi
leaqCSWTCH.0(%rip), %rax
movq(%rax,%rdi,8), %rax
.L1:
ret
.cfi_endproc
.LFE0:
.size   phy_modes, .-phy_modes
.section.rodata.str1.1
.LC1:
.string ""
.LC2:
.string "internal"
.LC3:
.string "mii"
.LC4:
.string "gmii"
.LC5:
.string "sgmii"
.LC6:
.string "tbi"
.LC7:
.string "rev-mii"
.LC8:
.string "rmii"
.LC9:
.string "rgmii"
.LC10:
.string "rgmii-id"
.LC11:
.string "rgmii-rxid"
.LC12:
.string "rgmii-txid"
.LC13:
.string "rtbi"
.LC14:
.string "smii"
.LC15:
.string "xgmii"
.LC16:
.string "moca"
.LC17:
.string "qsgmii"
.LC18:
.string "trgmii"
.LC19:
.string "1000base-x"
.LC20:
.string "2500base-x"
.LC21:
.string "rxaui"
.LC22:
.string "xaui"
.LC23:
.string "10gbase-kr"
.section.data.rel.ro.local,"aw",@progbits
.align 32
.type   CSWTCH.0, @object
.size   CSWTCH.0, 184
CSWTCH.0:
.quad   .LC1
.quad   .LC2
.quad   .LC3
.quad   .LC4
.quad   .LC5
.quad   .LC6
.quad   .LC7
.quad   .LC8
.quad   .LC9
.quad   .LC10
.quad   .LC11
.quad   .LC12
.quad   .LC13
.quad   .LC14
.quad   .LC15
.quad   .LC16
.quad   .LC17
.quad   .LC18
.quad   .LC19
.quad   .LC20
.quad   .LC21
.quad   .LC22
.quad   .LC23
.ident  "GCC: (GNU) 8.0.1 20180117 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr82303]$ gcc -c f.s
[hjl@gnu-skl-1 pr82303]$ readelf -rW f.o

Relocation section '.rela.text' at offset 0x370 contains 2 entries:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
0003  000a0002 R_X86_64_PC32   .LC0
- 4
0011  00070002 R_X86_64_PC32  
.data.rel.ro.local - 4

Relocation section '.rela.data.rel.ro.local' at offset 0x3a0 contains 23
entries:
Offset Info Type   Symbol's Value 
Symbol's Name + Addend
  00050001 R_X86_64_64
.rodata.str1.1 + 8
0008  00050001 R_X86_64_64
.rodata.str1.1 + 9
0010  00050001 R_X86_64_64
.rodata.str1.1 + 12
0018  00050001 R_X86_64_64
.rodata.str1.1 + 16
0020  00050001 R_X86_64_64
.rodata.str1.1 + 1b
0028  00050001 R_X86_64_64
.rodata.str1.1 + 21
0030  00050001 R_X86_64_64
.rodata.str1.1 + 25
0038  00050001 R_X86_64_64
.rodata.str1.1 + 2d
0040  00050001 R_X86_64_64
.rodata.str1.1 + 32

[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure

2018-01-24 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992

--- Comment #6 from Ian Lance Taylor  ---
In this case the problem happens before the assembler.  The bad location
information shows up in reemit_insn_block_notes in gcc/final.c.  As the first
insn in the block has no location, reemit_insn_block_notes adds a
NOTE_INSN_BLOCK_BEG note before the second insn.  See the NOTE_INSN_BLOCK_BEG
in the RTL dump in the initial report.

Perhaps reemit_insn_block_notes should check for NOTE_INSN_BASIC_BLOCK as it
already checks for NOTE_INSN_BEGIN_STMT.  Although the comments for
NOTE_INSN_BASIC_BLOCK say that it can not be considered to be reliable at that
point.

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

--- Comment #3 from H.J. Lu  ---
This patch works on the testcase:

diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index c2538908340..a1e85407bf3 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -827,16 +827,9 @@ check_final_bb (gswitch *swtch, struct switch_conv_info
*info)
  else
{
  reloc = initializer_constant_valid_p (val, TREE_TYPE (val));
- if ((flag_pic && reloc != null_pointer_node)
- || (!flag_pic && reloc == NULL_TREE))
-   {
- if (reloc)
-   reason
- = "value from a case would need runtime relocations";
- else
-   reason
- = "value from a case is not a valid initializer";
-   }
+ if (reloc == NULL_TREE)
+   reason
+ = "value from a case is not a valid initializer";
}
  if (reason)
{

[Bug middle-end/84024] [8 Regression] internal compiler error: in operator>, at profile-count.h:855

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84024

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Dup of PR83055 or related to that?

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

--- Comment #4 from rguenther at suse dot de  ---
On Wed, 24 Jan 2018, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
> 
> --- Comment #2 from H.J. Lu  ---
> (In reply to Richard Biener from comment #1)
> > Somehow switch-conversion doesn't transform the switch with -f{PIE,PIC}. 
> > Without
> > we get
> > 
> > phy_modes (phy_interface_t interface)
> > {
> >   const char * _1;
> >   const char * _4;
> > 
> >[local count: 1073741825]:
> >   if (interface_2(D) <= 22)
> > goto ; [50.00%]
> >   else
> > goto ; [50.00%]
> > 
> >[local count: 536870912]:
> >   _4 = CSWTCH.0[interface_2(D)];
> > 
> >[local count: 1073741825]:
> >   # _1 = PHI <_4(3), "unknown"(2)>
> >   return _1;
> > 
> > due to
> > 
> > Bailing out - value from a case would need runtime relocations
> > 
> >   reloc = initializer_constant_valid_p (val, TREE_TYPE
> > (val));
> >   if ((flag_pic && reloc != null_pointer_node)
> >   || (!flag_pic && reloc == NULL_TREE))
> > {
> >   if (reloc)
> > reason
> >   = "value from a case would need runtime
> > relocations";
> >   else
> > reason
> >   = "value from a case is not a valid initializer";
> > }
> > 
> > not sure why we need relocations for string constants?
> 
> They do need run-time relocations:
> 
> /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2  -fpic -S -o f.s f.i
> [hjl@gnu-skl-1 pr82303]$ cat f.s
> .file   "f.i"
> .text
> .section.rodata.str1.1,"aMS",@progbits,1
> .LC0:
> .string "unknown"
> .text
> .p2align 4,,15
> .globl  phy_modes
> .type   phy_modes, @function
> phy_modes:
> .LFB0:
> .cfi_startproc
> leaq.LC0(%rip), %rax
> cmpl$22, %edi
> ja  .L1
> movl%edi, %edi
> leaqCSWTCH.0(%rip), %rax
> movq(%rax,%rdi,8), %rax
> .L1:
> ret
> .cfi_endproc
> .LFE0:
> .size   phy_modes, .-phy_modes
> .section.rodata.str1.1
> .LC1:
> .string ""
> .LC2:
> .string "internal"
> .LC3:
> .string "mii"
> .LC4:
> .string "gmii"
> .LC5:
> .string "sgmii"
> .LC6:
> .string "tbi"
> .LC7:
> .string "rev-mii"
> .LC8:
> .string "rmii"
> .LC9:
> .string "rgmii"
> .LC10:
> .string "rgmii-id"
> .LC11:
> .string "rgmii-rxid"
> .LC12:
> .string "rgmii-txid"
> .LC13:
> .string "rtbi"
> .LC14:
> .string "smii"
> .LC15:
> .string "xgmii"
> .LC16:
> .string "moca"
> .LC17:
> .string "qsgmii"
> .LC18:
> .string "trgmii"
> .LC19:
> .string "1000base-x"
> .LC20:
> .string "2500base-x"
> .LC21:
> .string "rxaui"
> .LC22:
> .string "xaui"
> .LC23:
> .string "10gbase-kr"
> .section.data.rel.ro.local,"aw",@progbits
> .align 32
> .type   CSWTCH.0, @object
> .size   CSWTCH.0, 184
> CSWTCH.0:
> .quad   .LC1
> .quad   .LC2
> .quad   .LC3
> .quad   .LC4
> .quad   .LC5
> .quad   .LC6
> .quad   .LC7
> .quad   .LC8
> .quad   .LC9
> .quad   .LC10
> .quad   .LC11
> .quad   .LC12
> .quad   .LC13
> .quad   .LC14
> .quad   .LC15
> .quad   .LC16
> .quad   .LC17
> .quad   .LC18
> .quad   .LC19
> .quad   .LC20
> .quad   .LC21
> .quad   .LC22
> .quad   .LC23
> .ident  "GCC: (GNU) 8.0.1 20180117 (experimental)"
> .section.note.GNU-stack,"",@progbits
> [hjl@gnu-skl-1 pr82303]$ gcc -c f.s
> [hjl@gnu-skl-1 pr82303]$ readelf -rW f.o
> 
> Relocation section '.rela.text' at offset 0x370 contains 2 entries:
> Offset Info Type   Symbol's Value 
> Symbol's Name + Addend
> 0003  000a0002 R_X86_64_PC32   
> .LC0
> - 4
> 0011  00070002 R_X86_64_PC32  
> .data.rel.ro.local - 4
> 
> Relocation section '.rela.data.rel.ro.local' at offset 0x3a0 contains 23
> entries:
> Offset Info Type   Symbol's Value 
> Symbol's Name + Addend
>   00050001 R_X86_64_64
> .rodata.str1.1 + 8
> 0008  00050001 R_X86_64_64
> .rodata.str1.1 + 9
> 0010  00050001 R_X86_64_64
> .rodata.str1.1 + 12
> 0018  00050001 R_X86_64_640

[Bug tree-optimization/83992] wrong debug info: wrong NOTE_INSN_BLOCK_BEG placement causes TestCrashDumpsAllThreads gotools testcase failure

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83992

--- Comment #7 from Jakub Jelinek  ---
Corresponding C testcase would be something like:
static inline void
foo (void)
{
  int j;
  while (1)
for (j = 0; j < 0x7fff; ++j)
  ;
}

int
main ()
{
  foo ();
}
at -O2 -g {,-fno-var-tracking-assignments} {,-gno-statement-frontiers}

[Bug fortran/2018] Sqrt causes ice in emit_move_insn, at expr.c:2718

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2018

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Wed Jan 24 13:52:12 2018
New Revision: 257016

URL: https://gcc.gnu.org/viewcvs?rev=257016&root=gcc&view=rev
Log:
[nvptx, PR83589] Workaround for branch-around-nothing JIT bug

2018-01-24  Tom de Vries  

PR target/83589
* config/nvptx/nvptx.c (WORKAROUND_PTXJIT_BUG_2): Define to 1.
(nvptx_pc_set, nvptx_condjump_label): New function. Copy from jump.c.
Add strict parameter.
(prevent_branch_around_nothing): Insert dummy insn between branch to
label and label with no ptx insn inbetween.
* config/nvptx/nvptx.md (define_insn "fake_nop"): New insn.

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

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr83589.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/nvptx/nvptx.md
trunk/libgomp/ChangeLog

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Even large unreduced preprocessed testcases are useful, just xz -9e it and
hopefully it won't be that huge anymore.

[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589

--- Comment #9 from Tom de Vries  ---
Author: vries
Date: Wed Jan 24 13:52:12 2018
New Revision: 257016

URL: https://gcc.gnu.org/viewcvs?rev=257016&root=gcc&view=rev
Log:
[nvptx, PR83589] Workaround for branch-around-nothing JIT bug

2018-01-24  Tom de Vries  

PR target/83589
* config/nvptx/nvptx.c (WORKAROUND_PTXJIT_BUG_2): Define to 1.
(nvptx_pc_set, nvptx_condjump_label): New function. Copy from jump.c.
Add strict parameter.
(prevent_branch_around_nothing): Insert dummy insn between branch to
label and label with no ptx insn inbetween.
* config/nvptx/nvptx.md (define_insn "fake_nop"): New insn.

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

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr83589.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c
trunk/gcc/config/nvptx/nvptx.md
trunk/libgomp/ChangeLog

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

--- Comment #5 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #4)

> > The question is why run-time relocations aren't allowed.
> 
> Probably added to save binary space?  An optimization would be to

I don't think so:

  text data bss dec hex filename
714   0   0 714 2ca before my change
240 184   0 424 1a8 after my change

My change cuts down size by a wide margin.

> add an indirection by, say, only recording the constant offset
> into an "array of strings" in the table, thus effectively
> 
>   "case1\0case2\0..."[CSWITCH[i]]
> 
> which would require only a relocation to access the single string
> constant.  But it would prohibit cases of string merging within
> those strings unless we implement that as well for this optimization.
> Note this might be profitable unconditionally, not just with -fpie/pic
> as the CSWITCH table would be smaller (dependent on the total
> size of the merged string).

True, this is independent of PIE/PIC.

[Bug target/84025] New: [nvptx] Don't generate branch-around-nothing

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84025

Bug ID: 84025
   Summary: [nvptx] Don't generate branch-around-nothing
   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: ---

For PR83589 we have a non-invasive but non-minimal workaround for a JIT bug
when translating a branch-around-nothing.

We want to fix this better in stage1: by not generating branch-around-nothing.

[Bug target/83589] [nvptx] mode-transitions.c and private-variables.{c,f90} execution FAILs at GOMP_NVPTX_JIT=-O0

2018-01-24 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83589

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #10 from Tom de Vries  ---
Patch with test-case committed. 

Filed PR84025 to work around this JIT bug in a more optimal way in stage1.

Marking resolved-fixed.

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

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|Spec2000 regression around  |[8 Regression] Spec2000
   |Jan 14 and Jan 19 2018  |regression around Jan 14
   ||and Jan 19 2018

--- Comment #1 from Richard Biener  ---
mgrid also on IA64:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-terbium-head-64/recent.html

[Bug testsuite/84023] gcc.dg/ipa/inline-8.c fail with -fpic

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84023

--- Comment #2 from H.J. Lu  ---
(In reply to Richard Biener from comment #1)
> I think that's probably spurious:
> 
> void
> set ()
> {
>  a=nan("");
> }
> ...
>   float a = move (1);
>   if (!__builtin_constant_p (a))
> __builtin_abort ();
> 
> 
> given set doesn't bind locally with -fpic we don't inline it and thus
> the result cannot be constant.
> 
> -> testsuite issue
> 
> A fix is probably to make set static.  That change is pre-approved.

It makes no difference.  It still aborts with -fpic.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

2018-01-24 Thread boger at us dot ibm.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758

--- Comment #21 from boger at us dot ibm.com ---
(In reply to Alexandre Oliva from comment #19)
> I was copied, presumably because the problem occurred in var-tracking.
> 
> I've tried to duplicate the problem on gcc112.  I bootstrapped the trunk
> (without any --with-cpu flag), and then build attachment 43208 [details]
> with stage3:
> 
> $ ./gccgo -B./ -I../../libgo/go -I../powerpc64le-unknown-linux-gnu/libgo
> -I../powerpc64le-unknown-linux-gnu/libgo/go -O2 -g t.go -mcpu=power8 -c
> [success]
> 
> Given this, I conclude that the problem only occurs if the compiler is
> bootstrapped --with-cpu=power[89].  This suggests to me that, although the
> ICE is triggered in var-tracking, the problem is unlikely to be there: the
> compiler is getting miscompiled.  I suppose that, by now, you already knew
> that ;-)

The problem only occurs when configuring --with-cpu=power8 or 9 AND compiling
for split stack. If you are on a system where glibc is 2.17 or older then split
stack is not enabled and you won't see the failure even with --with-cpu=power8
or 9.

[Bug target/84011] Optimize switch table with -fPIE

2018-01-24 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

H.J. Lu  changed:

   What|Removed |Added

 CC||jakub at redhat dot com
 Depends on||36881

--- Comment #6 from H.J. Lu  ---
The code in question is done on purpose:

commit 54af7f7e3f0f38a4cd5667fda9fd9a68ad554df0
Author: jakub 
Date:   Wed Oct 15 06:43:19 2008 +

PR tree-optimization/36881
* tree-switch-conversion.c (check_final_bb): For flag_pic, check
that each value doesn't need runtime relocations, for !flag_pic
check that each value is just a valid initializer constant.

* gcc.dg/tree-ssa/pr36881.c: New test.


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

Should we revisit this decision?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36881
[Bug 36881] [4.4 Regression] Creating runtime relocations for code which does
not need it

[Bug tree-optimization/84011] Optimize switch table with run-time relocation

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Well, we'd need a target hook for these weirdo targets that don't support them
at all (spu, anything else?), and for the rest, perhaps we should think of
something better.  E.g. if not just some elements of the array return
null_pointer_node, but all of them, perhaps we could emit in the array content
value - array instead of value and then add array to whatever we load from the
array.

[Bug c++/83993] [7/8 Regression] ICE: constant not recomputed when ADDR_EXPR changed

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested patch for the 1) part.  With this the testcase doesn't ICE anymore,
but
modified testcase like:
extern const int a[];
const int *const b = &a[1];

int
foo ()
{
  return b[0];
}

still ICEs, so 2) needs to be resolved too.

[Bug tree-optimization/84011] Optimize switch table with run-time relocation

2018-01-24 Thread rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 24 Jan 2018, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84011
> 
> H.J. Lu  changed:
> 
>What|Removed |Added
> 
>  CC||jakub at redhat dot com
>  Depends on||36881
> 
> --- Comment #6 from H.J. Lu  ---
> The code in question is done on purpose:
> 
> commit 54af7f7e3f0f38a4cd5667fda9fd9a68ad554df0
> Author: jakub 
> Date:   Wed Oct 15 06:43:19 2008 +
> 
> PR tree-optimization/36881
> * tree-switch-conversion.c (check_final_bb): For flag_pic, check
> that each value doesn't need runtime relocations, for !flag_pic
> check that each value is just a valid initializer constant.
> 
> * gcc.dg/tree-ssa/pr36881.c: New test.
> 
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@141129
> 138bc75d-0d04-0410-961f-82ee72b054a4
> 
> Should we revisit this decision?

We could add a hook to allow the target to override.  Like
targetm.avoid_runtime_relocations_p () or runtime_relocations_expensive_p 
() or just (as it seems for SPU) runtime_relocations_supported_p ()?

As said ideally we'd simply avoid creating relocations for string
constants or other constant initializers.  Maybe that's even possible
in some weird ways via using section labels/addresses?  Thus make
the table contain

 .Lstring1 - .section_start_of_where_Lstring1_is,
 ...

and thus a constant initializer using some extension to query that
section start or even the offset -- __builtin_offset_from_section_start 
("foo")?

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

2018-01-24 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Can't reproduce mgrid, facerec and apsi regression on a Haswell machine.

[Bug c++/84026] New: invalid 'unnamed scoped enum is not allowed' when scoped enum has a full qualified-id

2018-01-24 Thread smw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84026

Bug ID: 84026
   Summary: invalid 'unnamed scoped enum is not allowed' when
scoped enum has a full qualified-id
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

On GCC (all versions tested, up to and including 8.0.1 20180117 with -std=c++14
-pedantic) but not o nMSVC, ICC, or clang, the following code

struct S1 {
  enum class E1;
};
enum class S1::E1 {}; // OK

struct S2 {
  enum class E2;
};
enum class ::S1::E1 {}; // Not OK

spits out the following error.

9 : :9:16: error: unnamed scoped enum is not allowed
 enum class ::S1::E1 {}; // Not OK
^~
9 : :9:10: warning: elaborated-type-specifier for a scoped enum must
not use the 'class' keyword
 enum class ::S1::E1 {}; // Not OK
  ^
  -
9 : :9:25: error: expected unqualified-id before '{' token
 enum class ::S1::E1 {}; // Not OK
 ^
Looks like it's not quite parsing correctly.

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

2018-01-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

--- Comment #3 from Richard Biener  ---
mgrid also on AMD Fam10:
https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-megrez-head-64/recent.html

[Bug fortran/84008] [PDT] ICE accessing kind and len parameters

2018-01-24 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84008

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Blocks||82173
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.


Referenced Bugs:

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

[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths

2018-01-24 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/82249] [8 Regression] wrong mismatched argument pack lengths

2018-01-24 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82249

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Jan 24 15:20:53 2018
New Revision: 257018

URL: https://gcc.gnu.org/viewcvs?rev=257018&root=gcc&view=rev
Log:
PR c++/82249 - wrong mismatched pack length error.

* pt.c (extract_fnparm_pack, tsubst_pack_expansion): Handle
unsubstituted function parameter pack.

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

[Bug c++/83796] [6/7/8 Regression] Abstract classes allowed to be instantiated when initialised as default parameter to function or constructor

2018-01-24 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83796

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #4 from Paolo Carlini  ---
Mine.

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

2018-01-24 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

--- Comment #4 from Martin Liška  ---
(In reply to Richard Biener from comment #3)
> mgrid also on AMD Fam10:
> https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-megrez-head-64/recent.html

Interesting about this regression is that mgrid is a single source benchmark.
Thus I would not expect a difference in between LTO and non-LTO mode.

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

2018-01-24 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
I can confirm regression from 517 -> 537s of gamess on a zen2 machine with
-Ofast -march=native. Let me bisect this one.

[Bug c++/83990] [7/8 Regression] Spurious "potential null pointer dereference" warning regression from 7.1 onwards

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83990

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I think this started with r246301.
This warning s an optimization warning and as the wording says, can have false
positives, the optimizer during path isolation simply finds a basic block
containing a pointer dereference where the pointer is known to be NULL on some
predecessor edge to the BB.
  basic_string(basic_string&& __str) noexcept
  : _M_dataplus(_M_local_data(), std::move(__str._M_get_allocator()))
  {
if (__str._M_is_local())
  {
traits_type::copy(_M_local_buf, __str._M_local_buf,
  _S_local_capacity + 1);
  }
and
  template
static _ForwardIterator
__uninit_copy(_InputIterator __first, _InputIterator __last,
  _ForwardIterator __result)
{
  _ForwardIterator __cur = __result;
  __try
{
  for (; __first != __last; ++__first, (void)++__cur)
std::_Construct(std::__addressof(*__cur), *__first);
  return __cur;
}
are the relevant snippets, the __first != __last guard is what guards the basic
block and the optimizers see some possibility that __first could be NULL in
some case.

[Bug fortran/82207] ieee_class identifies signaling NaNs as quiet NaNs

2018-01-24 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207

--- Comment #9 from Steve Kargl  ---
On Wed, Jan 24, 2018 at 10:53:40AM +, guez at lmd dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
> 
> --- Comment #8 from Lionel GUEZ  ---
> It does not seem completely true that gfortran makes no distinction between
> qNaN and sNaN.

See comment #2.

[Bug fortran/84006] [6/7/8 Regression] ICE in storage_size() with CLASS entity

2018-01-24 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
  Known to work||5.5.0
   Target Milestone|--- |6.5
Summary|ICE in storage_size() with  |[6/7/8 Regression] ICE in
   |CLASS entity|storage_size() with CLASS
   ||entity
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 6.4.0, 7.2.0 and trunk (8.0), likely r222361.

I am not sure the code is valid, it should not lead to an ICE.

[Bug fortran/84007] ICE with same_type_as with CLASS entity

2018-01-24 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from a least 4.8 up to trunk (8.0).

[Bug fortran/83976] ICE in gfc_add_component_ref, at fortran/class.c:211

2018-01-24 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83976

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-24
 Ever confirmed|0   |1

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

> bailed out with 5/6

Likely configured with --enable-checking=release.

[Bug target/84010] [sparc64] Problematic TLS code generation

2018-01-24 Thread jrtc27 at jrtc27 dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010

--- Comment #5 from James Clarke  ---
My patch seems to work for this case:

sethi   %tie_hi22(tcg_ctx), %g2
...
add %g2, %tie_lo10(tcg_ctx), %g1
ldx [%l7 + %g1], %g1, %tie_ldx(tcg_ctx)
stx %g2, [%fp+1783] ! note this is %g2, i.e. just the hi22...
callgen_new_label, 0
 ldx[%g7+%g1], %i5
...
ldx [%fp+1783], %g1 ! reload the hi22
add %g1, %tie_lo10(tcg_ctx), %i5
ldx [%l7 + %i5], %i5, %tie_ldx(tcg_ctx)
ldx [%g7+%i5], %g1

The code gen is something else; I don't understand why it spills the result of
the hi22 and re-adds the lo10 (which takes the worst aspects of
rematerialisation and spilling), but that's a whole other story.

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

2018-01-24 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84016

--- Comment #6 from Jan Hubicka  ---
Thanks! -flto makes differnce even for single file benchmarks (because of
thrown away type info and extra info from linker). So perhaps that is reason
why it did not reproduce?

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

2018-01-24 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81535

--- Comment #9 from seurer at gcc dot gnu.org ---
Just an FYI that the output of this test case changed a bit somewhere in the
range r256987 to r257017:

Now it gets this:

FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl g\\M 1 (found 2
times)

previously it failed with this:

FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mnop\\M 3 (found 2
times)

[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644

2018-01-24 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Jan 24 16:22:40 2018
New Revision: 257022

URL: https://gcc.gnu.org/viewcvs?rev=257022&root=gcc&view=rev
Log:
Remove explicit dg-do runs from gcc.dg/vect (PR 83889)

The failures in this PR were from forcing { dg-do run } even when
vect.exp chooses options that are incompatible with the runtime.
The default vect.exp behaviour is to execute when possible, so there's
no need for a dg-do at all.

The patch removes other unconditional { dg-do run }s too.  Many of them
were already failing in the same way.

Also, the dg-do run condition in vect-reduc-or* seems unnecessary:
the test should run correctly whatever happens, and the scan tests
are already guarded properly.

2018-01-24  Richard Sandiford  

gcc/testsuite/
PR testsuite/83889
* gcc.dg/vect/pr79920.c: Remove explicit dg-do run.
* gcc.dg/vect/pr80631-1.c: Likewise.
* gcc.dg/vect/pr80631-2.c: Likewise.
* gcc.dg/vect/pr81410.c: Likewise.
* gcc.dg/vect/pr81633.c: Likewise.
* gcc.dg/vect/pr81815.c: Likewise.
* gcc.dg/vect/pr82108.c: Likewise.
* gcc.dg/vect/pr83857.c: Likewise.
* gcc.dg/vect/vect-alias-check-8.c: Likewise.
* gcc.dg/vect/vect-alias-check-9.c: Likewise.
* gcc.dg/vect/vect-alias-check-10.c: Likewise.
* gcc.dg/vect/vect-alias-check-11.c: Likewise.
* gcc.dg/vect/vect-alias-check-12.c: Likewise.
* gcc.dg/vect/vect-reduc-11.c: Likewise.
* gcc.dg/vect/vect-tail-nomask-1.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-1.c: Remove dg-do run and use
dg-xfail-run-if instead.
* gcc.dg/vect/vect-reduc-in-order-2.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-3.c: Likewise.
* gcc.dg/vect/vect-reduc-in-order-4.c: Likewise.
* gcc.dg/vect/vect-reduc-or_1.c: Remove conditional dg-do run.
* gcc.dg/vect/vect-reduc-or_2.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr79920.c
trunk/gcc/testsuite/gcc.dg/vect/pr80631-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr80631-2.c
trunk/gcc/testsuite/gcc.dg/vect/pr81410.c
trunk/gcc/testsuite/gcc.dg/vect/pr81633.c
trunk/gcc/testsuite/gcc.dg/vect/pr81815.c
trunk/gcc/testsuite/gcc.dg/vect/pr82108.c
trunk/gcc/testsuite/gcc.dg/vect/pr83857.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-10.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-11.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-12.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-8.c
trunk/gcc/testsuite/gcc.dg/vect/vect-alias-check-9.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-11.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-2.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-3.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-in-order-4.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-or_1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-reduc-or_2.c
trunk/gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c

[Bug c++/83979] [8 Regression] ICE with pointer comparison

2018-01-24 Thread rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83979

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Jan 24 16:22:30 2018
New Revision: 257021

URL: https://gcc.gnu.org/viewcvs?rev=257021&root=gcc&view=rev
Log:
Fix use of boolean_true/false_node (PR 83979)

r255913 changed some constant_boolean_node calls to boolean_true_node
and boolean_false_node, which meant that the returned tree didn't
always have the right type.

2018-01-24  Richard Sandiford  

gcc/
PR tree-optimization/83979
* fold-const.c (fold_comparison): Use constant_boolean_node
instead of boolean_{true,false}_node.

gcc/testsuite/
PR tree-optimization/83979
* g++.dg/pr83979.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr83979.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/83977] [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184

2018-01-24 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan 24 16:28:47 2018
New Revision: 257023

URL: https://gcc.gnu.org/viewcvs?rev=257023&root=gcc&view=rev
Log:
PR middle-end/83977
* tree.c (free_lang_data_in_decl): Don't clear DECL_ABSTRACT_ORIGIN
here.
* omp-low.c (create_omp_child_function): Remove "omp declare simd"
attributes from DECL_ATTRIBUTES (decl) without affecting
DECL_ATTRIBUTES (current_function_decl).
* omp-simd-clone.c (expand_simd_clones): Ignore DECL_ARTIFICIAL
functions with non-NULL DECL_ABSTRACT_ORIGIN.

* c-c++-common/gomp/pr83977-1.c: New test.
* c-c++-common/gomp/pr83977-2.c: New test.
* c-c++-common/gomp/pr83977-3.c: New test.
* gfortran.dg/gomp/pr83977.f90: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr83977-1.c
trunk/gcc/testsuite/c-c++-common/gomp/pr83977-2.c
trunk/gcc/testsuite/c-c++-common/gomp/pr83977-3.c
trunk/gcc/testsuite/gfortran.dg/gomp/pr83977.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/omp-simd-clone.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree.c

[Bug c++/82514] [8 Regression] ICE: in operator[], at vec.h:749

2018-01-24 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82514

--- Comment #5 from Jason Merrill  ---
Further reduced:

template  void i(h) { }
template  void n() {
  [] {
struct p { };
i(p{});
  };
}

auto f = n<1>;

[Bug c++/84027] New: new-expression does not accept an attribute-specifier-seq

2018-01-24 Thread smw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84027

Bug ID: 84027
   Summary: new-expression does not accept an
attribute-specifier-seq
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: smw at gcc dot gnu.org
  Target Milestone: ---

The standard [expr.new]/1 defines the new-type-id part of a new expression as
having (one or more) attribute-specifier-seq but GCC does not accept that
construct.  Example code:

void f() { char* p = new char[sizeof(int)] alignas(int); }

GCC 8.0.1 20180117 (exprimental) with -std=c++14 -pedantic gives the following
diagnostic.

: In function 'void f()':
1 : :1:44: error: expected ',' or ';' before 'alignas'
 void f() { char* p = new char[sizeof(int)] alignas(int); }
^~~
1 : :1:18: warning: unused variable 'p' [-Wunused-variable]
 void f() { char* p = new char[sizeof(int)] alignas(int); }
  ^
Note that the example code is accepted without error by clang and ICC.

  1   2   >