[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[babokin at gmail dot com]

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

--- Comment #17 from Dmitry Babokin  ---
Any chances for the fix for this bug?

Looks like this one stands as a last obstacle to claim UBSAN in GCC fully
functional.

I still see quite a few errors, but looks like all of them are attributed to
this problem. Anyway, I have no way to verify this before this bug is fixed.

[Bug other/80923] New: RTEMS SH ICE building gcc-7.1.0 on FreeBSD 11.0

[chrisj at rtems dot org]

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

Bug ID: 80923
   Summary: RTEMS SH ICE building gcc-7.1.0 on FreeBSD 11.0
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisj at rtems dot org
  Target Milestone: ---

FreeBSD version is 11.0-RELEASE-p9.

Configure line is:

../gcc-7.1.0/configure --prefix=/build/rtems/tools/4.12-7.1
--bindir=/build/rtems/tools/4.12-7.1/bin
--exec_prefix=/build/rtems/tools/4.12-7.1
--includedir=/build/rtems/tools/4.12-7.1/include
--libdir=/build/rtems/tools/4.12-7.1/lib
--libexecdir=/build/rtems/tools/4.12-7.1/libexec
--mandir=/build/rtems/tools/4.12-7.1/share/man
--infodir=/build/rtems/tools/4.12-7.1/share/info
--datadir=/build/rtems/tools/4.12-7.1/share --build=x86_64-freebsd11.0
--host=x86_64-freebsd11.0 --target=sh-rtems4.12 --disable-libstdcxx-pch
--with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls
--without-included-gettext --disable-win32-registry
--enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-languages=c,c++

The error is:

/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/sh-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170323-x86_64-freebsd11.0-1/build/./gcc/xgcc
-B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/sh-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170323-x86_64-freebsd11.0-1/build/./gcc/
-nostdinc
-B/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/sh-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170323-x86_64-freebsd11.0-1/build/sh-rtems4.12/newlib/
-isystem
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/sh-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170323-x86_64-freebsd11.0-1/build/sh-rtems4.12/newlib/targ-include
-isystem
/opt/work/chris/rtems/rsb/rtems-source-builder.git/rtems/build/sh-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170323-x86_64-freebsd11.0-1/gcc-7.1.0/newlib/libc/include
-B/build/rtems/tools/4.12-7.1/sh-rtems4.12/bin/
-B/build/rtems/tools/4.12-7.1/sh-rtems4.12/lib/ -isystem
/build/rtems/tools/4.12-7.1/sh-rtems4.12/include -isystem
/build/rtems/tools/4.12-7.1/sh-rtems4.12/sys-include-g -O2 -m2 -O2
-I../../../../gcc-7.1.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
 -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I../../../../gcc-7.1.0/libgcc
-I../../../../gcc-7.1.0/libgcc/. -I../../../../gcc-7.1.0/libgcc/../gcc
-I../../../../gcc-7.1.0/libgcc/../include  -DHAVE_CC_TLS  -o _fixdfdi.o -MT
_fixdfdi.o -MD -MP -MF _fixdfdi.dep -DL_fixdfdi -c
../../../../gcc-7.1.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-7.1.0/libgcc/unwind-dw2.c: In function 'execute_stack_op':
../../../../gcc-7.1.0/libgcc/unwind-dw2.c:840:10: internal compiler error:
Segmentation fault
   result = (_Unwind_Sword) second / (_Unwind_Sword) first;
   ~~~^~~~
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.

I have not provided prepossessed source because it is a libgcc file.

I have no idea which component to select.

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #6 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 31 00:05:38 2017
New Revision: 248714

URL: https://gcc.gnu.org/viewcvs?rev=248714=gcc=rev
Log:
xtensa: Fix PR target/78603

2017-05-30  Max Filippov  
gcc/
Backport from mainline
2016-11-29  Max Filippov  

* config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
overhead loop start between a call and its CALL_ARG_LOCATION
note.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/xtensa/xtensa.c

[Bug target/78118] xtensa: ICE in gcc-6.1.0/libgcc/libgcc2.c:1992:1: error: unrecognizable insn

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #6 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 31 00:05:01 2017
New Revision: 248713

URL: https://gcc.gnu.org/viewcvs?rev=248713=gcc=rev
Log:
xtensa: Fix PR target/78118

It started failing after the following commit: 32e90dc6a0cda45 ("PR
rtl-optimization/61047").

The change that made xtensa backend go ICE looks completely unrelated,
and indeed, the issue is caused by the side effect of
compute_frame_size() function call hidden in the
INITIAL_ELIMINATION_OFFSET macro. This call updates the value of the
xtensa_current_frame_size static variable, used in "return" instruction
predicate. Prior to the change the value of xtensa_current_frame_size was
set to 0 after the end of epilogue generation, which enabled the "return"
instruction for the CALL0 ABI, but after the change the additional
INITIAL_ELIMINATION_OFFSET calls make xtensa_current_frame_size non-zero
and "return" pattern unavailable.

Get rid of the global xtensa_current_frame_size and
xtensa_callee_save_size variables by moving them into the
machine_function structure. Implement predicate for the "return" pattern
as a function. Don't communicate completion of epilogue generation
through zeroing of xtensa_current_frame_size, add explicit epilogue_done
variable to the machine_function structure. Don't update stack frame
layout after the completion of reload.

2017-05-30  Max Filippov  
gcc/
Backport from mainline
2016-11-01  Max Filippov  

* config/xtensa/xtensa-protos.h
(xtensa_use_return_instruction_p): New prototype.
* config/xtensa/xtensa.c (xtensa_current_frame_size,
xtensa_callee_save_size): Remove.
(struct machine_function): Add new fields: current_frame_size,
callee_save_size, frame_laid_out and epilogue_done.
(compute_frame_size, xtensa_expand_prologue,
xtensa_expand_epilogue): Replace xtensa_callee_save_size with
cfun->machine->callee_save_size and xtensa_current_frame_size
with cfun->machine->current_frame_size.
(compute_frame_size): Update cfun->machine->frame_laid_out and
don't update frame layout after reload completion.
(xtensa_expand_epilogue): Set cfun->machine->epilogue_done
instead of zeroing xtensa_current_frame_size.
(xtensa_use_return_instruction_p): New function.
* config/xtensa/xtensa.h (xtensa_current_frame_size): Remove
declaration.
(INITIAL_ELIMINATION_OFFSET): Use return value of
compute_frame_size instead of xtensa_current_frame_size value.
* config/xtensa/xtensa.md ("return" pattern): Use new predicate
function xtensa_use_return_instruction_p instead of inline code.


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/xtensa/xtensa-protos.h
branches/gcc-6-branch/gcc/config/xtensa/xtensa.c
branches/gcc-6-branch/gcc/config/xtensa/xtensa.h
branches/gcc-6-branch/gcc/config/xtensa/xtensa.md

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

[davmac at davmac dot org]

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

--- Comment #1 from Davin McCall  ---
(Does not actually require -Wno-invalid-offsetof to reproduce; that was just me
copying my command line literally. Problem first appears in GCC 6.1, not in
5.x, still present in 7.1).

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Tue May 30 23:41:58 2017
New Revision: 248708

URL: https://gcc.gnu.org/viewcvs?rev=248708=gcc=rev
Log:
xtensa: Fix PR target/78603

2017-05-30  Max Filippov  
gcc/
Backport from mainline
2016-11-29  Max Filippov  

* config/xtensa/xtensa.c (hwloop_optimize): Don't emit zero
overhead loop start between a call and its CALL_ARG_LOCATION
note.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/xtensa/xtensa.c

[Bug c++/80840] [7/8 Regression] ICE in convert_nontype_argument reference to double

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
236968 OK
248467 Not OK
Trying 242717 ...

[Bug testsuite/80557] rewrite absolute line numbers into relative or saved line numbers

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #14 from Tom de Vries  ---
These test-cases still have absolute line numbers, but should probably keep
them:
...
./gcc/testsuite/c-c++-common/cpp/pr60400.c
./gcc/testsuite/gcc.dg/cpp/19940712-1.c
./gcc/testsuite/gcc.dg/cpp/hash1.c
./gcc/testsuite/gcc.dg/cpp/line2.c
./gcc/testsuite/gcc.dg/cpp/multiline.c
./gcc/testsuite/gcc.dg/cpp/pr66415-2.c
./gcc/testsuite/gcc.dg/cpp/syshdr.c
./gcc/testsuite/gcc.dg/cpp/unc4.c
./gcc/testsuite/gcc.dg/format/pr78569.c
./gcc/testsuite/gcc.dg/pr40340-1.c
./gcc/testsuite/gcc.dg/pr40340-2.c
./gcc/testsuite/gcc.dg/pr40340-3.c
./gcc/testsuite/gcc.dg/pr40340-4.c
./gcc/testsuite/gcc.dg/pr40340-5.c
./gcc/testsuite/gcc.dg/va-arg-2.c
./gcc/testsuite/gcc.target/avr/progmem-error-1.cpp
...

Marking resolved-fixed.

[Bug c/80922] New: #pragma diagnostic ignored not honoured with -flto

[thiago at kde dot org]

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

Bug ID: 80922
   Summary: #pragma diagnostic ignored  not honoured with -flto
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

$ cat f1.cpp
#pragma GCC diagnostic ignored "-Wfree-nonheap-object"
void myfree(void *ptr)
{
__builtin_free(ptr);
}

$ cat f2.cpp
void myfree(void *);

static char c;
int main()
{
myfree();
}

This code is intentionally bogus just to trigger the warning. The situation
that caused this was correct code, with a false positive warning I was trying
to suppress.

$ gcc -O2 -include f1.cpp f2.cpp
[no warning, as expected]

$ gcc -O2 -flto f1.cpp f2.cpp   
In function ‘myfree.constprop’,
inlined from ‘main’ at f2.cpp:6:11:
f1.cpp:4:19: warning: attempt to free a non-heap object ‘c’
[-Wfree-nonheap-object]
 __builtin_free(ptr);
   ^

[Bug testsuite/80910] FAIL: gcc.target/x86_64/abi/ms-sys

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #3 from Tom de Vries  ---
Patch committed, marking resolved-fixed.

[Bug testsuite/80910] FAIL: gcc.target/x86_64/abi/ms-sys

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Tue May 30 22:00:57 2017
New Revision: 248701

URL: https://gcc.gnu.org/viewcvs?rev=248701=gcc=rev
Log:
Test if host compiler supports -std=c++11 in ms-sysv.exp

2017-05-30  Tom de Vries  

PR testsuite/80910
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp: Exit with status
unsupported if host compiler does not support c++11.
(host_supports_c++11): New proc.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp

[Bug c/54202] Overeager warning about freeing non-heap objects

[thiago at kde dot org]

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

--- Comment #6 from Thiago Macieira  ---
ping.

If you can't fix GCC so that it can prove that the free is on a non-heap
object, then please change the warning to indicate that GCC may be wrong. For
example:

warning: free() may be called with non-heap object 'name'

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[timshen at gcc dot gnu.org]

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

--- Comment #5 from Tim Shen  ---
(In reply to Ambroz Bizjak from comment #4)
> Oh wait sorry, that doesn't solve it (yet), the variant_storage_byte would
> still have a default copy constructor that copies the byte member.

Yeah, your solution seems to move the triviality forwarding down to the
individual elements, not in the variant level. However, I'm not sure if it
helps on the forwarding itself. You may still need the 4-layer inheritance on
each byte.

[Bug c/80731] poor -Woverflow warnings, missing detail

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Tue May 30 21:27:35 2017
New Revision: 248700

URL: https://gcc.gnu.org/viewcvs?rev=248700=gcc=rev
Log:
gcc/testsuite/ChangeLog:
PR c/80731
* g++.dg/ext/utf16-4.C: Relax test.
* gcc.dg/fixed-point/int-warning.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/utf16-4.C
trunk/gcc/testsuite/gcc.dg/fixed-point/int-warning.c

[Bug c++/80856] [7/8 Regression] ICE from template local overload resolution

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Tue May 30 21:13:27 2017
New Revision: 248699

URL: https://gcc.gnu.org/viewcvs?rev=248699=gcc=rev
Log:
PR c++/80856 - ICE with local extern in template

* semantics.c (finish_call_expr): Replace a local extern overload
set in a template with the IDENTIFIER_NODE.

Added:
trunk/gcc/testsuite/g++.dg/template/local-fn2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug go/80914] gcc-go binaries don't run

[steven at uplinklabs dot net]

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

--- Comment #3 from Steven Noonan  ---
This is from a different go.gcc binary, because I've rebuilt several times to
try and troubleshoot. But this one still exhibits the bad behavior. Just in
case, I've uploaded a copy of the binary, the entire 'readelf --debug=info'
output, and the current gdb output:

https://www.uplinklabs.net/files/gcc-pr80914/gcc-go-debug-info.txt
https://www.uplinklabs.net/files/gcc-pr80914/gdb.txt
https://www.uplinklabs.net/files/gcc-pr80914/go.gcc.gz


Here's 'tail -n 30' of the gcc-go-debug-info.txt from above:

<2338a>   DW_AT_location: 2 byte block: 91 60   (DW_OP_fbreg: -32)  
 <2><2338d>: Abbrev Number: 0   
 <1><2338e>: Abbrev Number: 7 (DW_TAG_pointer_type) 
<2338f>   DW_AT_byte_size   : 8 
<23390>   DW_AT_type: <0x22f27> 
 <1><23394>: Abbrev Number: 43 (DW_TAG_subprogram)  
<23395>   DW_AT_name: (indirect string, offset: 0x32231):
base_of_encoded_value  
<23399>   DW_AT_decl_file   : 1 
<2339a>   DW_AT_decl_line   : 101   
<2339b>   DW_AT_prototyped  : 1 
<2339b>   DW_AT_type: <0x22e30> 
<2339f>   DW_AT_low_pc  : 0x4bc54a  
<233a7>   DW_AT_high_pc : 0x83  
<233af>   DW_AT_frame_base  : 1 byte block: 9c  (DW_OP_call_frame_cfa)  
<233b1>   DW_AT_GNU_all_tail_call_sites: 1
 <2><233b1>: Abbrev Number: 28 (DW_TAG_formal_parameter)
<233b2>   DW_AT_name: (indirect string, offset: 0x3216f): encoding
<233b6>   DW_AT_decl_file   : 1
<233b7>   DW_AT_decl_line   : 101
<233b8>   DW_AT_type: <0x22a32>
<233bc>   DW_AT_location: 2 byte block: 91 6c   (DW_OP_fbreg: -20)
 <2><233bf>: Abbrev Number: 28 (DW_TAG_formal_parameter)
<233c0>   DW_AT_name: (indirect string, offset: 0x21373): context
<233c4>   DW_AT_decl_file   : 1
<233c5>   DW_AT_decl_line   : 101
<233c6>   DW_AT_type: <0x22f10>
<233ca>   DW_AT_location: 2 byte block: 91 60   (DW_OP_fbreg: -32)
 <2><233cd>: Abbrev Number: 0
 <1><233ce>: Abbrev Number: 0

[Bug ada/80921] Cross compiling for mingw32 target fails to build Ada shared libraries

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-30
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
(> All seems fine, except that libgnarl-6.dll, libgnarl.dll.a, libgnat-6.dll,
> and libgnat.dll.a are nowhere to be found, either in my build tree, or in my
> staged installation tree.

Look into the compilation log, there must be an error reported in this case.

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[ambrop7 at gmail dot com]

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

--- Comment #4 from Ambroz Bizjak  ---
Oh wait sorry, that doesn't solve it (yet), the variant_storage_byte would
still have a default copy constructor that copies the byte member.

[Bug libstdc++/80187] C++ variant should be trivially copy constructible if possible

[ambrop7 at gmail dot com]

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

--- Comment #3 from Ambroz Bizjak  ---
Hey,
Does this idea help: https://godbolt.org/g/3Iqp2c ?
The storage is an array of "special" byte classes which have empty
constructors/assign when those would be implemented by one of the mixins.

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
(In reply to DIL from comment #4)
> Offset of zero is fine. I have never observed this SegFault before. I ran
> the test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1.
> Also, as I mentioned before, the test passed the VALGRIND check. Would you
> be able to point me to the specific line of the deepest user-level procedure
> in the call stack where the segfault occurs? Was it line 744 of
> __gfc_vector_MOD_vectoriterelementvalue (from your previous comment)?

I set the breakpoint which you see in comment 3. I then ran the program. After
the brak I simply stepped with the n (next) command until the segfault
occurred. So yes at line 744 as shown.

[Bug ada/80921] New: Cross compiling for mingw32 target fails to build Ada shared libraries

[keith.marshall at mailinator dot com]

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

Bug ID: 80921
   Summary: Cross compiling for mingw32 target fails to build Ada
shared libraries
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keith.marshall at mailinator dot com
  Target Milestone: ---

Working on a GNU/Linux host, my goal is to deliver a crossed-native GCC build
for deployment on MS-Windows32 hosts.  Currently focussing on GCC-6.3.0, I
have:

1) Bootstrapped and installed native Ada-enabled GCC-6.3.0, for the GNU/Linux
host.

2) With (1) at start of $PATH, built and installed GNU/Linux hosted GCC-6.3.0
cross-comiler suite for the mingw32 target.

3) With (1) still at the start of $PATH, followed by (2), built and installed
(into a local staging directory) GCC-6.3.0 suite for host = target = mingw32.

All seems fine, except that libgnarl-6.dll, libgnarl.dll.a, libgnat-6.dll, and
libgnat.dll.a are nowhere to be found, either in my build tree, or in my staged
installation tree.  A colleague, building natively on MS-Windows (a process
which takes approximately six times longer that my cross-hosted build), with
the same configuration, (except for the necessary build/host/target
differences), confirms that these shared libraries and import libraries are
created by his build.

What might I be missing, to get these components delivered by the
crossed-native build?  I've observed the same omission from previous GCC-4.9.3
and GCC-5.3.0 crossed-native builds, and I like to see a resolution before I
progress to any attempt to build GCC-7.x

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
I'm trying for some bisection.

I hope this is not going to turn out as complex as PR 79430 ...

[Bug c++/80830] [8 Regression] ICE in tsubst_copy, at cp/pt.c:14569

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Fixed on trunk too.

[Bug c/80892] [8 regression] -Wfloat-conversion now warns about non-floats

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg02288.html

[Bug tree-optimization/80894] [8 Regression] 456.hmmer in SPEC CPU 2006 is miscompiled

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #5 from seurer at gcc dot gnu.org ---
The problem appears to be in compiling hmmio.c.  If I compile everything else
with a compiler built from r248447 and hmmio.c from a compiler built with
r248446 then the 456.hmmer test works.

(this is on powerpc64 LE)

[Bug c++/80856] [7/8 Regression] ICE from template local overload resolution

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from H.J. Lu  ---
Fixed by r248687.

[Bug libstdc++/80893] std::vector creation dereferences null pointer

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
This is actually a problem in vector though: it assumes allocate(0)
returns a non-null pointer, which is unspecified.

This should fix it:

--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/include/bits/stl_bvector.h
@@ -1091,7 +1091,7 @@ template
 {
   _Bit_pointer __q = this->_M_allocate(__n);
   this->_M_impl._M_end_of_storage = __q + _S_nword(__n);
-  this->_M_impl._M_start = iterator(std::__addressof(*__q), 0);
+  this->_M_impl._M_start = iterator(__q ? std::__addressof(*__q) : 0, 0);
   this->_M_impl._M_finish = this->_M_impl._M_start + difference_type(__n);
 }

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
This may be fixed by r248687.

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

[uros at gcc dot gnu.org]

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

--- Comment #13 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 30 17:18:25 2017
New Revision: 248691

URL: https://gcc.gnu.org/viewcvs?rev=248691=gcc=rev
Log:
PR target/80833
* config/i386/constraints.md (Yd): New constraint.
(Ye): Ditto.
* config/i386/i386.md (*movti_internal): Add (?r, Ye)
and (?Yd, r) alternatives.  Update insn attributes.
* config/i386/i386.md (*movti_internal): Add (?r, *Ye)
and (?*Yd, r) alternatives.  Update insn attributes.
(double-mode inter-unit splitters): Add new GR<->XMM splitters.

testsuite/ChangeLog:

PR target/80833
* gcc.target/i386/pr80833-1.c: New test.
* gcc.target/i386/pr80833-2.c: Ditto.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80833-1.c
trunk/gcc/testsuite/gcc.target/i386/pr80833-2.c
Modified:
trunk/gcc/config/i386/constraints.md
trunk/gcc/config/i386/i386.md

[Bug libstdc++/80893] std::vector creation dereferences null pointer

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-30
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
Confirmed when using the pool allocator:

#include 
#include 

int main() {
  // OK
  std::vector a;

  // Fails.
  std::vector b(a);

  // Fails.
  std::vector c(0);

  (void)a;
  (void)b;
  (void)c;
}

tmp$ ~/gcc/7.1.0/bin/g++  vb.cc  -fsanitize=undefined -O
tmp$ ./a.out
/home/jwakely/gcc/7.1.0/include/c++/7.1.0/bits/stl_bvector.h:1094:7: runtime
error: reference binding to null pointer of type 'long unsigned int'
/home/jwakely/gcc/7.1.0/include/c++/7.1.0/bits/stl_bvector.h:1094:7: runtime
error: reference binding to null pointer of type 'long unsigned int'

[Bug libstdc++/80893] std::vector creation dereferences null pointer

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this with the default configuration so I assume it's caused
by --enable-libstdcxx-allocator=pool (why are you using that?)

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
I'm unable to reproduce this with the following, based on the llvm code. GCC
does the right thing here, so without a testcase there's nothing we can do.

#include 

template
class storage {
public:
  operator T() const { return {}; }
};

template
class opt : public storage {
public:
  explicit opt() { }
  opt(const opt&) = delete;
};

opt pf{};

class Pass {
public:
  std::string filename;

  Pass() {
filename = pf;
  }
};

Pass p;

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-30
 Ever confirmed|0   |1

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Works for me:
/data/users/nathans/trunk/obj/x86_64-lto/./prev-gcc/xg++
-B/data/users/nathans/trunk/obj/x86_64-lto/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/data/users/nathans/trunk/src/libstdc++-v3/libsupc++
-L/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/data/users/nathans/trunk/obj/x86_64-lto/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -flto=jobserver -frandom-seed=1 -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/c
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/../include
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/../libcpp/include 
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/../libdecnumber
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/../libdecnumber/bid
-I../libdecnumber
-I/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/../libbacktrace   -o
c/c-array-notation.o -MT c/c-array-notation.o -MMD -MP -MF
c/.deps/c-array-notation.TPo
/data/users/nathans/trunk/obj/x86_64-lto/../../src/gcc/c/c-array-notation.c -g
-O2 -flto=jobserver

Please provide a self-contained testcase

[Bug libstdc++/79162] [7 Regression] [C++17] ambiguity in string assignment due to string_view overload

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Can you reduce the failing code down to something smaller than the entirety of
LLVM?

Richard also says the overload shouldn't exist and is a bug, but the overload
has to exist, because the C++17 draft is defective.

[Bug c++/80920] warnings get position wrong - very confusing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-30
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jason Vas Dias from comment #0)
> Incidentally, why should it be illegal to specify an initializer for 
> an array of non-class types ?  How else is one meant to ensure that
> all elements of A::_a[] are initialized to zero ? Must one put :
>memset(_a, '\0', sizeof(_a))
> inside the initializer - there is no other way ?

It's not illegal to specify an initializer, you just did it wrong.

Either of _a() or _a{} works fine. The former has always been valid, even in
C++98.

I'm fairly sure we already have a bug report for the location of the error, but
I can't find it now.

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[liakhdi at ornl dot gov]

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

--- Comment #4 from DIL  ---
Offset of zero is fine. I have never observed this SegFault before. I ran the
test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1. Also, as I
mentioned before, the test passed the VALGRIND check. Would you be able to
point me to the specific line of the deepest user-level procedure in the call
stack where the segfault occurs? Was it line 744 of
__gfc_vector_MOD_vectoriterelementvalue (from your previous comment)?

[Bug c++/80913] [8 regression] Infinite loop in cc1plus with stat hack patch

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #11 from Nathan Sidwell  ---
Fixed r248687.

[Bug c++/80913] [8 regression] Infinite loop in cc1plus with stat hack patch

[nathan at gcc dot gnu.org]

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

--- Comment #10 from Nathan Sidwell  ---
Author: nathan
Date: Tue May 30 14:43:45 2017
New Revision: 248687

URL: https://gcc.gnu.org/viewcvs?rev=248687=gcc=rev
Log:
PR c++/80913
* name-lookup.c (add_decl_to_level): Assert not making a circular
chain.
(update_binding): Don't prematurely slide artificial decl.

* g++.dg/lookup/pr80913.C: New.

Added:
trunk/gcc/testsuite/g++.dg/lookup/pr80913.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Nathan Sidwell from comment #1)
> I cannot reproduce this.  an x86_64-linux host using
> --with-build-config=bootstrap-lto
> 
> 
> How exactly is gcc being configured and built?  Alternatively, is is
> possible for a self-contained testcase?

Nothing special.  Just add -g -O2 -flto=jobserver to compile
c/c-array-notation.c
with the newly built GCC.

[Bug middle-end/80917] missed bit information propagation

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
For this special case, we could simplify

  a_6 = a_5(D) + 4;
  _2 = a_6 & 2;

to

  _2 = a_5(D) & 2;

I believe we already have a similar transform with | 4 instead of + 4.

[Bug c++/80920] New: warnings get position wrong - very confusing

[jason.vas.dias at gmail dot com]

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

Bug ID: 80920
   Summary: warnings get position wrong - very confusing
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.vas.dias at gmail dot com
  Target Milestone: ---

Attempts to compile the following demo code :
$ echo '
#include 
struct A
{ char _a[256];
  std::initializer_list _al;
  A( std::initializer_list l )
: _a({0}),
  _al(l)
  {}  
};
' > b.C

produce the warning:

$ c++ -std=c++17 -Wall -Wextra -c b2.C
b.C: In constructor 'A::A(std::initializer_list)':
b.C:7:12: warning: list-initializer for non-class type must not be
parenthesized
   _al(l)
^

This is very confusing, since the code that produces the warning is :
   _a({0})
 ^

Please could gcc point out the relevant element in the initializer list
that causes the problem, rather than the end of the initializer list, 
which makes it appear as if that line causes the problem .

Incidentally, why should it be illegal to specify an initializer for 
an array of non-class types ?  How else is one meant to ensure that
all elements of A::_a[] are initialized to zero ? Must one put :
   memset(_a, '\0', sizeof(_a))
inside the initializer - there is no other way ?

[Bug bootstrap/80915] [8 Regression] bootstrap failed with LTO

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
I cannot reproduce this.  an x86_64-linux host using
--with-build-config=bootstrap-lto


How exactly is gcc being configured and built?  Alternatively, is is possible
for a self-contained testcase?

[Bug go/80914] gcc-go binaries don't run

[ian at airs dot com]

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

--- Comment #2 from Ian Lance Taylor  ---
The failure is in libbacktrace.  The program crashes because once libbacktrace
fails the first time, the program is trying to use libbacktrace to show a stack
trace of the failure.  This leads to an infinite recursion that blows out the
stack.

libbacktrace appears to be failing because it finds a compilation unit in the
.debug_info section with length 1.  That doesn't leave enough space for the two
byte version number at the start of the compilation unit.  I don't understand
why this would be.

The failure appears to be at the end of the .debug_info section.  Can you run
`readelf --debug=info` on your executable, and attach the last thirty lines or
so?  Thanks.

[Bug testsuite/80910] FAIL: gcc.target/x86_64/abi/ms-sys

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 41440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41440=edit
tentative patch

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from Daniel Santos  ---
> I intended to respond to your comments from 6 days ago sooner, but better late
> than never!  Again, sorry for the delay

No worries at all: I'm way late here myself ;-)

> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> You need to make certain to have the necessary 32-bit libraries and
>> headers.  Apart from that, configure --target=i686-pc-linux-gnu
>> --enable-targets=all should be enough, together with CC='gcc -m32'
>> CXX='g++ -m32'.  I don't pass --enable-multilib, this happens by default.
>
> I think I'll need to figure this part out soon, as I posted earlier about
> strange problems when calling exec.  As it turns out, there are a lot of
> variables in the generated script that aren't being populated,
> ORIGINAL_AS_FOR_TARGET being one of them.  The "exec: --: invalid option"
> problem is occurs because ORIGINAL_AS_FOR_TARGET expands to an empty string 
> and
> the first thing after "exec" is the argument "--32" that is intended for the 
> AS
> program.

I now remembered what you're probably missing: as soon as configure and
the gcc build process are run with --target= which differs
from the (guessed by config.sub) values for --host and --build, they
conclude that a cross-configuration/-build is running and make their set
of assumptions on how to locate cross-ar/as/ld.  In the case at hand
(and any multilibbed target in general), this is wrong: this is *not* a
cross-build since the host can execute both 32 and 64-bit binaries and
many of those assumptions are wrong.

The way to convince configure of that fact is to run it with

--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu

This way, you'll get a native build and all problems should vanish.

While in theory both /usr/bin/as and /usr/bin/ld should be capable of
performing both 32 and 64-bit assemblies/links, I found it best to
provide an i686-pc-linux-gnu gas and gld with

--with-as= --with-gnu-as --with-ld= --with-gnu-ld

to avoid a couple of corner cases.  You should configure binutils in the
same way, perhaps again with CC='gcc -m32' CXX='g++ -m32'.

I'll comment on the rest later once I find some time.

Rainer

[Bug c++/80913] [8 regression] Infinite loop in cc1plus with stat hack patch

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Nathan Sidwell  ---
> It doesn't appear to be the stathack patch at fault here.  I still get the
> infinite loop with my reduced testcase when I revert it.  (Which is good,
> because I can't see how that patch could cause this behaviour.)

This is weird since just reverting the stathack patch was enough to
allow the bootstraps to succeed for me.

Rainer

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I got a prototype patch.

[Bug c++/80913] [8 regression] Infinite loop in cc1plus with stat hack patch

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.12,|i386-pc-solaris2.12,
   |sparc-sun-solaris2.12   |sparc-sun-solaris2.12,
   ||powerpc-ibm-aix*
 CC||dje at gcc dot gnu.org

--- Comment #8 from David Edelsohn  ---
Probably also a cause of AIX bootstrap hang.

[Bug libgomp/80822] libgomp incorrect affinity when OMP_PLACES=threads

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue May 30 12:05:30 2017
New Revision: 248683

URL: https://gcc.gnu.org/viewcvs?rev=248683=gcc=rev
Log:
PR libgomp/80822
* config/linux/affinity.c (gomp_affinity_init_level_1): New function.
(gomp_affinity_init_level): Use it.  Always analyze the core and thread
sibling lists, depending on level just pick up what CPUs to put
together into a place vs. whether add multiple ordered places.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/config/linux/affinity.c

[Bug tree-optimization/80901] [8 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in verify_loop_structure, at cfgloop.c:1644

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c/80919] [7/8 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I'll take a look.

[Bug c/80919] [7/8 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-30
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.2
Summary|[7 Regression] ICE: |[7/8 Regression] ICE:
   |Segmentation fault with |Segmentation fault with
   |-Wall when printing address |-Wall when printing address
   |of size 0 array |of size 0 array
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r240095.

[Bug c/80919] New: [7 Regression] ICE: Segmentation fault with -Wall when printing address of size 0 array

[bastian.beisc...@rwth-aachen.de]

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

Bug ID: 80919
   Summary: [7 Regression] ICE: Segmentation fault with -Wall when
printing address of size 0 array
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bastian.beisc...@rwth-aachen.de
  Target Milestone: ---

Hey,

the following code causes a GCC segmentation fault when compiled with -Wall:

#include 

void conftest(void)
{
  int gid[0];
  printf("%x\n", );
}

Compiler output:

$ gcc -Wall -c -o conftest.o conftest.c
conftest.c: In function ‘conftest’:
conftest.c:6:3: internal compiler error: Segmentation fault
   printf("%x\n", );
   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Cheers
Bastian

[Bug c++/80913] [8 regression] Infinite loop in cc1plus with stat hack patch

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
It doesn't appear to be the stathack patch at fault here.  I still get the
infinite loop with my reduced testcase when I revert it.  (Which is good,
because I can't see how that patch could cause this behaviour.)

I think it was my do_pushdecl change that didn't include another change I had
thought was unrelated.

[Bug tree-optimization/80901] [8 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu: in verify_loop_structure, at cfgloop.c:1644

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue May 30 11:08:36 2017
New Revision: 248681

URL: https://gcc.gnu.org/viewcvs?rev=248681=gcc=rev
Log:
2017-05-30  Richard Biener  

PR middle-end/80901
* cfgexpand.c (expand_gimple_cond): Match up loop fixup with
split_edge code.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr80901.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created

[nickc at gcc dot gnu.org]

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

--- Comment #3 from Nick Clifton  ---
Author: nickc
Date: Tue May 30 10:49:29 2017
New Revision: 248674

URL: https://gcc.gnu.org/viewcvs?rev=248674=gcc=rev
Log:
PR target/78838
gcc * config/msp430/msp430.c (gen_prefix): Return NULL when section name is
.lowtext.
(has_section_name): New function.

testsuite * gcc.target/msp430/interrupt_fn_placement.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/msp430/msp430.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80918] [6/7/8 Regression] Assumed size whole array rejected in depend clause

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.4

[Bug middle-end/13182] -fstack-check probes too distant when allocating on stack

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> To be clear: x86/Linux and x86-64/Linux (and for them there is no protection
> area during the probing).

I misremembered: there is exactly one page of protection area for them because
of the way the unwinding mechanism (run on the alternate stack) restores the
regular execution of the program.

[Bug fortran/80918] [6/7/8 Regression] Assumed size whole array rejected in depend clause

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug fortran/80918] New: [6/7/8 Regression] Assumed size whole array rejected in depend clause

[jakub at gcc dot gnu.org]

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

Bug ID: 80918
   Summary: [6/7/8 Regression] Assumed size whole array rejected
in depend clause
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

subroutine foo (a)
  integer :: a(*)
  !$omp task depend(inout:a)
  !$omp end task
  !$omp task depend(inout:a)
  !$omp end task
end subroutine foo

is rejected due to a typo.

[Bug middle-end/13182] -fstack-check probes too distant when allocating on stack

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> Right, the Ada runtime uses an alternate signal stack for specific platforms.

To be clear: x86/Linux and x86-64/Linux (and for them there is no protection
area during the probing).

[Bug gcov-profile/80911] gcov failed: gcno corrupted

[vries at gcc dot gnu.org]

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

--- Comment #17 from Tom de Vries  ---
(In reply to Martin Liška from comment #2)
> Can't confirm that, running trunk@248556 works fine for me.
> Utilizing valgrind also does not help.

I also had problems reproducing the problem, so I decided to dig a little
further.

The problem occurred for me with g++ 4.4.3.

With a more recent g++ (5.4.0), we generate at gimplify:
...
  D.67316 = {};
  block_info::block_info ();
  try
{
  D.74239 = gcov_read_unsigned ();
  D.74240 = (long unsigned int) D.74239;
  D.74241 = >blocks;
  std::vector::resize (D.74241, D.74240, );
}
  finally
{
  block_info::~block_info ();
  D.67316 = {CLOBBER};
}
...
In other words, before calling the default constructor block_info::block_info
on the implicit resize argument D.67316, we initialize it to zero using
'D.67316 = {}'.

With 4.4.3, we generate:
...
  __comp_ctor  ();
  try
{
  D.67371 = gcov_read_unsigned ();
  D.67372 = (long unsigned int) D.67371;
  D.67373 = >blocks;
  resize (D.67373, D.67372, );
}
  finally
{
  __comp_dtor  ();
}
...
and we don't initialize all of D.67200 to zero.

So, when compiling with a more recent compiler, the initialization is done
regardless of how the default constructor is implemented, so there's no problem
to detect with valgrind.

[Bug middle-end/13182] -fstack-check probes too distant when allocating on stack

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
> I'm not sure if the the probing offset is large enough for this purpose
> because the kernel keeps pushing more and more data onto the stack during
> signal handling:
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=20305

Right, the Ada runtime uses an alternate signal stack for specific platforms.

[Bug c++/59457] name mangling in presence of variadic templates seems wrong

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ABI
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
The default behaviour changed with r211593 when the default changed to
-fabi-version=0, because the mangling was corrected for -fabi-version=6 by
r182970.

So this is a dup of PR 51322

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

[Bug c++/51322] [C++11] wrong mangling with argument packs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||plasmahh at gmx dot net

--- Comment #5 from Jonathan Wakely  ---
*** Bug 59457 has been marked as a duplicate of this bug. ***

[Bug middle-end/13182] -fstack-check probes too distant when allocating on stack

[fw at gcc dot gnu.org]

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

--- Comment #7 from Florian Weimer  ---
(In reply to Eric Botcazou from comment #6)
> That's as expected: the probing mechanism maintains a protection area so the
> program can recover from a stack overflow condition by raising an exception.
> That's why it always probes a few pages ahead but, once the first few pages
> are skipped at the entry point, every subsequent page is probed.

I'm not sure if the the probing offset is large enough for this purpose because
the kernel keeps pushing more and more data onto the stack during signal
handling:

  https://sourceware.org/bugzilla/show_bug.cgi?id=20305

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

[gustavo.hime at mpimet dot mpg.de]

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

--- Comment #17 from Gustavo Hime  ---
(In reply to Jerry DeLisle from comment #12)
Dear Jerry,

Thank you for the feedback.

For the record, I didn't say gfortran is crap, nor did I throw insults at it.
At least I didn't mean to. Sorry if you misunderstood that. I wrote "any
compiler/code that crashes is crap" to make a point of this not being "not a
bug", as it was being blatantly ignored, to say the least.

>Or, better yet, don't expand/initialize
> the array at compile time.  We should set some sort of global
> constructor/iterator that gets finally executed at run time, but at compile
> time, we know the value of any aspect of the array as a parameter with out
> actually needing to expand it.

I'm honestly surprised this is not how things are being done already. You might
as well be calling the constructor for static instances of C++ classes at
compile time. 

> Yes that will take some frontend magic and we have so few people to support
> gfortran (for free remember) that we may not be able to get to it.

I would be happy to help if you can show me a few of the ropes. I'm overworked
as is, but (as I've already said before) gfortran is a much better alternative
to either intel or nag, when it comes to development. When it comes to
performance, intel is far superior, but that is a hard target to compete with.

> I don't think the report is invalid at all.

Again, thanks for the feedback and sorry for the misunderstanding. And to all
the maintainers who shared in later on a more reasonable tone.

[Bug middle-end/13182] -fstack-check probes too distant when allocating on stack

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #6 from Eric Botcazou  ---
That's as expected: the probing mechanism maintains a protection area so the
program can recover from a stack overflow condition by raising an exception.
That's why it always probes a few pages ahead but, once the first few pages are
skipped at the entry point, every subsequent page is probed.

[Bug middle-end/80701] Option for generating link symbol for functions removed by DCE

[gustavo.hime at mpimet dot mpg.de]

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

--- Comment #6 from Gustavo Hime  ---
(In reply to Thomas Koenig from comment #5)

Dear Thomas,

Thank you for the feedback.

Please keep in mind this can easily arise in a shared codebase, sometimes
unintentionally. As Dominique pointed out, a similar issue is open in the GCC
tracker as well. The example you wrote below is something I do as well, and is
code instrumentation, which is not what I am pointing out as a source of
problems.

Cheers.

> This one really depends on personal preference.
> 
> Personally, I like adding statemens like
> 
>   parameter, logical :: debug = .false.
> 
>   ...
>   if (debug) then
>  call some_routine_for_debugging_stuff
>   end if
> 
> Removing dead code including function calls is something that is done in the
> middle-end. Here is an equivalent C test case:
> 
> $ cat undef.c
> void foo(void);
> 
> int main()
> {
>if (0)
>   foo();
>return 0;
> }
> $ gcc -Wall -Wextra undef.c
> $ 
> 
> I don't think we will get agreement to turn on such a warning
> by default. However, a request for an option that warns in such
> a case is justified.
> 
> Confirming as enhancement request.

[Bug middle-end/80701] Option for generating link symbol for functions removed by DCE

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tkoenig at gcc dot gnu.org
  Component|fortran |middle-end
 Blocks||46476
Summary|gfortran ignores dead code  |Option for generating link
   |after return statement  |symbol for functions
   ||removed by DCE
   Severity|normal  |enhancement

--- Comment #5 from Thomas Koenig  ---
(In reply to Gustavo Hime from comment #4)

> However, since the object code does not contain the dead part, and hence no
> symbols are resolved at link-time, many of the potential problems remain,
> i.e., the code will still compile and link in spite of there being a
> function call to a symbol that isn't defined.

This one really depends on personal preference.

Personally, I like adding statemens like

  parameter, logical :: debug = .false.

  ...
  if (debug) then
 call some_routine_for_debugging_stuff
  end if

Removing dead code including function calls is something that is done in the
middle-end. Here is an equivalent C test case:

$ cat undef.c
void foo(void);

int main()
{
   if (0)
  foo();
   return 0;
}
$ gcc -Wall -Wextra undef.c
$ 

I don't think we will get agreement to turn on such a warning
by default. However, a request for an option that warns in such
a case is justified.

Confirming as enhancement request.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
[Bug 46476] Missing Warning about unreachable code after return

[Bug tree-optimization/80906] [7/8 Regression] ICE in copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2094

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||70390

--- Comment #3 from Richard Biener  ---
Ok, I have a patch that replaces the gcc_unreachable with proper code-gen
(hopefully ...).  This is probably still a dup of the mentioned PR.  I didn't
touch the conditional PHI case, I believe we may still run into that ICE
though.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70390
[Bug 70390] [6 Regression] internal compiler error: in
copy_loop_close_phi_args, at graphite-isl-ast-to-gimple.c:2114

[Bug libgomp/80394] Empty OpenMP task is wrongly removed when optimizing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/80385] [5/6 Regression] Segfault in commutative_operand_precedence() rtlanal.c:3373

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/80286] [5/6 Regression] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80363] #'vec_cond_expr' not supported by dump_expr#

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80176] [5/6 Regression] cannot bind reference to static member function using object access expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/80168] [5/6 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80141] ICE with pragma omp declare

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/80112] [5/6 Regression] ICE in doloop_condition_get at loop-doloop.c:158

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80129] wrong code with ternary struct assignment to const

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/80097] internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/79944] asan: incorrect instrumentation of atomic operations

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug debug/80025] [5/6 Regression] ICE w/ -O2 (-O3, -Ofast) -g -ftracer (infinite recursion in rtx_equal_for_cselib_1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/79896] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79932] _mm512_packus_epi32 does not compile under -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/79901] ICE in prepare_cmp_insn, at optabs.c:3904

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79807] [5/6 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79729] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18231

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/79641] [5 Regression] ICE with const variable and attribute

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79570] [5/6 Regression] ICE in sel-sched-ir.c:4534 in pr69956.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79568] ICE in extract_insn, at recog.c:2311 for pr70325.c (with -mavx512bw)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79559] [5/6 Regression] ICE in ix86_print_operand, at config/i386/i386.c:18189

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/79512] [6 Regression] ICE: Segfault in gimple_build_call_1, at gimple.c:218

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79494] [5/6 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/79197] [5 Regression] ICE in extract_insn in gcc/recog.c:2311

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/79396] [5/6 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2 -march=haswell

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79411] [5 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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