[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/81636] Confusing warning message containing "#‘obj_type_ref’ not supported by expression#"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug lto/81612] lto1: internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Thanks, but I will need output generated with '-E' which will create
pre-processed source file that I can test.
Can you please create it for me?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|[7 Regression] AIX  |[8 Regression] AIX
   |bootstrap failure due to|bootstrap failure due to
   |Recover GOTO predictor  |Recover GOTO predictor

[Bug lto/81612] lto1: internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
Ok, are you able to at least append build flags (CFLAGS) to the build system?
If so, adding --save-temps and --verbose will save the file and you can attach
it here.

[Bug target/81643] New: FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[amker at gcc dot gnu.org]

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

Bug ID: 81643
   Summary: FAIL: gcc.target/aarch64/long_branch_1.c
scan-assembler Ltb
   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: ---

The test failed on aarch64-none-elf, aarch64-none-linux-gnu,
aarch64_be-none-elf,
looks like because of:
commit 38ef3642f7cce23012fc1126e292aa1a7285f849
Author: marxin 
Date:   Mon Jul 31 11:16:00 2017 +

Recover GOTO predictor.

2017-07-31  Jan Hubicka 
Martin Liska  

* c-typeck.c (c_finish_goto_label): Build gimple predict
stament.
2017-07-31  Jan Hubicka 
Martin Liska  

* predict.def: Remove old comment and adjust probability.
* gimplify.c (should_warn_for_implicit_fallthrough): Ignore
PREDICT statements.
2017-07-31  Jan Hubicka 
Martin Liska  

* gcc.dg/predict-15.c: New test.
* gcc.dg/tree-ssa/vrp24.c: Update scanned pattern.
2017-07-31  Jan Hubicka 
Martin Liska  

* pt.c (tsubst_copy): Copy PREDICT_EXPR.
* semantics.c (finish_goto_stmt): Build gimple predict
stament.
* constexpr.c (potential_constant_expression_1): Handle
PREDICT_EXPR.


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

[Bug tree-optimization/81297] [8 Regression] ICE in get_single_symbol

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Aug  1 07:04:10 2017
New Revision: 250758

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

PR tree-optimization/81297
* tree-vrp.c (get_single_symbol): Remove assert, instead drop
TREE_OVERFLOW from INTEGER_CSTs.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr81297.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug target/79499] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-01
 CC||marxin at gcc dot gnu.org,
   ||zhenqiang.chen at linaro dot 
org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, -O2 -fsplit-stack -fno-omit-frame-pointer started with r210458

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=21874

--- Comment #1 from Uroš Bizjak  ---
gas issue is reported at [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21874

[Bug tree-optimization/81620] [8 Regression] ICE in is_inv_store_elimination_chain, at tree-predcom.c:1651 with -O3

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug  1 09:17:29 2017
New Revision: 250763

URL: https://gcc.gnu.org/viewcvs?rev=250763=gcc=rev
Log:
PR tree-optimization/81620
* tree-predcom.c (add_ref_to_chain): Don't set has_max_use_after
for store-store chain.

gcc/testsuite
* gcc.dg/tree-ssa/pr81620-1.c: New.
* gcc.dg/tree-ssa/pr81620-2.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81620-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81620-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug target/81635] nvptx SLP test cases regressions

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
I.

The test-case slp.c (minus dg-final checks) looks like this:
...
/* { dg-options "-O2 -ftree-slp-vectorize" } */
int p[1000] __attribute__((aligned(8)));
int p2[1000] __attribute__((aligned(8)));

void __attribute__((noinline, noclone))
foo ()
{
  unsigned int a, b;

  unsigned int i;
  for (i = 0; i < 1000; i += 2)
{
  a = p[i];
  b = p[i+1];

  p2[i] = a;
  p2[i+1] = b;
}
}
...

Changing the type of the loop iteration variable 'i' from 'unsigned int' to
'int' makes the slp.c test pass again.


II.

With int, we have same 'offset from base address' and an 'constant offset from
base address' of 0 and 4:
...
Creating dr for p[i_13]
analyze_innermost: success.
base_address: 
offset from base address: (ssizetype) ((sizetype) i_13 * 4)
constant offset from base address: 0
step: 0
base alignment: 8
base misalignment: 0
offset alignment: 8
step alignment: 128
base_object: p[i_13]
Creating dr for p[_1]
analyze_innermost: success.
base_address: 
offset from base address: (ssizetype) ((sizetype) i_13 * 4)
constant offset from base address: 4
step: 0
base alignment: 8
base misalignment: 0
offset alignment: 8
step alignment: 128
base_object: p[_1]
...

resulting in:
...
gcc/testsuite/gcc.target/nvptx/slp.c:13:3: note: Detected interleaving load
p[i_13] and p[_1]
...


III.

With unsigned int, we have different offset of base address (note that _1 ==
i_13 + 1):
...
Creating dr for p[i_13]
analyze_innermost: success.
base_address: 
offset from base address: (ssizetype) ((sizetype) i_13 * 4)
constant offset from base address: 0
step: 0
base alignment: 8
base misalignment: 0
offset alignment: 8
step alignment: 128
base_object: p[i_13]
Creating dr for p[_1]
analyze_innermost: success.
base_address: 
offset from base address: (ssizetype) ((sizetype) _1 * 4)
constant offset from base address: 0
step: 0
base alignment: 8
base misalignment: 0
offset alignment: 4
step alignment: 128
base_object: p[_1]
...

resulting in:
...
gcc/testsuite/gcc.target/nvptx/slp.c:13:3: note: not consecutive access b_6 =
p[_1];
gcc/testsuite/gcc.target/nvptx/slp.c:13:3: note: not consecutive access a_5 =
p[i_13];
...


IV.

On x86_64 -m32, the test-case is not vectorized (reason: 'unrolling required in
basic block SLP'), but the interleaving load is recognized, both with int and
unsigned int.

On x86_64 -m64, we have:
- for int, detected interleaving load, but test-case not vectorized (reason:
  'unrolling required in basic block SLP')
- for unsigned int, we got failure to detect interleaving load, just as in III.

[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 #3 from Tom de Vries  ---
(In reply to Richard Biener from comment #2)
> So maybe finally a testcase where that SCEV analysis did sth useful...
> 
> x86_64 testcase should be possible with changing the datatype to double?

Yep.

This fails to vectorize with -O2 -ftree-slp-vectorize:

double p[1000] __attribute__((aligned(8)));
double p2[1000] __attribute__((aligned(8)));

void __attribute__((noinline, noclone))
foo ()
{
  double a, b;

  unsigned int i;
  for (i = 0; i < 1000; i += 2)
{
  a = p[i];
  b = p[i+1];

  p2[i] = a;
  p2[i+1] = b;
}
}
...

Changing 'i' to type int allows it to be vectorized.

[Bug tree-optimization/81620] [8 Regression] ICE in is_inv_store_elimination_chain, at tree-predcom.c:1651 with -O3

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||seurer at gcc dot gnu.org

--- Comment #2 from amker at gcc dot gnu.org ---
*** Bug 81637 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/81637] [8 regression] compilation of 416.gamess from spec2006 fails starting with r250670

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from amker at gcc dot gnu.org ---
I think this duplicates PR81620.

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

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Alexander Monakov from comment #6)
> TLS canary is initialized by the libc; in Glibc sources you can grep for
> THREAD_STACK_SET_GUARD.
> 
> In this example the leftmost byte of the SSP canary is overwritten by a
> zero. This does not change the canary because Glibc deliberately zeroes that
> leftmost byte (presumably, to harden against information-leak attacks when a
> string function like strcpy can be used to copy the canary value in an
> attacker-controlled manner):
> 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-
> osinfo.h;h=823cd8224df939134018fbd8f0227e9f501393ab;hb=HEAD#l63
> 
> So what is the GCC bug here? What do we want to change?

Thank you Alexander for explanation. Making the last byte '\0' makes sense.
Thus we need to only fix the second issue with missing -lssp and the PR will be
fix.
Patch has been already sent to ML.

[Bug lto/81612] lto1: internal compiler error: Segmentation fault

[vctrex at mailfence dot com]

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

--- Comment #2 from vctrex at mailfence dot com ---
The arduino code is:

void setup() {
  Serial.begin(9600);
}

void loop() {
}

Arduino:1.8.3 (Linux), Płytka:"Arduino/Genuino Uno"

/usr/lib/arduino/arduino-builder -dump-prefs -logger=machine -hardware
/usr/lib/arduino/hardware -tools /usr/lib/arduino/tools-builder
-built-in-libraries /usr/lib/arduino/libraries -libraries
/home/vctrex/Kod/Arduino/libraries -fqbn=arduino:avr:uno -ide-version=10803
-build-path /tmp/arduino_build_621292 -warnings=all -build-cache
/tmp/arduino_cache_74036 -prefs=build.warn_data_percentage=75 -verbose
/tmp/arduino_modified_sketch_352971/ReadASCIIString.ino
/usr/lib/arduino/arduino-builder -compile -logger=machine -hardware
/usr/lib/arduino/hardware -tools /usr/lib/arduino/tools-builder
-built-in-libraries /usr/lib/arduino/libraries -libraries
/home/vctrex/Kod/Arduino/libraries -fqbn=arduino:avr:uno -ide-version=10803
-build-path /tmp/arduino_build_621292 -warnings=all -build-cache
/tmp/arduino_cache_74036 -prefs=build.warn_data_percentage=75 -verbose
/tmp/arduino_modified_sketch_352971/ReadASCIIString.ino
Using board 'uno' from platform in folder:
/usr/lib/arduino/hardware/arduino/avr
Using core 'arduino' from platform in folder:
/usr/lib/arduino/hardware/arduino/avr
Detecting libraries used...
"/usr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions
-ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E
-CC -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10803 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR   "-I/usr/lib/arduino/hardware/arduino/avr/cores/arduino"
"-I/usr/lib/arduino/hardware/arduino/avr/variants/standard"
"/tmp/arduino_build_621292/sketch/ReadASCIIString.ino.cpp" -o "/dev/null"
Generating function prototypes...
"/usr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions
-ffunction-sections -fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E
-CC -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10803 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR   "-I/usr/lib/arduino/hardware/arduino/avr/cores/arduino"
"-I/usr/lib/arduino/hardware/arduino/avr/variants/standard"
"/tmp/arduino_build_621292/sketch/ReadASCIIString.ino.cpp" -o
"/tmp/arduino_build_621292/preproc/ctags_target_for_gcc_minus_e.cpp"
"/usr/lib/arduino/tools-builder/ctags/5.8-arduino11/ctags" -u
--language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives
"/tmp/arduino_build_621292/preproc/ctags_target_for_gcc_minus_e.cpp"
Kompilowanie szkicu...
"/usr/bin/avr-g++" -c -g -Os -Wall -Wextra -std=gnu++11 -fpermissive
-fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics
-MMD -flto -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10803 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR   "-I/usr/lib/arduino/hardware/arduino/avr/cores/arduino"
"-I/usr/lib/arduino/hardware/arduino/avr/variants/standard"
"/tmp/arduino_build_621292/sketch/ReadASCIIString.ino.cpp" -o
"/tmp/arduino_build_621292/sketch/ReadASCIIString.ino.cpp.o"
Compiling libraries...
Compiling core...
Using precompiled core
Linking everything together...
"/usr/bin/avr-gcc" -Wall -Wextra -Os -g -flto -fuse-linker-plugin
-Wl,--gc-sections -mmcu=atmega328p  -o
"/tmp/arduino_build_621292/ReadASCIIString.ino.elf"
"/tmp/arduino_build_621292/sketch/ReadASCIIString.ino.cpp.o"
"/tmp/arduino_build_621292/../arduino_cache_74036/core/core_arduino_avr_uno_1463c1525e5674af859013f08ea32c59.a"
"-L/tmp/arduino_build_621292" -lm
lto1: internal compiler error: Segmentation fault
0x8b64df crash_signal
../../gcc/toplev.c:333
0x7fb8faf8ea8f ???
   
/builddir/glibc-2.25/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7428b6 maybe_record_node
../../gcc/ipa-devirt.c:2468
0x747245 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, bool)
../../gcc/ipa-devirt.c:3186
0x747d0e possible_polymorphic_call_targets(cgraph_edge*, bool*, void**, bool)
../../gcc/ipa-utils.h:115
0x747d0e ipa_devirt
../../gcc/ipa-devirt.c:3597
0x747d0e execute
../../gcc/ipa-devirt.c:3913
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/avr-gcc returned 1 exit status
compilation terminated.
/usr/bin/avr-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
exit status 1
Błąd kompilacji dla płytki Arduino/Genuino Uno.

And here is Seria.begin() definiton which will probably come handy.
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/HardwareSerial.h

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

[ubizjak at gmail dot com]

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

Bug ID: 81641
   Summary: Assemble failure with named address spaces and
-masm=intel
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Using -O -masm=intel following testcase (gcc.target/i386/addr-space-2.c):

--cut here--
int test(void)
{
  int __seg_fs *f = (int __seg_fs *)16;
  int __seg_gs *g = (int __seg_gs *)16;
  return *f + *g;
}
--cut here--

compiles to:

mov eax, DWORD PTR gs:ds:16
add eax, DWORD PTR fs:ds:16
ret

Fortunately (?) gas doesn't error out on this assembly and generates correct
object file:

 :
   0:   65 8b 04 25 10 00 00mov%gs:0x10,%eax
   7:   00 
   8:   64 03 04 25 10 00 00add%fs:0x10,%eax
   f:   00 
  10:   c3  retq

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 08:32:37 2017
New Revision: 250760

URL: https://gcc.gnu.org/viewcvs?rev=250760=gcc=rev
Log:
PR tree-optimization/81588
* tree-ssa-reassoc.c (optimize_range_tests_var_bound): If
ranges[i].in_p, invert comparison code ccode.  For >/>=,
swap rhs1 and rhs2 and comparison code unconditionally,
for rank is BIT_IOR_EXPR.

* gcc.dg/tree-ssa/pr81588.c: New test.
* gcc.dg/pr81588.c: New test.
* gcc.c-torture/execute/pr81588.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr81588.c
trunk/gcc/testsuite/gcc.dg/pr81588.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81588.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 08:43:45 2017
New Revision: 250761

URL: https://gcc.gnu.org/viewcvs?rev=250761=gcc=rev
Log:
PR tree-optimization/81588
* tree-ssa-reassoc.c (optimize_range_tests_var_bound): If
ranges[i].in_p, invert comparison code ccode.  For >/>=,
swap rhs1 and rhs2 and comparison code unconditionally,
for rank is BIT_IOR_EXPR.

* gcc.dg/tree-ssa/pr81588.c: New test.
* gcc.dg/pr81588.c: New test.
* gcc.c-torture/execute/pr81588.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/pr81588.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr81588.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/tree-ssa/pr81588.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-ssa-reassoc.c

[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Aug  1 09:20:08 2017
New Revision: 250764

URL: https://gcc.gnu.org/viewcvs?rev=250764=gcc=rev
Log:
PR tree-optimization/81627
* tree-predcom.c (prepare_finalizers): Always rewrite into loop
closed ssa form for store-store chain.

gcc/testsuite
* gcc.dg/tree-ssa/pr81627.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81627.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug c++/81640] [8 Regression] ICE in lookup_fnfields_slot_nolazy w/ -Wshadow=compatible-local

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
Version|7.0 |8.0
   Target Milestone|--- |8.0

[Bug c++/81642] New: -Wtype-limits should not trigger for defined numbers

[seikusaro at web dot de]

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

Bug ID: 81642
   Summary: -Wtype-limits should not trigger for defined numbers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seikusaro at web dot de
  Target Milestone: ---

Hi,
My Problem is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712

bool foo(const unsigned port)
{
  if(port

[Bug c++/81642] -Wtype-limits should not trigger for defined numbers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I don't think the fact that NUM_IFC comes from a macro should be relevant to
whether the warning is emitted or not, that will just hide real bugs in other
code.

[Bug target/81639] New: ICE in rtl_verify_bb_insns, at cfgrtl.c:2669 with a naked function

[marxin at gcc dot gnu.org]

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

Bug ID: 81639
   Summary: ICE in rtl_verify_bb_insns, at cfgrtl.c:2669 with a
naked function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: uros at gcc dot gnu.org
  Target Milestone: ---

Following test-case ICEs starting from r250736:

$ cat /tmp/ice.i
__attribute__ ((naked)) a () { b (); }

$ ./xgcc -B. /tmp/ice.i -Os
/tmp/ice.i:1:25: warning: return type defaults to ‘int’ [-Wimplicit-int]
 __attribute__ ((naked)) a () { b (); }
 ^
/tmp/ice.i: In function ‘a’:
/tmp/ice.i:1:32: warning: implicit declaration of function ‘b’
[-Wimplicit-function-declaration]
 __attribute__ ((naked)) a () { b (); }
^
/tmp/ice.i:1:1: error: in basic block 2:
 __attribute__ ((naked)) a () { b (); }
 ^
/tmp/ice.i:1:1: error: flow control insn inside a basic block
(insn 16 17 6 2 (trap_if (const_int 1 [0x1])
(const_int 6 [0x6])) "/tmp/ice.i":1 -1
 (nil))
during RTL pass: pro_and_epilogue
/tmp/ice.i:1:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.c:2669
0x5a1de4 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x760305 rtl_verify_bb_insns
../../gcc/cfgrtl.c:2669
0x760305 rtl_verify_flow_info_1
../../gcc/cfgrtl.c:2755
0x760322 rtl_verify_flow_info
../../gcc/cfgrtl.c:2997
0x747bde verify_flow_info()
../../gcc/cfghooks.c:257
0xab31c9 execute_function_todo
../../gcc/passes.c:2002
0xab4222 execute_todo
../../gcc/passes.c:2044

[Bug testsuite/81624] [8 Regression] FAIL: gcc.target/i386/pr59501-3a.c scan-assembler-not and[^\n\r]*sp

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #2 from Andrey Guskov  ---
Also having this.

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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
To answer myself, child_index doesn't need to be equal to i, e.g. if some
operand is constant in all the statements, then there is no SLP child for it.
If there are no NULL oprnd, then we can as well just start from one above the
previous child_index, what we before this change.
The question for NULL oprnd is whether the omitted operand will always be a
SSA_NAME which always has (or always does not have) a corresponding
SLP_TREE_CHILDREN child node.  If it is not unconditional, then perhaps we need
to say add an index integer into struct _slp_tree and use those numbers to find
the slp child or lack thereof based on the position of the argument, not its
value.

[Bug target/81639] ICE in rtl_verify_bb_insns, at cfgrtl.c:2669 with a naked function

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-01
Version|7.0 |8.0
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
We have to prevent sibcalls in naked functions.

--cut here--
Index: i386.c
===
--- i386.c  (revision 250757)
+++ i386.c  (working copy)
@@ -94,6 +94,7 @@ static rtx legitimize_pe_coff_extern_decl (rtx, bo
 static rtx legitimize_pe_coff_symbol (rtx, bool);
 static void ix86_print_operand_address_as (FILE *, rtx, addr_space_t, bool);
 static bool ix86_save_reg (unsigned int, bool, bool);
+static bool ix86_function_naked (const_tree);

 #ifndef CHECK_STACK_LIMIT
 #define CHECK_STACK_LIMIT (-1)
@@ -7929,6 +7930,9 @@ ix86_function_ok_for_sibcall (tree decl, tree exp)
   rtx a, b;
   bool bind_global = decl && !targetm.binds_local_p (decl);

+  if (ix86_function_naked (current_function_decl))
+return false;
+
   /* Sibling call isn't OK if there are no caller-saved registers
  since all registers must be preserved before return.  */
   if (cfun->machine->no_caller_saved_registers)
--cut here--

[Bug c++/81640] [8 Regression] ICE in lookup_fnfields_slot_nolazy w/ -Wshadow=compatible-local

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
I don't think we should be adding -lssp automatically. 
-mstack-protector-guard=
is meant mainly for kernel or special purpose libraries, libssp.a we build in
gcc is just one of the many possible implementations of the _FORTIFY_SOURCE
etc. stuff, only if the C library doesn't provide that.  The same stuff can
come from many other spots, C libraries, kernel, ...

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-01
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Patch in testing:

--cut here--
Index: i386.c
===
--- i386.c  (revision 250757)
+++ i386.c  (working copy)
@@ -19442,7 +19448,7 @@ ix86_print_operand_address_as (FILE *file, rtx add
   /* Displacement only requires special attention.  */
   if (CONST_INT_P (disp))
{
- if (ASSEMBLER_DIALECT == ASM_INTEL && parts.seg ==
ADDR_SPACE_GENERIC)
+ if (ASSEMBLER_DIALECT == ASM_INTEL && ADDR_SPACE_GENERIC_P (as))
fputs ("ds:", file);
  fprintf (file, HOST_WIDE_INT_PRINT_DEC, INTVAL (disp));
}
--cut here--

[Bug fortran/53542] Diagnostic of USE-associated variables shows original instead of renamed symbol name

[dominiq at gcc dot gnu.org]

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

--- Comment #3 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Aug  1 09:02:58 2017
New Revision: 250762

URL: https://gcc.gnu.org/viewcvs?rev=250762=gcc=rev
Log:
2017-08-01  Dominique d'Humieres  

PR fortran/53542
* expr.c (gfc_check_init_expr): Use the renamed name.

PR testsuite/53542
* gfortran.dg/use_30.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/use_30.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/81640] New: [8 Regression] ICE in lookup_fnfields_slot_nolazy w/ -Wshadow=compatible-local

[marxin at gcc dot gnu.org]

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

Bug ID: 81640
   Summary: [8 Regression] ICE in lookup_fnfields_slot_nolazy w/
-Wshadow=compatible-local
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
  Target Milestone: ---

Starting from r250440 we ICE on:

$ cat ice.ii
struct a;
template 
void
c ()
{
  b d, e;
  if (e)
a d;
}

$ g++ ice.ii -Wshadow=compatible-local
ice.ii: In function ‘void c()’:
ice.ii:8:7: internal compiler error: Segmentation fault
 a d;
   ^
0xd90eff crash_signal
../../gcc/toplev.c:338
0x7ef213 lookup_fnfields_slot_nolazy(tree_node*, tree_node*)
../../gcc/cp/search.c:1577
0x6050bc build_user_type_conversion_1
../../gcc/cp/call.c:3741
0x60699b implicit_conversion
../../gcc/cp/call.c:1899
0x60bd46 can_convert_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:10448
0x72c99b check_local_shadow
../../gcc/cp/name-lookup.c:2084
0x72c99b do_pushdecl
../../gcc/cp/name-lookup.c:2416
0x72c99b pushdecl(tree_node*, bool)
../../gcc/cp/name-lookup.c:2479
0x6ac905 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5057
0x767477 cp_parser_init_declarator
../../gcc/cp/parser.c:19433
0x76eadc cp_parser_simple_declaration
../../gcc/cp/parser.c:12951
0x76f9d5 cp_parser_block_declaration
../../gcc/cp/parser.c:12776
0x7704a9 cp_parser_declaration_statement
../../gcc/cp/parser.c:12371
0x74b123 cp_parser_statement
../../gcc/cp/parser.c:10854
0x770c3b cp_parser_implicitly_scoped_statement
../../gcc/cp/parser.c:12433
0x74b953 cp_parser_selection_statement
../../gcc/cp/parser.c:11329
0x74b953 cp_parser_statement
../../gcc/cp/parser.c:10715
0x74c1e0 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11190
0x74c2af cp_parser_compound_statement
../../gcc/cp/parser.c:11144
0x7656b8 cp_parser_function_body
../../gcc/cp/parser.c:21608

[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 #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue Aug  1 08:26:14 2017
New Revision: 250759

URL: https://gcc.gnu.org/viewcvs?rev=250759=gcc=rev
Log:
PR target/80846
* optabs.def (vec_extract_optab, vec_init_optab): Change from
a direct optab to conversion optab.
* optabs.c (expand_vector_broadcast): Use convert_optab_handler
with GET_MODE_INNER as last argument instead of optab_handler.
* expmed.c (extract_bit_field_1): Likewise.  Use vector from
vector extraction if possible and optab is available.
* expr.c (store_constructor): Use convert_optab_handler instead
of optab_handler.  Use vector initialization from smaller
vectors if possible and optab is available.
* tree-vect-stmts.c (vectorizable_load): Likewise.
* doc/md.texi (vec_extract, vec_init): Document that the optabs
now have two modes.
* config/i386/i386.c (ix86_expand_vector_init): Handle expansion
of vec_init from half-sized vectors with the same element mode.
* config/i386/sse.md (ssehalfvecmode): Add V4TI case.
(ssehalfvecmodelower, ssescalarmodelower): New mode attributes.
(reduc_plus_scal_v8df, reduc_plus_scal_v4df, reduc_plus_scal_v2df,
reduc_plus_scal_v16sf, reduc_plus_scal_v8sf, reduc_plus_scal_v4sf,
reduc__scal_, reduc_umin_scal_v8hi): Add element mode
after mode in gen_vec_extract* calls.
(vec_extract): Renamed to ...
(vec_extract): ... this.
(vec_extract): New expander.
(rotl3, rotr3, 3, ashrv2di3): Add
element mode after mode in gen_vec_init* calls.
(VEC_INIT_HALF_MODE): New mode iterator.
(vec_init): Renamed to ...
(vec_init): ... this.
(vec_init): New expander.
* config/i386/mmx.md (vec_extractv2sf): Renamed to ...
(vec_extractv2sfsf): ... this.
(vec_initv2sf): Renamed to ...
(vec_initv2sfsf): ... this.
(vec_extractv2si): Renamed to ...
(vec_extractv2sisi): ... this.
(vec_initv2si): Renamed to ...
(vec_initv2sisi): ... this.
(vec_extractv4hi): Renamed to ...
(vec_extractv4hihi): ... this.
(vec_initv4hi): Renamed to ...
(vec_initv4hihi): ... this.
(vec_extractv8qi): Renamed to ...
(vec_extractv8qiqi): ... this.
(vec_initv8qi): Renamed to ...
(vec_initv8qiqi): ... this.
* config/rs6000/vector.md (VEC_base_l): New mode attribute.
(vec_init): Renamed to ...
(vec_init): ... this.
(vec_extract): Renamed to ...
(vec_extract): ... this.
* config/rs6000/paired.md (vec_initv2sf): Renamed to ...
(vec_initv2sfsf): ... this.
* config/rs6000/altivec.md (splitter, altivec_copysign_v4sf3,
vec_unpacku_hi_v16qi, vec_unpacku_hi_v8hi, vec_unpacku_lo_v16qi,
vec_unpacku_lo_v8hi, mulv16qi3, altivec_vreve2): Add
element mode after mode in gen_vec_init* calls.
* config/aarch64/aarch64-simd.md (vec_init): Renamed to ...
(vec_init): ... this.
(vec_extract): Renamed to ...
(vec_extract): ... this.
* config/aarch64/iterators.md (Vel): New mode attribute.
* config/s390/s390.c (s390_expand_vec_strlen, s390_expand_vec_movstr):
Add element mode after mode in gen_vec_extract* calls.
* config/s390/vector.md (non_vec_l): New mode attribute.
(vec_extract): Renamed to ...
(vec_extract): ... this.
(vec_init): Renamed to ...
(vec_init): ... this.
* config/s390/s390-builtins.def (s390_vlgvb, s390_vlgvh, s390_vlgvf,
s390_vlgvf_flt, s390_vlgvg, s390_vlgvg_dbl): Add element mode after
vec_extract mode.
* config/arm/iterators.md (V_elem_l): New mode attribute.
* config/arm/neon.md (vec_extract): Renamed to ...
(vec_extract): ... this.
(vec_extractv2di): Renamed to ...
(vec_extractv2didi): ... this.
(vec_init): Renamed to ...
(vec_init): ... this.
(reduc_plus_scal_, reduc_plus_scal_v2di, reduc_smin_scal_,
reduc_smax_scal_, reduc_umin_scal_,
reduc_umax_scal_, neon_vget_lane, neon_vget_laneu):
Add element mode after gen_vec_extract* calls.
* config/mips/mips-msa.md (vec_init): Renamed to ...
(vec_init): ... this.
(vec_extract): Renamed to ...
(vec_extract): ... this.
* config/mips/loongson.md (vec_init): Renamed to ...
(vec_init): ... this.
* config/mips/mips-ps-3d.md (vec_initv2sf): Renamed to ...
(vec_initv2sfsf): ... this.
(vec_extractv2sf): Renamed to ...
(vec_extractv2sfsf): ... this.
(reduc_plus_scal_v2sf, reduc_smin_scal_v2sf, reduc_smax_scal_v2sf):
Add element mode after gen_vec_extract* calls.
* config/mips/mips.md (unitmode): New mode iterator.
  

[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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Testing patch(es).

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/81640] [8 Regression] ICE in lookup_fnfields_slot_nolazy w/ -Wshadow=compatible-local

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that:
  if (MAYBE_CLASS_TYPE_P (totype))
/* Use lookup_fnfields_slot instead of lookup_fnfields to avoid
   creating a garbage BASELINK; constructors can't be inherited. 
*/
ctors = lookup_fnfields_slot (totype, complete_ctor_identifier);
calls lookup_fnfields_slot with just MAYBE_CLASS_TYPE_P, not CLASS_TYPE_P, but
lookup_fnfields_slot does complete_type, so perhaps that is fine.
Unfortunately the r250440 commit removed the
  if (!CLASS_TYPE_P (type))
return -1;
part from lookup_fnfields_slot_nolazy that made this work before.
So either we should readd it there (in the form of if (!CLASS_TYPE_P (type))
return NULL_TREE; ), or not call lookup_fnfields_slot_nolazy from
lookup_fnfields_slot like:
-  return lookup_fnfields_slot_nolazy (type, name);
+  if (CLASS_TYPE_P (type))
+return lookup_fnfields_slot_nolazy (type, name);
+  return NULL_TREE;
(seems other lookup_fnfields_slot_nolazy callers should likely ensure that it
is a CLASS_TYPE_P, either explicitly, or through using types from binfo
accessors).

[Bug target/81635] nvptx SLP test cases regressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So maybe finally a testcase where that SCEV analysis did sth useful...

x86_64 testcase should be possible with changing the datatype to double?

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|target  |tree-optimization
   Target Milestone|--- |8.0
Summary|nvptx SLP test cases|[8 Regression] nvptx SLP
   |regressions |test cases regressions

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[marxin at gcc dot gnu.org]

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

--- Comment #10 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #8)
> I don't think we should be adding -lssp automatically. 
> -mstack-protector-guard=
> is meant mainly for kernel or special purpose libraries, libssp.a we build
> in gcc is just one of the many possible implementations of the
> _FORTIFY_SOURCE etc. stuff, only if the C library doesn't provide that.  The
> same stuff can come from many other spots, C libraries, kernel, ...

As mentioned above, I'm not expert in this area. If you believe it should not
be added automatically then please close this PR as invalid. Thanks.

[Bug middle-end/81400] Stack smashing not caught by stack protector strong and allowing me to stack smash

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

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

[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 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 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 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 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 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/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

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 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 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 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 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 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 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 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/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 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 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 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 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 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 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 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 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 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 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/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 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 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 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 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 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 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 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/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 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 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 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/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/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 c/80383] wrong caret location and missing detail in warning: initializer element is not a constant expression on a signed overflow

[egallager at gcc dot gnu.org]

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

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  ---
(In reply to Martin Sebor from comment #0)
> The caret in the pedantic warnings issued for the following test case points
> to the wrong subexpression, making the warning confusing.  The caret should
> point to the shift expression and the operands should be underlined.  It
> would help if the warning also explained why the result of the shift
> expression isn't a constant expression.  Perhaps -Wshift-overflow=2 should
> be enabled by -Wpedantic?
> 
> $ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
> const int i = 1 << (sizeof (int) * __CHAR_BIT__ - 1);
> const int j = 1 << (sizeof (int) * __CHAR_BIT__);
> b.c:1:15: warning: initializer element is not a constant expression
> [-Wpedantic]
>  const int i = 1 << (sizeof (int) * __CHAR_BIT__ - 1);
>^
> b.c:2:17: warning: left shift count >= width of type [-Wshift-count-overflow]
>  const int j = 1 << (sizeof (int) * __CHAR_BIT__);
>  ^~
> b.c:2:15: warning: initializer element is not a constant expression
> [-Wpedantic]
>  const int j = 1 << (sizeof (int) * __CHAR_BIT__);
>^
> 

Confirmed for this part at least.

> In contrast, with -Wshift-overlow=2, GCC prints the following.  With
> -Wshift-overflow and -Wshift-count-overflow the caret is in the right place
> (but the operands aren't underlined).
> 
> b.c:1:17: warning: result of ‘1 << 31’ requires 33 bits to represent, but
> ‘int’ only has 32 bits [-Wshift-overflow=]
>  const int i = 1 << (sizeof (int) * __CHAR_BIT__ - 1);
>  ^~
> b.c:1:15: warning: initializer element is not a constant expression
> [-Wpedantic]
>  const int i = 1 << (sizeof (int) * __CHAR_BIT__ - 1);
>^
> b.c:2:17: warning: left shift count >= width of type [-Wshift-count-overflow]
>  const int j = 1 << (sizeof (int) * __CHAR_BIT__);
>  ^~
> b.c:2:15: warning: initializer element is not a constant expression
> [-Wpedantic]
>  const int j = 1 << (sizeof (int) * __CHAR_BIT__);
>^
> 

I tried testing this but it looks like the -Wshift-overflow=2 option has
broken; I'll have to open a separate bug about that:

$ /usr/local/bin/gcc -c -O2 -S -Wall -Wextra -Wpedantic -Wshift-overlow=2
80383.c
gcc: error: unrecognized command line option ‘-Wshift-overlow=2’; did you mean
‘-Wshift-overflow=’?
$ /usr/local/bin/gcc -c -O2 -S -Wall -Wextra -Wpedantic -Wshift-overlow 80383.c
gcc: error: unrecognized command line option ‘-Wshift-overlow’; did you mean
‘-Wshift-overflow’?

[Bug target/81639] ICE in rtl_verify_bb_insns, at cfgrtl.c:2669 with a naked function

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Uroš Bizjak  ---
Fixed.

[Bug c/80454] -Wmissing-braces wrongly warns about universal zero initializer {0}

[egallager at gcc dot gnu.org]

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

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, and the placement of the fixit hint looks weird, too:

$ /usr/local/bin/gcc -c -Wmissing-braces 80454.c
80454.c:5:56: warning: missing braces around initializer [-Wmissing-braces]
 struct { struct { union_t a; long b; } x; int y; } u = { { 0 }, 1 };
^
{ }
$

[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #3)
> On Wed, 12 Apr 2017, pascal_cuoq at hotmail dot com wrote:
> 
> > Since the open-source world divides the C compilation platform described by
> > the C standard into C compilers (Clang, GCC) and standard libraries (Glibc,
> > musl, ...), with the implementation of varargs on the compiler side and the
> > implementation of scanf on the standard library side, it would make sense to
> > document that on target platforms where the representation of pointers is
> > uniform, the compilers allow va_arg(ap, void*) to consume any pointer
> > argument.
> 
> Note that this is documented in POSIX (XSI-shaded, in the specification of 
> stdarg.h).

So in that case it should be easy to just put a reference to the POSIX docs in
the GCC docs

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

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Created attachment 41878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41878=edit
Reduced test-case

Reduced test-case that contains maybe uninitialized warning from the mentioned
commit. Note that release_ssa diff in probabilities is following:

--- /tmp/good/pr81638.i.049t.release_ssa2017-08-01 13:22:44.009392386
+0200
+++ /tmp/bad/pr81638.i.049t.release_ssa 2017-08-01 13:21:37.164092117 +0200
@@ -183,25 +183,25 @@
[1.67%] [count: INV]:
   _5 = a ();
   if (_5 != 0)
-goto ; [67.00%] [count: INV]
+goto ; [51.12%] [count: INV]
   else
-goto ; [33.00%] [count: INV]
+goto ; [48.88%] [count: INV]

-   [0.55%] [count: INV]:
+   [0.82%] [count: INV]:
   _6 = a ();
   if (_6 != 0)
 goto ; [33.00%] [count: INV]
   else
 goto ; [67.00%] [count: INV]

-   [0.18%] [count: INV]:
+   [0.27%] [count: INV]:
   _7 = a ();
   if (_7 != 0)
 goto ; [33.00%] [count: INV]
   else
 goto ; [67.00%] [count: INV]

-   [0.06%] [count: INV]:
+   [0.09%] [count: INV]:
   bt ();

[100.00%] [count: INV]:

which then causes the convergence. I guess it's another from set of false
positives.

[Bug rtl-optimization/81644] ICE in rtl_verify_bb_insn, BBRO pass duplicates BB that ends with flow control insn

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 CC||law at redhat dot com

--- Comment #1 from Uroš Bizjak  ---
Adding CC.

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

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Created attachment 41882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41882=edit
Suggested patch

Patch I'm suggesting. Can you David please test it?

[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 #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #4)
> Looking at the x86_64 example, the difference between the signed and
> unsigned case happens here in split_constant_offset_1:

Same thing for nvptx.

[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/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 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 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 ;)