Re: GCC 7.3 Released

[bojanowski]

Hi Richard
Please let me know if you have any knowledge about compiler used to this 
project

I had some info they use gnu compiler before the change name sincerley chris
http://www.samsung.com/global/business/telecommunication-systems/resource/opensource/ip-set-top-box.html
 SMT-6010E SMT-6010E_OpenSource.zip

info from inside procesor bsp-15 mapca mapca1000a equator 
/pixelworks/hitachi japan VLIW



###
### Equator Technologies, Inc.
###

###
### Module name  : $RCSfile: Makefile.ETI,v $ $Revision: 1.2 $
###
### Last update  : $Date: 2005/06/16 13:46:21 $ UTC
###

#
# Default Settings

ETI_INSTALL := $(HOME)/build/eti_tools/v6.0/install
ETI_TOOLKIT := $(HOME)/build/eti_tools/v6.0/install
ETI_REFERENCE_INSTALL := $(HOME)/build/eti_tools/v6.0/install

WORKSPACE := $(shell pwd)
export HOST_ARCH  := i686
export HOST_PLATFORM  := Linux

ARCH   := BSP
PLATFORM   := Linux

###
# Configurations
# (see arch/bsp/configs/README)

# Default Configuration
# e.g. Dolphin
#ETI_CONFIGURATION  := PCIMASTER_NORD
# e.g. Stingray
#ETI_CONFIGURATION  := NOPCIMASTER_NORD
# e.g. Dolphin/Tetra with tinykernel
#By Changlae Jo
# We will use Ramdisk
ETI_CONFIGURATION  := PCIMASTER_RD
# e.g. Starfish
#ETI_CONFIGURATION  := STARFISH_NORD

PCIMASTER_NORD_VMLINUX:= vmlinux.out vmlinux.l2sei vmlinux.flashsei
NOPCIMASTER_NORD_VMLINUX  := vmlinux.out vmlinux.l2sei
PCIMASTER_RD_VMLINUX  := vmlinux.l2sei vmlinux.flashsei
STARFISH_NORD_VMLINUX := vmlinux.out vmlinux.l2sei

DOT_CONFIG := $(ETI_CONFIGURATION)_.config
AUTOCONF_H := $(ETI_CONFIGURATION)_autoconf.h
VMLINUX:= $($(ETI_CONFIGURATION)_VMLINUX)


# Modules for rootfilesystem
# By Changlae Jo.
#TINYROOTFS_ETI_MODULES := \
# 
$(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/boardSupportDev.o 
\
# 
$(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/noncoregpDev.o 
\

# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/flash.o

#TINYROOTFS_LINUX_MODULES := \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/fat.o \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/vfat.o \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/msdos.o


# Dependencies
.PHONY  : check tinyrootfs_prep configure build install 
install.headers clean


ifeq ($(ETI_CONFIGURATION),PCIMASTER_NORD)
all : check configure install.headers build.modules build 
install.modules install post.install

else
# Do not install headers for non-PCI master builds.
all : check configure build install
endif

# Prepare tinyrootfs. Copy necessary file to it
ifeq ($(ETI_CONFIGURATION),PCIMASTER_RD)
build: tinyrootfs_prep
tinyrootfs_prep  : $(TINYROOTFS_ETI_MODULES) $(TINYROOTFS_LINUX_MODULES)
$(TINYROOTFS_LINUX_MODULES) : build.modules
endif

ifdef ETIQADEPS
configure  : check
install.headers: configure
build.modules  : configure
build  : configure
install.modules: build.modules
install: build
endif



# Verbosity, debug etc.
ifeq ($(VERBOSEBUILD),)
   .SILENT :
endif

##
# Exports
BSP_Linux_CC := $(ETI_TOOLKIT)/$(HOST_ARCH)_$(HOST_PLATFORM)/bin/ecc

export CC :=  $($(ARCH)_$(PLATFORM)_CC) -D__KERNEL__
export LD :=  `$(CC) -print-prog-name=ld`
export NM :=  `$(CC) -print-prog-name=nm`
export AS :=  $(CC)
export CPP :=  $(CC) -E

# Root filesystem for tiny kernel gets picked up from here:
ETI_REFERENCE_INSTALL = /h/qa/build/eti_tools/latest

###
# Rules

##
configure:
ifdef ETIQABUILD
$(MAKE) -f Makefile xconfig  > /dev/null 2>&1 &
sleep 5
cp $(WORKSPACE)/arch/bsp/configs/$(DOT_CONFIG) $(WORKSPACE)/.config
cp $(WORKSPACE)/arch/bsp/configs/$(AUTOCONF_H) 
$(WORKSPACE)/include/linux/autoconf.h

else
# $(MAKE) -f Makefile xconfig
# by Changlae Jo
$(MAKE) -f Makefile menuconfig
endif
$(MAKE) -f Makefile dep

build.modules:
$(MAKE) -C $(WORKSPACE) -f Makefile modules

build:
$(MAKE) -C $(WORKSPACE) -f Makefile $(VMLINUX)

##
install.headers:
$(MAKE) -C $(WORKSPACE) -f Makefile 
$(WORKSPACE)/include/linux/modversions.h

echo "Copying Linux header files"
mkdir -p $(ETI_INSTALL)/BSP_Linux/include
cd $(WORKSPACE)/include; /bin/tar --exclude CVS -czf - linux asm asm-bsp | 
\

(cd $(ETI_INSTALL)/BSP_Linux/include; /bin/tar -xzf -)

install.modules:
mkdir -p $(ETI_INSTALL)/BSP_Linux/rootfs;   \
$(MAKE) -C $(WORKSPACE) -f Makefile  \
 INSTALL_MOD_PATH=$(ETI_INSTALL)/BSP_Linux/rootfs \
 modules_install;   \
rm -f $(ETI_INSTALL)/BSP_Linux/rootfs/lib/modules/2.2.20/build

install:
if [ ! -f $(WORKSPACE)/arch/bsp/boot/vmlinux.out ];then\
  ln -s $(WORKSPACE)/vmlinux.out $(WORKSPACE)/arch/bsp/boot/vmlinux.out; \
fi
mkdir -p $(ETI_INSTALL)/util/linux_kernel/$(ETI_CONFIGURATION)
install -D -m 444 $(WORKSPACE)/arch/bsp/configs/README 

Re: Retpolines and CFI

[Florian Weimer]

On 01/22/2018 01:21 PM, Florian Weimer wrote:


There is a different issue with the think itself.

__x86_indirect_thunk_rax:
.LFB2:
     .cfi_startproc
     call    .LIND5
.LIND4:
     pause
     lfence
     jmp .LIND4
.LIND5:
     mov %rax, (%rsp)
     ret
     .cfi_endproc

If a signal is delivered after the mov has executed, the unwinder will 
eventually unwind through the signal frame and hit 
__x86_indirect_thunk_rax.  It does not treat it as a signal frame, so 
the return address of the stack is decremented by one, in an attempt to 
obtain a program counter value which is within the call instruction. 
However, in this scenario, the return address is actually the start of 
the function, and subtracting one moves the program counter out of the 
unwind region for that function.


I think it is possible to fix the second case by hiding the the return 
address at the top of the stack, like this:


__x86_indirect_thunk_rax:
.LFB2:
.cfi_startproc
call.LIND5
.LIND4:
pause
lfence
jmp .LIND4
.LIND5:
.cfi_def_cfa_offset 16
mov %rax, (%rsp)
ret
.cfi_endproc

The unwinder should then use the other return address, from the caller 
of the thunk routine.


Thanks,
Florian

Re: bugs in external debug info support in libbacktrace

[Ian Lance Taylor]

On Mon, Nov 27, 2017 at 2:23 AM, Milian Wolff  wrote:
>
> I was made aware that libbacktrace got support for external debug info with
> [1], great work! I have just synced the latest libbacktrace into heaptrack [2]
> in a local branch and played around with it and noticed two limitations:
>
> [1]: https://github.com/gcc-mirror/gcc/commit/
> b919941efc58035debbcf69b645c072b7dd6ba4e
> [2]: https://github.com/KDE/heaptrack
>
> a) elf_open_debugfile_by_debuglink checks the crc, even if it is not provided
> by the debug file. I.e. I have a file where `debuglink_crc == 0`, but the
> got_crc calculated from elf_crc32_file is non-zero. I have patched this
> locally with the following to make it work for me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..24bf58728fd 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -1005,7 +1005,7 @@ elf_open_debugfile_by_debuglink (struct backtrace_state
> *state,
>if (ddescriptor < 0)
>  return -1;
>
> -  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
> +  got_crc = debuglink_crc ? elf_crc32_file (state, ddescriptor,
> error_callback, data) : 0;
>if (got_crc != debuglink_crc)
>  {
>backtrace_close (ddescriptor, error_callback, data);

Thanks.  I fixed this problem with a slightly different patch,
appended.  Committed to mainline.


> b) elf_add guards the code to inspect the symtab-shndx with a `&& !debuginfo`
> check in loc 2797. This results in all files with separate debug info yielding
> `found_sym = 0` when calling elf_add, and symbol resolution is broken.
> Personally I have patched this check out to make symbol resolution work for
> me:
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index 06823fcf59b..6876bd3ed8e 100644
> --- a/libbacktrace/elf.c
> +++ b/libbacktrace/elf.c
> @@ -2794,7 +2794,7 @@ elf_add (struct backtrace_state *state, const char
> *filename, int descriptor,
>
>if (symtab_shndx == 0)
>  symtab_shndx = dynsym_shndx;
> -  if (symtab_shndx != 0 && !debuginfo)
> +  if (symtab_shndx != 0)
>  {
>const b_elf_shdr *symtab_shdr;
>unsigned int strtab_shndx;
>
> Could you please check whether the two patches above could be upstreamed?

I don't think that's the right approach.  In the appended patch I skip
clearing *found_sym if debuginfo is set.  I hope that will fix the
problem.

Ian

2018-01-25  Ian Lance Taylor  

* elf.c (elf_open_debugfile_by_debuglink): Don't check CRC if the
desired CRC is zero.
(elf_add): Don't clear *found_sym and *found_dwarf if debuginfo.
Index: elf.c
===
--- elf.c   (revision 257038)
+++ elf.c   (working copy)
@@ -997,7 +997,6 @@ elf_open_debugfile_by_debuglink (struct
 void *data)
 {
   int ddescriptor;
-  uint32_t got_crc;
 
   ddescriptor = elf_find_debugfile_by_debuglink (state, filename,
 debuglink_name,
@@ -1005,11 +1004,16 @@ elf_open_debugfile_by_debuglink (struct
   if (ddescriptor < 0)
 return -1;
 
-  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
-  if (got_crc != debuglink_crc)
+  if (debuglink_crc != 0)
 {
-  backtrace_close (ddescriptor, error_callback, data);
-  return -1;
+  uint32_t got_crc;
+
+  got_crc = elf_crc32_file (state, ddescriptor, error_callback, data);
+  if (got_crc != debuglink_crc)
+   {
+ backtrace_close (ddescriptor, error_callback, data);
+ return -1;
+   }
 }
 
   return ddescriptor;
@@ -2634,8 +2638,11 @@ elf_add (struct backtrace_state *state,
   unsigned int using_debug_view;
   uint16_t *zdebug_table;
 
-  *found_sym = 0;
-  *found_dwarf = 0;
+  if (!debuginfo)
+{
+  *found_sym = 0;
+  *found_dwarf = 0;
+}
 
   shdrs_view_valid = 0;
   names_view_valid = 0;

Cortex-r52 FP double precision

[Alexander Fedotov]

Hi,
As I understand from this
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master
branch doesn't have support of double-precision FPv5 floating-point
instructions for ARMv8-R (Cortex-r52).
If yes, are there any chances to see them in GCC 8 ?

Alex

gcc-7-20180125 is now available

[gccadmin]

Snapshot gcc-7-20180125 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 257067

You'll find:

 gcc-7-20180125.tar.xzComplete GCC

  SHA256=f4cad0895aa6dd237cbcb6e81750e40c3fb3eba8a5bcdf25a21c4ee5520c344b
  SHA1=3b0c38bad58b57a69260916c4f10c40baf56a099

Diffs from 7-20180111 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Retpolines and CFI

[Jeff Law]

On 01/25/2018 06:38 AM, H.J. Lu wrote:
> On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer  wrote:
>> I tried this:
>>
>> struct C {
>>   virtual ~C();
>>   virtual void f();
>> };
>>
>> void
>> f (C *p)
>> {
>>   p->f();
>>   p->f();
>> }
>>
>> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
>> this:
>>
>> _Z1fP1C:
>> .LFB0:
>> .cfi_startproc
>> pushq   %rbx
>> .cfi_def_cfa_offset 16
>> .cfi_offset 3, -16
>> movq(%rdi), %rax
>> movq%rdi, %rbx
>> jmp .LIND1
>> .LIND0:
>> pushq   16(%rax)
>> jmp __x86_indirect_thunk
>> .LIND1:
>> call.LIND0
>> movq(%rbx), %rax
>> movq%rbx, %rdi
>> popq%rbx
>> .cfi_def_cfa_offset 8
>> movq16(%rax), %rax
>> jmp __x86_indirect_thunk_rax
>> .cfi_endproc
>>
>> This doesn't look quite right.  x86-64 is supposed to have asynchronous
>> unwind tables by default, but there is nothing that reflects the change in
>> the (relative) frame address after .LIND0.  I think that region really has
>> to be moved outside of the .cfi_startproc/.cfi_endproc bracket.
> 
> I'd like to remove __x86_indirect_thunk since it can't be made compatible
> with CET:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
User code should be built with CET, not retpolines.   So I don't see
that removing x86_indirect_thunk is that important because we won't be
using them together.

jeff

Re: GCC 7.3 Released

[Jonathan Wakely]

You've just sent that to hundreds of people who can't unsubscribe you.

Read the SMTP headers of the email, or go to
https://gcc.gnu.org/lists.html and follow the instructions there.

On 25 January 2018 at 14:56, Jimmy Shen  wrote:
> unsubscribe
>
> On Thu, Jan 25, 2018 at 4:41 AM, Richard Biener  wrote:
>
>>
>> The GNU Compiler Collection version 7.3 has been released.
>>
>> GCC 7.3 is a bug-fix release from the GCC 7 branch
>> containing important fixes for regressions and serious bugs in
>> GCC 7.2 with more than 99 bugs fixed since the previous release.
>>
>> This release includes code generation options to mitigate
>> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.
>>
>> This release is available from the FTP servers listed at:
>>
>>   http://www.gnu.org/order/ftp.html
>>
>> Please do not contact me directly regarding questions or comments
>> about this release.  Instead, use the resources available from
>> http://gcc.gnu.org.
>>
>> As always, a vast number of people contributed to this GCC release
>> -- far too many to thank them individually!
>>

Re: extern const initialized warns in C

[Jonathan Wakely]

On 25 January 2018 at 12:27, Georg-Johann Lay wrote:
> On 22.01.2018 16:20, Jonathan Wakely wrote:
>>
>> On 21 January 2018 at 12:08, Georg-Johann Lay wrote:
>>>
>>> Jay K schrieb:


 extern const int foo = 123;

 Why does this warn?
 This is a valid portable form, with the same meaning
 across all compilers, and, importantly, portably
 to C and C++.
>>>
>>>
>>> I also wondered about this.
>>>
>>> In C99 §6.9.2 "External object definitions" there's actually
>>> the following example in clause 4:
>>>
>>> extern int i3 = 3; // definition, external linkage
>>
>>
>> That's a different case. There's no advantage to the 'extern' here,
>> because the code means the same thing in C and C++ without the
>> 'extern', so just leave it out.
>
>
> I'd rather like to know why GCC is throwing a warning here.
>
> It's clear how to hack the C source, but that's a different point.
>
> It's just the case that I don't see any problem with that construct,
> and it was worth an explicit example in the standard.  Or is it
> common practice to warn constructs that are "no advantage"?

Read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977 (as already
stated earlier in the thread).

Re: extern const initialized warns in C

[Georg-Johann Lay]

On 22.01.2018 16:20, Jonathan Wakely wrote:

On 21 January 2018 at 12:08, Georg-Johann Lay wrote:

Jay K schrieb:


extern const int foo = 123;

Why does this warn?
This is a valid portable form, with the same meaning
across all compilers, and, importantly, portably
to C and C++.


I also wondered about this.

In C99 §6.9.2 "External object definitions" there's actually
the following example in clause 4:

extern int i3 = 3; // definition, external linkage


That's a different case. There's no advantage to the 'extern' here,
because the code means the same thing in C and C++ without the
'extern', so just leave it out.


I'd rather like to know why GCC is throwing a warning here.

It's clear how to hack the C source, but that's a different point.

It's just the case that I don't see any problem with that construct,
and it was worth an explicit example in the standard.  Or is it
common practice to warn constructs that are "no advantage"?

Johann

Re: extern const initialized warns in C

[Jonathan Wakely]

On 25 January 2018 at 12:29, Jonathan Wakely wrote:
> On 25 January 2018 at 12:27, Georg-Johann Lay wrote:
>> On 22.01.2018 16:20, Jonathan Wakely wrote:
>>>
>>> On 21 January 2018 at 12:08, Georg-Johann Lay wrote:

 Jay K schrieb:
>
>
> extern const int foo = 123;
>
> Why does this warn?
> This is a valid portable form, with the same meaning
> across all compilers, and, importantly, portably
> to C and C++.


 I also wondered about this.

 In C99 §6.9.2 "External object definitions" there's actually
 the following example in clause 4:

 extern int i3 = 3; // definition, external linkage
>>>
>>>
>>> That's a different case. There's no advantage to the 'extern' here,
>>> because the code means the same thing in C and C++ without the
>>> 'extern', so just leave it out.
>>
>>
>> I'd rather like to know why GCC is throwing a warning here.
>>
>> It's clear how to hack the C source, but that's a different point.
>>
>> It's just the case that I don't see any problem with that construct,
>> and it was worth an explicit example in the standard.  Or is it
>> common practice to warn constructs that are "no advantage"?
>
> Read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977 (as already
> stated earlier in the thread).

Also, examples in the standard exist to show what is technically
valid, not what is good coding style.

GCC 7.4 Status report (2018-01-25)

[Richard Biener]

Status
==

The GCC 7 branch is again open for regression and documentation fixes.


Quality Data


Priority  #   Change from last report
---   ---
P1   
P2  164   +   2
P3   22   +   9
P4  154   +   1
P5   28 
---   ---
Total P1-P3 186   +  12
Total   368   +  13


Previous Report
===

https://gcc.gnu.org/ml/gcc/2017-12/msg00102.html

GCC 7.3 Released

[Richard Biener]

The GNU Compiler Collection version 7.3 has been released.

GCC 7.3 is a bug-fix release from the GCC 7 branch
containing important fixes for regressions and serious bugs in
GCC 7.2 with more than 99 bugs fixed since the previous release.

This release includes code generation options to mitigate
Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.

This release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: GCC 7.3 Released

[Vikrant Abbott]

Hi

I don't know how to unsubscribe to this.

Thanks.
Vik.

On 25 Jan 2018 9:48 am, "Richard Biener"  wrote:

>
> The GNU Compiler Collection version 7.3 has been released.
>
> GCC 7.3 is a bug-fix release from the GCC 7 branch
> containing important fixes for regressions and serious bugs in
> GCC 7.2 with more than 99 bugs fixed since the previous release.
>
> This release includes code generation options to mitigate
> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.
>
> This release is available from the FTP servers listed at:
>
>   http://www.gnu.org/order/ftp.html
>
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
>

Re: Retpolines and CFI

[Florian Weimer]

On 01/25/2018 02:38 PM, H.J. Lu wrote:

On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer  wrote:

On 01/22/2018 01:21 PM, Florian Weimer wrote:


There is a different issue with the think itself.

__x86_indirect_thunk_rax:
.LFB2:
  .cfi_startproc
  call.LIND5
.LIND4:
  pause
  lfence
  jmp .LIND4
.LIND5:
  mov %rax, (%rsp)
  ret
  .cfi_endproc

If a signal is delivered after the mov has executed, the unwinder will
eventually unwind through the signal frame and hit __x86_indirect_thunk_rax.
It does not treat it as a signal frame, so the return address of the stack
is decremented by one, in an attempt to obtain a program counter value which
is within the call instruction. However, in this scenario, the return
address is actually the start of the function, and subtracting one moves the
program counter out of the unwind region for that function.



I think it is possible to fix the second case by hiding the the return
address at the top of the stack, like this:

__x86_indirect_thunk_rax:
.LFB2:
 .cfi_startproc
 call.LIND5
.LIND4:
 pause
 lfence
 jmp .LIND4
.LIND5:
 .cfi_def_cfa_offset 16
 mov %rax, (%rsp)
 ret
 .cfi_endproc

The unwinder should then use the other return address, from the caller of
the thunk routine.


Can you open a GCC bug to track it?


Sure, I filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039

As mentioned on the bug, we now have a reported of a potential kernel 
issue related to retpolines and unwinding, but it's not clear that the 
thunk routine is at fault (which would be supplied by the kernel anyway).


Thanks,
Florian

Re: GCC 7.3 Released

[Jonathan Wakely]

Read the SMTP headers of the email, or go to
https://gcc.gnu.org/lists.html and follow the instructions there.

On 25 January 2018 at 10:48, Vikrant Abbott  wrote:
> Hi
>
> I don't know how to unsubscribe to this.
>
> Thanks.
> Vik.
>
> On 25 Jan 2018 9:48 am, "Richard Biener"  wrote:
>
>>
>> The GNU Compiler Collection version 7.3 has been released.
>>
>> GCC 7.3 is a bug-fix release from the GCC 7 branch
>> containing important fixes for regressions and serious bugs in
>> GCC 7.2 with more than 99 bugs fixed since the previous release.
>>
>> This release includes code generation options to mitigate
>> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.
>>
>> This release is available from the FTP servers listed at:
>>
>>   http://www.gnu.org/order/ftp.html
>>
>> Please do not contact me directly regarding questions or comments
>> about this release.  Instead, use the resources available from
>> http://gcc.gnu.org.
>>
>> As always, a vast number of people contributed to this GCC release
>> -- far too many to thank them individually!
>>

Re: GCC 7.3 Released

[Vikrant Abbott]

Thank you!

On 25 Jan 2018 1:16 pm, "Jonathan Wakely"  wrote:

> Read the SMTP headers of the email, or go to
> https://gcc.gnu.org/lists.html and follow the instructions there.
>
> On 25 January 2018 at 10:48, Vikrant Abbott 
> wrote:
> > Hi
> >
> > I don't know how to unsubscribe to this.
> >
> > Thanks.
> > Vik.
> >
> > On 25 Jan 2018 9:48 am, "Richard Biener"  wrote:
> >
> >>
> >> The GNU Compiler Collection version 7.3 has been released.
> >>
> >> GCC 7.3 is a bug-fix release from the GCC 7 branch
> >> containing important fixes for regressions and serious bugs in
> >> GCC 7.2 with more than 99 bugs fixed since the previous release.
> >>
> >> This release includes code generation options to mitigate
> >> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.
> >>
> >> This release is available from the FTP servers listed at:
> >>
> >>   http://www.gnu.org/order/ftp.html
> >>
> >> Please do not contact me directly regarding questions or comments
> >> about this release.  Instead, use the resources available from
> >> http://gcc.gnu.org.
> >>
> >> As always, a vast number of people contributed to this GCC release
> >> -- far too many to thank them individually!
> >>
>

Re: Retpolines and CFI

[H.J. Lu]

On Thu, Jan 25, 2018 at 12:32 AM, Florian Weimer  wrote:
> On 01/22/2018 01:21 PM, Florian Weimer wrote:
>
>> There is a different issue with the think itself.
>>
>> __x86_indirect_thunk_rax:
>> .LFB2:
>>  .cfi_startproc
>>  call.LIND5
>> .LIND4:
>>  pause
>>  lfence
>>  jmp .LIND4
>> .LIND5:
>>  mov %rax, (%rsp)
>>  ret
>>  .cfi_endproc
>>
>> If a signal is delivered after the mov has executed, the unwinder will
>> eventually unwind through the signal frame and hit __x86_indirect_thunk_rax.
>> It does not treat it as a signal frame, so the return address of the stack
>> is decremented by one, in an attempt to obtain a program counter value which
>> is within the call instruction. However, in this scenario, the return
>> address is actually the start of the function, and subtracting one moves the
>> program counter out of the unwind region for that function.
>
>
> I think it is possible to fix the second case by hiding the the return
> address at the top of the stack, like this:
>
> __x86_indirect_thunk_rax:
> .LFB2:
> .cfi_startproc
> call.LIND5
> .LIND4:
> pause
> lfence
> jmp .LIND4
> .LIND5:
> .cfi_def_cfa_offset 16
> mov %rax, (%rsp)
> ret
> .cfi_endproc
>
> The unwinder should then use the other return address, from the caller of
> the thunk routine.

Can you open a GCC bug to track it?

Thanks.

-- 
H.J.

Re: Retpolines and CFI

[H.J. Lu]

On Mon, Jan 22, 2018 at 4:21 AM, Florian Weimer  wrote:
> I tried this:
>
> struct C {
>   virtual ~C();
>   virtual void f();
> };
>
> void
> f (C *p)
> {
>   p->f();
>   p->f();
> }
>
> with r256939 and -mindirect-branch=thunk -O2 on x86-64 GNU/Linux, and got
> this:
>
> _Z1fP1C:
> .LFB0:
> .cfi_startproc
> pushq   %rbx
> .cfi_def_cfa_offset 16
> .cfi_offset 3, -16
> movq(%rdi), %rax
> movq%rdi, %rbx
> jmp .LIND1
> .LIND0:
> pushq   16(%rax)
> jmp __x86_indirect_thunk
> .LIND1:
> call.LIND0
> movq(%rbx), %rax
> movq%rbx, %rdi
> popq%rbx
> .cfi_def_cfa_offset 8
> movq16(%rax), %rax
> jmp __x86_indirect_thunk_rax
> .cfi_endproc
>
> This doesn't look quite right.  x86-64 is supposed to have asynchronous
> unwind tables by default, but there is nothing that reflects the change in
> the (relative) frame address after .LIND0.  I think that region really has
> to be moved outside of the .cfi_startproc/.cfi_endproc bracket.

I'd like to remove __x86_indirect_thunk since it can't be made compatible
with CET:

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

That means  -mindirect-branch=thunk should imply  -mindirect-branch-register.
When -fno-plt is used with __x86_indirect_thunk_reg, linker can convert call
via GOT to direct branch if function is locally defined:

https://groups.google.com/forum/#!topic/x86-64-abi/eED5lzn3_Mg


H.J.

Re: Unstable build/host qsorts causing differing generated target code

[Franz Sirl]

Am 2018-01-12 um 19:45 schrieb Jeff Law:

On 01/12/2018 11:26 AM, Cory Fields wrote:

Quick disclaimer: I'm 100% new to GCC code and the dev process, so
there are bound to be some faulty assumptions below.

I recently worked on a build of gcc, x86_64-pc-linux-gnu ->
x86_64-pc-linux-musl. In order to boost my confidence in musl, I
decided that I'd like to ensure that 3 (and 4) stage bootstraps
succeed and compare equal.

I quickly ran into failed object comparisons at stage3. The issue, as
it turned out, was that musl's qsort algorithm differs significantly
from gcc's, though both (as far as I can tell) are perfectly legal.
The c spec allows for different results in the cast of unstable
arrays.

THe key here is the results can differ if the comparison function is not
stable.  That's inherent in the qsort algorithms.

But, if the comparison functions are fixed, then the implementation
differences between the qsorts won't matter.

Alexander Monokov has led an effort to identify cases where the
comparison functions do not provide a stable ordering and to fix them.
Some remain, but the majority have been addressed over the last year.
His work also includes a qsort checking implementation to try and spot
these problems as part of GCC's internal consistency checking mechanisms.

His work is on the development trunk and will show up in the upcoming
gcc-8 release.


Coincidentally I just stumbled over the differences in assembler code 
for a gcc-6 powerpc-eabi cross-compiler running on Linux, Cygwin64 and 
Solaris. With some help from IRC I found the following 3 trunk revisions
seem to be enough to greatly stabilize gcc-6 (and likely gcc-7) on these 
platforms:


r250395:
2017-07-20  Alexander Monakov  

 * lra-assigns.c (pseudo_compare_func): Fix comparison step based on
 non_spilled_static_chain_regno_p.

r253207:
2017-09-26  Martin Jambor  

 * tree-sra.c (compare_access_positions): Put integral types first,
 stabilize sorting of integral types, remove conditions putting
 non-full-precision integers last.
 (sort_and_splice_var_accesses): Disable scalarization if a
 non-integert would be represented by a non-full-precision integer.

r256682:
2018-01-14  Cory Fields  

 * tree-ssa-loop-im.c (sort_bbs_in_loop_postorder_cmp): Stabilize sort.
 * ira-color (allocno_hard_regs_compare): Likewise.


All applied cleanly to the current gcc-6-branch. I'm unsure if it's 
worth backporting them to the branches, but since I already prepared the 
list...


Franz

Re: GCC 7.3 Released

[Jimmy Shen]

unsubscribe

On Thu, Jan 25, 2018 at 4:41 AM, Richard Biener  wrote:

>
> The GNU Compiler Collection version 7.3 has been released.
>
> GCC 7.3 is a bug-fix release from the GCC 7 branch
> containing important fixes for regressions and serious bugs in
> GCC 7.2 with more than 99 bugs fixed since the previous release.
>
> This release includes code generation options to mitigate
> Spectre Variant 2 (CVE 2017-5715) for the x86 and powerpc targets.
>
> This release is available from the FTP servers listed at:
>
>   http://www.gnu.org/order/ftp.html
>
> Please do not contact me directly regarding questions or comments
> about this release.  Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release
> -- far too many to thank them individually!
>

[Bug tree-optimization/84050] New: missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Bug ID: 84050
   Summary: missing -Warray-bounds accessing a struct array member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses tnhe out-of-bounds array index in function farray() below but
fails to diagnose the same bug in fstatic_array.

$ cat t.c && gcc -O2 -S -Wall t.c
struct A { int a[3]; };

int fstatic_array (void)
{
  static struct A a = { { 1, 2, 3 } };

  return a.a[7];   // missing -Warray-bounds
}

int farray (void)
{
  extern struct A f (void);

  struct A a = f ();

  return a.a[7];   // -Warray-bounds (good)
}

t.c: In function ‘farray’:
t.c:16:13: warning: array subscript 7 is above array bounds of ‘int[3]’
[-Warray-bounds]
   return a.a[7];   // -Warray-bounds (good)
  ~~~^~~

[Bug middle-end/84048] New: [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 84048
   Summary: [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c   -O0
 -pie -fPIE  execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c
-fno-d
iagnostics-show-caret -fdiagnostics-color=never -O0 -pie -fPIE -ansi
-pedantic-e
rrors -lm -o ./run-ld.exe
PASS: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fPIE  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj
dir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g
nu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-li
nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.
libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/o
bjdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/
gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/
src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/g
cc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/
libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev
-gcc
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fPIE  execution test

Similar fail:
FAIL: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fpie  execution test

[Bug tree-optimization/84053] [5//6/7 Regression] missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.6.3
Summary|missing -Warray-bounds  |[5//6/7 Regression] missing
   |accessing a struct array|-Warray-bounds accessing a
   |member  |struct array member
  Known to fail||4.7.4, 4.8.4, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r178312 committed in GCC 4.7 as the change that introduced
this regression:

r178312 | rguenth | 2011-08-30 10:06:00 -0400 (Tue, 30 Aug 2011) | 30 lines

2011-08-30  Richard Guenther  

PR middle-end/48571

[PATCH] restore -Warray-bounds for string literals (PR 83776)

[Martin Sebor]

PR tree-optimization/83776 - [6/7/8 Regression] missing
-Warray-bounds indexing past the end of a string literal,
identified a not-so-recent improvement to constant propagation
as the reason for GCC no longer being able to detect out-of-
bounds accesses to string literals.  The root cause is that
the change caused accesses to strings to be transformed into
MEM_REFs that the -Warray-bounds checker isn't prepared to
handle.  A simple example is:

  int h (void)
  {
const char *p = "1234";
return p[16];   // missing -Warray-bounds
  }

To fix the regression the attached patch extends the array bounds
checker to handle the small subset of MEM_REF expressions that
refer to string literals but stops of short of doing more than
that.  There are outstanding gaps in the detection that the patch
intentionally doesn't handle.  They are either caused by other
regressions (PR 84047) or by other latent bugs/limitations, or
by limitations in the approach I took to try to keep the patch
simple.  I hope to address some of those in a follow-up patch
for GCC 9.

Martin
PR tree-optimization/83776 - [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

gcc/ChangeLog:

	PR tree-optimization/83776
	* tree-vrp.c (vrp_prop::check_mem_ref): New function.
	(check_array_bounds): Call it.

gcc/testsuite/ChangeLog:

	PR tree-optimization/83776
	* gcc.dg/Warray-bounds-27.c: New test.
	* gcc.dg/Warray-bounds-28.c: New test.
	* gcc.dg/Warray-bounds-29.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-27.c b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
new file mode 100644
index 000..ccc88cd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
@@ -0,0 +1,223 @@
+/* PR tree-optimization/83776: missing -Warray-bounds indexing past the end
+   of a string literal
+   Test to exercise detection of out-of-bounds indices into narrow string
+   literals.
+   { dg-do compile }
+   { dg-options "-O2 -Warray-bounds -ftrack-macro-expansion=0" } */
+
+#include "range.h"
+
+#define MAX DIFF_MAX
+#define MIN DIFF_MIN
+
+#define S1 "1"
+#define S3 "123"
+#define S7 "1234567"
+#define S8 "12345678"
+#define S9 "123456789"
+
+void sink (int, ...);
+
+#define T(expr)   sink (0, expr)
+
+
+void narrow_direct_cst (void)
+{
+  T (S1[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" "" { xfail *-*-* } } */
+  T (S1[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T (S1[0]);
+  T (S1[1]);
+  T (S1[2]);  /* { dg-warning "array subscript 2 is above array bounds of .char\\\[2]" } */
+  T (S1[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T ([MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" } */
+  T ([-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T ([0]);
+  T ([2]);
+  T ([3]); /* { dg-warning "array subscript 3 is above array bounds of .char\\\[2]" } */
+  T ([MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T (S9[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" "" { xfail *-*-* } } */
+  T (S9[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T (S9[9]);
+  T (S9[10]); /* { dg-warning "array subscript 10 is above array bounds of .char\\\[10]" } */
+  T (S9[11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T (S9[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+
+  T ([MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" } */
+  T ([-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T ([9]);
+  T ([10]);
+  T ([11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T ([MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+}
+
+void narrow_ptr_deref_cst (void)
+{
+  const char *p = S8 + 9;
+
+  T (*(p + MIN)); /* { dg-warning "array subscript -\[0-9\]+ is outside array bounds of .char\\\[9]." } */
+  T (*(p - 10));  /* { dg-warning "array subscript -1 is outside array bounds of .char\\\[9]." } */
+  T (*(p - 9));
+  T (*(p - 1));
+  T (*p); /* { dg-warning "array subscript 9 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 1));   /* { dg-warning "array subscript 10 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 2));   /* { dg-warning "array subscript 11 is outside array bounds of .char\\\[9]." } */
+}
+
+void 

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02144.html

[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83776
Summary|missing -Warray-bounds  |[6/7/8 Regression] missing
   |accessing a struct array|-Warray-bounds accessing a
   |member  |struct array member
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Same as in bug 83776, bisection points to r164688 committed into GCC 4.6 as the
root cause of the regression:

r164688 | hubicka | 2010-09-28 12:28:39 -0400 (Tue, 28 Sep 2010) | 5 lines

* tree-ssa-ccp.c (fold_ctor_reference): New function.
(fold_const_aggregate_ref): Use it.
* fold-const.c (canonicalize_constructor_val): Check that we don't fold
into external static.

[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
Summary|missing -Warray-bounds on   |[6/7/8 Regression] missing
   |an out-of-bounds access via |-Warray-bounds on an
   |an array pointer|out-of-bounds access via an
   ||array pointer
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to either r158060 or r158060, both committed into GCC 4.6. 
The latter seems like the more likely culprit:

2010-04-07  Richard Guenther  

PR tree-optimization/43270
* tree-vrp.c (check_array_ref): Fix flexible array member
detection.
* tree-ssa-sccvn.h (fully_constant_vn_reference_p): Declare.
* tree-ssa-pre.c (phi_translate_1): Adjust.
(fully_constant_expression): Split out vn_reference handling to ...
* tree-ssa-sccvn.c (fully_constant_vn_reference_p): ... here.
Fold reads from constant strings.
(vn_reference_lookup): Handle fully constant references.
(vn_reference_lookup_pieces): Likewise.
* Makefile.in (expmed.o-warn): Add -Wno-error.

[Bug tree-optimization/84057] [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with Richi's r253149.

[Bug testsuite/84049] New: libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a long time to run

[hjl.tools at gmail dot com]

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

Bug ID: 84049
   Summary: libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a
long time to run
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On a machine with 100+ cores, libgomp.c++/for-[56].C and
libgomp.c/for-[56].c take a long time to run:

   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
127330 hjl   20   0 56.831g  34568   2400 R  1169  0.1  48:22.56 for-5.exe  
273104 hjl   20   0 1158488  13084   2280 S  1067  0.0  13:28.57 for-5.exe 

Should these tests adjust number of threads and loop counts based on
number of cores?

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #8)
>> This kernel AT_PLATFORM name should strip the '+' off:
>>   .platform = "power7+", -> "power7"
>
> We probably should have a -mcpu=power7+, we have power5+ as well etc.

Well, we have a -mcpu=power5+ because power5+ added a few new instructions over
and above what power5 has.  That is not the case with power7+.  It implements
the exact same instructions that power7 does, so power7+ doesn't really buy us
anything.


>> These kernel AT_PLATFORM names should strip their prefix and suffix off:
>>   .platform = "ppc440gp", -> "440"
>>   .platform = "ppc-cell-be", -> "cell"
>> 
>> These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as
>> well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>>   .platform = "ppc405", -> "405" | "405fp"
>>   .platform = "ppc440", -> "440" | "440fp"
>> 
>> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change
>> 470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>>   .platform = "ppc470", -> "476" | "476fp"
> 
> We could also decide not to support those for "native" (except cell?),
> they all have problems and no one will try to build on those anyway.
> I hope.

Well, it was easy enough to add support for them in case some did try in the
future.  Up to you though if you want to leave them out.


> e500mc64 is a different core AFAIK, one that was never shipped anyway.

Ok, so the current patch and the updated one I'm working on don't support it,
so I'll leave it that way.


> Could use 970 for pa6t, if we care.

Its up to you if you want me to map that to 970.  Let me know what you want me
to do.

[Bug c++/83911] [6/7/8 Regression] ICE with target attribute on constructor in gimplify_expr at gimplify.c:11321

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-01-26
 CC||msebor at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE with target attribute   |[6/7/8 Regression] ICE with
   |on constructor in   |target attribute on
   |gimplify_expr at|constructor in
   |gimplify.c:11321|gimplify_expr at
   ||gimplify.c:11321
  Known to fail||5.4.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 5, 6, 7, and 8.  Bisection points to Richard's r210692
committed in gcc 4.10 (5.0).

GCC 8 abends with the following output:

gcc -O2 -S -Wall -Wextra pr83911.C
pr83911.C: In constructor ‘SimdFloat::SimdFloat(float)’:
pr83911.C:5:21: warning: unused parameter ‘x’ [-Wunused-parameter]
 SimdFloat(float x) {}
   ~~^
pr83911.C: In constructor ‘SimdFloat::SimdFloat(float)’:
pr83911.C:8:21: warning: unused parameter ‘x’ [-Wunused-parameter]
 SimdFloat(float x) {}
   ~~^
pr83911.C: In function ‘SimdFloat foo()’:
pr83911.C:13:12: internal compiler error: in
ix86_get_function_versions_dispatcher, at config/i386/i386.c:32432
 return 1;
^
0x13f2168 ix86_get_function_versions_dispatcher
/ssd/src/gcc/svn/gcc/config/i386/i386.c:32432
0x7e5a3c get_function_version_dispatcher(tree_node*)
/ssd/src/gcc/svn/gcc/cp/call.c:7479
0x7e7b1c build_over_call
/ssd/src/gcc/svn/gcc/cp/call.c:8191
0x7e3af0 convert_like_real
/ssd/src/gcc/svn/gcc/cp/call.c:6783
0x7e42c6 convert_like_real
/ssd/src/gcc/svn/gcc/cp/call.c:6909
0x7ee318 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/call.c:10574
0x9b6b5c convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/typeck.c:8982
0x9b7bd4 check_return_expr(tree_node*, bool*)
/ssd/src/gcc/svn/gcc/cp/typeck.c:9372
0x97004f finish_return_stmt(tree_node*)
/ssd/src/gcc/svn/gcc/cp/semantics.c:890
0x8def99 cp_parser_jump_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:12368
0x8dbf5c cp_parser_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:10773
0x8dcbe1 cp_parser_statement_seq_opt
/ssd/src/gcc/svn/gcc/cp/parser.c:11218
0x8dcad7 cp_parser_compound_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:11172
0x8ee1dd cp_parser_function_body
/ssd/src/gcc/svn/gcc/cp/parser.c:21712
0x8ee2e8 cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/svn/gcc/cp/parser.c:21747
0x8f6245 cp_parser_function_definition_after_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:26648
0x8f606b cp_parser_function_definition_from_specifiers_and_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:26565
0x8ea718 cp_parser_init_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:19436
0x8e02b3 cp_parser_simple_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:13009
0x8dfe48 cp_parser_block_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:12827
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
tmp$

Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

[Kirill Yukhin]

Hello Julia,
On 24 Jan 14:00, Koval, Julia wrote:
> Hi,
> Fixed it. Ok for trunk?
> 
> gcc/
>   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
>   _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask,
>   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
>   _mm_mask_bitshuffle_epi64_mask): Fix type.
>   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
>   USI_FTYPE_V4DI_V4DI_USI): Remove.
>   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
>   __builtin_ia32_vpshufbitqmb256_mask,
>   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
>   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
>   * config/i386/sse.md (VI1_AVX512VLBW): Change types.
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f 
> -mavx512bw.
>   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
>   * gcc.target/i386/i386.exp: Fix types.
Your patch is OK for trunk. I've checked it in.

--
Thanks, K
> 
> Thanks,
> Julia
> 
> > -Original Message-
> > From: Kirill Yukhin [mailto:kirill.yuk...@gmail.com]
> > Sent: Saturday, January 20, 2018 11:49 AM
> > To: Koval, Julia 
> > Cc: 'Jakub Jelinek' ; 'Uros Bizjak' ;
> > 'GCC Patches' 
> > Subject: Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} 
> > issues (PR
> > target/83488)
> > 
> > Hello Julia,
> > On 12 Jan 08:55, Koval, Julia wrote:
> > > Changelog
> > >
> > > gcc/
> > >   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
> > >   _mm512_mask_bitshuffle_epi64_mask,
> > _mm256_bitshuffle_epi64_mask,
> > >   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
> > >   _mm_mask_bitshuffle_epi64_mask): Fix type.
> > >   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
> > >   USI_FTYPE_V4DI_V4DI_USI): Remove.
> > >   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
> > >   __builtin_ia32_vpshufbitqmb256_mask,
> > >   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
> > >   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
> > >   * config/i386/sse.md (VI48_AVX512VLBW): Change types.
> > >
> > > gcc/testsuite/
> > >   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f -
> > mavx512bw.
> > >   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
> > >   * gcc.target/i386/i386.exp: Fix types.
> > 
> >  (define_mode_iterator VI48_AVX512VLBW
> > -  [(V8DI "TARGET_AVX512BW") (V4DI  "TARGET_AVX512VL")
> > -   (V2DI  "TARGET_AVX512VL")])
> > +  [(V64QI "TARGET_AVX512BW") (V32QI  "TARGET_AVX512VL")
> > +   (V16QI  "TARGET_AVX512VL")])
> > I'd call this iterator VI1_AVX512VLBW.
> > 
> > --
> > Thanks, K
> 

[Bug tree-optimization/84057] New: [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[asolokha at gmx dot com]

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

Bug ID: 84057
   Summary: [8 Regression] ICE: Segmentation fault (in
can_remove_branch_p)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180121 snapshot (r256935) ICEs when compiling the following
snippet w/ -O2 -fgraphite -funroll-loops -fno-tree-ccp -fno-tree-dce:

int ue;

void
fr (int ct)
{
  int au = 0;
  int *ra = 

  while (au < 1)
{
  au -= 0x7878788;
  if (au != ct && ue != 0)
{
  while (au < 1)
{
}

 fc:
  while (ct != 0)
{
}
}
}

  for (au = 0; au < 2; ++au)
if (ct != 0)
  goto fc;
}

% gcc-8.0.0-alpha20180121 -O2 -fgraphite -funroll-loops -fno-tree-ccp
-fno-tree-dce -c imaaek0k.c
during GIMPLE pass: cunroll
imaaek0k.c: In function 'fr':
imaaek0k.c:4:1: internal compiler error: Segmentation fault
 fr (int ct)
 ^~
0xc969ef crash_signal
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/toplev.c:325
0x8829e3 can_remove_branch_p(edge_def const*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfghooks.c:389
0x891683 remove_path(edge_def*, bool*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfgloopmanip.c:315
0xdd4b03 unloop_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:668
0xdd7f01 unloop_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1450
0xdd7f01 tree_unroll_loops_completely
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1450
0xdd83b4 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1599

[Bug libstdc++/84056] map insertes a pair when check a value

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Where is the bug? Did you read the documentation for operator[]?

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
Did you upgrade binutils?  We had the same failures on SPARC, see PR ld/22727.

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
r256935 was okay.

[Bug tree-optimization/84053] New: missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Bug ID: 84053
   Summary: missing -Warray-bounds accessing a struct array member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to version 4.7, GCC would diagnose out-of-bounds accesses to local arrays
across inlined function boundaries.  The test case below shows that these
invalid accesses are no longer diagnosed.

int f (int i)
{
  int a[] = { 1, 2 };

  if (i < 3)
i = 3;

  return a[i];   // -Warray-bounds (good)
}

int g (const int *p, int i)
{
  return p[i];
}

int h (int i)
{
  int a[] = { 2, 3 };

  if (i < 3)
i = 3;

  return g (a, i);   // missing -Warray-bounds
}
t.c: In function ‘f’:
t.c:8:11: warning: array subscript 3 is above array bounds of ‘int[2]’
[-Warray-bounds]
   return a[i];   // -Warray-bounds (good)
  ~^~~

[Bug c++/84055] New: warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

Bug ID: 84055
   Summary: warning: ignoring attributes on template argument
‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kip at thevertigo dot com
  Target Milestone: ---

Created attachment 43248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43248=edit
Minimal example to reproduce the problem.

The following minimal requires an OpenCL C++ installation. Manually typedef'ing
cl_uint makes the problem go away, but for some reason using the OpenCL
header's version, I see the following error:

$ g++ minimal.cpp -o minimal `pkg-config --cflags --libs OpenCL`
minimal.cpp:13:28: warning: ignoring attributes on template argument ‘cl_uint
{aka unsigned int}’ [-Wignored-attributes]
 std::vector m_BreakMe;
^

$ g++ --version
g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[dtrebbien at gmail dot com]

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

--- Comment #13 from Daniel Trebbien  ---
(In reply to Jonathan Wakely from comment #9)
> Also, if boost::optional had a noexcept move constructor it would work fine.
> This is a boost bug.
> 
> The part of the patch addressing PR 83982 seems right.

I have split out the part of the patch addressing PR 83982 and have attached
the reduced patch there.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #39 from Mike Lothian  ---
I can confirm it fixes things for me too. 

Is that the final patch in Comment 36? If so I'll try and get the Gentoo devs
to include it in the GCC ebuilds

Will this be added to GCC 8.1 and 7.4?

Thanks again, this bug has been plaguing me for the last 8 months

[Bug tree-optimization/84051] New: missing -Warray-bounds on an out-of-bounds access via an array pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 84051
   Summary: missing -Warray-bounds on an out-of-bounds access via
an array pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC used to diagnose out-of-bounds accesses made by pointers to arrays of a
fixed bound.  The test case below shows it can no longer do that.   Clang and
ICC bot detect this bug.

typedef int A4[4];

int f (A4 *p)
{
  return (*p)[7];
}

[Bug testsuite/83881] FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
  Component|c   |testsuite
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
With the top of the trunk the test passes for me with an hppa-unknown-linux-gnu
cross-compiler (both C and C++) with the following results:

Running /ssd/src/gcc/git/gcc/testsuite/g++.dg/dg.exp ...

=== g++ Summary ===

# of expected passes465
# of expected failures  18
/ssd/build/hppa-unknown-linux-gnu/gcc-git/gcc/xg++  version 8.0.1 20180125
(experimental) (GCC) 

Can you please try again and update the bug with your latest results?

Re: [PATCH, wwwdocs] Update GCC 8 release notes for NDS32 port

[Chung-Ju Wu]

Gerald Pfeifer on 2018/1/23 22:39 wrote:

On Tue, 23 Jan 2018, Chung-Ju Wu wrote:

+New command-line options -mext-perf -mext-perf2 -mext-string


Can you write this as

   "...-mext-perf, -mext-perf2, and
   -mext-string..."

please?

Approved with that change.



Thank you for the review. :)

I made the change and committed it as revision 1.33 of 
htdosc/gcc-8/changes.html.


Best regards,
jasonwucj



Gerald

[Bug c/84054] New: seems -fno-bounds-checking no longer supported

[sbansal at ciena dot com]

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

Bug ID: 84054
   Summary: seems -fno-bounds-checking no longer supported
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

Hi,

We are migrating from 3.4.5 to 4.8.1 compiler and some of our code is using 
"-fno-bounds-checking" option to avoid doing bounds check on a special piece of
code.

This was working good in 3.4.5 but it seems not supported on 4.8.1 giving
compilation error.

Please suggest any possible resolution.

Regards,
Sumit

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #2 from Kip Warner  ---
Created attachment 43250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43250=edit
Assembly listing of minimal.cpp

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #1 from Kip Warner  ---
Created attachment 43249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43249=edit
Pre-processed intermediate form of minimal.cpp

[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met

[dtrebbien at gmail dot com]

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

--- Comment #2 from Daniel Trebbien  ---
Created attachment 43247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43247=edit
Patch for PR 83982 alone

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/25/18 3:56 PM, Peter Bergner wrote:
> Ok, I'll move the table to driver-rs6000.c and I'll resubmit.

Ok, here is a separate translation table like you wanted.  I still use the
RS6000_CPU table to hold entire list of canonical cpu names, the new
translation table in driver-rs6000.c only contains cpus whose AT_PLATFORM
names do not match their GCC canonical names.  I also added the pa6t to
970 translation you mentioned in the bugzilla.  If you want me to drop
that, that's easy enough to do.

I realize I also failed to mention in the first submission, that I have
added caching of the elf_plaform() result, so we don't have to mount and
scan /proc/self/auxv multiple times.

Is this better?  I did the same unit testing by forcing unknown names
and names that need translation and I've verified it works.  Bootstrap
and regtesting is still running though.

Peter

PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Index: gcc/config/rs6000/driver-rs6000.c
===
--- gcc/config/rs6000/driver-rs6000.c   (revision 256364)
+++ gcc/config/rs6000/driver-rs6000.c   (working copy)
@@ -23,6 +23,7 @@
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "diagnostic.h"
 #include 
 
 #ifdef _AIX
@@ -38,6 +39,44 @@
 # include 
 #endif
 
+#ifdef __linux__
+/* Canonical GCC cpu name table.  */
+static const char *rs6000_supported_cpu_names[] =
+{
+#define RS6000_CPU(NAME, CPU, FLAGS) NAME,
+#include "rs6000-cpus.def"
+#undef RS6000_CPU
+};
+
+/* This table holds a list of cpus where their Linux AT_PLATFORM name differs
+   from their GCC canonical name.  The first column in a row contains the GCC
+   canonical cpu name and the other columns in that row contain AT_PLATFORM
+   names that should be mapped to the canonical name.  */
+
+static const char *linux_cpu_translation_table[][4] = {
+  { "403", "ppc403", NULL },
+  { "405", "ppc405", NULL },
+  { "440", "ppc440", "ppc440gp", NULL },
+  { "476", "ppc470", NULL },
+  { "601", "ppc601", NULL },
+  { "603", "ppc603", NULL },
+  { "604", "ppc604", NULL },
+  { "7400", "ppc7400", NULL },
+  { "7450", "ppc7450", NULL },
+  { "750", "ppc750", NULL },
+  { "823", "ppc823", NULL },
+  { "8540", "ppc8540", NULL },
+  { "8548", "ppc8548", NULL },
+  { "970", "ppc970", "pa6t", NULL },
+  { "cell", "ppc-cell-be", NULL },
+  { "e500mc", "ppce500mc", NULL },
+  { "e5500", "ppce5500", NULL },
+  { "e6500", "ppce6500", NULL },
+  { "power7", "power7+", NULL },
+  { NULL } /* End of table sentinel.  */
+};
+#endif
+
 const char *host_detect_local_cpu (int argc, const char **argv);
 
 #if GCC_VERSION >= 0
@@ -158,15 +197,19 @@
 
 #ifdef __linux__
 
-/* Returns AT_PLATFORM if present, otherwise generic PowerPC.  */
+/* Returns the canonical AT_PLATFORM if present, otherwise NULL.  */
 
 static const char *
 elf_platform (void)
 {
-  int fd;
+  static const char *cpu = NULL;
 
-  fd = open ("/proc/self/auxv", O_RDONLY);
+  /* Use the cached AT_PLATFORM cpu name if we've already determined it.  */
+  if (cpu != NULL)
+return cpu;
 
+  int fd = open ("/proc/self/auxv", O_RDONLY);
+
   if (fd != -1)
 {
   char buf[1024];
@@ -179,15 +222,60 @@
   if (n > 0)
{
  for (av = (ElfW(auxv_t) *) buf; av->a_type != AT_NULL; ++av)
-   switch (av->a_type)
+   if (av->a_type == AT_PLATFORM)
  {
- case AT_PLATFORM:
-   return (const char *) av->a_un.a_val;
-
- default:
+   cpu = (const char *) av->a_un.a_val;
break;
  }
}
+
+  /* Verify that CPU is either a valid -mcpu= option name, or is a
+valid alternative name.  If it is a valid alternative name, then use
+the canonical name.  */
+  if (cpu != NULL)
+   {
+ size_t i, j, len = 0;
+ char *s, *p;
+
+ /* Check if AT_PLATFORM is a GCC canonical cpu name.  */
+ for (i = 0; i < ARRAY_SIZE (rs6000_supported_cpu_names); i++)
+   {
+ if (!strcmp (cpu, rs6000_supported_cpu_names[i]))
+   return cpu;
+ len += strlen (rs6000_supported_cpu_names[i]) + 1;
+   }
+
+ /* Check if AT_PLATFORM can be translated to a canonical cpu name.  */
+ for (i = 0; linux_cpu_translation_table[i][0] != NULL; i++)
+   {
+ const char *canonical = linux_cpu_translation_table[i][0];
+ for (j = 1; linux_cpu_translation_table[i][j] != NULL; j++)
+   if (!strcmp (cpu, linux_cpu_translation_table[i][j]))
+ {
+   cpu = canonical;
+

[Bug c/84052] New: Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[caoj.fnst at cn dot fujitsu.com]

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

Bug ID: 84052
   Summary: Using Randomizing structure layout plugin in linux
kernel compilation doesn't generate proper debuginfo
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caoj.fnst at cn dot fujitsu.com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

Recently, linux kernel introduced a security feature[*] to randomize the layout
of some crucial structures during compilation.

[*]https://lwn.net/Articles/722293/

FYI: the plugin related source files locate:

scripts/gcc-plugins/Makefile
scripts/gcc-plugins/gen-random-seed.sh
scripts/gcc-plugins/randomize_layout_plugin.c

of linux kernel source.

After enable/disable this feature, I use "gdb vmlinux" to examine the
debuginfo, and find that the output of "ptype struct xxx"(xxx is the randomized
structure like uts_namespace) in both condition are identical, which feels like
a bug to me. And this result would affect other utility like crash tool.

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Plugins issues like this should reported to the plugin author and not to gcc.

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[caoj.fnst at cn dot fujitsu.com]

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

--- Comment #2 from pino  ---
(In reply to Andrew Pinski from comment #1)
> Plugins issues like this should reported to the plugin author and not to gcc.

I don't know gcc internals, from my very limited understanding about gcc & that
plugin, the plugin just does one optimization on the intermediate language:
redefine a structure with randomized order and set it back to its context. So
the backend would see a structure different from its original definition in
source file and could generate the proper debuginfo.   So I feels this issue
may be more close to gcc.

I was not sure where should I report this problem. I was hoping gcc guys could
take a look at that plugin, I feel it is not hard for you gcc expert to read,
even I can tell the basic logic inside.

[Bug c++/84056] map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

--- Comment #1 from Alper Ce  ---
output:

a => 1
b => 2
Map after if condition(a new pair ['c':0] inserted in map!):
a => 1
b => 2
c => 0

[Bug c++/84056] New: map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

Bug ID: 84056
   Summary: map insertes a pair when check a value
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alper.ccc at yandex dot com
  Target Milestone: ---

In this example there is a map with 2 pairs ( a:1 and b:2)
but after checking the unavailable vale in if statement (value of c) it inserts
new pair (c:0) to the map:


#include 
#include 
using namespace std;
int main ()
{
  map my_map;
  my_map['a'] = 1;
  my_map['b'] = 2;

  for (map::iterator it=my_map.begin(); it!=my_map.end(); ++it)
cout << it->first << " => " << it->second << endl;

  if(my_map['c'] == 100)
  cout<<"my_map['c'] = 100"<::iterator it=my_map.begin(); it!=my_map.end(); ++it)
cout << it->first << " => " << it->second << endl;

  return 0;
}

[Bug tree-optimization/83177] [7/8 Regression] ICE with -mmpx -fcheck-pointer-bounds + __builtin___bnd_narrow_ptr_bounds + _setjmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #6 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug middle-end/81889] [7 Regression] bogus warnings with -Wmaybe-uninitialized -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #14 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c/82186] [7/8 Regression] ICE (segfault), VLA type with inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/81997] [7/8 Regression] segfault while instantiating constrained function template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #5 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug go/78980] runtime/internal/atomic FAILs on 32-bit SPARC

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #2 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82461] [7/8 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #6 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug tree-optimization/81373] [7 Regression] Graphite ICE in ssa_default_def at gcc/tree-dfa.c:305

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/81061] [7 Regression] ICE modifying read-only variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #5 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/81013] [7 Regression] ICE with invalid union in class hierarchy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #5 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82468] [7/8 Regression] ICE with deduction guide template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #2 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug tree-optimization/71625] missing strlen optimization on different array initialization style

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #14 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/78633] [7/8 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #22 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/81456] [7/8 Regression] x86-64 optimizer makes wrong decision when optimizing for size

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #4 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug tree-optimization/81661] [7/8 Regression] ICE in gimplify_modify_expr, at gimplify.c:5638

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug rtl-optimization/70902] GCC freezes while compiling for 'skylake-avx512' target

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug libstdc++/83830] has_unique_object_representations_v is missing

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #4 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82764] [7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/82807] [7/8 Regression] SPEC CPU2006 473.astar ~6% performance deviation in between 6.3 and 7.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #6 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug rtl-optimization/83317] [7 Regression] ICE in lra_eliminate_reg_if_possible compiling Python with -mfpmath=sse on x86 Linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #6 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/80763] [7 Regression] -O3 causes error: inline clone in same comdat group list

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #15 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug middle-end/84029] Partially inline strcmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-25
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
If we know the length of either argument and the other argument is properly
aligned we can do a 2, 4 or 8 byte compare upfront.  Not sure how often that
happens (esp. with regard to knowing alignment to make sure there's no
page fault).

Note this optimization has a code-size impact and thus should be done only
for hot code regions, eventually based on a value-profile?

[Bug middle-end/84034] New: incomplete warning message with dos line endings

[bernd.edlinger at hotmail dot de]

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

Bug ID: 84034
   Summary: incomplete warning message with dos line endings
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

cat test.c
extern int a,b,c,d,e,f;
int test()
{
  if ((!a && b > c) ||
  (d && b > e) &&
  f)
return 1;
  return 0; 
}

gcc -Wall -c test.c
test.c: In function ‘test’:
test.c:5:20: warning: suggest parentheses around ‘&&’ within ‘||’
[-Wparentheses]

   ~^~~
   f)
   ~ 

NOTE: test.c is with DOS line endings
open it in vi, say ":set ff=dos" save.

The warning prints both lines correctly with ff=unix.

[Bug middle-end/46555] [6/7/8 Regression] PHI RTL expansion leads to CSiBE regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug tree-optimization/79621] Missed path isolation opportunity

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82722] [7 Regression] ICE in finish_member_declaration, at cp/semantics.c:2984

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #5 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c/32643] [6/7/8 Regression] Wrong error message with unsigned char a = uchar&512

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #25 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #17 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/71555] ICE: compilation "never" finishes with -O -mtune=sandybridge -mavx512bw

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug ada/81961] [7/8 regression] an imported unsized C array in the auto-translated binding raises Storage_Error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c/80778] [7/8 Regression] gcc.dg/auto-type-1.c ICEs with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/71169] [7/8 Regression] ICE on invalid C++ code in pop_nested_class (cp/class.c:7785)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/82804] [7/8 Regression] SPEC CPU2006 470.lbm ~5% performance deviation with r237185

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug bootstrap/80867] gnat bootstrap broken on powerpc64le-linux-gnu with -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug middle-end/83945] [7 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #8 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82565] [7/8 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #2 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/71450] [6 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_base, at cp/search

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug target/82981] [7 Regression] unnecessary __multi3 call for mips64r6 linux kernel

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #16 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #27 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug tree-optimization/33562] [6 Regression] aggregate DSE disabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #34 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug libgomp/70805] libgomp.c/for-5.c and libgomp.c++/for-13.C FAIL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #2 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug fortran/83118] [7/8 Regression] Bad intrinsic assignment of class(*) array component of derived type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

[Bug c++/82331] [7 Regression] ICE specializing template for function pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #7 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.