[Bug c++/80916] Spurious "declared 'static' but never defined" warning

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #3 from ensadc at mailnesia dot com ---
Reduced:

struct j {
  virtual void dispatch(void *);
};
template 
struct i : j {
  void dispatch(void *);
};
namespace {
struct l : i {};
}
void f(j *k) {
  k->dispatch(0);
}

[Bug libstdc++/78179] FAIL: 26_numerics/headers/cmath/hypot.cc execution test

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #1 from sandra at gcc dot gnu.org ---
This test also fails on nios2 (both nios2-elf and nios2-linux-gnu).

[Bug c++/87161] New: if -Werror appear after -Wmissing-prototypes the warning is not turn into error

[nir.aizik at harman dot com]

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

Bug ID: 87161
   Summary: if -Werror appear after -Wmissing-prototypes the
warning is not turn into error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nir.aizik at harman dot com
  Target Milestone: ---

Werror before Wmissing-prototypes gives:

g++ -c -Werror -Wmissing-prototypes test.c -o test.o
cc1plus: error: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC
but not for C++ [-Werror]
cc1plus: all warnings being treated as errors

Werror after Wmissing-prototypes gives:

g++ -c -Wmissing-prototypes -Werror test.c -o test.o
cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for
C/ObjC but not for C++


I believe both options should end with error or at least this behavior should
be documented

[Bug c/86134] earlier diagnostic causes followup diagnostic about unknown -Wno-* options

[P at draigBrady dot com]

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

--- Comment #11 from Pádraig Brady  ---
I agree that -Wno-... should never be promoted to an error as we see with:

$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-error=return-type -
: In function ‘maint’:
:1:1: warning: control reaches end of non-void function [-Wreturn-type]
: At top level:
cc1: error: unrecognized command line option ‘-Wno-unknown-warning-option’
[-Werror]
cc1: all warnings being treated as errors


However it's worth noting that one can suppress the other warnings entirely
that trigger the promotion. This may be ok as a workaround for some:

$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-return-type -

[Bug c++/87125] [9 Regression] ICE in tsubst_copy starting with r261084

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #2 from ensadc at mailnesia dot com ---
Reduced:

template struct ch {
  template constexpr ch(by) noexcept(br());
};
class ce : ch {
  using ch::ch;
};

void f() {
  noexcept(ce(0));
}

[Bug testsuite/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Indeed, having -fdump-tree-vect-details-blocks dump would probably make it easy
to figure out what happens.

What is configuration tripplet and exact invocation line for the test?

[Bug testsuite/87158] FAIL gcc.c-torture/execute/memchr-1.c on big endian targets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
*** Bug 87159 has been marked as a duplicate of this bug. ***

[Bug testsuite/87159] [9 regression] new test gcc.c-torture/execute/memchr-1.c fails starting with introduction in r263963

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Resolved as a duplicate of bug 87158 (fixed in r264000).

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

[Bug testsuite/87158] FAIL gcc.c-torture/execute/memchr-1.c on big endian targets

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Aug 30 21:25:10 2018
New Revision: 264000

URL: https://gcc.gnu.org/viewcvs?rev=264000=gcc=rev
Log:
PR testsuite/87158 - FAIL gcc.c-torture/execute/memchr-1.c on big endian
targets

gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/memchr-1.c: Correct big-endian expectations.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/memchr-1.c

[Bug testsuite/87158] FAIL gcc.c-torture/execute/memchr-1.c on big endian targets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Martin Sebor  ---
Fixed in r264000.

[Bug bootstrap/87141] configure:14586: error: Could not determine word size.

[mfe at live dot de]

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

--- Comment #3 from martin  ---
Created attachment 44633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44633=edit
config.log of root gcc dir

[Bug target/87160] New: Maybe miscompilation of a polyhedron test

[marxin at gcc dot gnu.org]

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

Bug ID: 87160
   Summary: Maybe miscompilation of a polyhedron test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

All releases that support -march=broadwell cause segfault on following
polyhedron test-case:

gfortran -Ofast -g -march=broadwell test_fpu2.f90 -o b.out &&  gdb ./b.out
...
Program received signal SIGSEGV, Segmentation fault.

(gdb) bt
#0  0x00402123 in crout (a=, n=2000) at
test_fpu2.f90:168
#1  0x0040e555 in test_fpu () at test_fpu2.f90:79
#2  0x0040118d in main (argc=argc@entry=1, argv=0x7fffe428) at
test_fpu2.f90:12
#3  0x77435feb in __libc_start_main (main=0x401170 , argc=1,
argv=0x7fffe038, init=, fini=,
rtld_fini=, stack_end=0x7fffe028) at ../csu/libc-start.c:308
#4  0x004011ea in _start () at ../sysdeps/x86_64/start.S:120

   │0x402120add%rsi,%rcx
  >│0x402123vmovdqu %ymm0,(%rdx)
   │0x402127add$0x20,%rdx
   │0x40212bvpaddd %ymm1,%ymm0,%ymm0

Maybe Richi is interested in that?
-O3 works fine; I can reproduce that on Haswell using the march option value

[Bug target/52034] __builtin_copysign optimization suboptimal

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Last reconfirmed|2012-01-29 00:00:00 |2018-8-30
  Known to fail||8.2.0

--- Comment #3 from Marc Glisse  ---
I don't understand why we keep UNSPEC_COPYSIGN so long, it is only expanded in
split2, after register allocation. Maybe splitting earlier into and+and+or
would help RA...

[Bug testsuite/87157] [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
I doubt the test cases need updating.  Looks like this change had a surprising
side of effect of breaking vectorization for this test on Power, which needs to
be understood and fixed.

[Bug testsuite/87159] New: [9 regression] new test gcc.c-torture/execute/memchr-1.c fails starting with introduction in r263963

[seurer at gcc dot gnu.org]

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

Bug ID: 87159
   Summary: [9 regression] new test
gcc.c-torture/execute/memchr-1.c fails starting with
introduction in r263963
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

These new tests fail on powerpc64 BE.  They work fine on LE so this is probably
an endian problem.

> FAIL: gcc.c-torture/execute/memchr-1.c   -O0  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -O1  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -O2  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/memchr-1.c   -Os  execution test


The failures are all:

assertion failed on line 142: memchr ([1], 0, nb - 1 * nwb) == pws4 + 1 *
nwb + 0

[Bug fortran/85357] ICE on invalid code with equal procedure names

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Further reduced test case for the ICE:


module base
   implicit none
contains
   subroutine summation(i)
  integer, intent(in) :: i
   end subroutine
end module

module extended
   use base
   implicit none
contains
   subroutine summation()
   end subroutine
end module

[Bug target/86007] precompiled header on bdver2 with -march=native triggers a "created and used with differing settings of '-mlwp'" warning, intermittently

[stefantalpalaru at yahoo dot com]

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

--- Comment #3 from Ștefan Talpalaru  ---
The problem persists in 8.2.0 and in current trunk. You need to run that
command a hundred of times or so, on a Piledriver, to replicate it:

for i in `seq 1 100`; do gcc -S t.c -march=native -v 2>&1 | grep lwp | sed -e
's/.*\(-m\(no-\)\?lwp\).*/\1/'; done | grep '\-mlwp' | wc -l

[Bug c++/87152] internal compiler error: in tsubst_copy, at cp/pt.c:15484

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Started with mine r260619, before it was of course rejected.  But this version

template
int int_from_bits()
{
int a[1] = {};
int index = 0;
for (int _ : a)
{
index;
}
return 0;
}

int j = int_from_bits<>();

compiles fine.  So mine, I guess.  Not a regression though.

[Bug testsuite/87158] FAIL gcc.c-torture/execute/memchr-1.c on big endian targets

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Target||powerpc64-linux
 CC||law at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Here's a patch:

diff --git a/gcc/testsuite/gcc.c-torture/execute/memchr-1.c
b/gcc/testsuite/gcc.
index ec37632..54fae16 100644
--- a/gcc/testsuite/gcc.c-torture/execute/memchr-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/memchr-1.c
@@ -139,9 +139,9 @@ void test_wide (void)
   A (memchr (ws1, 0, sizeof ws1) == pws1 + 0);

   A (memchr ([0], 0, nb) == pws4 + 0);
-  A (memchr ([1], 0, nb - 1 * nwb) == pws4 + 1 * nwb + 0);
-  A (memchr ([2], 0, nb - 2 * nwb) == pws4 + 2 * nwb + 1);
-  A (memchr ([3], 0, nb - 3 * nwb) == pws4 + 3 * nwb + 2);
+  A (memchr ([1], 0, nb - 1 * nwb) == pws4 + 1 * nwb + 1);
+  A (memchr ([2], 0, nb - 2 * nwb) == pws4 + 2 * nwb + 2);
+  A (memchr ([3], 0, nb - 3 * nwb) == pws4 + 3 * nwb + 3);
 #endif
 }

[Bug c++/87152] internal compiler error: in tsubst_copy, at cp/pt.c:15484

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug testsuite/87158] New: FAIL gcc.c-torture/execute/memchr-1.c on big endian targets

[msebor at gcc dot gnu.org]

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

Bug ID: 87158
   Summary: FAIL gcc.c-torture/execute/memchr-1.c on big endian
targets
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The new runtime test memchr-1.c fails on the big-endian powerpc64.  The initial
revision of the test wasn't right for big-endian targets but I thought I fixed
that so I may not have updated the posted patch before Jeff committed it in
r263963.

FAIL: gcc.c-torture/execute/memchr-1.c   -O0  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -O1  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -O2  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/memchr-1.c   -Os  execution test

[Bug testsuite/87157] New: [9 regression] gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails starting with r263981

[seurer at gcc dot gnu.org]

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

Bug ID: 87157
   Summary: [9 regression]
gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
starting with r263981
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

On power 8/9 it fails like this:
> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect 
> "vectorized 1 loops" 1

On power 7 it fails like this:
> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect 
> "loop versioned for vectorization to enhance alignment" 1
> FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect 
> "vectorized 1 loops" 1


Do the test cases just need updating?


make -k check-gcc
RUNTESTFLAGS=ppc-costmodel-vect.exp=gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c

# of expected passes1
# of unexpected failures1
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times vect
"vectorized 1 loops" 1


r263981 | hubicka | 2018-08-30 07:58:42 -0500 (Thu, 30 Aug 2018) | 8 lines


* sreal.h (SREAL_PART_BITS): Change to 31; remove seemingly unnecessary
comment that it has to be even number.
(class sreal): Change m_sig type to int32_t.
* sreal.c (sreal::dump, sreal::to_int, opreator+, operator-): Use
int64_t for temporary calculations.
(sreal_verify_basics): Drop one bit from minimum and maximum.

[Bug target/87156] New: [9 Regression] ICE building libstdc++ for mips64

[jsm28 at gcc dot gnu.org]

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

Bug ID: 87156
   Summary: [9 Regression] ICE building libstdc++ for mips64
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: mips64-linux-gnu

Created attachment 44632
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44632=edit
Preprocessed source

I see the following ICE building libstdc++ for mips64-linux-gnu.  Compile with:
-S -O2 -std=gnu++11 compatibility-c++0x.ii

Bisecting shows it first appearing with r263962, though I don't really see what
it has to do with that commit.  Still fails as of r263983 (line numbers in this
backtrace are from that revision).

during GIMPLE pass: fnsplit
/scratch/jmyers/glibc/many9/src/gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:
In function 'virtual std::error_condition
std::error_category::default_error_condition(int) const':
/scratch/jmyers/glibc/many9/src/gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:256:1:
internal compiler error: Segmentation fault
256 | }
| ^
0xd71e5f crash_signal
/scratch/jmyers/glibc/many9/src/gcc/gcc/toplev.c:325
0x1036ca8 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.h:3235
0x1036ca8 decl_function_context(tree_node const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree.c:8994
0x10d0cb7 mips_get_compress_mode
/scratch/jmyers/glibc/many9/src/gcc/gcc/config/mips/mips.c:1355
0x10d1fa8 mips_set_current_function
/scratch/jmyers/glibc/many9/src/gcc/gcc/config/mips/mips.c:19636
0xa6ba9b invoke_set_current_function_hook
/scratch/jmyers/glibc/many9/src/gcc/gcc/function.c:4616
0xa74533 invoke_set_current_function_hook
/scratch/jmyers/glibc/many9/src/gcc/gcc/function.c:4600
0xa74533 allocate_struct_function(tree_node*, bool)
/scratch/jmyers/glibc/many9/src/gcc/gcc/function.c:4729
0xe05d4d initialize_cfun
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-inline.c:2452
0xe05d4d tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/tree-inline.c:5833
0x92e80c cgraph_node::create_version_clone_with_body(vec, vec*, bitmap_head*, bool,
bitmap_head*, basic_block_def*, char const*)
/scratch/jmyers/glibc/many9/src/gcc/gcc/cgraphclones.c:984
0x58b18c split_function
/scratch/jmyers/glibc/many9/src/gcc/gcc/ipa-split.c:1330
0x14269d2 execute_split_functions
/scratch/jmyers/glibc/many9/src/gcc/gcc/ipa-split.c:1825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/87152] internal compiler error: in tsubst_copy, at cp/pt.c:15484

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:

template
int int_from_bits()
{
int a[1] = {};
for (int index = 0; int _ : a)
{
index;
}
return 0;
}

int j = int_from_bits<>();

[Bug c++/84707] [8 Regression] internal compiler error: Segmentation fault (tree_check()/duplicate_decls())

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #8 from Marek Polacek  ---
Oop.  Adjusting the keyword then.

[Bug c++/84707] [8 Regression] internal compiler error: Segmentation fault (tree_check()/duplicate_decls())

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 CC||nathan at gcc dot gnu.org
 Resolution|FIXED   |---
   Assignee|mpolacek at gcc dot gnu.org|nathan at gcc dot 
gnu.org

--- Comment #7 from Nathan Sidwell  ---
The code is actually well formed.  the final final namespace decl reopens the
inline anon namespace!

[Bug c++/87148] [6/7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The decision to reject the code in comment #0 was deliberate (as Jonathan
explained in comment #2).  We wanted (and still do) G++ to enforce rules that
are at least as strict as C's (and GCC's in C mode).

The other test case:

  struct Tst {
int i;
char t[];
  };

  Tst t = Tst();

arguably should be accepted because the equivalent

  Tst t { };

is accepted.

[Bug fortran/87103] [OOP] ICE in gfc_new_symbol() due to overlong symbol name

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org
Summary|ICE in gfc_new_symbol() due |[OOP] ICE in
   |to overlong symbol name |gfc_new_symbol() due to
   ||overlong symbol name

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Andrew Benson from comment #0)
> The following code causes an ICE with gfortan 9.0.0 (r263855):
> 
> [..]
>
> The problem seems to be that gfc_new_symbol() is passed a name
> '__tmp_class_namethatisverylongbutnottoolongthatitshouldbeinvalid' in this
> case which exceeds GFC_MAX_SYMBOL_LEN=64. My understanding is that the code
> is valid since the symbol name itself,
> 'namethatisverylongbutnottoolongthatitshouldbeinvalid', is less than 64
> characters. 
> 
> I'm not sure what the correct fix for this is - should the name length limit
> in gfc_new_symbol() just be increased by enough to allow the '__tmp_class_'
> prefix?

Yes, one could just bump GFC_MAX_SYMBOL_LEN to 64+12.


Btw, in the F08 standard I find:

C301 (R303) The maximum length of a name is 63 characters.

I guess GFC_MAX_SYMBOL_LEN needs to be 64 in order to account for null
termination.

[Bug lto/86517] relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object with LTO

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Thu Aug 30 15:50:39 2018
New Revision: 263988

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


PR lto/86517
* lto-opts.c (lto_write_options): Always stream PIC/PIE mode.
* lto-wrapper.c (merge_and_complain): Fix merging of PIC/PIE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-opts.c
trunk/gcc/lto-wrapper.c

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
   Target Milestone|8.3 |---

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
There are three things going wrong:

1) You configure without having an assembler available.  This will disable
various features in your compiler.  The same happens on e.g. the x86 port.

2) We allow disabling fprnd independently from other things,  That just raises
complexity enormously, without any real benefit.  The same flag (TARGET_FPRND)
is used as a stand-in for ISA 2.04 in some places.

3) You end up getting ISA 2.04 insns disabled, but most VSX stuff enabled.
That should not happen.


1) is easy to fix: Do Not Do That Then.

2) and 3) will take time; but I have a band-aid to make the pain for PR86684
and this go away, which I'll commit in a bit.

[Bug target/37158] Wrong insn for _mm_comieq_sd

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/78809] Inline strcmp with small constant strings

[qinzhao at gcc dot gnu.org]

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

--- Comment #47 from qinzhao at gcc dot gnu.org ---
all the issues triggered by the previous patch have been fixed.
I am planing to close this PR as fixed.

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

[qinzhao at gcc dot gnu.org]

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

--- Comment #21 from qinzhao at gcc dot gnu.org ---
the latest patch to this test bug has just been checked in at:

https://gcc.gnu.org/viewcvs/gcc?view=revision=263983

[Bug bootstrap/87141] configure:14586: error: Could not determine word size.

[mfe at live dot de]

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

--- Comment #2 from martin  ---
>Can you even execute a simple hello world you compile yourself?

Yes (using /opt/gcc-7.3/bin/gcc).

>here (x86_64-linux) 126 is ENOKEY.  Looks like somehow your platform requires
signed executables?

No, I already compiled many libraries and executables like libmpc,libgnutls,
curl,wget and never had any issues which mention to sign the executables.

[Bug bootstrap/87146] ubsan bootstrap with non-gcc compiler fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
With bootstrap-ubsan only stage2/stage3 are built with -fsanitize=undefined, so
most likely clang just miscompiled something.

[Bug fortran/87154] Internal compiler error: in gimplify_expr, at gimplify.c:12215

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-08-30
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed on 7.3.0. This seems to be fixed on 8.2.0 and trunk (9.0).

Revision r252781 (2017-09-15) gives the error

   ASSOCIATE(arg=>args(1))
1
Error: Entity 'arg' at (1) has a deferred type parameter and requires either
the POINTER or ALLOCATABLE attribute

r253527 (2017-10-08) compiles the test.

I get the ICE with revisions r253041, r253132, and r253237.

[Bug target/87104] missed &, == optimization makes Emacs ~0.4% slower on x86-64

[pipcet at gmail dot com]

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

--- Comment #12 from pipcet at gmail dot com ---
(In reply to pipcet from comment #11)
>  (insn 7 6 8 2 (set (reg:CCZ 17 flags)
>  (compare:CCZ (and:DI (not:DI (reg/v:DI 86 [ i ]))
>  (const_int 12 [0xc]))
>  (const_int 0 [0]))) "h17.c":4 15 {*cmpdi_1}
>   (expr_list:REG_DEAD (reg:DI 88)
> 
> Surely we should be dealing with a canonical form instead?  Who's
> generating this non-canonical expression, and why?

simplify-rtx.c, it turns out, because it "canonicalizes" (x & y) = y to (~x &
y) = 0. I think that's strange, but we can work around it.

I'm testing these three approaches:
1. canonicalize to (x-y) & z = 0
2. don't canonicalize, but add a define_insn_and_split
3. original gcc

head-to-head. I'm compiling trunk Emacs with Paul's patch reverted, then
running  "perf stat ./src/temacs --batch" in a loop and producing a histogram
of the cycles needed. It seems (1) and (2) beat (3) quite significantly (1.1%)
while (1) very narrowly beats (2) (< 0.1%). Both values are the median values,
but it looks like the curves are simply shifted a little, so I'm prepared to
say it's a consistent effect.

The code looks good, and the slight difference between (1) and (2) makes sense,
because (2) generates:

leal-5(%rdi), %esi
movq%rdi, %rax
andl$7, %esi
je  .L129
ret
.p2align 4,,10
.p2align 3
.L129:
movslq  suspicious_object_index(%rip), %rsi
movl$0, %ecx

while (1) realizes %rsi is zero at this point and skips the movl. (Looking at
this code, I do not understand why movl is used rather than the standard xorl,
though, so maybe this is another optimization opportunity).

So I think the performance difference is really significant for Emacs; my plan
is to test all three versions on other programs, make sure the code works for C
bitfields, and then submit it for inclusion. Is that okay?

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Perhaps that
  if (conv->kind == ck_rvalue)
conv = next_conversion (conv);
shouldn't be done if (flags & LOOKUP_PREFER_RVALUE) or if
conv->rvaluedness_matches_p?  Just a wild guess though, that code dates back
to:
Fri Feb 13 14:55:37 1998  Jason Merrill  

* call.c (standard_conversion): Fix multi-level ptr conversions.

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes but it would conflict with n1::n2::bob because n2 is an inline namespace.

It seems like the diagnostic is misleading, it suggests n1::bob conflicts with
itself, but actually it conflicts with n1::n2::bob:

namespace n1 {
namespace bob {}

inline namespace n2 {
namespace bob {}
} 

namespace bob {}
} 

anon.cc:8:15: error: 'namespace n1::bob { }' conflicts with a previous
declaration
8 | namespace bob {}
  |   ^~~
anon.cc:2:15: note: previous declaration 'namespace n1::bob { }'
2 | namespace bob {}
  |   ^~~

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[artiom.yurol at ya dot ru]

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

--- Comment #3 from Artem Yurchenko  ---
(In reply to Nathan Sidwell from comment #2)
> Hm, while I understand the intent here, I wonder if clang is succeeding by
> accident?  The std is not completely clear whether all anonymous namespaces
> may share the same unique identifier or not.  We do, and hence fail here for
> the same reasons as-if the two anonymous namespaces were named 'bob'.  Will
> ask.

If two namespaces named 'bob' are in the same enclosing namespace, the second
should extend the first one, not redeclare it. Also, I checked it on
https://godbolt.org/z/4PhIG0, and the code compiles with virtually every
compiler that I choose (besides gcc 8.1+)

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
r251035 clearly has code that handles that rule:
+
+  if (flags & LOOKUP_PREFER_RVALUE)
+   {
+ /* The implicit move specified in 15.8.3/3 fails "...if the type of
+the first parameter of the selected constructor is not an rvalue
+reference to the object’s type (possibly cv-qualified)" */
+ gcc_assert (!(complain & tf_error));
+ tree ptype = convs[0]->type;
+ if (TREE_CODE (ptype) != REFERENCE_TYPE
+ || !TYPE_REF_IS_RVALUE (ptype)
+ || CONVERSION_RANK (convs[0]) > cr_exact)
+   return error_mark_node;
+   }

The thing is that LOOKUP_PREFER_RVALUE isn't set in this case, as we trigger
first:
  else if (MAYBE_CLASS_TYPE_P (to) && MAYBE_CLASS_TYPE_P (from)
   && is_properly_derived_from (from, to))
{
  if (conv->kind == ck_rvalue)
conv = next_conversion (conv);
  conv = build_conv (ck_base, to, conv);
  /* The derived-to-base conversion indicates the initialization
 of a parameter with base type from an object of a derived
 type.  A temporary object is created to hold the result of
 the conversion unless we're binding directly to a reference.  */
  conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
}
  else
return NULL;
in standard_conversion, where
*conv
$17 = {kind = ck_rvalue, rank = cr_identity, user_conv_p = 0, ellipsis_p = 0,
this_p = 0, bad_p = 0, need_temporary_p = 0, base_p = 0, 
  rvaluedness_matches_p = 1, check_narrowing = 0, check_narrowing_const_only =
0, type = , u = {next = 0x2f92e80, 
expr = , list = 0x2f92e80}, cand = 0x0}
and
*next_conversion (conv)
$18 = {kind = ck_identity, rank = cr_identity, user_conv_p = 0, ellipsis_p = 0,
this_p = 0, bad_p = 0, need_temporary_p = 0, base_p = 0, 
  rvaluedness_matches_p = 0, check_narrowing = 0, check_narrowing_const_only =
0, type = , u = {
next = 0x7fffefdbd6c0, expr = , list =
0x7fffefdbd6c0}, cand = 0x0}
so we are no longer using ck_rvalue conversion with rvaluedness_matches_p, but
ck_base conversion instead.

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Right. CWG 1579 says we should move here:

struct A { };
struct B { B(A&&) { } };
B f() { A a; return a; }

That's a different case though.

[Bug libstdc++/87135] [C++17] unordered containers violate iterator validity requirements

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This changed with https://wg21.link/lwg2156

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
So, so far I have only reproduced it if I configure the compiler for
ppc64le-linux
(not powerpc64le-linux), _and_ I have no working assembler for that.  Is that
your situation, too?

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.3

[Bug libstdc++/87135] [C++17] unordered containers violate iterator validity requirements

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
 CC||fdumont at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r251035 aka PR80452 aka C++ Core issue 1579.
> So, is this really invalid?

but CWG1579 didn't change the "if the type of the first parameter of the
selected constructor is not an rvalue reference to the object’s type (possibly
cv-qualified), overload resolution is performed again, considering the object
as an
lvalue." part

[Bug tree-optimization/87147] [9 Regression] GCC miscompiles at -O3 on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87147] [9 Regression] GCC miscompiles at -O3 on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Aug 30 12:37:10 2018
New Revision: 263980

URL: https://gcc.gnu.org/viewcvs?rev=263980=gcc=rev
Log:
2018-08-30  Richard Biener  

PR tree-optimization/87147
* tree-ssa-sccvn.c (SSA_VISITED): New function.
(visit_phi): When the degenerate result is from the backedge and
we didn't visit its definition yet drop to VARYING.
(do_rpo_vn): Properly mark blocks with incoming backedges as
executable.

* gcc.dg/torture/pr87147.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87147.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
Hm, while I understand the intent here, I wonder if clang is succeeding by
accident?  The std is not completely clear whether all anonymous namespaces may
share the same unique identifier or not.  We do, and hence fail here for the
same reasons as-if the two anonymous namespaces were named 'bob'.  Will ask.

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
This changed with r251035 aka PR80452 aka C++ Core issue 1579.
So, is this really invalid?

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
So both -Q --help=target as well as -fverbose-asm say -mfprnd is on; but the
ICE is because TARGET_FPRND is _off_.  What.

[Bug c++/87155] [8/9 Regression] unnamed namespace redeclaration error when inline namespace is present

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org
  Known to work||7.3.0
Summary|unnamed namespace   |[8/9 Regression] unnamed
   |redeclaration error when|namespace redeclaration
   |inline namespace is present |error when inline namespace
   ||is present
  Known to fail||8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
This is a regression since GCC 7, starting with r248521

gcc/
Implement DR2061
* name-lookup.c (push_inline_namespaces): New.
(push_namespace): Look inside inline namespaces.

testsuite/
* g++.dg/cpp0x/dr2061.C: New.
* g++.dg/parse/namespace-alias-1.C: Add more test.

[Bug c++/87155] unnamed namespace redeclaration error when inline namespace is present

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
 Ever confirmed|0   |1

[Bug target/37158] Wrong insn for _mm_comieq_sd

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #3 from Uroš Bizjak  ---
This is fixed in gcc-8.

Related to PR82692.

[Bug c++/87155] New: unnamed namespace redeclaration error when inline namespace is present

[artiom.yurol at ya dot ru]

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

Bug ID: 87155
   Summary: unnamed namespace redeclaration error when inline
namespace is present
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: artiom.yurol at ya dot ru
  Target Milestone: ---

Created attachment 44631
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44631=edit
preprocessed file

namespace n1 {
namespace {}

inline namespace n2 {
namespace {}
} 

namespace {}
} 

This should compile just fine, but it doesn't. G++ rejects it reporting that
the extension of unnamed namespace at line 8 conflicts with the declaration at
line 2.

$ gcc ../playground.cpp 
../playground.cpp:8:5: error: ‘namespace n1:: { }’ conflicts with a previous
declaration
 namespace {}
 ^
../playground.cpp:2:5: note: previous declaration ‘namespace n1:: { }’
 namespace {}
 ^

Clang-6.0 doesn't reject the code. Removing nested namespace n2 also fixes the
problem

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-08-30
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
I have reproduced it.

[Bug fortran/87154] Internal compiler error: in gimplify_expr, at gimplify.c:12215

[uberprugelknabe at hotmail dot com]

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

--- Comment #1 from Ögmundur Petersson  ---
Created attachment 44630
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44630=edit
This file works fine

[Bug fortran/87154] New: Internal compiler error: in gimplify_expr, at gimplify.c:12215

[uberprugelknabe at hotmail dot com]

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

Bug ID: 87154
   Summary: Internal compiler error: in gimplify_expr, at
gimplify.c:12215
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uberprugelknabe at hotmail dot com
  Target Milestone: ---

Created attachment 44629
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44629=edit
This file triggers the crash

When compiling the attached source file (originally from a large project,
reduced to just the lines causing the crash) an ICE is triggered.

Confirmed in both gcc 7.3.1 and 7.3.0.

Example compiles correctly in Intel fortran and PGI fortran.

A slightly modified source file also attached using an explicit pointer instead
of an ASSICATE compiles without errors.

Stack trace:
gfortran -c crash.f90

crash.f90:31:0:



   args = str_split(param,',')

internal compiler error: in gimplify_expr, at gimplify.c:12215

0x87241e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:12215

0x8789e9 gimplify_modify_expr

../../gcc/gimplify.c:5488

0x871489 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11248

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x871d2b gimplify_statement_list

../../gcc/gimplify.c:1715

0x871d2b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11676

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x874448 gimplify_bind_expr

../../gcc/gimplify.c:1288

0x8720aa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11448

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x871d2b gimplify_statement_list

../../gcc/gimplify.c:1715

0x871d2b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11676

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x874448 gimplify_bind_expr

../../gcc/gimplify.c:1288

0x8720aa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11448

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x871d2b gimplify_statement_list

../../gcc/gimplify.c:1715

0x871d2b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)

../../gcc/gimplify.c:11676

0x873b08 gimplify_stmt(tree_node**, gimple**)

../../gcc/gimplify.c:6505

0x874448 gimplify_bind_expr

../../gcc/gimplify.c:1288

Please submit a full bug report,

with preprocessed source if appropriate.

Please include the complete backtrace with any bug report.

See  for instructions.

[Bug target/37158] Wrong insn for _mm_comieq_sd

[artem.alimarin at gmail dot com]

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

Artem Alimarin  changed:

   What|Removed |Added

 CC||artem.alimarin at gmail dot com

--- Comment #2 from Artem Alimarin  ---
Just checked. This bug is still there in gcc 5.5.0.

Compiler intrinsics like _mm_comieq_sd() are a way to use the corresponding
processor instructions. ix86_fp_compare_mode has nothing to do with that.

The double FP number implementation one can use ucomisd explicitly. It is not
bound to using comisd. 

Please reconsider fixing the bug.

[Bug gcov-profile/83877] Make gcov accept a path to the gcda and a path to the gcno file

[mcastelluccio at mozilla dot com]

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

--- Comment #3 from Marco Castelluccio  ---
The problem we have is that there's a directory containing gcno files and
multiple directories containing gcda files (one for each test suite execution).

gcov expects the gcda and gcno files to be in the same directory, so we
currently create symlinks to the gcno files in the gcda directories.

Example situation:
gcno_dir/main.gcno
gcda_dir_1/main.gcda
gcda_dir_2/main.gcda

If I run `gcov gcda_dir_1/main.gcda -o gcno_dir/`, gcov says:
gcno/main.gcda:cannot open data file, assuming not executed

[Bug gcov-profile/86536] Function "returned NAN %" for a simple program which forks

[mcastelluccio at mozilla dot com]

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

--- Comment #4 from Marco Castelluccio  ---
Sorry for the delay, it sounds fine to me, I can't think of anything better
than that!

[Bug middle-end/87153] Confusing / Incorrect clobber warning with ISRA / -Wclobber

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic, ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I think the warning tells you that the ISRA.312 when not spilled
to the stack by the compiler, might be not properly restored.  That it is
'const' doesn't really matter.

Given the source passes an aggregate by value depending on the ABI
you might get the very same bad effect.

Eventually we can do better with this warning and only warn when we
actually failed to spill the register.

I think the warning for arguments is usually a false positive since
argument registers are call-clobbered.

Given we use setjmp_crosses for the warning I wonder why we do not use
that to guide register allocation ...

[Bug c++/84980] [concepts] ICE with missing typename in concept

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug c/87153] New: Confusing / Incorrect clobber warning with ISRA / -Wclobber

[chris at bubblescope dot net]

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

Bug ID: 87153
   Summary: Confusing / Incorrect clobber warning with ISRA /
-Wclobber
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris at bubblescope dot net
  Target Milestone: ---

Created attachment 44628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44628=edit
Preprocessed file which produces clobbering warning

I am getting the following warning from code, compiling with -Os -Wclobbered

src/read.c: In function ‘EvalRef.isra.25’:
cc1: warning: argument ‘ISRA.312’ might be clobbered by ‘longjmp’ or ‘vfork’
[-Wclobbered]

EvalRef is defined as:

static UInt EvalRef(const LHSRef ref, Int needExpr)

Which fdump-tree-all, preprocess.c.225t.switchlower shows as:

EvalRef.isra.25 (const REFTYPE ISRA.310, const UInt ISRA.311, const UInt
ISRA.312, Int needExpr)

So, there are (I feel) two issues. Firstly, the warning isn't helpful as it
references a gcc-introduced function. Also I still don't see how ISRA.312 could
get clobbered, as it is const.

Unfortunately I have tried and failed to produce a small reproducable case of
this. I attach a preprocessed source file, made with gcc 8.0.1 on Ubuntu 18.04,
from the current master branch of https://www.github.com/gap-system/gap

[Bug c++/87145] [7/8/9 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Ah, the regression started with the same revision as the ICE, r241425 (applying
the fix from r257311 to that revision fixes the ICE but gives the "taking the
address of temporary" error).

[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL

[vladlazar at gcc dot gnu.org]

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

vladlazar at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||vladlazar at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from vladlazar at gcc dot gnu.org ---
Fixed by r263973. The issue was that in case of underflow, the overflow flag
was not set. The solution was to use wi::sub when decrementing.

[Bug fortran/69455] [6/7/8/9 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #13 from Dominique d'Humieres  ---
> A two line patch (or one rather long line) is sufficient to work
> around the brokeness of the intrinsics modules.

Could someone guess what are this two lines?

[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
It's a different symptom, but sure, might be related.  Somehow your toolchain
thinks it is a newer ISA but not compliant to older ISAs :-/

[Bug c++/87145] [7/8/9 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.2.0, 9.0

--- Comment #1 from Jonathan Wakely  ---
(In reply to programmer from comment #0)
> PS: Which version should I choose if multiple versions are affected: stable,
> trunk or [the first version with that regression]?

It doesn't really matter. We use other fields to track which versions the
regression affects.

Reduced:

template struct integral_constant {
  static constexpr T value = t;
};

enum class Enum : unsigned {};

struct Pod {
  unsigned val;

  constexpr operator Enum() const {
return static_cast(val);
  }
};

template
constexpr void foo() {
  using Foo = integral_constant;
}

int main() {
  foo<2>();
}


This started to ICE with r241425:

PR c++/77656
* pt.c (convert_template_argument): Call convert_nontype_argument
on value-dependent but not type-dependent arguments.
(convert_nontype_argument): Handle value-dependent arguments.
(canonicalize_expr_argument): New.
(deducible_expression, unify): Skip CONVERT_EXPR.
* error.c (dump_template_argument): Likewise.
* mangle.c (write_expression): Likewise.

And then started giving the current error with r257311 which relaxed an
assertion to stop the ICE:

PR c++/84125
* typeck.c (build_address): Relax the assert when
processing_template_decl.

Because of the ICE I can't tell when the error started.

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
That one works fine on both native and cross for me, too.

Please describe your config better?  binutils version, libc version, exact
configure command, to start with?

[Bug c++/87148] [6/7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
See PR 68478 in particular for the change requiring a complete type.

[Bug middle-end/86995] [9 regression] c-c++-common/torture/builtin-arith-overflow-17.c etc. FAIL

[vladlazar at gcc dot gnu.org]

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

--- Comment #7 from vladlazar at gcc dot gnu.org ---
Author: vladlazar
Date: Thu Aug 30 09:30:49 2018
New Revision: 263973

URL: https://gcc.gnu.org/viewcvs?rev=263973=gcc=rev
Log:
Enable underflow check in canonicalize_comparison. (PR86995)

gcc/
2018-08-30  Vlad Lazar  

PR middle-end/86995
* expmed.c (canonicalize_comparison): Use wi::sub instead of wi::add
if to_add is negative.


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

[Bug c++/87148] [6/7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
There is no reason to accept this code, the struct type is not valid in GNU C
and not valid in ISO C++.

This is a proper testcase that actually compiled with older versions of G++:

struct Tst{
   char t[];
};
Tst* p = new Tst();

This was silently accepted until r231665 which correctly says:

87148.cc:2:11: error: flexible array member ‘Tst::t’ in an otherwise empty
‘struct Tst’
char t[];
   ^

87148.cc:1:8: note: in the definition of ‘struct Tst’
 struct Tst{
^~~

87148.cc:4:18: error: value-initialization of incomplete type ‘char []’
 Tst* p = new Tst();
  ^

Rejecting a struct with no members except a flexible/empty array member is the
right thing to do. G++ was wrong to accept them previously (it was far too
lenient in the nonsense it accepted as flexible array members).

If we fix the testcase:

struct Tst{
  int i;
   char t[];
};
Tst t = Tst();


Now we get the claimed error:

87148.c:5:13: error: value-initialization of incomplete type 'char []'
 Tst t = Tst();
 ^

It seems reasonable to accept this, ignoring the array during initialization.

This started with r231665. CCing Martin who fixed all the bugs with
flexible/empty array members.

[Bug fortran/87151] allocating array of character

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-30
 Blocks||68241
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.9.3 up to trunk (9.0).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug c++/87152] New: internal compiler error: in tsubst_copy, at cp/pt.c:15484

[tiagomacarios at gmail dot com]

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

Bug ID: 87152
   Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:15484
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tiagomacarios at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/RnO6a-

#include 
#include 
#include 

template
constexpr int int_from_bits()
{
constexpr auto a = std::array{bits...};

int sum = 0;
for (int index = 0; bool const b : a)
{
sum += b ? exp2(index) : 0;
}

return sum;
}

int j = int_from_bits();

: In instantiation of 'constexpr int int_from_bits() [with bool ...bits
= {false, false, true}]':
:19:40:   required from here
:13:25: internal compiler error: in tsubst_copy, at cp/pt.c:15486
13 | sum += b ? exp2(index) : 0;
   | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
But ICEs with:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90
-c -mno-fprnd
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90:52:0:

52 |   end
   | 
Error: unrecognizable insn:
(insn 12 11 13 2 (set (reg:DI 152)
(unspec:DI [
(reg:DF 154)
] UNSPEC_FCTID))
"/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90":15 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90:52:0:
internal compiler error: in extract_insn, at recog.c:2305
0x10f1f903 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x10f1f97b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0x10ea251f extract_insn(rtx_insn*)
../../gcc/recog.c:2305
0x10a1409f instantiate_virtual_regs_in_insn
../../gcc/function.c:1605
0x10a15eaf instantiate_virtual_regs
../../gcc/function.c:1975
0x10a1601f execute
../../gcc/function.c:2024
Thus dup of PR86684?

[Bug c++/87150] [8/9 Regression] move ctor wrongly chosen in return stmt (derived vs. base)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.3.1
   Keywords||accepts-invalid, wrong-code
   Last reconfirmed||2018-08-30
 Ever confirmed|0   |1
Summary|move ctor wrongly chosen in |[8/9 Regression] move ctor
   |return stmt (derived vs.|wrongly chosen in return
   |base)   |stmt (derived vs. base)
   Target Milestone|--- |8.3
  Known to fail||8.1.0

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

[Bug target/87149] ICE in extract_insn, at recog.c:2305 on ppc64le

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Native compiler works fine however.

[Bug target/87133] ICE in aggregate_value_p with -frounding-math on ppc64le

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Same happens for:

./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/do_check_3.f90

#0  lookup_handler (scode=1122058) at insn-opinit.c:1156
#1  0x032f34de in raw_optab_handler (scode=1122058) at
insn-opinit.c:1173
#2  0x013a87d2 in convert_optab_handler (op=ufixtrunc_optab,
to_mode=E_DImode, from_mode=E_SFmode) at
/home/marxin/Programming/gcc/gcc/optabs-query.h:55
#3  0x01c4c93a in can_fix_p (fixmode=E_DImode, fltmode=E_SFmode,
unsignedp=1, truncp_ptr=0x7fffc9bb) at
/home/marxin/Programming/gcc/gcc/optabs-query.c:313
#4  0x01c2759a in expand_fix (to=0x75afca38, from=0x75afc9f0,
unsignedp=1) at /home/marxin/Programming/gcc/gcc/optabs.c:4922
#5  0x01405268 in expand_expr_real_2 (ops=0x7fffd230,
target=0x75afca38, tmode=E_DImode, modifier=EXPAND_NORMAL) at
/home/marxin/Programming/gcc/gcc/expr.c:8961
#6  0x00f8e553 in expand_gimple_stmt_1 (stmt=) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:3673
#7  0x00f8ea9a in expand_gimple_stmt (stmt=) at /home/marxin/Programming/gcc/gcc/cfgexpand.c:3734
#8  0x00fa3f59 in expand_gimple_basic_block (bb=, disable_tail_calls=false) at
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5770

on native target pats contains {scode = 1122058, icode =
CODE_FOR_fixuns_truncsfdi2}, on cross compiler not.

cross-compiler: (gdb) p sizeof(pats)
$2 = 4440

native:
(gdb) p sizeof(pats)
$15 = 5448

That said, isn't it similar to: PR86684?

[Bug tree-optimization/87147] [9 Regression] GCC miscompiles at -O3 on valid code

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
OK, so the issue is that while non-iterating RPO VN assumes executable
backedges it fails to mark destination blocks as executable.

Testing fix.

[Bug fortran/87151] New: allocating array of character

[valeryweber at hotmail dot com]

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

Bug ID: 87151
   Summary: allocating array of character
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valeryweber at hotmail dot com
  Target Milestone: ---

dear all

gcc 8.2 seems to have a problem allocating the string below. the len() should
be 2, is that a bug?

many thanks

valery


cat alloc_char.f90
module bvec
type, public :: bvec_t
 private
 character(:), dimension(:), allocatable :: vc 
   contains
 PROCEDURE, PASS :: create
  end type bvec_t
contains
  subroutine create(this)
class(bvec_t), intent(inout) :: this
allocate(character(2)::this%vc(3))
write(*,*) len(this%vc),size(this%vc)
  end subroutine create
end module bvec

program test
  use bvec
  type(bvec_t) :: a
  call a%create()
end program test



gfortran-8.2.0 alloc_char.f90
./a.out 
   0   3

[Bug c++/87150] New: move ctor wrongly chosen in return stmt (derived vs. base)

[sbergman at redhat dot com]

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

Bug ID: 87150
   Summary: move ctor wrongly chosen in return stmt (derived vs.
base)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

struct S1 { S1(S1 &&); };
  struct S2: S1 {};
  S1 f(S2 s) { return s; }

is accepted by GCC 8.1 but violates [class.copy.elision]/3, which dismisses the
move ctor if "the type of the first parameter of the selected constructor is
not an rvalue reference to the object’s type (possibly cv-qualified)" (and
which is the case here, where the object's type is S2 but the ctor parameter's
type is S1&&.  (Referring to C++17, but wording is similar back to C++11, and
GCC's behavior is the same for -std=c++{11,14,17}.)

Checking on godbolt.org, the error of accepting the code appears to have been
introduced between GCC 7.3 and 8.1.

(Also see mail thread starting at
 "return
lvalue move instead of copy?".)

[Bug tree-optimization/87147] [9 Regression] GCC miscompiles at -O3 on valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Summary|GCC miscompiles at -O3 on   |[9 Regression] GCC
   |valid code  |miscompiles at -O3 on valid
   ||code

--- Comment #1 from Richard Biener  ---
Disabling cunroll fixes it.  Investigating.

[Bug bootstrap/87146] ubsan bootstrap with non-gcc compiler fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*

--- Comment #1 from Richard Biener  ---
There is nothing special about a non-GCC host compiler bootstrap.  Does clang
default to optimizing?  If so try bootstrapping with STAGE1_CFLAGS="-O0"

[Bug c++/87145] [7/8/9 Regression] Implicit conversion to scoped enum fails: "error: taking address of temporary/rvalue"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.3.0
Version|unknown |7.3.1
   Target Milestone|--- |7.4
Summary|Implicit conversion to  |[7/8/9 Regression] Implicit
   |scoped enum fails: "error:  |conversion to scoped enum
   |taking address of   |fails: "error: taking
   |temporary/rvalue"   |address of
   ||temporary/rvalue"

[Bug target/87149] New: ICE in extract_insn, at recog.c:2305 on ppc64le

[marxin at gcc dot gnu.org]

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

Bug ID: 87149
   Summary: ICE in extract_insn, at recog.c:2305 on ppc64le
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: powerpc64le-linux

Following causes ICE:

$ ./xgcc -B.  /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90:52:0:

52 |   end
   | 
Error: unrecognizable insn:
(insn 11 10 12 2 (set (reg:DI 151)
(unspec:DI [
(reg:DF 153)
] UNSPEC_FCTID))
"/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90":15 -1
 (nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90:52:0:
internal compiler error: in extract_insn, at recog.c:2305
0x1f27bfa _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0x1f27c79 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:116
0x1df1088 extract_insn(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2305
0x1510334 instantiate_virtual_regs_in_insn
/home/marxin/Programming/gcc/gcc/function.c:1605
0x1513e03 instantiate_virtual_regs
/home/marxin/Programming/gcc/gcc/function.c:1975
0x151406e execute
/home/marxin/Programming/gcc/gcc/function.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 30 Aug 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
> 
> --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
> > --- Comment #2 from Richard Biener  ---
> > You also might want to test the patch from PR87132.
> 
> I had it in my tree already last night.  I've now retried the exact same
> tree without libumem, and now get an ICE in stage2 compiling gimplify.c:

OK, so at least that one cannot be caused by stage1 miscompiling stage2
cc1[plus].

I wonder if you can run the testsuite in the not bootstrapped tree
and look for sth suspicious.

There is uninitialized memory (but it should never be used...) in
the new VN, so a shot in the dark would be

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 263972)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -6240,7 +6240,7 @@ do_rpo_vn (function *fn, edge entry, bit
   for (int i = 0; i < n; ++i)
 bb_to_rpo[rpo[i]] = i;

-  unwind_state *rpo_state = XNEWVEC (unwind_state, n);
+  unwind_state *rpo_state = XCNEWVEC (unwind_state, n);

   rpo_elim avail (entry->dest);
   rpo_avail = 

> during IPA pass: fnsummary
> /vol/gcc/src/hg/trunk/local/gcc/gimplify.c: In function ‘void
> gimplify_scan_omp_clauses(tree_node**, gimple**, omp_region_type, tree_code)’:
> /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:13162:1: internal compiler error: 
> in
> compute_fn_summary, at ipa-fnsummary.c:2492
> 13162 | }
>   | ^
> 0x9400a42 compute_fn_summary(cgraph_node*, bool)
> /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:2492
> 0x94029f2 inline_analyze_function(cgraph_node*)
> /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3146
> 0x9402b8c ipa_fn_summary_generate
> /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3189
> 0x956db21 execute_ipa_summary_passes(ipa_opt_pass_d*)
> /vol/gcc/src/hg/trunk/local/gcc/passes.c:2149
> 0x9161451 ipa_passes
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2432
> 0x91617c4 symbol_table::compile()
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2543
> 0x9161e4b symbol_table::finalize_compilation_unit()
> /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2788

Given this is the stage1 compiler complaining it looks unrelated.

What's your host compiler?  Do you use custom STAGE1_CFLAGS?

[Bug tree-optimization/87147] GCC miscompiles at -O3 on valid code

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
Version|unknown |9.0
   Keywords||wrong-code
   Last reconfirmed||2018-08-30
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |9.0

[Bug bootstrap/87141] configure:14586: error: Could not determine word size.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-08-30
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
configure:14583: ./conftest
/media/gcc-8.2.0/libatomic/configure: line 1: ./conftest: cannot execute binary
file
configure:14583: $? = 126
configure: program exited with status 126

here (x86_64-linux) 126 is ENOKEY.  Looks like somehow your platform requires
signed executables?

Can you even execute a simple hello world you compile yourself?

[Bug c++/87148] [6/7/8/9 Regression] backward compatibility issue to take char [] as incomplete type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.5.0
Version|unknown |6.4.1
   Keywords||needs-bisection,
   ||rejects-valid
   Last reconfirmed||2018-08-30
 Ever confirmed|0   |1
Summary|backward compatibility  |[6/7/8/9 Regression]
   |issue  to take char [] as   |backward compatibility
   |incomplete type |issue  to take char [] as
   ||incomplete type
   Target Milestone|--- |6.5
  Known to fail||6.1.0

--- Comment #1 from Richard Biener  ---
This is rejected since GCC 6.  gcc-6/changes.html doesn't document this change
in behavior.

Marking as regression.  I guess it should be possible to allow this with
-fpermissive, effectively treating it as [0] (which is a GCC extension,
as is flexible array members).

[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Richard Biener  ---
> You also might want to test the patch from PR87132.

I had it in my tree already last night.  I've now retried the exact same
tree without libumem, and now get an ICE in stage2 compiling gimplify.c:

during IPA pass: fnsummary
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c: In function ‘void
gimplify_scan_omp_clauses(tree_node**, gimple**, omp_region_type, tree_code)’:
/vol/gcc/src/hg/trunk/local/gcc/gimplify.c:13162:1: internal compiler error: in
compute_fn_summary, at ipa-fnsummary.c:2492
13162 | }
  | ^
0x9400a42 compute_fn_summary(cgraph_node*, bool)
/vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:2492
0x94029f2 inline_analyze_function(cgraph_node*)
/vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3146
0x9402b8c ipa_fn_summary_generate
/vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3189
0x956db21 execute_ipa_summary_passes(ipa_opt_pass_d*)
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2149
0x9161451 ipa_passes
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2432
0x91617c4 symbol_table::compile()
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2543
0x9161e4b symbol_table::finalize_compilation_unit()
/vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2788

[Bug c++/87136] internal compiler error: in emit_move_insn, at expr.c:3722

[darko.veberic at ijs dot si]

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

--- Comment #3 from Darko Veberic  ---
i will, soon. the delta is still running. unfortunately, the .ii file had 100k
lines...

[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from Richard Biener  ---
You also might want to test the patch from PR87132.

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Richard Biener  ---
> If you disable bootstrap does it work?  The backtrace makes it look like 
> memory
> corruption.  Maybe you can also throw valgrind on it?

A --disable-bootstrap build (c, c++ only) does work on
i386-pc-solaris2.11, but I didn't run make check.

While there is a Solaris/x86 valgrind port, I haven't used it yet (and
it seems I'll have to use the git version on Solaris 11.4).

For a start, I ran the failing compilation with libumem (a debugging
malloc) preloaded and UMEM_DEBUG=default: this way, the compilation
succeeded without errors.

Afterwards, I managed to bootstrap with just LD_PRELOAD=libumem.so on
both i386-pc-solaris2.11 and sparc-sun-solaris2.11.  That completed
successfully, but 200+ 32-bit Go tests now FAIL, together with two
64-bit libstdc++ max_align_t tests.  Since there are already similar Go
failures with the libc malloc, I'm pretty sure this is just uncovering a
preexisting libgo bug.

I'll try what I can find with valgrind next.