[Bug other/80437] large decimal numbers in diagnostics are hard to read

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to David Malcolm from comment #3)
> Maybe could also make creative use of underscores in large hex values to
> make things easier on the eye e.g.:
> 
> bug.c:11:5: warning: 'memset': specified size 18446744073709551611 (aka
> 0x___fffb, 1<<64 - 5, SOME_CONST) exceeds maximum object size
> 9223372036854775807  (aka 0x7fff___, 1<<63 - 1, SOME_OTHER_CONST)

The underscores would make copying and pasting the values more difficult
though...

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> Created attachment 41887 [details]
> compiler output
> 
> (In reply to Mike Hommey from comment #4)
> > Created attachment 29800 [details]
> > nsDiskCacheMap.gcda
> > 
> > I can reproduce with the preprocessed file and this gcda with gcc 4.7.2-5
> > from debian unstable with the following command line:
> > 
> > g++ -o nsDiskCacheMap.o -c -fPIC  -Wall -Wno-invalid-offsetof
> > -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -std=gnu++0x
> > -pipe -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3
> > -fno-omit-frame-pointer  -Werror -Wno-error=uninitialized
> > -Wno-error=deprecated-declarations nsDiskCacheMap.ii
> 
> I get lots of other errors when compiling the preprocessed file, but none
> from -Warray-bounds. Attaching my output as a separate file.

Also closing since I couldn't reproduce the bug.

[Bug c++/56698] "array subscript is above array bounds" triggered on code that doesn't have that problem

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
Created attachment 41887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41887=edit
compiler output

(In reply to Mike Hommey from comment #4)
> Created attachment 29800 [details]
> nsDiskCacheMap.gcda
> 
> I can reproduce with the preprocessed file and this gcda with gcc 4.7.2-5
> from debian unstable with the following command line:
> 
> g++ -o nsDiskCacheMap.o -c -fPIC  -Wall -Wno-invalid-offsetof
> -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -std=gnu++0x
> -pipe -g -fprofile-use -fprofile-correction -Wcoverage-mismatch -O3
> -fno-omit-frame-pointer  -Werror -Wno-error=uninitialized
> -Wno-error=deprecated-declarations nsDiskCacheMap.ii

I get lots of other errors when compiling the preprocessed file, but none from
-Warray-bounds. Attaching my output as a separate file.

[Bug middle-end/55808] excessive memory usage from gcc 4.7.2 when compiling mame source code

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #7 from Eric Gallager  ---
(In reply to Patrick from comment #6)
> Created attachment 29071 [details]
> the preprocessed source when gcc fails to compile mame
> 
> here is the preprocessed source when gcc 4.7.2 fails to compile mame,
> 
> output :
> 
> gcc: erreur interne du compilateur: Processus arrêté (program cc1plus)
> Veuillez soumettre un rapport complet d'anomalies,
> avec le source pré-traité si nécessaire.
> Consultez  pour plus de détail.
> make: *** [obj/sdl/emu/cpu/tms57002/tms57002.o] Erreur 4
> 
> CFLAGS :
> -save-temps -pipe -O3 -Werror -fno-strict-aliasing -Wall -Wcast-align
> -Wundef -Wformat-security -Wwrite-strings -Wno-sign-compare -Wno-conversion
> -Wno-narrowing -Wno-attributes -D_GNU_SOURCE=1 -D_REENTRANT -pthread
> -pthread -Isrc/mame -Iobj/sdl/mame/layout -Isrc/emu -Iobj/sdl/emu
> -Iobj/sdl/emu/layout -Isrc/lib/util -Isrc/lib -Isrc/osd -Isrc/osd/sdl
> -Isrc/lib/expat -Isrc/lib/zlib -Isrc/lib/util -Isrc/lib/libjpeg -Isrc/debug
> -include src/osd/sdl/sdlprefix.h -I/usr/include -I/usr/include/gtk-2.0
> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
> -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/harfbuzz
> -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/X11/include
> -I/usr/X11R6/include -I/usr/openwin/include -x c++ -std=gnu++98
> -Woverloaded-virtual
> 
> the problem seems to be related to low memory ( 1 Gb ram, 512 Mb swap )

Seems to compile quickly enough for me

[Bug c/81566] invalid attribute aligned accepted on functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|attribute aligned with no   |invalid attribute aligned
   |argument accepted on|accepted on functions
   |functions   |

--- Comment #1 from Martin Sebor  ---
Changing the Summary to make it clearer that there are two problems here.

[Bug target/53362] gcc 4.7 generates invalid code with -O3 and -mtune=bdver1

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #6 from Eric Gallager  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to comment #4)
> 
> > Is this enough for you to work with?
> 
> No, please follow the instructions in [1].  Also, since this is a runtime
> problem, we will need (preferrably minimized) source that can be compiled to
> an executable that fails.
> 
> [1] http://gcc.gnu.org/bugs/#report

Reporter never provided the source requested; closing

[Bug lto/53312] crash in materialize_cgraph (invalid free)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to philippe.waroquiers from comment #2)
> (In reply to comment #1)
> > This looks like PR53214 - unable to verify without a testcase though.  Thus,
> > please try a recent GCC 4.7 snapshot instead.  You can also simply grep for
> > optimization attribute usage in your sources.
> 
> It looks effectively the same (or least similar).
> In my case, the offending line was:
> # pragma GCC optimize("-fomit-frame-pointer")
> 
> When removing this line, the crash disappeared.
> I suppose this is the same bug as PR53214 (even if this bug
> was with attribute rather than pragma).
> 
> Thanks for the help

And that one was fixed, so I guess this is fixed too then.

[Bug lto/52322] lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:148

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> The tmp files are useless - we need preprocessed source instead.

Reporter never provided the preprocessed source requested; closing for being
stuck in WAITING for so long with no response.

[Bug target/52811] -O3 flag makes xorg-server-1.11.4 compile fail on amd64

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Eric Gallager  ---
(In reply to goeland86 from comment #2)
> Apologies. I will upload the proper files as soon as possible - at the
> moment I have gentoo installing the whole system having fixed the bug. I
> will re-create the conditions tomorrow and upload the required data then. I
> was told to report this bug to gcc, and have been a bit hasty.

Since you still haven't done this after 5 years, I'm going to assume things
worked out for you and close this bug. Feel free to reopen if you do ever
upload the files.

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #13)
> Previous discussions in this bug suggest it was specific to 32-bit 
> HOST_WIDE_INT.  HOST_WIDE_INT is now always 64-bit.

Closing as FIXED then

[Bug c/81656] incompatible _Alignas silently accepted

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
To be clear: that requirement is not a constraint, so no diagnostic is 
required.  Diagnosis may make sense for _Alignas, but I don't think 
different choices of __attribute__ ((aligned)) should be diagnosed, as a 
matter of compatibility with existing code.

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Indeed, it's purely the *internal* LTGT_EXPR and LTGT RTL for which the 
semantics are unclear; the semantics of the built-in function are 
unambiguous (exception only for signaling NaNs).

[Bug tree-optimization/81038] [8 regression] test case g++.dg/vect/slp-pr56812.cc fails starting with r248678

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||sje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Steve Ellcey  ---
Looking at the slp dump file on aarch64 where this also fails I see these
messages:

slp-pr56812.cc:18:1: note: === vect_analyze_data_refs ===
slp-pr56812.cc:18:1: note: not vectorized: no vectype for stmt: MEM[(float
*)thi
s_4(D)] = vect_cst__10;
 scalar_type: vector(4) float
slp-pr56812.cc:18:1: note: not vectorized: no vectype for stmt: MEM[(float
*)vec
tp_this.5_6] = vect_cst__10;
 scalar_type: vector(4) float
slp-pr56812.cc:18:1: note: === vect_analyze_data_ref_accesses ===
slp-pr56812.cc:18:1: note: not vectorized: no grouped stores in basic block.

[Bug target/81641] Assemble failure with named address spaces and -masm=intel

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Aug  1 22:06:11 2017
New Revision: 250801

URL: https://gcc.gnu.org/viewcvs?rev=250801=gcc=rev
Log:
PR target/81641
* config/i386/i386.c (ix86_print_operand_address_as): For -masm=intel
print "ds:" only for immediates in generic address space.

testsuite/ChangeLog:

PR target/81641
* gcc.target/i386/pr81641.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81641.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/i386.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4

[fredrik.hederstie...@securitas-direct.com]

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

Fredrik Hederstierna  changed:

   What|Removed |Added

 CC||fredrik.hederstierna@securi
   ||tas-direct.com

--- Comment #3 from Fredrik Hederstierna 
 ---
Checked size of text segment on arm-none-eabi from 4.6 to 7.1 but no major
difference seen, though some increase in later releases.

I previously saw code growt especially on ARM thumb1 code, but seems to be on
track again with newer releases, at least when running CsiBE benchmark.

gcc-4.6.41868 bytes (0)
gcc-4.7.41844 bytes (-1.3%)
gcc-4.8.51832 bytes (-1.9%)
gcc-4.9.31824 bytes (-2.4%)
gcc-5.3.01832 bytes (-1.9%)
gcc-6.3.01856 bytes (-0.6%)
gcc-7.1.01856 bytes (-0.6%)
gcc-8-master 1872 bytes (+0.2%)

arm-none-eabi-gcc -c -Os -std=gnu89 -mcpu=cortex-m3 -mthumb snake.c

See my CSibe benchmark data at http://gcc.hederstierna.com/csibe/
currently only for ARM but my plan was to add more targets after time, but
project halted due now to no time unfortunately.

[Bug c++/81605] -Wignored-attributes emitted when decltype(function) used in template for function with __nonnull__

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
In my view, whenever it's meaningful to act on an attribute for a call via 
a function pointer (e.g. format, format_arg, const, pure, noreturn, ...), 
the attribute should apply to the type internally so that it can indeed 
work with function pointers (this does not assert what decltype does or 
does not do with such an attributed function, however).

[Bug driver/81658] New: gcc configured with --enable-default-pie on SPARC produces buggy executable from working .o files

[bruno at clisp dot org]

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

Bug ID: 81658
   Summary: gcc configured with --enable-default-pie on SPARC
produces buggy executable from working .o files
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 41886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41886=edit
tarball of object files

GCC, configured with --enable-default-pie on SPARC, links object files that
happen to access global variables in such a way that the resulting executable
is broken: it crashes when attempting to access the global variable.

Test case: Find attached a tarball with 4 object files. They were produced from
https://haible.de/bruno/gnu/libffcall-2.0-20170731.tar.gz on a Linux/sparc
machine with gcc 6.3.0 (that is NOT configured with --enable-default-pie). On
that machine:
$ gcc -m32 vacall-libapi.o vacall.o vacall-structcpy.o minitests.o
$ ./a.out


Unpack the same tarball and link the same object files on a machine with a GCC
configured with --enable-default-pie:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper
Target: sparc64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-2'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=sparc64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-sparc64
--with-arch-directory=sparc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc=auto --enable-multiarch --enable-targets=all
--with-cpu-32=ultrasparc --with-long-double-128 --enable-multilib
--enable-checking=release --build=sparc64-linux-gnu --host=sparc64-linux-gnu
--target=sparc64-linux-gnu
Thread model: posix
gcc version 6.4.0 20170724 (Debian 6.4.0-2) 

$ gcc -m32 vacall-libapi.o vacall.o vacall-structcpy.o minitests.o
$ ./a.out 
void f(void):
Segmentation fault

Using "gcc -v", I see that the link command is essentially
/usr/lib/gcc/sparc64-linux-gnu/6/collect2 --sysroot=/ --build-id --eh-frame-hdr
-m elf32_sparc -dynamic-linker /lib/ld-linux.so.2 -relax -pie -o a.out
/usr/lib32/Scrt1.o /usr/lib32/crti.o
/usr/lib/gcc/sparc64-linux-gnu/6/32/crtbeginS.o
-L/usr/lib/gcc/sparc64-linux-gnu/6/32 -L/usr/lib32 -L/lib32 -L/usr/lib32
-L/usr/lib/gcc/sparc64-linux-gnu/6 -L/usr/lib vacall-libapi.o vacall.o
vacall-structcpy.o minitests.o -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/sparc64-linux-gnu/6/32/crtend.o /usr/lib32/crtn.o

If I execute it manually, the resulting a.out file crashes:
$ ./a.out 
void f(void):
Segmentation fault

But if I execute it manually without the "-pie" option, the resulting a.out
file works.
$ ./a.out


The difference between the two is at the beginning of function vacall_receiver.
   0x5b48 :save  %sp, -144, %sp
   0x5b4c :  sethi  %hi(0), %o0
   0x5b50 :  sethi  %hi(0x1c400), %l7
   0x5b54 : call  0x5b40
   0x5b58 : add  %l7, 0xac, %l7 ! 0x1c4ac
   0x5b5c : or  %o0, 0x180, %o0
   0x5b60 : ld  [ %l7 + %o0 ], %o1
At the instruction
   ld  [ %l7 + %o0 ], %o1
the values are:
In the case that works:
   %l7 + %o0 = 0x32180 => loads the word 0x32b58 into %o1
   _function = 0x32b58
In the case that does not work:
   %l7 + %o0 = 0x70022180 => loads the word 0x700456b0 into %o1
   _function = 0x70022b58
   The value in memory is wrong! 0x700456b0 is too high by 0x22b58
   (strange coincidence of numbers - looks like a relocation has been applied
twice instead of just once)

When I set a watchpoint at that location, I see that it's modified only once:

(gdb) watch *(void**)0x70022180
Hardware watchpoint 1: *(void**)0x70022180
(gdb) run
Starting program: /home/haible/vacall/a.out 

Watchpoint 1: *(void**)0x70022180

Old value = (void *) 0x22b58
New value = (void *) 0x700456b0
elf_dynamic_do_Rela (skip_ifunc=, lazy=0, nrelative=, relsize=, reladdr=, map=0xf7ffaa10)
at do-rel.h:112
112 do-rel.h: No such file or directory.


I'm 

[Bug c/57821] 'array is too large' error is missing when sizetype overflows

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
Previous discussions in this bug suggest it was specific to 32-bit 
HOST_WIDE_INT.  HOST_WIDE_INT is now always 64-bit.

[Bug middle-end/81657] New: [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

Bug ID: 81657
   Summary: [8 Regression] FAIL: gcc.dg/20050503-1.c
scan-assembler-not call
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86, r250789 caused:

FAIL: gcc.dg/20050503-1.c scan-assembler-not call

since tail call optimization is no longer applied to mempcpy.  We
are generating:

test2a:
.LFB2:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdx, %rbx
callmemcpy
addq%rbx, %rax
popq%rbx
.cfi_def_cfa_offset 8
ret

instead of

test2a:
.LFB2:
.cfi_startproc
jmp mempcpy
.cfi_endproc

[Bug middle-end/81657] [8 Regression] FAIL: gcc.dg/20050503-1.c scan-assembler-not call

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug target/81654] Should interrupt attribute be allowed together with naked attribute?

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/81654] Should interrupt attribute be allowed together with naked attribute?

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Aug  1 20:25:41 2017
New Revision: 250793

URL: https://gcc.gnu.org/viewcvs?rev=250793=gcc=rev
Log:
386: Disallow naked attribute with interrupt attribute

gcc/

PR target/81654
* config/i386/i386.c (ix86_set_func_type): Disallow naked
attribute with interrupt attribute.

gcc/testsuite/

PR target/81654
* gcc.target/i386/pr81654.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81654.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug other/80437] large decimal numbers in diagnostics are hard to read

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
If the warning is based of a const, maybe lead with that e.g. in the 2nd place
here:

bug.c:11:5: warning: 'memset': specified size 18446744073709551611 (aka
0x___fffb, 1<<64 - 5, SOME_CONST) exceeds maximum object size
PTRDIFF_MAX (aka 9223372036854775807, 0x7fff___, 1<<63 - 1)

[Bug other/80437] large decimal numbers in diagnostics are hard to read

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Maybe could also make creative use of underscores in large hex values to make
things easier on the eye e.g.:

bug.c:11:5: warning: 'memset': specified size 18446744073709551611 (aka
0x___fffb, 1<<64 - 5, SOME_CONST) exceeds maximum object size
9223372036854775807  (aka 0x7fff___, 1<<63 - 1, SOME_OTHER_CONST)

[Bug other/80437] large decimal numbers in diagnostics are hard to read

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Maybe all four (decimal, hex, formula, and constant):

bug.c:11:5: warning: 'memset': specified size 18446744073709551611 (aka
0xfffb, 1<<64 - 5, SOME_CONST) exceeds maximum object size
9223372036854775807  (aka 0x7fff, 1<<63 - 1, SOME_OTHER_CONST)

[Bug c/81656] New: incompatible _Alignas silently accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81656
   Summary: incompatible _Alignas silently accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing my improvements to detect mutually exclusive attribute
specifications I came across another problem, this one specific to the _Alignas
specifier (but it should also apply to attribute aligned. both on objects and
functions).

In 6.7.5, p7, C11 specifies the following two requirements on _Alignas:

  If the definition of an object has an alignment specifier, any other
declaration of that object shall either specify equivalent alignment or have no
alignment specifier.  If the definition of an object does not have an alignment
specifier, any other declaration of that object shall also have no alignment
specifier.

The test case below violates both of these requirements and so should be
diagnosed but isn't.  The problem seems to be  (as in bug 81544 and some
others) that the handle_aligned_attribute() function in c-family/c-attribs.c
doesn't have access to the last declaration as it processes a new one.  That
GCC manages to do the reasonable thing despite it (i.e., use the most
restrictive alignment) means that some other mechanism must detect and resolve
the conflict, but without diagnosing it.

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic -o /dev/stdout b.c
extern _Alignas (32) int a;

_Alignas (8) int a = 32;   // violates sentence 1


extern _Alignas (32) int b;
extern _Alignas (16) int b;
extern _Alignas (8) int b;

int b = 32;   // violates sentence 2

.file   "b.c"
.globl  b
.data
.align 32
.type   b, @object
.size   b, 4
b:
.long   32
.globl  a
.align 32
.type   a, @object
.size   a, 4
a:
.long   32
.ident  "GCC: (GNU) 8.0.0 20170727 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug other/80437] large decimal numbers in diagnostics are hard to read

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
(In reply to Martin Sebor from comment #0)

[...snip...]

> bug.c:11:5: warning: 'memset': specified size 0xfffb exceeds
> maximum object size 0x [-Wstringop-overflow=]
> 
> I'm not sure that this a significant improvement.  Those already familiar
> with the -Wstringop-overflow warning will likely understand what
> 0x in this context means but only because we know the
> maximum object size limit (i.e., PTRDIFF_MAX) and realize that all printed
> values are in the [PTRDIFF_MAX + 1, SIZE_MAX] range and thus always consist
> of 16 hex digits.  Someone who's seen the warning for the first time will
> either have to guess or count the f's.  This is even more likely for the
> specified size (such as 0xfffb).  In cases where a much lower
> limit is specified by the user (e.g., via -Walloca-larger-than) it's even
> less clear how to interpret a number in any base.
> 
> I think it's possible to do better.  One approach is to print very large
> values in terms of well-known constants such as SIZE_MAX or PTRDIFF_MAX. 
> For instance, instead of printing 18446744073709551611 (i.e., -5) print
> SIZE_MAX - 4.  Another solution might be to print sizes as signed (though
> that won't help in the case of the user-specified limit).

How about printing *both* i.e.:

bug.c:11:5: warning: 'memset': specified size 0xfffb (SIZE_MAX - 4)
exceeds maximum object size 0x (PTRDIFF_MAX)
[-Wstringop-overflow=]

(I may have got the expressions wrong, but hopefully the meaning is clear)

> Since the problem of how best to present large decimal numbers is general
> and applies to all diagnostics, including warnings, errors, and notes, a
> change to how these numbers are presented should be brought up for a wider
> discussion before it's implemented consistently, for all diagnostics.

I find large decimal numbers intimidating, and find hexadecimals easier for
values close to large powers of two.

Suggestion: choose base based on a "mental effort cost":

Example 1
*
For example, if we have an overflow that occurs when x >= 2^31,
which is easier to read:

DECIMAL:
  warning: buffer overflow occurs when x >= 2147483648

HEX:
  warning: buffer overflow occurs when x >= 0x8000

FORMULA:
  warning: buffer overflow occurs when x >= 2^31

FORMULA and HEX:
  warning: buffer overflow occurs when x >= 2^31 (0x8000)

Example 2
*
an overflow that occurs when x >= 100

DECIMAL:
  warning: buffer overflow occurs when x >= 100

HEX:
  warning: buffer overflow occurs when x >= 0x64

In the above case, decimal is the easier-to-read format.

Example 3
*

an overflow that occurs when x >= 0x7fff

DECIMAL:
  warning: buffer overflow occurs when x >= 2147418112

HEX:
  warning: buffer overflow occurs when x >= 0x7fff

In this case, hexadecimal is the easier-to-read format.

Example 4
*

an overflow that occurs when x <= -8000

DECIMAL:
  warning: buffer overflow occurs when x <= -8000

HEX:
  warning: buffer overflow occurs when x <= -0x1f40


The idea


The idea is a way to choose the printed representation based on the value,
based on the number of "awkward" digits.

On implementation is to assign a cost to a digit based on closeness to zero.

For example, in decimal,
  '0' : low cost
  '1', '9': medium cost
  '2'..'8': high cost

in hexadecimal:i
  '0' : low cost
  '1', 'f': medium cost
  '2'..'e': high cost

We can weight these, say cost 10 for "high", cost 1 for "medium", cost 0 for
"low".

"Cheaper" in this sense should mean "easier for a human to understand"; a rough
measure of the amount of mental effort required by a human reader.

Hence:

example 1:
  decimal: 2147483648
10 digits, 9 high cost, 1 medium cost: cost = 91

  hexadecimal: 0x8000
8 digits; 1 high cost, 7 low cost: cost = 17

  hence hexadecimal is "cheaper", and we use it

example 2:
  decimal: 100
3 digits, 1 medium cost, 2 low cost: cost = 1

  hexadecimal: 0x64
2 high cost digits: cost = 20

  hence decimal is "cheaper", and we use it

example 3:
  decimal: 2147418112
10 digits: 4 medium cost, 6 high cost: cost = 64

  hexadecimal: 0x7fff
8 digits: 1 high cost, 3 medium cost, 4 low cost: cost = 13

  hence hexadecimal is "cheaper", and we use it

example 4:
  decimal: -8000
3 low cost digits, 1 high cost: cost = 10

  hexadecimal: -0x1f40
1 low cost, 2 medium cost, 1 high cost: cost = 12

  hence decimal is "cheaper", and we use it

I guessed at these weightings; there may be better ones.

[Bug c++/71440] ICE on invalid C++ code on x86_64-linux-gnu: in instantiate_type, at cp/class.c:8247

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
Seems mostly fixed in trunk modulo pretty printing. Looking further into it.

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #8 from Eric Gallager  ---
(In reply to Matt Hargett from comment #7)
> I get this when trying to compile scummvm with LTO and whole-program:
> 
> $ /usr/lib/gcc-snapshot/bin/g++ --version
> 
> g++ (Ubuntu/Linaro 20110813-1ubuntu1) 4.7.0 20110813 (experimental) [trunk
> revision 177733]
> 
> 
> $ CC=/usr/lib/gcc-snapshot/bin/gcc CXX=/usr/lib/gcc-snapshot/bin/g++
> CFLAGS="-Ofast -flto" CXXFLAGS="-Ofast -flto" LDFLAGS="-flto
> -fwhole-program" ./configure
> 
> [...]
> 
> $ make -j9
> 
> [...]
> 
> 
> RANLIB   base/libbase.a
> LINK scummvm
> lto1: internal compiler error: in generate_canonical_option, at
> opts-common.c:303
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> lto-wrapper: /usr/lib/gcc-snapshot/bin/g++ returned 1 exit status
> /usr/bin/ld.bfd.real: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> 
> 
> Removing -fwhole-program and changing the CXXFLAGS to -O1 doesn't change the
> behaviour. I can attach a tarball if downloading the latest scummvm tarball
> is too bothersome.
> 

If there's too many files to attach preprocessed source for each of them, could
you at least post a link to the scummvm tarball you used?

[Bug target/48256] gcc4.4.5 internal compiler error: in change_address_1, at emit-rtl.c:1954

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Eric Gallager  ---
(In reply to Mikael Pettersson from comment #2)
> Created attachment 24559 [details]
> preprocessed test case
> 
> Several files in gsoc2010-fftw-neon ICE gcc-4.4 in change_address_1, this is
> the preprocessed code for the first one.
> 
> The ICE doesn't occur with gcc-4.6.0, it was cured by r159480, a generic
> patch to reduce stack frame sizes.
> 
> The description 
> didn't mention fixing any bugs, so I don't know if it actually fixed this
> bug or just made it latent.

Assuming it actually fixed it.
(I can't reproduce due to target differences)

[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden => gp-relative relocation against dynamic symbol

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target||alphaev5-unknown-linux-gnu
 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||4.3.5, 4.4.5, 4.5.1
 Resolution|--- |FIXED
  Known to fail||4.2.4

--- Comment #6 from Eric Gallager  ---
Closing since it's apparently fixed in more recent versions of GCC

[Bug target/81654] Should interrupt attribute be allowed together with naked attribute?

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Short answer to the question in the summary: No.

You are out of luck with every function that touches the stack in any kind of
automatic way.

Patch that makes interrupt and naked attribute mutually exclusive is welcome,
even if the subject falls into "Doctor, it hurts when I do that..." category.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #9 from Bill Schmidt  ---
This is overkill, it has some test case fallout.  Will have to look a bit
deeper.

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug tree-optimization/81655] New: [7 Regression] new test case gcc.dg/tree-ssa/pr81588.c fails on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 81655
   Summary: [7 Regression] new test case gcc.dg/tree-ssa/pr81588.c
fails on powerpc64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

FAIL: gcc.dg/tree-ssa/pr81588.c scan-tree-dump-times reassoc1 "Optimizing range
test [^\n\r]* and comparison" 1

This fails on both LE and BE.  Tested on a power8 system.

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Aug  1 19:09:02 2017
New Revision: 250792

URL: https://gcc.gnu.org/viewcvs?rev=250792=gcc=rev
Log:
2017-08-01  Thomas König  

PR fortran/79312
* intrisic.c (gfc_convert_type_warn):  Only set typespec for
empty array constructors which don't have it already.

2017-08-01  Thomas König  

PR fortran/79312
* gfortran.dg/logical_assignment_1.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/logical_assignment_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81654] New: Should interrupt attribute be allowed together with naked attribute?

[hjl.tools at gmail dot com]

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

Bug ID: 81654
   Summary: Should interrupt attribute be allowed together with
naked attribute?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 naked-1]$ cat x.c
/* { dg-do run { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-mgeneral-regs-only" } */

extern void exit (int);

typedef unsigned int uword_t __attribute__ ((mode (__word__)));

#define ERROR   0x12345670
#define IP  0x12345671
#define CS  0x12345672
#define FLAGS   0x12345673
#define SP  0x12345674
#define SS  0x12345675

#define STRING(x)   XSTRING(x)
#define XSTRING(x)  #x
#define ASMNAME(cname)  ASMNAME2 (__USER_LABEL_PREFIX__, cname)
#define ASMNAME2(prefix, cname) XSTRING (prefix) cname

struct interrupt_frame
{
  uword_t ip;
  uword_t cs;
  uword_t flags;
  uword_t sp;
  uword_t ss;
};

__attribute__((interrupt, naked, used))
void
fn (struct interrupt_frame *frame, uword_t error)
{
  if (ERROR != error)
__builtin_abort ();
  if (IP != frame->ip)
__builtin_abort ();
  if (CS != frame->cs)
__builtin_abort ();
  if (FLAGS != frame->flags)
__builtin_abort ();
  if (SP != frame->sp)
__builtin_abort ();
  if (SS != frame->ss)
__builtin_abort ();

  exit (0);
}

int
main ()
{
  asm ("push$" STRING (SS) ";   \
push$" STRING (SP) ";   \
push$" STRING (FLAGS) ";\
push$" STRING (CS) ";   \
push$" STRING (IP) ";   \
push$" STRING (ERROR) ";\
jmp  " ASMNAME ("fn"));
  return 0;
}
[hjl@gnu-6 naked-1]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -mgeneral-regs-only -c -o
x.o x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/   x.o   -o x
./x
make: *** [Makefile:12: all] Segmentation fault
[hjl@gnu-6 naked-1]$

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

[bruno at clisp dot org]

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

Bruno Haible  changed:

   What|Removed |Added

 Target||sparc64-linux-gnu

--- Comment #2 from Bruno Haible  ---
Apparently, on SPARC, there are two ways of referring to global variables from
within .s files. The non-PIC way is

sethi   %hi(variable), %g1
or  %g1, %lo(variable), %g1

The PIC way is

sethi   %hi(_GLOBAL_OFFSET_TABLE_-8), %l7
add %l7, %lo(_GLOBAL_OFFSET_TABLE_-4), %l7
call__sparc_get_pc_thunk.l7
 nop
sethi   %gdop_hix22(variable), %g1
xor %g1, %gdop_lox10(variable), %g1
ld  [%l7 + %g1], %g1, %gdop(variable)

The ugly thing is that
* the non-PIC way, compiled by "gcc -fPIC", crashes,
* the PIC way, compiled by "gcc" without -fPIC and without
--enable-default-pie, crashes as well.

So in order to write hand-written assembly that accesses global variables, one
has to write a .S file (that gets preprocessed!)

#ifdef __PIC__
sethi   %hi(_GLOBAL_OFFSET_TABLE_-8), %l7
add %l7, %lo(_GLOBAL_OFFSET_TABLE_-4), %l7
call__sparc_get_pc_thunk.l7
 nop
sethi   %gdop_hix22(variable), %g1
xor %g1, %gdop_lox10(variable), %g1
ld  [%l7 + %g1], %g1, %gdop(variable)
#else
sethi   %hi(variable), %g1
or  %g1, %lo(variable), %g1
#endif

Is this the only workaround to a silent change of behaviour of commands such as
"gcc -c getter.s" ?

[Bug driver/81653] gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

[bruno at clisp dot org]

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

--- Comment #1 from Bruno Haible  ---
Created attachment 41885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41885=edit
Test case program, part 2

[Bug driver/81653] New: gcc configured with --enable-default-pie on SPARC miscompiles hand-written .s files

[bruno at clisp dot org]

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

Bug ID: 81653
   Summary: gcc configured with --enable-default-pie on SPARC
miscompiles hand-written .s files
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 41884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41884=edit
Test case program, part 1

GCC, configured with --enable-default-pie on SPARC, miscompiles hand-written .s
files that happen to access global variables. The cause is that it passes the
option "-K PIC" to the assembler; the assembler then interprets the .s file
differently (by putting different relocations into the .o file). The resulting
executable does not work.

Test case: Find attached main.c and getter.s.

With a GCC not configured with --enable-default-pie:

$ gcc -m32 main.c getter.s
$ ./a.out 
$ echo $?
42

With a GCC configured with --enable-default-pie:

$ gcc -m32 main.c getter.s
$ ./a.out 
Segmentation fault

$ gdb a.out
(gdb) run
Starting program: /home/haible/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x76c8 in getter ()
(gdb) disassemble getter
Dump of assembler code for function getter:
   0x76c0 <+0>: sethi  %hi(0), %g1
   0x76c4 <+4>: or  %g1, 0x10, %g1  ! 0x10
=> 0x76c8 <+8>: ld  [ %g1 ], %o0
   0x76cc <+12>:retl 
   0x76d0 <+16>:nop 
End of assembler dump.
(gdb) print $g1
$1 = 16

Details about this GCC version:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc64-linux-gnu/6/lto-wrapper
Target: sparc64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.4.0-2'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=sparc64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-sparc64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-sparc64
--with-arch-directory=sparc64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc=auto --enable-multiarch --enable-targets=all
--with-cpu-32=ultrasparc --with-long-double-128 --enable-multilib
--enable-checking=release --build=sparc64-linux-gnu --host=sparc64-linux-gnu
--target=sparc64-linux-gnu
Thread model: posix
gcc version 6.4.0 20170724 (Debian 6.4.0-2) 

Analysis of the difference between that and this GCC:

1) The "as" invocation was
as -v -s -Av9a -32 -relax -o /tmp/cci9hbn2.o getter.s
and in this GCC version is
as -v -s -K PIC -Av9a -32 -relax -o /tmp/ccYeBhLa.o getter.s

2) The relocations in the object file:

That GCC:

$ gcc -m32 -c getter.s -o getter.o
$ objdump --disassemble --reloc getter.o

getter.o: file format elf32-sparc


Disassembly of section .text:

 :
   0:   03 00 00 00 sethi  %hi(0), %g1
0: R_SPARC_HI22 variable
   4:   82 10 60 00 mov  %g1, %g1   ! 0 
4: R_SPARC_LO10 variable
   8:   d0 00 40 00 ld  [ %g1 ], %o0
   c:   81 c3 e0 08 retl 
  10:   01 00 00 00 nop 

This GCC:

$ gcc -m32 -c getter.s -o getter.o
$ objdump --disassemble --reloc getter.o

getter.o: file format elf32-sparc


Disassembly of section .text:

 :
   0:   03 00 00 00 sethi  %hi(0), %g1
0: R_SPARC_GOT22variable
   4:   82 10 60 00 mov  %g1, %g1   ! 0 
4: R_SPARC_GOT10variable
   8:   d0 00 40 00 ld  [ %g1 ], %o0
   c:   81 c3 e0 08 retl 
  10:   01 00 00 00 nop 

As you can see, the assembler has inserted different relocations with "-K PIC"
than without.

3) The instructions in the linked a.out file:

That GCC:

$ objdump --disassemble a.out
00010480 :
   10480:   9d e3 bf a0 save  %sp, -96, %sp
   10484:   03 00 00 88 sethi  %hi(0x22000), %g1
   10488:   82 10 60 68 or  %g1, 0x68, %g1  ! 22068 
   1048c:   84 10 20 2a mov  0x2a, %g2
   10490:   c4 20 40 00 st  %g2, [ %g1 ]
   10494:   40 00 00 06 call  104ac 
   10498:   01 00 00 00 nop 
   1049c:   82 10 00 08 mov  %o0, %g1
   104a0:   b0 10 00 01 mov  %g1, %i0
   104a4:   81 cf e0 08 rett  %i7 + 8
   104a8:   01 00 00 00   

[Bug target/42199] A problem with -maltivec

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Eric Gallager  ---
(In reply to Rafał Mużyło from comment #3)
> There's new input in a different Gentoo bug:
> http://bugs.gentoo.org/show_bug.cgi?id=305333
> 
> Apparently in certain conditions on ppc, 
> bool is both defined and undefined.
> 
> Unless you'll see that as bad code on openjpeg side.

Yeah, bad code on the openjpeg side. Plus it's possible to trigger errors even
without -maltivec, so -maltivec is not the problem. Closing.

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Patch under test that fixes this case:

Index: gcc/gimple-ssa-strength-reduction.c  
===
--- gcc/gimple-ssa-strength-reduction.c (revision 250791)   
+++ gcc/gimple-ssa-strength-reduction.c (working copy)  
@@ -2082,6 +2082,11 @@ replace_mult_candidate (slsr_cand_t c, tree basis_
  types but allows for safe negation without twisted logic.  */ 
   if (wi::fits_shwi_p (bump)   
   && bump.to_shwi () != HOST_WIDE_INT_MIN  
+  /* It is more likely that the bump doesn't fit in the target 
+type, so check whether constraining it to that type changes
+the value.  */ 
+  && wi::eq_p (TREE_INT_CST_LOW (wide_int_to_tree (target_type, bump)),
+  bump)
   /* It is not useful to replace casts, copies, negates, or adds of
 an SSA name and a constant.  */
   && cand_code != SSA_NAME

[Bug target/81652] New: [meta-bug] -finstrument-control-flow -mcet bugs

[hjl.tools at gmail dot com]

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

Bug ID: 81652
   Summary: [meta-bug] -finstrument-control-flow -mcet bugs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

This meta-bug tracks all bugs related to -finstrument-control-flow -mcet.

[Bug target/40503] DEC_EVAL_METHOD not match operators

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Fred J. Tydeman from comment #2)
> Created attachment 18073 [details]
> Find precision of *, /, +, -, ==

Can't reproduce because my target doesn't support decimal floating point;
someone with a target where decimal floating point works will have to try the
testcase to move this bug out of WAITING.

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Florian Weimer from comment #5)
> (In reply to H.J. Lu from comment #4)
> > You can use -mstackrealign.
> 
> I don't want to realign the stack unconditionally for performance reasons. 
> I want to preserve alignment for callback functions, and give GCC the option
> to use SSE2 where beneficial.  If that's not possible, so be it, considering
> that it's only i386.

Have you tried mstackrealign on your code? I got

[hjl@gnu-6 gcc]$ cat x.c
#include 

extern void foo1 (__m128, __m128, __m128);
extern void foo2 (__m128, __m128, __m128, __m128);

extern __m128 x;

void
bar1 (void)
{
  foo1 (x, x, x);
}

void
bar2 (void)
{
  foo2 (x, x, x, x);
}
[hjl@gnu-6 gcc]$ gcc -S -O2 -m32 x.c -mstackrealign  -msse2
[hjl@gnu-6 gcc]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  bar1
.type   bar1, @function
bar1:
.LFB4910:
.cfi_startproc
movaps  x, %xmm0
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
jmp foo1
.cfi_endproc
.LFE4910:
.size   bar1, .-bar1
.p2align 4,,15
.globl  bar2
.type   bar2, @function
bar2:
.LFB4911:
.cfi_startproc
leal4(%esp), %ecx
.cfi_def_cfa 1, 0
andl$-16, %esp
pushl   -4(%ecx)
pushl   %ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
movl%esp, %ebp
pushl   %ecx
.cfi_escape 0xf,0x3,0x75,0x7c,0x6
subl$20, %esp
movaps  x, %xmm0
movaps  %xmm0, %xmm2
movaps  %xmm0, %xmm1
movaps  %xmm0, (%esp)
callfoo2
addl$16, %esp
movl-4(%ebp), %ecx
.cfi_def_cfa 1, 0
leave
.cfi_restore 5
leal-4(%ecx), %esp
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE4911:
.size   bar2, .-bar2
.ident  "GCC: (GNU) 7.1.1 20170709 (Red Hat 7.1.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$ 

GCC aligns stack only in foo2, not in foo1 since there is no need for it.

[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||egallager at gcc dot gnu.org

--- Comment #12 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #11)
> Simple testcase for powerpc64.
> int main(void){ return 0; }
> --- CUT --
> gcc  t.c -flto -c -m64 
> /home/apinski/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/
> lto1 t.o  -m32
> 
> --- CUT ---
> I have not tried after the patch though.

Confirmed, happens on i386-apple-darwin9.8.0 too.

[Bug fortran/45435] Automatically generate C interop interface blocks from C code

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
Author: tkoenig
Date: Tue Aug  1 17:59:11 2017
New Revision: 250791

URL: https://gcc.gnu.org/viewcvs?rev=250791=gcc=rev
Log:
2017-08-01  Thomas Koenig  

PR fortran/45435
* lang.opt (fc-prototypes): Add option.
* gfortran.h (gfc_typespec): Add interop_kind to struct.
(gfc_dump_c_prototypes): Add prototype.
* decl.c (gfc_match_kind_spec): Copy symbol used for kind to typespec.
* parse.c (gfc_parse_file): Call gfc_dump_prototypes.
* dump-parse-tree.c (gfc_dump_c_prototypes): New function.
(type_return): New enum.
(get_c_type_name): New function.
(write_decl): New function.
(write_type): New function.
(write_variable): New function.
(write_proc): New function.
(write_interop_decl): New function.
* invoke.texi: Document -fc-prototypes.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/parse.c

[Bug bootstrap/81638] [8 Regression] AIX bootstrap failure due to Recover GOTO predictor

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn  ---
I already tested the equivalent patch. If the preferred solution is a
work-around for the false positive, I'll install that.

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[fw at gcc dot gnu.org]

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

--- Comment #5 from Florian Weimer  ---
(In reply to H.J. Lu from comment #4)
> You can use -mstackrealign.

I don't want to realign the stack unconditionally for performance reasons.  I
want to preserve alignment for callback functions, and give GCC the option to
use SSE2 where beneficial.  If that's not possible, so be it, considering that
it's only i386.

[Bug target/35179] execs crash in shared lib destructor = do_global_dtors_aux

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.10 |i386-pc-solaris2.10,
   ||i486-linux-gnu
 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Radu Hociung from comment #6)
> Comment on attachment 17939 [details]
> Improved hello-test case showing working and failing command lines, with
> Makefile
> 
> Works as expected:
> gcc -g -o hello-exec hellomain.o -L. -lhello
> 
> Triggers the bug:
> gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L. -lhello -v

Testcase fails to link for me on Darwin due to a difference in linkers:

$ make hello-exec-gccbug35179
/usr/local/bin/gcc -o hellomain.o -c -g hellomain.c 
hellomain.c: In function ‘main’:
hellomain.c:9:2: warning: implicit declaration of function ‘exit’
[-Wimplicit-function-declaration]
  exit(0);
  ^~~~
hellomain.c:9:2: warning: incompatible implicit declaration of built-in
function ‘exit’
hellomain.c:9:2: note: include ‘’ or provide a declaration of ‘exit’
/usr/local/bin/gcc -o hello_.o -g -c -fpic -DPIC hello.c 
/usr/local/bin/gcc -o libhello.so -shared -g hello_.o 
echo Linking with both -static and -shared flags exposes the bug.
Linking with both -static and -shared flags exposes the bug.
/usr/local/bin/gcc -g -static -o hello-exec-gccbug35179 hellomain.o -shared -L.
-lhello -v 
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../configure --disable-werror --disable-werror-always
--enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release,rtl
-C --with-system-libunwind --enable-secureplt --enable-frame-pointer
--enable-debug --with-isl --disable-host-shared --enable-maintainer-mode
--disable-default-pie --with-ld64 --without-pic --enable-target-optspace
CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf
AUTOHEADER=/usr/local/bin/autoheader AUTORECONF=/usr/local/bin/autoreconf
AUTOM4TE=/usr/local/bin/autom4te AUTOSCAN=/usr/local/bin/autoscan
AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames
Thread model: posix
gcc version 8.0.0 20170702 (experimental) (GCC) 
COMPILER_PATH=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/libexec/gcc/i386-apple-darwin9.8.0/:/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/lib/gcc/i386-apple-darwin9.8.0/
LIBRARY_PATH=/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/:/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../../
COLLECT_GCC_OPTIONS='-g' '-static' '-o' 'hello-exec-gccbug35179'  '-L.' '-v'
'-mmacosx-version-min=10.5.8' '-asm_macosx_version_min=10.5' '-mtune=core2'
'-Zdynamiclib'
 /usr/local/libexec/gcc/i386-apple-darwin9.8.0/8.0.0/collect2 -static -dylib
-arch i386 -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o
hello-exec-gccbug35179 -ldylib1.10.5.o -L.
-L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0
-L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o -lhello
-lgcc_eh -lgcc -v -idsym
collect2 version 8.0.0 20170702 (experimental)
/usr/bin/ld -static -dylib -arch i386 -macosx_version_min 10.5.8
-weak_reference_mismatches non-weak -o hello-exec-gccbug35179 -ldylib1.10.5.o
-L. -L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0
-L/usr/local/lib/gcc/i386-apple-darwin9.8.0/8.0.0/../../.. hellomain.o -lhello
-lgcc_eh -lgcc -v
Apple Computer, Inc. version cctools-698.1~1
ld_classic: incompatible flag -dylib used (must specify "-dynamic" to be used)
collect2: error: ld returned 1 exit status
make: *** [hello-exec-gccbug35179] Error 1
$

Someone running GNU/Linux will have to try the testcase to move this out of
WAITING.

[Bug fortran/81651] New: Enhancement request: have f951 print out fully qualified module file name

[hbl3973 at gmail dot com]

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

Bug ID: 81651
   Summary: Enhancement request: have f951 print out fully
qualified module file name
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hbl3973 at gmail dot com
  Target Milestone: ---

Working with cmake to build our local source tree, I ran into the f951 message
that it received an unexpected EOF reading fort_func_mod.mod.  Our cmake
configuration invokes the -J flag to place modules in a central directory. 
After several days of digging through Xpert Xchange, compiler -v output, etc.,
I found that there was a stray fort_func_mod.mod file in the source tree that
had been created by an Intel compiler in the same directory as the
fort_func_mod.f90 file.  While the documentation for the -J flag does say that
gfortran looks in the current directory, this is ambiguous as cmake uses the
toplevel directory for all its actions and compiles and links with fully
qualified paths to a subdirectory in the source or build tree.

Bottom line: had f951 printed out a fully qualified module name in its error
message, the problem would have been obvious and fixed immediately.

[Bug c/81289] [8 Regression] ICE in libcpp/line-map.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|powerpc-*-linux-gnu*,   |
   |powerpcspe-*-linux-gnu* |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed; removing target since the ICE happens for i386-apple-darwin9.8.0,
too

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Martin Liška  ---
Now it should be fine.

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

--- Comment #17 from Martin Liška  ---
Author: marxin
Date: Tue Aug  1 17:21:29 2017
New Revision: 250789

URL: https://gcc.gnu.org/viewcvs?rev=250789=gcc=rev
Log:
Make mempcpy more optimal (PR middle-end/70140).

2017-08-01  Martin Liska  

PR middle-end/70140
* gcc.dg/string-opt-1.c: Adjust test-case to scan for memcpy.
2017-08-01  Martin Liska  

PR middle-end/70140
* builtins.c (expand_builtin_memcpy_args): Remove.
(expand_builtin_memcpy): Call newly added function
expand_builtin_memory_copy_args.
(expand_builtin_memcpy_with_bounds): Likewise.
(expand_builtin_mempcpy): Remove last argument.
(expand_builtin_mempcpy_with_bounds): Likewise.
(expand_builtin_memory_copy_args): New function created from
expand_builtin_mempcpy_args with small modifications.
(expand_builtin_mempcpy_args): Remove.
(expand_builtin_stpcpy): Remove unused argument.
(expand_builtin): Likewise.
(expand_builtin_with_bounds): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/string-opt-1.c

[Bug c/81141] missing warning using sizeof a/sizeof *a with a zero-length array

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
You can use -mstackrealign.

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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #89 from H.J. Lu  ---
*** Bug 81646 has been marked as a duplicate of this bug. ***

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
So I accidentally installed an old version of patch, reverted in r250788.

[Bug c/80872] There is no warning on accidental infinite loops

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed that such a warning would be nice to have, but probably impossible to
implement properly due to the halting problem. Thus setting status to
SUSPENDED.

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 16:44:17 2017
New Revision: 250787

URL: https://gcc.gnu.org/viewcvs?rev=250787=gcc=rev
Log:
PR target/81622
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
__builtin_vec_cmpne verify both arguments are compatible vectors
before looking at TYPE_MODE on the element type.  For __builtin_vec_ld
verify arg1_type is a pointer or array type.  For __builtin_vec_st,
move computation of aligned to after checking the argument types.
Formatting fixes.

* gcc.target/powerpc/pr81622.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr81622.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c/81650] New: gcc -m32 mishandles -Walloc-size-larger-than=9223372036854775807

[eggert at gnu dot org]

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

Bug ID: 81650
   Summary: gcc -m32 mishandles
-Walloc-size-larger-than=9223372036854775807
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

This is following up a Gnulib bug report:

http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00150.html

which appears to stem from a bug in GCC. To reproduce the problem, compile the
following program:

extern void *malloc (unsigned long);
int
main (void)
{
  return !malloc (5);
}

with this shell command:

gcc -m32 -Walloc-size-larger-than=9223372036854775807 -S foo.c

On Fedora 26, gcc 7.1.1 20170622 (Red Hat 7.1.1-3) outputs the following false
alarm:

foo.c: In function 'main':
foo.c:5:11: warning: argument 1 value '5' exceeds maximum object size -1
[-Walloc-size-larger-than=]
   return !malloc (5);
   ^~
foo.c:1:14: note: in a call to allocation function 'malloc' declared here
 extern void *malloc (unsigned long);
  ^~

GCC works correctly (i.e., silently) if -m32 is omitted. Evidently GCC is not
doing the right thing when the operand of -Walloc-size-larger-than is too
large: such an operand should be treated as infinity, not as -1.

[Bug c++/80744] Detect Divide By Zero and give a warning in C/C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
  Component|c   |c++
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Testcase needs some modification to compile properly; after adding the proper
includes and namespace, the results are:

$ /usr/local/bin/g++ -c -Wdiv-by-zero 80744.cc
80744.cc: In function ‘void test_func(size_t, const string&)’:
80744.cc:14:25: warning: division by zero [-Wdiv-by-zero]
 printf("B %zu\n", 10/i);
   ~~^~
$

Confirmed that warnings are still missing for (A) and (C), although maybe there
should be a separate option: -Wmaybe-div-by-zero, analogous to how there's both
-Wmaybe-uninitialized and -Wuninitialized, depending on how certain gcc is.

(Changing component from 'c' to 'c++' while I'm at it since testcase uses
c++-specific things)

[Bug target/81622] [7/8 Regression] ICE on invalid altivec code with ppc64{,le}

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 16:34:31 2017
New Revision: 250785

URL: https://gcc.gnu.org/viewcvs?rev=250785=gcc=rev
Log:
PR target/81622
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): For
__builtin_vec_cmpne verify both arguments are compatible vectors
before looking at TYPE_MODE on the element type.  For __builtin_vec_ld
verify arg1_type is a pointer or array type.  For __builtin_vec_st,
move computation of aligned to after checking the argument types.
Formatting fixes.

* gcc.target/powerpc/pr81622.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr81622.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
__builtin_islessgreater  should never set or raise an "fp" exception. 
Interesting the vectorized version does ...

[Bug target/81648] [8 regression] r250759 breaks build on powerpc64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Oops, the issue is that this is in fairly newly addded stuff - r250477, and I
wrote the patch before this was committed, so my grep didn't reveal that.  And
my cross-compiler was built without binutils, so HAVE_AS_POWER9 wasn't defined
and that builds fine too.
Fixed as obvious with:
Author: jakub
Date: Tue Aug  1 16:12:31 2017
New Revision: 250784

URL: https://gcc.gnu.org/viewcvs?rev=250784=gcc=rev
Log:
PR target/80846
* config/rs6000/vsx.md (vextract_fp_from_shorth,
vextract_fp_from_shortl): Add element mode after mode in gen_vec_init*
calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug web/81649] New: Instrumentation Options page grammar

[jg at jguk dot org]

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

Bug ID: 81649
   Summary: Instrumentation Options  page grammar
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello

https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html


Current:
-fsanitize=leak
Enable LeakSanitizer, a memory leak detector. This option only matters for
linking of executables *and* the executable is linked against a library that
overrides malloc and other allocator functions.

I replaced word *and* with *when* below.

Proposed:
-fsanitize=leak
Enable LeakSanitizer, a memory leak detector. This option only matters for
linking of executables *when* the executable is linked against a library that
overrides malloc and other allocator functions.

[Bug target/80846] auto-vectorized AVX2 horizontal sum should narrow to 128b right away, to be more efficient for Ryzen and Intel

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 16:12:31 2017
New Revision: 250784

URL: https://gcc.gnu.org/viewcvs?rev=250784=gcc=rev
Log:
PR target/80846
* config/rs6000/vsx.md (vextract_fp_from_shorth,
vextract_fp_from_shortl): Add element mode after mode in gen_vec_init*
calls.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/vsx.md

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
Sorry for the breakage, I'm going to take a look.

[Bug target/81648] New: [8 regression] r250759 breaks build on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 81648
   Summary: [8 regression] r250759 breaks build on powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

r250758 worked fine.

/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md: In function 'rtx_def*
gen_vextract_fp_from_shorth(rtx, rtx)':
/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md:4526:14: error:
'gen_vec_initv16qi' was not declared in this scope
   emit_insn (gen_vec_initv16qi (mask, gen_rtx_PARALLEL (V16QImode, v)));
  ^
/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md:4526:14: note: suggested
alternative: 'gen_vec_initv16qiqi'
   emit_insn (gen_vec_initv16qi (mask, gen_rtx_PARALLEL (V16QImode, v)));
  ^
  gen_vec_initv16qiqi
/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md: In function 'rtx_def*
gen_vextract_fp_from_shortl(rtx, rtx)':
/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md:4555:14: error:
'gen_vec_initv16qi' was not declared in this scope
   emit_insn (gen_vec_initv16qi (mask, gen_rtx_PARALLEL (V16QImode, v)));
  ^
/home/seurer/gcc/gcc-test/gcc/config/rs6000/vsx.md:4555:14: note: suggested
alternative: 'gen_vec_initv16qiqi'
   emit_insn (gen_vec_initv16qi (mask, gen_rtx_PARALLEL (V16QImode, v)));
  ^
  gen_vec_initv16qiqi

[Bug c/80745] inconsistent warning: large integer implicitly truncated to unsigned type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> In four declarations below, the initializer expression is truncated when
> assigned to unsigned char.  Yet only the first two initializers are
> diagnosed (the warning message could be more helpful but that's the subject
> of bug 80731).  The same problem affects other unsigned integers besides
> unsigned char.
> 
> All four initializers should be diagnosed.
> 
> $ cat t.c && gcc -S -Wall -Wextra -Wpedantic -Woverflow t.c
> #include 
> 
> unsigned char uc1 = UCHAR_MAX + 1U;
> unsigned char uc2 = USHRT_MAX + 1U;
> unsigned char uc3 = UINT_MAX + 1U;
> unsigned char uc4 = ULONG_MAX + 1LU;
> 
> t.c:3:21: warning: large integer implicitly truncated to unsigned type
> [-Woverflow]
>  unsigned char uc1 = UCHAR_MAX + 1U;
>  ^
> t.c:4:21: warning: large integer implicitly truncated to unsigned type
> [-Woverflow]
>  unsigned char uc2 = USHRT_MAX + 1U;
>  ^

Confirmed, although since you've already improved -Woverflow a little since
then, the warning now reads:

$ /usr/local/bin/gcc -c -S -Wall -Wextra -Wpedantic -Woverflow 80745.c
80745.c:3:21: warning: conversion from ‘unsigned int’ to ‘unsigned char’
changes value from ‘256’ to ‘0’ [-Woverflow]
 unsigned char uc1 = UCHAR_MAX + 1U;
 ^
80745.c:4:21: warning: conversion from ‘unsigned int’ to ‘unsigned char’
changes value from ‘65536’ to ‘0’ [-Woverflow]
 unsigned char uc2 = USHRT_MAX + 1U;
 ^
$

(In reply to Martin Sebor from comment #1)
> The reason for the missing warning is that in the latter two cases the
> initializer expression itself wraps around to zero, which isn't diagnosed or
> detected, and the initialization then isn't diagnosed.
> 
> It seems that unsigned integer wrapping should be diagnosed independently of
> signed integer overflow (e.g., under -Wtruncation or something like that),
> and consistently for any kind of unsigned truncation or wrapping.
> 

I dunno, the fact that unsigned integers wrap is pretty commonly (ab)used on
purpose in lots of code I've seen. I'd be wary about a warning about unsigned
integer wrapping triggering lots of false positives. Still, at least in this
specific testcase in this bug, warning in the additional cases you recommend
seems reasonable.

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hjl.tools at gmail dot com
 Resolution|FIXED   |---

--- Comment #14 from H.J. Lu  ---
On Fedora 26/x86-64, I got

FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O0
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/mempcpy.c compilation,  -O1  (internal
compiler error)
FAIL: gcc.c-torture/execute/builtins/mempcpy.c compilation,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (internal compiler error)
FAIL: gcc.c-torture/execute/builtins/mempcpy.c compilation,  -O2  (internal
compiler error)
FAIL: gcc.c-torture/execute/builtins/mempcpy.c compilation,  -O3 -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/builtins/mempcpy.c compilation,  -Og -g  (internal
compiler error)
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O1
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -Og -g
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/pr23484-chk.c execution,  -Os
FAIL: gcc.c-torture/execute/builtins/strpcpy-2.c execution,  -Os
FAIL: gcc.dg/builtin-stringop-chk-4.c (internal compiler error)
FAIL: gcc.dg/builtin-stringop-chk-4.c (test for excess errors)
FAIL: gcc.dg/builtin-stringop-chk-4.c  (test for warnings, line 196)
FAIL: gcc.dg/builtin-stringop-chk-4.c  (test for warnings, line 211)
FAIL: gcc.dg/builtin-stringop-chk-4.c  (test for warnings, line 213)
FAIL: 

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #1)
> The Linux ABI says the stack should be 16-byte alignment, anything else is a
> bug.

The GCC manual recommends this (under -mincoming-stack-boundary):

 This extra alignment does consume extra stack space, and generally
 increases code size.  Code that is sensitive to stack space usage,
 such as embedded systems and operating system kernels, may want to
 reduce the preferred alignment to '-mpreferred-stack-boundary=2'.

It doesn't note the ABI impact, so the sorry situation is part our fault.

> That said, one can use -mpreferred-stack-boundary=,
> -mincoming-stack-boundary= and/or -mstackrealign options to tune stuff as
> desired.

Based on the gcc-help discussion,

  https://gcc.gnu.org/ml/gcc-help/2017-07/msg00087.html

no combination of these options work.  Stack alignment on every function entry
is much too expensive.

[Bug tree-optimization/80925] [8 Regression] vect peeling failures

[sje at gcc dot gnu.org]

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

--- Comment #20 from Steve Ellcey  ---
Author: sje
Date: Tue Aug  1 15:37:22 2017
New Revision: 250783

URL: https://gcc.gnu.org/viewcvs?rev=250783=gcc=rev
Log:
2017-08-01  Steve Ellcey  

PR tree-optimization/80925
* gcc.dg/vect/vect-28.c: Add
--param vect-max-peeling-for-alignment=0 option.
Remove unaligned access and peeling checks.
* gcc.dg/vect/vect-33-big-array.c: Ditto.
* gcc.dg/vect/vect-70.c: Ditto.
* gcc.dg/vect/vect-87.c: Ditto.
* gcc.dg/vect/vect-88.c: Ditto.
* gcc.dg/vect/vect-91.c: Ditto.
* gcc.dg/vect/vect-93.c: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-28.c
trunk/gcc/testsuite/gcc.dg/vect/vect-33-big-array.c
trunk/gcc/testsuite/gcc.dg/vect/vect-70.c
trunk/gcc/testsuite/gcc.dg/vect/vect-87.c
trunk/gcc/testsuite/gcc.dg/vect/vect-88.c
trunk/gcc/testsuite/gcc.dg/vect/vect-91.c
trunk/gcc/testsuite/gcc.dg/vect/vect-93.c

[Bug c/69981] -f[no]keep-static-consts has no effect

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to David L. from comment #6)
> Created attachment 37808 [details]
> patch (gcc-5.3.0)
> 
> patch attached (probably makes the user's PC explode and burns down their
> house)
> 
> varpool_node::finalize_decl (tree decl)
> -node->force_output = true;
> +node->force_output = !TREE_READONLY (decl) || flag_keep_static_consts;

Patches go to the gcc-patches mailing list

[Bug c/78736] enum warnings in GCC

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |prathamesh3492 at gcc 
dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Eric Gallager  ---
Prathamesh has submitted a patch to the gcc-patches mailing list that still
needs to be reviewed for this bug:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00514.html

[Bug c/80619] bad fix-it hint for GCC %lu directive with int argument: %wu

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Confirmed.

[Bug testsuite/81626] Need effective target omp_target

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Tom de Vries  ---
Failures fixed by enabling multilibs in accel compiler.

Closing as resolved-wontfix.

[Bug c/77331] incorrect range location in -Wformat with a concatenated format literal

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Sebor from comment #0)
> While getting the latest c-format.c changes integrated into the
> -Wformat-length pass and testing the result I noticed that GCC underlines
> different parts of the format strings than shown in the examples in the
> comment above the definition of the format_warning_va function.  The output
> shown in the comments makes sense.  The actual output not so much because
> parts of the format strings that are unrelated to the problem are underlined.
> 
> $ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wformat
> -Wformat-signedness t.c
> extern int printf (const char*, ...);
> 
> void f (const char *msg)
> {
>   printf ("hello " "%i", msg);
> 
> #define INT_FMT "%i"
> 
>   printf ("hello " INT_FMT " world", msg);
> 
> }
> t.c: In function ‘f’:
> t.c:5:11: warning: format ‘%i’ expects argument of type ‘int’, but argument
> 2 has type ‘const char *’ [-Wformat=]
>printf ("hello " "%i", msg);
>^~~~
> t.c:5:22: note: format string is defined here
>printf ("hello " "%i", msg);
>  ~^
>  %s
> t.c:9:11: warning: format ‘%i’ expects argument of type ‘int’, but argument
> 2 has type ‘const char *’ [-Wformat=]
>printf ("hello " INT_FMT " world", msg);
>^~~~
> t.c:7:19: note: format string is defined here
>  #define INT_FMT "%i"
>   ~^
>   %s

Confirmed.

[Bug gcov-profile/81561] [7 Regression] Segfault in gcov with -a argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed also on GCC 7 branch.

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I believe the check that triggers here is just wrong, if we have 2 different
queuest, it is very well possible that they will have different tasks with the
same priority as the next candidates.  And the code right below this test
doesn't make sense if t1 == t2.

Thus, I think we should apply:
--- libgomp/priority_queue.c.jj 2017-01-01 12:45:52.0 +0100
+++ libgomp/priority_queue.c2017-08-01 16:39:20.137155439 +0200
@@ -272,10 +272,6 @@ priority_tree_next_task (enum priority_q
 }
   /* If we get here, the priorities are the same, so we must look at
  parent_depends_on to make our decision.  */
-#if _LIBGOMP_CHECKING_
-  if (t1 != t2)
-gomp_fatal ("priority_tree_next_task: t1 != t2");
-#endif
   if (t2->parent_depends_on && !t1->parent_depends_on)
 {
   *q1_chosen_p = false;

I'm not getting any failures after this change, but it doesn't explain any
issues with non-_LIBGOMP_CHECKING_ builds.
So, can you apply the above change and see if you can come up with a testcase
that fails (segfault or some other gomp_fatal)?

[Bug gcov-profile/81561] [7 Regression] Segfault in gcov with -a argument

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Author: marxin
Date: Tue Aug  1 14:49:54 2017
New Revision: 250782

URL: https://gcc.gnu.org/viewcvs?rev=250782=gcc=rev
Log:
Fix segfault in gcov.c (PR gcov-profile/81561).

2017-08-01  Martin Liska  

Backport from mainline
2017-07-26  Martin Liska  

PR gcov-profile/81561
* gcov.c (unblock): Make unblocking safe as we need to preserve
index correspondence of blocks and block_lists.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gcov.c

[Bug libgomp/81591] segmentation fault when using priorities of nested tasks

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Slightly adjusted testcase - no headers, no VLAs, etc.:
int
main ()
{
#define MT 4
  int a[MT * MT];
  for (int i = 0; i < MT * MT; i++)
a[i] = 0;

  #pragma omp parallel
  #pragma omp master
  {
for (int k = 0; k < MT; k++)
  {
int *a0 = [k * MT + k];
int *a2 = [k * MT + MT - 1];
#pragma omp task depend(inout:a0[0:1]) \
 depend(inout:a2[0:1]) priority(1)
{
  #pragma omp taskloop num_tasks(MT - k) priority(2)
  for (int m = k; m < MT; m++)
a[k * MT + m] += 1;
  #pragma omp taskwait
}
  }
  }

  for (int i = 0; i < MT * MT; i++)
if (a[i] != ((i % MT) >= (i / MT)))
  __builtin_abort ();
  return 0;
}

[Bug gcov-profile/81561] [7 Regression] Segfault in gcov with -a argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[7/8 Regression] Segfault   |[7 Regression] Segfault in
   |in gcov with -a argument|gcov with -a argument
  Known to fail||7.1.0

--- Comment #4 from Martin Liška  ---
Fixed on trunk.

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Target|aarch64 |aarch64,x86_64

--- Comment #2 from amker at gcc dot gnu.org ---
So the same issue happens on x86_64 too:
$ ./g++ -O3 -fdump-tree-optimized uneq.cc -o uneq.O3.exe -mavx2
$ ./uneq.O3.exe
$ echo $?
1

And:
$ ./g++ -O2 -fdump-tree-optimized uneq.cc -o uneq.O2.exe -mavx2
$ ./uneq.O2.exe
$ echo $?
0

Note I increased iteration number to get it vectorized.

[Bug gcov-profile/81561] [7/8 Regression] Segfault in gcov with -a argument

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Tue Aug  1 14:06:13 2017
New Revision: 250780

URL: https://gcc.gnu.org/viewcvs?rev=250780=gcc=rev
Log:
Fix segfault in gcov.c (PR gcov-profile/81561).

2017-08-01  Martin Liska  

PR gcov-profile/81561
* gcov.c (unblock): Make unblocking safe as we need to preserve
index correspondence of blocks and block_lists.

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

[Bug sanitizer/81645] Learn UBSAN to support -fsanitize=builtin

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|8.0 |---

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Yes, I think everything asked for is already present via those options (just no
way to configure a different default).

Thus either INVALID or WORKSFORME.  Pick ;)

[Bug tree-optimization/81633] [7/8 Regression] Incorrect floating point result with tree vectoriser

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Aug  1 13:58:13 2017
New Revision: 250779

URL: https://gcc.gnu.org/viewcvs?rev=250779=gcc=rev
Log:
2017-08-01  Richard Biener  

PR tree-optimization/71752
PR tree-optimization/81633
* tree-vect-slp.c (vect_get_slp_defs): Handle null operands
in the original suggested way.

* gcc.dg/vect/pr81633.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81633.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-slp.c

[Bug tree-optimization/71752] [7 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:229 w/ -O1 -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Aug  1 13:58:13 2017
New Revision: 250779

URL: https://gcc.gnu.org/viewcvs?rev=250779=gcc=rev
Log:
2017-08-01  Richard Biener  

PR tree-optimization/71752
PR tree-optimization/81633
* tree-vect-slp.c (vect_get_slp_defs): Handle null operands
in the original suggested way.

* gcc.dg/vect/pr81633.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81633.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-slp.c

[Bug target/81646] i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The Linux ABI says the stack should be 16-byte alignment, anything else is a
bug.

That said, one can use -mpreferred-stack-boundary=, -mincoming-stack-boundary=
and/or -mstackrealign options to tune stuff as desired.

[Bug tree-optimization/81635] [8 Regression] nvptx SLP test cases regressions

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
Author: vries
Date: Tue Aug  1 13:52:14 2017
New Revision: 250778

URL: https://gcc.gnu.org/viewcvs?rev=250778=gcc=rev
Log:
Simplify nvptx/slp* test-cases

Use signed loop iteration variable in nvtpx/slp* test-cases to work around
PR tree-optimizaion/81635.

2017-08-01  Tom de Vries  

* gcc.target/nvptx/slp-2.c (foo): Use signed loop iteration variable.
* gcc.target/nvptx/slp.c (foo): Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/nvptx/slp-2.c
trunk/gcc/testsuite/gcc.target/nvptx/slp.c

[Bug target/81647] inconsistent LTGT behavior at different optimization levels on AArch64.

[amker at gcc dot gnu.org]

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

--- Comment #1 from amker at gcc dot gnu.org ---
According to thread https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00583.html
it's still not clear if LTGT should be quite or singaling, but inconsistent
behavior seems not correct here.

[Bug target/81647] New: inconsistent LTGT behavior at different optimization levels on AArch64.

[amker at gcc dot gnu.org]

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

Bug ID: 81647
   Summary: inconsistent LTGT behavior at different optimization
levels on AArch64.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amker at gcc dot gnu.org
  Target Milestone: ---

Given below test from Richard S,
#include 

double x[16], y[16];
int res[16];

int
main (void)
{
  for (int i = 0; i < 16; ++i)
{
  x[i] = __builtin_nan ("");
  y[i] = i;
}
  asm volatile ("" ::: "memory");
  feclearexcept (FE_ALL_EXCEPT);
  for (int i = 0; i < 16; ++i)
res[i] = __builtin_islessgreater (x[i], y[i]);
  asm volatile ("" ::: "memory");
  return fetestexcept (FE_ALL_EXCEPT) != 0;
}
If we compile and run it with:
$ ./g++ -O3 test.cc -o test.O3.exe
$ ./test.O3.exe
$ echo $?
1

If we compile and run it with:

$ ./g++ -O2 test.cc -o test.O2.exe
$ ./test.O2.exe
$ echo $?
0

It is because of different implementation of LTGT w/o vectorization.

[Bug tree-optimization/81181] [7/8 Regression] ICE in compute_antic, at tree-ssa-pre.c:2410

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Aug  1 13:36:50 2017
New Revision: 250777

URL: https://gcc.gnu.org/viewcvs?rev=250777=gcc=rev
Log:
2017-08-01  Richard Biener  

PR tree-optimization/81181
* tree-ssa-pre.c (compute_antic_aux): Defer clean() to ...
(compute_antic): ... end of iteration here.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81181.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug target/81646] New: i386 SSE2 compilation mode which preserves psABI stack alignment without requiring it

[fw at gcc dot gnu.org]

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

Bug ID: 81646
   Summary: i386 SSE2 compilation mode which preserves psABI stack
alignment without requiring it
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
Target: i386

It would be helpful to have an i386 compilation mode which preserves the
16-byte stack alignment (if it is aligned), supports SSE2, but does not require
stack alignment.

Currently, it is almost impossible to enable SSE2 for system libraries because
too much code is compiled with four byte stack alignment (as suggested in the
GCC manual, among other places).  Having a stack-conservative SSE2 mode would
change that.

[Bug sanitizer/81645] Learn UBSAN to support -fsanitize=builtin

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
   Severity|normal  |enhancement

[Bug sanitizer/81645] New: Learn UBSAN to support -fsanitize=builtin

[marxin at gcc dot gnu.org]

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

Bug ID: 81645
   Summary: Learn UBSAN to support -fsanitize=builtin
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, mpolacek at gcc dot gnu.org
  Target Milestone: ---

I've just read LLVM weekly:

* The Undefined Behavior Sanitizer (UBSan) learned to detect undefined 
behaviour in calls to builtins. [r309459](http://reviews.llvm.org/rL309459).

And we can also support that. Currently they instrument CLZ and CZT builtins
family. But maybe there are also others that worth adding?

[Bug c/80502] Provide macro to indicate OpenMP SIMD support

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
_OPENMP_SIMD is a bad idea, that namespace is reserved for OpenMP, so unless it
shows up in the OpenMP standard, it shouldn't be added.
Why do you need a macro?  Just use #pragma omp simd etc. unconditionally,
compilers that don't have support for such pragmas will just ignore those.

[Bug tree-optimization/80769] Invalid delayed string length computation in tree-ssa-strlen.c

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Aug  1 12:22:03 2017
New Revision: 250772

URL: https://gcc.gnu.org/viewcvs?rev=250772=gcc=rev
Log:
Backport fix for PR 80769

2017-08-01  Richard Sandiford  

gcc/
PR tree-optimization/80769
* tree-ssa-strlen.c (strinfo): Document that "stmt" is also used
for malloc and calloc.  Document the new invariant that all related
strinfos have delayed lengths or none do.
(get_next_strinfo): New function.
(verify_related_strinfos): Move earlier in file.
(set_endptr_and_length): New function, split out from...
(get_string_length): ...here.  Also set the lengths of related
strinfos.

gcc/testsuite/
PR tree-optimization/80769
* gcc.dg/strlenopt-31.c: New test.
* gcc.dg/strlenopt-31g.c: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/strlenopt-31.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/strlenopt-31g.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-strlen.c