[Bug debug/84408] [8 regression] gcc.dg/plugin/poly-int-07_plugin.c compilation times out with -g

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Mar  8 08:27:56 2018
New Revision: 258355

URL: https://gcc.gnu.org/viewcvs?rev=258355&root=gcc&view=rev
Log:
[LVU] reset view at function entry, omit views at line zero

Location views might be associated with locations that lack line
number information (line number zero), but since we omit .loc
directives that would have been issued with line number zero, we also
omit the symbolic view numbers that would have been issued at such
points.

Resetting views at function entry points address some of these issues,
and alleviate the huge chains of symbolic views that have burdened
assemblers since we disabled -ginternal-reset-location-views by
default, but other problems of undefined views remain when it's not
the whole function that lacks line number info, just parts of it.

So, when we encounter a request to output a view that may have been
referenced, but we decide to omit the .loc because the line is zero,
we will now omit the view as well, i.e., we will internally regard
that view as zero-numbered.

for  gcc/ChangeLog

PR debug/84404
PR debug/84408
* dwarf2out.c (struct dw_line_info_table): Update comments for
view == -1.
(FORCE_RESET_NEXT_VIEW): New.
(FORCE_RESETTING_VIEW_P): New.
(RESETTING_VIEW_P): Check for -1 too.
(ZERO_VIEW_P): Likewise.
(new_line_info_table): Force-reset next view.
(dwarf2out_begin_function): Likewise.
(dwarf2out_source_line): Simplify zero_view_p initialization.
Test FORCE_RESETTING_VIEW_P and RESETTING_VIEW_P instead of
view directly.  Omit view when omitting .loc at line 0.

for  gcc/testsuite/ChangeLog

PR debug/84404
PR debug/84408
* gcc.dg/graphite/pr84404.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr84404.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva  ---
Author: aoliva
Date: Thu Mar  8 08:27:56 2018
New Revision: 258355

URL: https://gcc.gnu.org/viewcvs?rev=258355&root=gcc&view=rev
Log:
[LVU] reset view at function entry, omit views at line zero

Location views might be associated with locations that lack line
number information (line number zero), but since we omit .loc
directives that would have been issued with line number zero, we also
omit the symbolic view numbers that would have been issued at such
points.

Resetting views at function entry points address some of these issues,
and alleviate the huge chains of symbolic views that have burdened
assemblers since we disabled -ginternal-reset-location-views by
default, but other problems of undefined views remain when it's not
the whole function that lacks line number info, just parts of it.

So, when we encounter a request to output a view that may have been
referenced, but we decide to omit the .loc because the line is zero,
we will now omit the view as well, i.e., we will internally regard
that view as zero-numbered.

for  gcc/ChangeLog

PR debug/84404
PR debug/84408
* dwarf2out.c (struct dw_line_info_table): Update comments for
view == -1.
(FORCE_RESET_NEXT_VIEW): New.
(FORCE_RESETTING_VIEW_P): New.
(RESETTING_VIEW_P): Check for -1 too.
(ZERO_VIEW_P): Likewise.
(new_line_info_table): Force-reset next view.
(dwarf2out_begin_function): Likewise.
(dwarf2out_source_line): Simplify zero_view_p initialization.
Test FORCE_RESETTING_VIEW_P and RESETTING_VIEW_P instead of
view directly.  Omit view when omitting .loc at line 0.

for  gcc/testsuite/ChangeLog

PR debug/84404
PR debug/84408
* gcc.dg/graphite/pr84404.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr84404.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[marxin at gcc dot gnu.org]

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

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

Well, I've got following reduced test-case. It comes from chromium project and
my question is how can user easily modify source code to make older GCC
releases happy :) ?

[Bug rtl-optimization/84682] [6/7/8 Regression] internal compiler error: Segmentation fault (process_address_1)

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Created attachment 43594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43594&action=edit
candidate patch

Here's what I'm testing

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
> So, the -Wstringop-truncation would need to do the suggested alias search
> for the store rather than next statement it does now, and in addition to
> that would need to ignore ASAN_CHECK, because those are guaranteed not to
> actually read the passed memory, just to check corresponding shadow memory.

Which is probably similar to what was seen in PR84307, am I right?

[Bug sanitizer/84732] false-positive -Wstringop-truncation warning with -fsanitize-coverage=trace-pc

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Martin Liška from comment #2)
> > I guess it somehow confuses VRP, Martin can you please take a look? Note
> > that __builtin___sanitizer_cov_trace_pc is pure function, can't modify
> > memory in original program.
> 
> No, __builtin___sanitizer_cov_trace_pc is certainly not pure and can't
> really be, otherwise would optimize them all away (nothing uses their void
> return value),
> so the problem is that it invalidates all recorded string lengths, at least
> those that escape (but in this testcase it is a global variable).
> As __sanitizer_cov_trace_pc is a user-supplied function, I don't really
> think we can assume anything on it (e.g. that it will not change any global
> or escaped local variables, it can change them and most likely will do at
> least some of them, otherwise it would be useless).

I see, I was probably too eager :)

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #30 from Christophe Lyon  ---
(In reply to Martin Liška from comment #29)
> Should be fixed on all active branches.

Actually the backport to gcc-6-branch introduced a regression. On arm, I'm
seeing:
lto1: fatal error: missing resolution data for _ZTV4base
compilation terminated.
lto-wrapper: fatal error:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabihf/gcc3/gcc/testsuite/g++2/../../xg++
returned 1 exit status
compilation terminated.
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/arm-none-linux-gnueabihf/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -flto
-flto-partition=1to1
UNRESOLVED: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o execute
-flto -flto-partition=1to1

Similar regressions on:
g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -flto
-flto-partition=1to1
g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0 -flto
-flto-partition=none -fuse-linker-plugin
g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O0
-flto -flto-partition=none -fuse-linker-plugin
g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link, -O0
-flto -fuse-linker-plugin -fno-fat-lto-objects 
g++.dg/torture/pr67600.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)


On aarch64, one of the testcases now produces an ICE:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/gcc/testsuite/g++3/../../xg++
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/gcc/testsuite/g++3/../../
cp_lto_20091210-1_0.o cp_lto_20091210-1_1.o g++_tg.o
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf
-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/libstdc++-v3/include
-I/libstdc++-v3/libsupc++ -I/libstdc++-v3/include/backward
-I/libstdc++-v3/testsuite/util -fmessage-length=0 -O0 -flto
-flto-partition=none -fuse-linker-plugin -specs=aem-ve.specs
-L/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/./libstdc++-v3/src/.libs
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/aarch64-none-elf/./libstdc++-v3/src/.libs
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -o
g++-dg-lto-20091210-1-01.exe
lto1: internal compiler error: in register_resolution, at lto/lto.c:840
0x5dd465 register_resolution
/gcc/lto/lto.c:840
0x5ddf57 lto_read_decls
/gcc/lto/lto.c:1792
0x5dff11 lto_file_finalize
/gcc/lto/lto.c:2064
0x5dff11 lto_create_files_from_ids
/gcc/lto/lto.c:2074
0x5dff11 lto_file_read
/gcc/lto/lto.c:2115
0x5dff11 read_cgraph_and_symbols
/gcc/lto/lto.c:2825
0x5dff11 lto_main()
/gcc/lto/lto.c:3337
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:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-elf/gcc3/gcc/testsuite/g++3/../../xg++
returned 1 exit status
compilation terminated.
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/aarch64-none-elf/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link,
-O0 -flto -flto-partition=none -fuse-linker-plugin (internal compiler error)

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Thank you, may I please ask you for the IPA CP dump file for not affected
revision (r256887). Do I understand the numbers right that version with
.resid_.constprop.1 is slower?

[Bug target/84751] ICE with debug build of gcc GIMPLE pass: store-merging or IPA pass: cp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||powerpc64-linux
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1

[Bug target/84756] Multiplication done twice just to get upper and lower parts of product

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
We immediately narrow "return (Longer)a*b;" to "return a*b;" which makes it
hard to CSE later.
If you can, it would be better to write the code as:
Longer mul = (Longer)a*b;
... use mul twice ...

Not sure what the best place would be for this optimization. Somewhere in RTL
when we don't care about signed/unsigned? Earlier in value numbering, checking
for each mult if a widening version is already available? Other, say like we
check if cos and sin are called on the same argument?

[Bug c/84755] GCC 4.6.0 build error with GCC-4.8.5 in Ubuntu 16.04 LTS

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Richard Biener  ---
As said, both compilers in question are no longer supported.

[Bug gcov-profile/82457] libgcov fork and exec hooks not always used

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
Author: marxin
Date: Thu Mar  8 08:52:39 2018
New Revision: 258356

URL: https://gcc.gnu.org/viewcvs?rev=258356&root=gcc&view=rev
Log:
Backport r254137

2018-03-08  Martin Liska  

Backport from mainline
2017-10-27  Martin Liska  

PR gcov-profile/82457
* doc/invoke.texi: Document that one needs a non-strict ISO mode
for fork-like functions to be properly instrumented.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/doc/invoke.texi

[Bug target/84757] [7/8 Regression] Useless MOVs and PUSHes to store results of MUL

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2018-03-08
 Ever confirmed|0   |1
Summary|Useless MOVs and PUSHes to  |[7/8 Regression] Useless
   |store results of MUL|MOVs and PUSHes to store
   ||results of MUL
   Target Milestone|--- |7.4

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

[Bug other/82352] [7 Regression] comdat-local function called by void h::i() outside its comdat

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
Author: marxin
Date: Thu Mar  8 08:56:20 2018
New Revision: 258358

URL: https://gcc.gnu.org/viewcvs?rev=258358&root=gcc&view=rev
Log:
Backport r256226

2018-03-08  Martin Liska  

Backport from mainline
2018-01-04  Martin Liska  

PR ipa/82352
* ipa-icf.c (sem_function::merge): Do not cross comdat boundary.
2018-03-08  Martin Liska  

Backport from mainline
2018-01-04  Martin Liska  

PR ipa/82352
* g++.dg/ipa/pr82352.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr82352.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-icf.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug gcov-profile/82633] Document GCOV and function removal (-fkeep-inline-functions, -fkeep-static-functions)

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Thu Mar  8 08:55:59 2018
New Revision: 258357

URL: https://gcc.gnu.org/viewcvs?rev=258357&root=gcc&view=rev
Log:
Backport r254257

2018-03-08  Martin Liska  

Backport from mainline
2017-10-31  Martin Liska  

PR gcov-profile/82633
* doc/gcov.texi: Document -fkeep-{static,inline}-functions and
their interaction with GCOV infrastructure.
* configure.ac: Add -fkeep-{inline,static}-functions to
coverage_flags.
* configure: Regenerate.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/configure
branches/gcc-6-branch/gcc/configure.ac
branches/gcc-6-branch/gcc/doc/gcov.texi

[Bug gcov-profile/82457] libgcov fork and exec hooks not always used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #13 from Martin Liška  ---
Should be fixed on all active branches.

[Bug debug/77844] [5 Regression] Compilation of simple C++ example exhaust memory

[marxin at gcc dot gnu.org]

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

--- Comment #13 from Martin Liška  ---
Author: marxin
Date: Thu Mar  8 08:56:45 2018
New Revision: 258359

URL: https://gcc.gnu.org/viewcvs?rev=258359&root=gcc&view=rev
Log:
Backport r243662

2018-03-08  Martin Liska  

Backport from mainline
2016-12-14  Jakub Jelinek  

PR debug/77844
* valtrack.c: Include rtl-iter.h.
(struct rtx_subst_pair): Add insn field.
(propagate_for_debug_subst): If pair->to contains at least 2
regs, create a DEBUG_INSN with a debug temp before pair->insn
and replace from with the debug temp instead of pair->to.
(propagate_for_debug): Initialize p.insn.
* combine.c (insn_uid_check): New inline function.
(INSN_COST, LOG_LINKS): Use it instead of INSN_UID.
(find_single_use, combine_instructions,
cant_combine_insn_p, try_combine): Use NONDEBUG_INSN_P instead of
INSN_P.
2018-03-08  Martin Liska  

Backport from mainline
2016-12-14  Jakub Jelinek  

PR debug/77844
* g++.dg/opt/pr77844.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/opt/pr77844.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/combine.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/valtrack.c

[Bug gcov-profile/82633] Document GCOV and function removal (-fkeep-inline-functions, -fkeep-static-functions)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Liška  ---
Should be fixed on all active branches.

[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug ipa/82107] [6 Regression] O2 optimisation on amd64 leads to error

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/84735] [8 Regression] Describe recent gcov data file format changes in gcov-io.h

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Thu Mar  8 09:05:26 2018
New Revision: 258360

URL: https://gcc.gnu.org/viewcvs?rev=258360&root=gcc&view=rev
Log:
Document gcov-io (PR gcov-profile/84735).

2018-03-08  Martin Liska  

PR gcov-profile/84735
* doc/gcov.texi: Document usage of profile files.
* gcov-io.h: Document changes in the format.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/gcov.texi
trunk/gcc/gcov-io.h

[Bug gcov-profile/84735] [8 Regression] Describe recent gcov data file format changes in gcov-io.h

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #9 from Alexandre Oliva  ---
Fixed

[Bug tree-optimization/84746] [8 Regression] ICE on valid code at -O2 and -O3: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||8.0
   Target Milestone|8.0 |7.4
Summary|[8 Regression] ICE on valid |[7 Regression] ICE on valid
   |code at -O2 and -O3:|code at -O2 and -O3:
   |Segmentation fault  |Segmentation fault
   Priority|P2  |P1
  Known to work|8.0 |
   Target Milestone|7.4 |8.0
Summary|[7 Regression] ICE on valid |[8 Regression] ICE on valid
   |code at -O2 and -O3:|code at -O2 and -O3:
   |Segmentation fault  |Segmentation fault

--- Comment #8 from Richard Biener  ---
Fixed on trunk, I'm eventually going to backport a variant of this.

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  8 09:23:44 2018
New Revision: 258361

URL: https://gcc.gnu.org/viewcvs?rev=258361&root=gcc&view=rev
Log:
2018-03-08  Richard Biener  

PR tree-optimization/84746
* tree-ssa-pre.c (find_leader_in_sets): Deal with SET1 being NULL.
(phi_translate): Pass in destination ANTIC_OUT set.
(phi_translate_1): Likewise.  For a simplified result lookup
a leader in ANTIC_OUT and AVAIL_OUT, not the ANTIC_IN sets.
(phi_translate_set): Adjust.
(do_pre_regular_insertion): Likewise.
(do_pre_partial_partial_insertion): Likewise.

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

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

[Bug tree-optimization/84746] [8 Regression] ICE on valid code at -O2 and -O3: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||8.0
   Target Milestone|8.0 |7.4
Summary|[8 Regression] ICE on valid |[7 Regression] ICE on valid
   |code at -O2 and -O3:|code at -O2 and -O3:
   |Segmentation fault  |Segmentation fault
   Priority|P2  |P1
  Known to work|8.0 |
   Target Milestone|7.4 |8.0
Summary|[7 Regression] ICE on valid |[8 Regression] ICE on valid
   |code at -O2 and -O3:|code at -O2 and -O3:
   |Segmentation fault  |Segmentation fault

--- Comment #8 from Richard Biener  ---
Fixed on trunk, I'm eventually going to backport a variant of this.

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  8 09:23:44 2018
New Revision: 258361

URL: https://gcc.gnu.org/viewcvs?rev=258361&root=gcc&view=rev
Log:
2018-03-08  Richard Biener  

PR tree-optimization/84746
* tree-ssa-pre.c (find_leader_in_sets): Deal with SET1 being NULL.
(phi_translate): Pass in destination ANTIC_OUT set.
(phi_translate_1): Likewise.  For a simplified result lookup
a leader in ANTIC_OUT and AVAIL_OUT, not the ANTIC_IN sets.
(phi_translate_set): Adjust.
(do_pre_regular_insertion): Likewise.
(do_pre_partial_partial_insertion): Likewise.

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

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

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

[hubicka at ucw dot cz]

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

--- Comment #31 from Jan Hubicka  ---
I will take a look.

Honza

[Bug c++/84724] [7/8 Regression] internal compiler error: in single_succ_edge, at basic-block.h:339 with a declaration of __builtin_trap

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 43595
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43595&action=edit
gcc8-pr84724.patch

Untested fix.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #32 from Martin Liška  ---
Reopened.

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

[marxin at gcc dot gnu.org]

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

--- Comment #33 from Martin Liška  ---
Can't reproduce the ICE on aarch64. There's my resolution file:

cat -- -lm.res
2
20091210-1_0.o 20
213 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN5Base1D2Ev
206 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTV5Base1
216 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN5Base1D1Ev
261 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN4Base1fEv
265 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZThn8_N4Base1fEv
268 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN4BaseD2Ev
246 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTV4Base
270 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN4BaseD1Ev
273 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN4BaseD0Ev
275 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZN5Base1D0Ev
299 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTS5Base1
312 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTI5Base1
326 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTS5Base2
328 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTI5Base2
336 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTS4Base
362 a66530621f3cf044 PREVAILING_DEF_IRONLY _ZTI4Base
181 a66530621f3cf044 RESOLVED_DYN __gxx_personality_v0
323 a66530621f3cf044 RESOLVED_DYN _ZTVN10__cxxabiv117__class_type_infoE
368 a66530621f3cf044 RESOLVED_DYN _ZTVN10__cxxabiv121__vmi_class_type_infoE
284 a66530621f3cf044 RESOLVED_DYN _ZdlPvm
20091210-1_1.o 25
213 e10871a982460b97 PREEMPTED_IR _ZN5Base1D2Ev
206 e10871a982460b97 PREEMPTED_IR _ZTV5Base1
216 e10871a982460b97 PREEMPTED_IR _ZN5Base1D1Ev
279 e10871a982460b97 PREVAILING_DEF_IRONLY _ZN3Foo1gEv
282 e10871a982460b97 PREEMPTED_IR _ZN5Base1D0Ev
285 e10871a982460b97 PREVAILING_DEF main
291 e10871a982460b97 PREEMPTED_IR _ZN4BaseD2Ev
293 e10871a982460b97 PREEMPTED_IR _ZN4BaseD1Ev
296 e10871a982460b97 PREVAILING_DEF_IRONLY _ZN3FooD2Ev
264 e10871a982460b97 PREVAILING_DEF_IRONLY _ZTV3Foo
298 e10871a982460b97 PREVAILING_DEF_IRONLY _ZN3FooD1Ev
300 e10871a982460b97 PREVAILING_DEF_IRONLY _ZN3FooD0Ev
302 e10871a982460b97 PREEMPTED_IR _ZN4BaseD0Ev
332 e10871a982460b97 PREEMPTED_IR _ZTS5Base1
345 e10871a982460b97 PREEMPTED_IR _ZTI5Base1
364 e10871a982460b97 PREVAILING_DEF_IRONLY _ZTS3Foo
380 e10871a982460b97 PREVAILING_DEF_IRONLY _ZTI3Foo
181 e10871a982460b97 RESOLVED_DYN __gxx_personality_v0
253 e10871a982460b97 RESOLVED_IR _ZTV4Base
356 e10871a982460b97 RESOLVED_DYN _ZTVN10__cxxabiv117__class_type_infoE
386 e10871a982460b97 RESOLVED_DYN _ZTVN10__cxxabiv120__si_class_type_infoE
404 e10871a982460b97 RESOLVED_IR _ZTI4Base
306 e10871a982460b97 RESOLVED_IR _ZN4Base1fEv
308 e10871a982460b97 RESOLVED_IR _ZThn8_N4Base1fEv
317 e10871a982460b97 RESOLVED_DYN _ZdlPvm

Can you please Christophe attach yours and take a look why the ICE is
triggered?
Thanks.

[Bug c++/84076] [6/7/8 Regression] Warning about objects through POD mistakenly claims the object is a pointer

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 43596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43596&action=edit
gcc8-pr84076.patch

Untested fix.

[Bug target/70359] [6/7/8 Regression] Code size increase for ARM compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org

--- Comment #30 from Aldy Hernandez  ---
Created attachment 43597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43597&action=edit
untested patch implementing suggestion in comment 26

The attached untested patch attempts to implement the suggestion in comment 26
of replacing the out-of-loop pre-inc with post-inc values.

Richi, is this more or less what you had in mind?

Assuming this:

LOOP:
  # p_8 = PHI 
  ...
  p_19 = p_8 + 4294967295;
  goto LOOP:

The patch replaces:
  p_22 = p_8 + 4294967294;
  MEM[(char *)p_19 + 4294967295B] = 45;
into:
  p_22 = p_19 + 4294967295;
  *p_22 = 45;

This allows the backend to use auto-dec in two places:

strbr1, [r4, #-1]!
...
strblt  r3, [r4, #-1]!

...reducing the byte count from 116 to 104, but just shy of the 96 needed to
eliminate the regression.  I will discuss the missing bytes in a follow-up
comment, as they are unrelated to this IV adjustment patch.

It is worth noting that x86 also benefits from a reduction of 3 bytes with this
patch, as we remove 2 lea instructions: one within the loop, and one before
returning.  Thus, I believe this is a regression across the board, or at least
in multiple architectures.

A few comments...

While I see the benefit of hijacking insert_backedge_copies() for this, I am
not a big fan of changing the IL after the last tree dump (*t.optimized), as
the modified IL would only be visible in *r.expand.  Could we perhaps move this
to another spot?  Say after the last forwprop pass, or perhaps right before
expand?  Or perhaps have a *t.final dump right before expand?

As mentioned, this is only a proof of concept.  I made the test rather
restrictive.  I suppose we could relax the conditions and generalize it a bit. 
There are comments throughout showing what I had in mind.

[Bug gcov-profile/84758] New: Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Bug ID: 84758
   Summary: Wrong coverage for quite simple CFG
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following isolated test-case is wrong:

$ cat gcovbug2.c
int x, y;

static void
foo (int a, int b)
{
  {
if (a == 1 || a == 2)
  {
x = 4;
if (b == 3)
  x = 6;
  }
else
  x = 15;
  }
}

int
main (void)
{
  foo (2, 3);
  return 0;
}

$ gcc --coverage gcovbug2.c && ./a.out && gcov gcovbug2.c && cat
gcovbug2.c.gcov
File 'gcovbug2.c'
Lines executed:90.00% of 10
Creating 'gcovbug2.c.gcov'

-:0:Source:gcovbug2.c
-:0:Graph:gcovbug2.gcno
-:0:Data:gcovbug2.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int x, y;
-:2:
-:3:static void
1:4:foo (int a, int b)
-:5:{
-:6:  {
1:7:if (a == 1 || a == 2)
-:8:  {
1:9:x = 4;
2:   10:if (b == 3) < this line is wrong
1:   11:  x = 6;
-:   12:  }
-:   13:else
#:   14:  x = 15;
-:   15:  }
1:   16:}
-:   17:
-:   18:int
1:   19:main (void)
-:   20:{
1:   21:  foo (2, 3);
1:   22:  return 0;
-:   23:}

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #31 from rguenther at suse dot de  ---
On Thu, 8 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> Aldy Hernandez  changed:
> 
>What|Removed |Added
> 
>Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot 
> gnu.org
> 
> --- Comment #30 from Aldy Hernandez  ---
> Created attachment 43597
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43597&action=edit
> untested patch implementing suggestion in comment 26
> 
> The attached untested patch attempts to implement the suggestion in comment 26
> of replacing the out-of-loop pre-inc with post-inc values.
> 
> Richi, is this more or less what you had in mind?

Yes.

> Assuming this:
> 
> LOOP:
>   # p_8 = PHI 
>   ...
>   p_19 = p_8 + 4294967295;
>   goto LOOP:
> 
> The patch replaces:
>   p_22 = p_8 + 4294967294;
>   MEM[(char *)p_19 + 4294967295B] = 45;
> into:
>   p_22 = p_19 + 4294967295;
>   *p_22 = 45;
> 
> This allows the backend to use auto-dec in two places:
> 
> strbr1, [r4, #-1]!
> ...
> strblt  r3, [r4, #-1]!
> 
> ...reducing the byte count from 116 to 104, but just shy of the 96 needed to
> eliminate the regression.  I will discuss the missing bytes in a follow-up
> comment, as they are unrelated to this IV adjustment patch.
> 
> It is worth noting that x86 also benefits from a reduction of 3 bytes with 
> this
> patch, as we remove 2 lea instructions: one within the loop, and one before
> returning.  Thus, I believe this is a regression across the board, or at least
> in multiple architectures.
> 
> A few comments...
> 
> While I see the benefit of hijacking insert_backedge_copies() for this, I am
> not a big fan of changing the IL after the last tree dump (*t.optimized), as
> the modified IL would only be visible in *r.expand.  Could we perhaps move 
> this
> to another spot?  Say after the last forwprop pass, or perhaps right before
> expand?  Or perhaps have a *t.final dump right before expand?

I don't see a big problem here - but yes, for example doing it
during uncprop would be possible as well (moving all of
insert_backedge_copies then).  I'd not do this at this point though.

> As mentioned, this is only a proof of concept.  I made the test rather
> restrictive.  I suppose we could relax the conditions and generalize it a 
> bit. 
> There are comments throughout showing what I had in mind.

I'd have not restricted the out-of-loop IV use to IV +- CST but
instead did the transform

+   LOOP:
+ # p_8 = PHI 
+ ...
+ p_INC = p_8 - 1;
+ goto LOOP;
+ ... p_8 uses ...

to

+   LOOP:
+ # p_8 = PHI 
+ ...
+ p_INC = p_8 - 1;
+ goto LOOP;
  newtem_12 = p_INC + 1; // undo IV increment
  ... p_8 out-of-loop p_8 uses replaced with newtem_12 ...

so it would always work if we can undo the IV increment.

The disadvantage might be that we then rely on RTL optimizations
to combine the original out-of-loop constant add with the
newtem computation but I guess that's not too much to ask ;)
k

[Bug target/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[aldyh at gcc dot gnu.org]

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

--- Comment #32 from Aldy Hernandez  ---
As mentioned in the previous comment, the proposed patch brings down the count
from 116 to 108 on ARM, but is shy of the desired 96.

The missing bytes can be attributed to forwprop folding this (IL expanded for
illustration):

  if (ui_7 / 10 != 0)

into:

  if (ui_7 > 9)

More specifically, changing this:

  # ui_7 = PHI 
  ...
  ui_21 = ui_7 / 10;
  if (ui_21 != 0)

into:

  # ui_7 = PHI 
  ...
  ui_21 = ui_7 / 10;
  if (ui_7 > 9)

Inhibiting this optimization brings down the byte count to 92 which is even
lower than our 96 boogie man, so perhaps worth pursuing.  (Assumes my proposed
patch is also applied.)  I'm no expert, but isn't a EQ/NE with 0 preferable
than a <> with a non-zero?

If so, should we restrict the folding somewhat, or clean this up after the
fact?

For reference, the folding (in forwprop) is due to this match.pd pattern:

/* X / C1 op C2 into a simple range test.  */

...though eliminating it causes another pattern to pick up the slack and do the
same:

/* Transform:
 * (X / Y) == 0 -> X < Y if X, Y are unsigned.
 * (X / Y) != 0 -> X >= Y, if X, Y are unsigned.
 */

Eliminating both patterns "fixes" the problem.

Suggestions welcome :).

[Bug target/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[segher at gcc dot gnu.org]

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

--- Comment #33 from Segher Boessenkool  ---
The "> 9" transform reduces path length.  But foe -Os that is often not a
good idea.

[Bug debug/84456] [8 regression] gcc.dg/guality/pr49888.c fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-08
 CC||jakub at gcc dot gnu.org
  Component|testsuite   |debug
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
In gcc 7 as well as with -gvariable-location-views in trunk, the 6 problematic
tests are UNSUPPORTED, due to:
Breakpoint 1, f (p=p@entry=0x7fffd844) at
/usr/src/gcc-7/gcc/testsuite/gcc.dg/guality/pr49888.c:18
18v = 0; /* { dg-final { gdb-test 18 "!c" "1" } } */
pr49888.gdb:3: Error in sourced command file:
value has been optimized out
UNSUPPORTED: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1
etc.
On the trunk without location views, it is a FAIL instead:
Breakpoint 1, f (p=p@entry=0x7fffd7d4) at
/usr/src/gcc/gcc/testsuite/gcc.dg/guality/pr49888.c:18
18v = 0; /* { dg-final { gdb-test 18 "!c" "1" } } */
$1 = 0
$2 = 1
A debugging session is active.

Inferior 1 [process 11689] will be killed.

0 != 1
FAIL: gcc.dg/guality/pr49888.c   -O1  line 18 !c == 1

The *.final dump is still correct, on the trunk:
1: NOTE_INSN_DELETED
   25: NOTE_INSN_VAR_LOCATION{loc di:DI}! p var
4: NOTE_INSN_BASIC_BLOCK 2
   17: NOTE_INSN_PROLOGUE_END
3: NOTE_INSN_FUNCTION_BEG
   21: NOTE_INSN_BEGIN_STMT
   26: NOTE_INSN_VAR_LOCATION{loc [di:DI]}  ! c var
   22: NOTE_INSN_BEGIN_STMT
   23: NOTE_INSN_BEGIN_STMT
   11: [di:DI]=0x1
  REG_DEAD di:DI
   27: NOTE_INSN_VAR_LOCATION{loc (nil)}! c var
   24: NOTE_INSN_BEGIN_STMT
   13: [`v']=0
   18: NOTE_INSN_EPILOGUE_BEG
   19: simple_return
   20: barrier
   16: NOTE_INSN_DELETED
and in 7.3 similarly with the NOTE_INSN_BEGIN_STMT deleted.
1: NOTE_INSN_DELETED
   17: NOTE_INSN_VAR_LOCATION{loc di:DI}! p var
4: NOTE_INSN_BASIC_BLOCK 2
   13: NOTE_INSN_PROLOGUE_END
3: NOTE_INSN_FUNCTION_BEG
   18: NOTE_INSN_VAR_LOCATION{loc [di:DI]}  ! c var
8: [di:DI]=0x1
  REG_DEAD di:DI
   19: NOTE_INSN_VAR_LOCATION{loc (nil)}
9: [`v']=0
   14: NOTE_INSN_EPILOGUE_BEG
   15: simple_return
   16: barrier
   12: NOTE_INSN_DELETED

The bug is that the trunk without -gvariable-location-views makes:
.uleb128 0x2# (DIE (0xb4) DW_TAG_variable)
.ascii "c\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (pr49888.c)
.byte   0xa # DW_AT_decl_line
.byte   0x7 # DW_AT_decl_column
.long   0x41# DW_AT_type
.uleb128 0x2# DW_AT_location
.byte   0x75# DW_OP_breg5
.sleb128 0
out of it rather than the expected:
.uleb128 0x9# (DIE (0xaf) DW_TAG_variable)
.ascii "c\0"# DW_AT_name
.byte   0x1 # DW_AT_decl_file (pr49888.c)
.byte   0xa # DW_AT_decl_line
.long   0x40# DW_AT_type
.long   .LLST0  # DW_AT_location
that e.g. GCC 7 emits.

[Bug target/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de  ---
On Thu, 8 Mar 2018, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #32 from Aldy Hernandez  ---
> As mentioned in the previous comment, the proposed patch brings down the count
> from 116 to 108 on ARM, but is shy of the desired 96.
> 
> The missing bytes can be attributed to forwprop folding this (IL expanded for
> illustration):
> 
>   if (ui_7 / 10 != 0)
> 
> into:
> 
>   if (ui_7 > 9)
> 
> More specifically, changing this:
> 
>   # ui_7 = PHI 
>   ...
>   ui_21 = ui_7 / 10;
>   if (ui_21 != 0)
> 
> into:
> 
>   # ui_7 = PHI 
>   ...
>   ui_21 = ui_7 / 10;
>   if (ui_7 > 9)
> 
> Inhibiting this optimization brings down the byte count to 92 which is even
> lower than our 96 boogie man, so perhaps worth pursuing.  (Assumes my proposed
> patch is also applied.)  I'm no expert, but isn't a EQ/NE with 0 preferable
> than a <> with a non-zero?
> 
> If so, should we restrict the folding somewhat, or clean this up after the
> fact?
> 
> For reference, the folding (in forwprop) is due to this match.pd pattern:
> 
> /* X / C1 op C2 into a simple range test.  */
> 
> ...though eliminating it causes another pattern to pick up the slack and do 
> the
> same:
> 
> /* Transform:
>  * (X / Y) == 0 -> X < Y if X, Y are unsigned.
>  * (X / Y) != 0 -> X >= Y, if X, Y are unsigned.
>  */
> 
> Eliminating both patterns "fixes" the problem.
> 
> Suggestions welcome :).

In other places where this happened we add single_use () checks to
the patterns.  The :s isn't really effective for patterns that
simplify into "simple" expressions.  A patch doing that to the
two patterns in question would be OK I think.

Sth like

Index: gcc/match.pd
===
--- gcc/match.pd(revision 258359)
+++ gcc/match.pd(working copy)
@@ -1290,11 +1290,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* X / C1 op C2 into a simple range test.  */
 (for cmp (simple_comparison)
  (simplify
-  (cmp (trunc_div:s @0 INTEGER_CST@1) INTEGER_CST@2)
+  (cmp (trunc_div:s@3 @0 INTEGER_CST@1) INTEGER_CST@2)
   (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& integer_nonzerop (@1)
&& !TREE_OVERFLOW (@1)
-   && !TREE_OVERFLOW (@2))
+   && !TREE_OVERFLOW (@2)
+   && single_use (@3))
(with { tree lo, hi; bool neg_overflow;
   enum tree_code code = fold_div_compare (cmp, @1, @2, &lo, &hi,
   &neg_overflow); }

tough there is at least one constant simplification result where
we shouldn't apply this restriction so moving the single_use check
to multiple places below or factoring things a bit would be
appropriate.

Similar for the other pattern then.

[Bug target/70359] [6/7/8 Regression] Code size increase for x86/ARM/others compared to gcc-5.3.0

[rguenther at suse dot de]

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

--- Comment #35 from rguenther at suse dot de  ---
On Thu, 8 Mar 2018, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70359
> 
> --- Comment #33 from Segher Boessenkool  ---
> The "> 9" transform reduces path length.  But foe -Os that is often not a
> good idea.

Hm, indeed - the > 9 might be notably faster.  So it's not a clear
win to disable the folding here.

[Bug tree-optimization/84746] [7 Regression] ICE on valid code at -O2 and -O3: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||8.0
   Target Milestone|8.0 |7.4
Summary|[8 Regression] ICE on valid |[7 Regression] ICE on valid
   |code at -O2 and -O3:|code at -O2 and -O3:
   |Segmentation fault  |Segmentation fault

--- Comment #10 from Richard Biener  ---
Fixed on trunk, I'm eventually going to backport a variant of this.

[Bug gcov-profile/84758] Wrong coverage for quite simple CFG

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|8.0 |9.0

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Richard Biener from comment #13)
> So you can loses the TREE_ADDRESSABLE restriction somewhat in requiring at
> most one decl to be TREE_ADDRESSABLE - that's the one you need to keep, the
> others may become aliases.  Given TREE_ADDRESSABLE isn't reliable for
> !TREE_STATIC vars
> we can't merge any exported decls that way.  Consider
> 
> const int foo1;
> const int foo2;
> 
> int *bar();  // in other TU, returns address of foo1
> 
> int main ()
> {
>   if (bar() != &foo2)
> ...;
> }
> 
> not sure if we want to do hand-waving saying that we can't possibly have
> points-to sets mentioning those without seeing the function IL.  Well,
> might be similarly hand-waving as the reference aliasing issue.
> 
> So we could drop the TREE_STATIC restriction if TREE_ADDRESSABLE is reliable
> within the current TU.

Note that this issue happens only with -fmerge-all-constants. And we have
caveat
in documentation that using the option, pointer comparison can be broken:

Languages like C or C++ require each variable,
   including multiple instances of the same variable in recursive
calls, to have distinct locations, so using this option results in
non-conforming behavior.

Thus:

$ cat test.c
const int foo1 = 3;
const int foo2 = 3;

const int *
__attribute__((noinline))
bar()
{
  return &foo1;
}

int main ()
{
  if ((bar() - &foo2) == 0)
__builtin_abort ();

  return 0;
}

$ gcc test.c -O2 -fno-ipa-icf -fmerge-all-constants  && ./a.out 
Aborted (core dumped)

That said, would be Richi your comment in c#12 a sufficient fix?

[Bug tree-optimization/84552] [6/7/8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P4  |P2
   Target Milestone|8.0 |6.5
Summary|[8 Regression] Compile time |[6/7/8 Regression] Compile
   |hog w/ -O2  |time hog w/ -O2
   |-floop-nest-optimize|-floop-nest-optimize
   |-fno-tree-copy-prop |-fno-tree-copy-prop
   |-fno-tree-fre   |-fno-tree-fre
   |-fno-tree-loop-ivcanon  |-fno-tree-loop-ivcanon

--- Comment #3 from Richard Biener  ---
So this is really a latent issue and not dependent on -floop-nest-optimize.  It
materializes during unrolling where we perform SCEV analysis on not up-to-date
SSA form when analyzing.

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #14)
> (In reply to Richard Biener from comment #13)
> > So you can loses the TREE_ADDRESSABLE restriction somewhat in requiring at
> > most one decl to be TREE_ADDRESSABLE - that's the one you need to keep, the
> > others may become aliases.  Given TREE_ADDRESSABLE isn't reliable for
> > !TREE_STATIC vars
> > we can't merge any exported decls that way.  Consider
> > 
> > const int foo1;
> > const int foo2;
> > 
> > int *bar();  // in other TU, returns address of foo1
> > 
> > int main ()
> > {
> >   if (bar() != &foo2)
> > ...;
> > }
> > 
> > not sure if we want to do hand-waving saying that we can't possibly have
> > points-to sets mentioning those without seeing the function IL.  Well,
> > might be similarly hand-waving as the reference aliasing issue.
> > 
> > So we could drop the TREE_STATIC restriction if TREE_ADDRESSABLE is reliable
> > within the current TU.
> 
> Note that this issue happens only with -fmerge-all-constants. And we have
> caveat
> in documentation that using the option, pointer comparison can be broken:
> 
> Languages like C or C++ require each variable,
>including multiple instances of the same variable in recursive
> calls, to have distinct locations, so using this option results in
> non-conforming behavior.
> 
> Thus:
> 
> $ cat test.c
> const int foo1 = 3;
> const int foo2 = 3;
> 
> const int *
> __attribute__((noinline))
> bar()
> {
>   return &foo1;
> }
> 
> int main ()
> {
>   if ((bar() - &foo2) == 0)
> __builtin_abort ();
> 
>   return 0;
> }
> 
> $ gcc test.c -O2 -fno-ipa-icf -fmerge-all-constants  && ./a.out 
> Aborted (core dumped)

Sure, the caveat of -fmerge-all-constants is that different constants can be
merged.
But that doesn't imply that the #c0 failure is fine, the testcase doesn't
really care if kTestCases constant arrays from the two functions are merged
together or not, if not, they will be separate, if yes, they will be the same,
but if it doesn't try to compare them in any way, it should make zero
difference on the behavior.

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
(In reply to Martin Liška from comment #14)
> (In reply to Richard Biener from comment #13)
> > So you can loses the TREE_ADDRESSABLE restriction somewhat in requiring at
> > most one decl to be TREE_ADDRESSABLE - that's the one you need to keep, the
> > others may become aliases.  Given TREE_ADDRESSABLE isn't reliable for
> > !TREE_STATIC vars
> > we can't merge any exported decls that way.  Consider
> > 
> > const int foo1;
> > const int foo2;
> > 
> > int *bar();  // in other TU, returns address of foo1
> > 
> > int main ()
> > {
> >   if (bar() != &foo2)
> > ...;
> > }
> > 
> > not sure if we want to do hand-waving saying that we can't possibly have
> > points-to sets mentioning those without seeing the function IL.  Well,
> > might be similarly hand-waving as the reference aliasing issue.
> > 
> > So we could drop the TREE_STATIC restriction if TREE_ADDRESSABLE is reliable
> > within the current TU.
> 
> Note that this issue happens only with -fmerge-all-constants. And we have
> caveat
> in documentation that using the option, pointer comparison can be broken:
> 
> Languages like C or C++ require each variable,
>including multiple instances of the same variable in recursive
> calls, to have distinct locations, so using this option results in
> non-conforming behavior.
> 
> Thus:
> 
> $ cat test.c
> const int foo1 = 3;
> const int foo2 = 3;
> 
> const int *
> __attribute__((noinline))
> bar()
> {
>   return &foo1;
> }
> 
> int main ()
> {
>   if ((bar() - &foo2) == 0)
> __builtin_abort ();
> 
>   return 0;
> }
> 
> $ gcc test.c -O2 -fno-ipa-icf -fmerge-all-constants  && ./a.out 
> Aborted (core dumped)
> 
> That said, would be Richi your comment in c#12 a sufficient fix?

Hum, isn't the bug INVALID then?  Shouldn't we restrict -fmerge-all-constants
to not address-taken variables to not make the option useless?

The suggested fix in c#12 is a band-aid only.

What's the impact of not merging TREE_ADDRESSABLE decls into other decls?

I presume -fmerge-all-constants pre-dates ICF?

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #16)
> Hum, isn't the bug INVALID then?  Shouldn't we restrict -fmerge-all-constants

No.

> to not address-taken variables to not make the option useless?

-fmerge-all-constants is an extension where the addresses of the constant
variables may be the same even if without the option they would need to be
guaranteed to be different.  That is the whole point of the option, many people
just don't care about it and care more about .rodata size, so they have an
option to tell the compiler about it.

> I presume -fmerge-all-constants pre-dates ICF?

Yes, by far.  -fmerge-all-constants is from 2001, ICF from 2014.

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[vegard.nossum at gmail dot com]

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

--- Comment #2 from Vegard Nossum  ---
Created attachment 43598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43598&action=edit
ASAN output

I compiled gcc itself using -fstack-protector-all -fsanitize=address and it
occasionally gives me the "heap-use-after-free" error (log attached).

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[b7.10110111 at gmail dot com]

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

Ruslan  changed:

   What|Removed |Added

 CC||b7.10110111 at gmail dot com

--- Comment #1 from Ruslan  ---
This seems to be fixed in GCC 7: see https://godbolt.org/g/Mz3Qi6 for example.

[Bug target/84759] New: Calculation of quotient and remainder with constant denominator uses __umoddi3+__udivdi3 instead of __udivmoddi4

[b7.10110111 at gmail dot com]

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

Bug ID: 84759
   Summary: Calculation of quotient and remainder with constant
denominator uses __umoddi3+__udivdi3 instead of
__udivmoddi4
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

Starting from GCC 7, code calculating both quotient and remainder of a loong
division calls a single __udivmodti4. But this only happens for general values
of denominator, while for specific constants for some reason GCC still
generates calls to __umodti3 and __udivti3. See the following code (the picture
is the same for x86 and amd64 targets):

#ifdef __SIZEOF_INT128__
typedef __uint128_t Longer;
#else
typedef unsigned long long Longer;
#endif
typedef unsigned long Shorter;

Shorter divmod(Longer numerator, Shorter denominator, Shorter* remainder)
{
*remainder = numerator%denominator;
return numerator/denominator;
}

Shorter divmodConst(Longer numerator, Shorter* remainder)
{
const Shorter denominator = 100;
*remainder = numerator%denominator;
return numerator/denominator;
}

Here divmod is optimized, while divmodConst appears not optimized:

divmod:
sub esp, 28
xor edx, edx
mov eax, DWORD PTR [esp+40]
lea ecx, [esp+8]
sub esp, 12
pushecx
pushedx
pusheax
pushDWORD PTR [esp+60]
pushDWORD PTR [esp+60]
call__udivmoddi4
mov edx, DWORD PTR [esp+76]
mov ecx, DWORD PTR [esp+40]
mov DWORD PTR [edx], ecx
add esp, 60
ret
divmodConst:
pushedi
pushesi
sub esp, 4
mov esi, DWORD PTR [esp+16]
mov edi, DWORD PTR [esp+20]
push0
push100
pushedi
pushesi
call__umoddi3
add esp, 16
mov edx, DWORD PTR [esp+24]
mov DWORD PTR [edx], eax
push0
push100
pushedi
pushesi
call__udivdi3
add esp, 20
pop esi
pop edi
ret

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[vegard.nossum at gmail dot com]

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

--- Comment #3 from Vegard Nossum  ---
gcc/recog.c:2395 is:

2390 case '0': case '1': case '2': case '3': case '4':
2391 case '5': case '6': case '7': case '8': case '9':
2392   {
2393 char *end;
2394 op_alt[i].matches = strtoul (p, &end, 10);
2395 op_alt[op_alt[i].matches].matched = i;
2396 p = end;
2397   }
2398   continue;

It's a bit weird because I don't see any digits in the constraints in the test
case.

[Bug debug/84456] [8 regression] gcc.dg/guality/pr49888.c fail

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
So, the bug is that GCC 7's dw_loc_list tail:
  /* Try to avoid the overhead of a location list emitting a location
 expression instead, but only if we didn't have more than one
 location entry in the first place.  If some entries were not
 representable, we don't want to pretend a single entry that was
 applies to the entire scope in which the variable is
 available.  */
  if (list && loc_list->first->next)
gen_llsym (list);

has been replaced with:
  /* Try to avoid the overhead of a location list emitting a location
 expression instead, but only if we didn't have more than one
 location entry in the first place.  If some entries were not
 representable, we don't want to pretend a single entry that was
 applies to the entire scope in which the variable is
 available.  */
  maybe_gen_llsym (list);

where maybe_gen_llsym has:
  if (!list || (!list->dw_loc_next && !loc_list_has_views (list)))
return;

  gen_llsym (list);

That is not really equivalent; it is equivalent in the other spot, where it
used to be:
  if (list && list->dw_loc_next)
gen_llsym (list);
and now is:
  maybe_gen_llsym (list);
but in the first case, we were calling gen_llsym even when list &&
list->dw_loc_next == NULL, intentionally so, that means we got some location
note that would start the range and then another one that resets the range.

The following patch fixes this for me:
2018-03-08  Jakub Jelinek  

PR debug/84456
* dwarf2out.c (dw_loc_list): If list && loc_list->first->next, call
gen_llsym, otherwise call maybe_gen_llsym.

--- gcc/dwarf2out.c.jj  2018-03-02 00:15:54.704780976 +0100
+++ gcc/dwarf2out.c 2018-03-08 12:54:01.794054675 +0100
@@ -17076,7 +17076,10 @@ dw_loc_list (var_loc_list *loc_list, tre
  representable, we don't want to pretend a single entry that was
  applies to the entire scope in which the variable is
  available.  */
-  maybe_gen_llsym (list);
+  if (list && loc_list->first->next)
+gen_llsym (list);
+  else
+maybe_gen_llsym (list);

   return list;
 }

The maybe_gen_llsym will cover the case when -gvariable-location-views and
list && list->dw_loc_next == NULL && loc_list->first->next == NULL and the
single entry list has some non-zero view.

[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #14 from ktkachov at gcc dot gnu.org ---
I'm testing a patch for issue 2b) from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193#c6 . 

Thanks for Andrew for the report and thanks Martin for the analysis!

[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Thu Mar  8 12:17:36 2018
New Revision: 258363

URL: https://gcc.gnu.org/viewcvs?rev=258363&root=gcc&view=rev
Log:
tree-if-conv.c: fix ICE seen with -fno-tree-forwprop (PR
tree-optimization/84178)

PR tree-optimization/84178 reports a couple of source files that ICE inside
ifcvt when compiled with -03 -fno-tree-forwprop (trunk and gcc 7).

Both cases involve problems with ifcvt's per-BB gimplified predicates.

Testcase 1 fails this assertion within release_bb_predicate during cleanup:

283   if (flag_checking)
284 for (gimple_stmt_iterator i = gsi_start (stmts);
285  !gsi_end_p (i); gsi_next (&i))
286   gcc_assert (! gimple_use_ops (gsi_stmt (i)));

The testcase contains a division in the loop, which leads to
if_convertible_loop_p returning false (due to gimple_could_trap_p being true
for the division).  This happens *after* the per-BB gimplified predicates
have been created in predicate_bbs (loop).
Hence tree_if_conversion bails out to "cleanup", but the gimplified predicates
exist and make use of SSA names; for example this conjunction for two BB
conditions:

  _4 = h4.1_112 != 0;
  _175 = (signed char) _117;
  _176 = _175 >= 0;
  _174 = _4 & _176;

is using SSA names.

This assertion was added in r236498 (aka
c3deca2519d97c55876869c57cf11ae1e5c6cf8b):

2016-05-20  Richard Biener  

* tree-if-conv.c (add_bb_predicate_gimplified_stmts): Use
gimple_seq_add_seq_without_update.
(release_bb_predicate): Assert we have no operands to free.
(if_convertible_loop_p_1): Calculate post dominators later.
Do not free BB predicates here.
(combine_blocks): Do not recompute BB predicates.
(version_loop_for_if_conversion): Save BB predicates around
loop versioning.

* gcc.dg/tree-ssa/ifc-cd.c: Adjust.

The following patch fixes this by adding a call to gimple_seq_discard
to release_bb_predicate.  It also updates the assertion, so that
instead of asserting the stmts have no imm uses, instead assert that
they weren't added to a bb before discarding them (otherwise discarding
them would be a bug).  We know this is the case because
insert_gimplified_predicates has:

  /* Once the sequence is code generated, set it to NULL.  */
  set_bb_predicate_gimplified_stmts (bb, NULL);

but asserting it seems appropriate as a double-check.

The patch doesn't address the 2nd issue within PR tree-optimization/84178.

gcc/ChangeLog:
PR tree-optimization/84178
* tree-if-conv.c (release_bb_predicate): Remove the
the assertion that the stmts have NULL use_ops.
Discard the statements, asserting that they haven't
yet been added to a BB.

gcc/testsuite/ChangeLog:
PR tree-optimization/84178
* gcc.c-torture/compile/pr84178-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84178-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[ramana.radhakrishnan at foss dot arm.com]

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

--- Comment #18 from ramana.radhakrishnan at foss dot arm.com ---
On 07/03/2018 18:59, sudi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
> 
> --- Comment #17 from sudi at gcc dot gnu.org ---
> I looked up what other targets were doing and one thing found to be 
> interesting
> was that a lot of them are defining the target hook
> TARGET_BUILTIN_SETJMP_FRAME_VALUE. In AArch64 case I am suggesting to define 
> it
> to return the hard frame pointer. That seems to solve the issue with both the
> attached test case and the test that Wilco mentioned.
> 
> Does this look like it solves "mid-end versus back-end : who fixes this issue"
> problem?
> 
> I am still pretty new to knowing how the stack should actually look. So 
> calling
> for some help!
> 
> Sudi
> 

That looks sensible. Especially see the comment in arc/arc.c - that
seems to mirror the decision we want in AArch64 as well. The logic /
comment around this in the arc port seems quite reasonable to me and
looks like what we can have on AArch64 as well.

Ramana

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[vegard.nossum at gmail dot com]

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

--- Comment #4 from Vegard Nossum  ---
So I think the problem is that this loop in lra_set_insn_recog_data() counts
the number of commas and uses that as the number of alternatives:

1018   for (p =  constraints[0]; *p; p++)
1019 nalt += *p == ',';

And then later we can skip over the comma inside preprocess_constraints()
because 'T' is not recognised in the switch and then it does:

p += CONSTRAINT_LEN (c, p);

where CONSTRAINT_LEN for 'T' is 2:

static inline size_t
insn_constraint_len (char fc, const char *str ATTRIBUTE_UNUSED)
{
  switch (fc)
{
case 'B': return 2;
case 'T': return 2;
case 'W': return 2;
case 'Y': return 2;
default: break;
}
  return 1;
}

(so the real problematic bit of the constraint is this: "T,")

[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
(In reply to David Malcolm from comment #6)
> Author: dmalcolm
> Date: Thu Mar  8 12:17:36 2018
> New Revision: 258363

This fixes the testcase in comment #0 on trunk.  Not yet fixed for
gcc-7-branch.

The testcase in comment #2 still affects trunk and gcc-7-branch; candidate
patch for that is here:
  https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00376.html

[Bug target/84759] Calculation of quotient and remainder with constant denominator uses __umoddi3+__udivdi3 instead of __udivmoddi4

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
In the former case, the divmod transform takes place and we emit call to
__udivmoddi4. However it does't trigger for divmodConst, because we avoid
handling constants in the transform since expand_divmod has specialized
expansions for few constants, which would otherwise have been missed. I suppose
this could be somewhat improved.

Thanks,
Prathamesh

[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  8 12:56:40 2018
New Revision: 258364

URL: https://gcc.gnu.org/viewcvs?rev=258364&root=gcc&view=rev
Log:
2018-03-08  Richard Biener  

PR tree-optimization/84178
* tree-if-conv.c (combine_blocks): Move insert_gimplified_predicates
to caller.
(version_loop_for_if_conversion): Delay update_ssa call.
(tree_if_conversion): Delay update_ssa until after predicate
insertion.

* gcc.dg/torture/pr84178-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr84178-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

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

[hubicka at ucw dot cz]

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

--- Comment #34 from Jan Hubicka  ---
Hi,
I do not get any assertion at lto.c:840, so please also check if that still
reproduce
with current branch and let us know the backtrace.

Honza

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[rguenther at suse dot de]

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

--- Comment #18 from rguenther at suse dot de  ---
On Thu, 8 Mar 2018, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
> 
> --- Comment #17 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #16)
> > Hum, isn't the bug INVALID then?  Shouldn't we restrict 
> > -fmerge-all-constants
> 
> No.
> 
> > to not address-taken variables to not make the option useless?
> 
> -fmerge-all-constants is an extension where the addresses of the constant
> variables may be the same even if without the option they would need to be
> guaranteed to be different.  That is the whole point of the option, many 
> people
> just don't care about it and care more about .rodata size, so they have an
> option to tell the compiler about it.

That's not really an answer to the question ...

But anyway, we have precedence in points-to-set editing which we do
during RTL expansion to reflect variable coalescing.

So ... a different approach for fixing would be if ICF would keep

 a) a global bitmap of all DECL_UID that took part in any merging operation
 b) a mapping of merged DECL_UID to prevailing DECL_UID (which is also the
DECL_PT_UID of the merged ones)

then during IPA ICF transform phase do

  FOR_EACH_DEFINED_FUNCTION (...)
{
   FOR_EACH_SSA_NAME_FN (..., name)
 if (POINTER_TYPE_P (TREE_TYPE (name))
 && SSA_NAME_PTR_INFO (name))
   fixup_pt_set (&SSA_NAME_PTR_INFO (name)->pt);
   fixup_pt_set (fn->gimple_df->escaped);

   /* The above get's us to 99% I guess, at least catching the
  address compares.  Below also gets us aliasing correct
  but as said we're giving leeway to the situation with
  readonly vars anyway, so ... */
   FOR_EACH_BB_FN (...)
 for (each-stmt)
   if (is_gimple_call (...))
 {
   fixup_pt_set (gimple_call_use_set (call));
   fixup_pt_set (gimple_call_clobber_set (call));
 }
}

and fixup_pt_set essentially doing

  EXECUTE_IF_AND_IN_BITMAP (pt->vars, bitmap-of-merged-decls, 0, i, bi)
bitmap_set_bit (pt->vars, *merged_uid_to_pt_uid->get (i));

that would be a "real" fix, also allowing the forthcoming pointer
comparison optimization using two pointers (and thus two points-to
sets).

> > I presume -fmerge-all-constants pre-dates ICF?
> 
> Yes, by far.  -fmerge-all-constants is from 2001, ICF from 2014.

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |8.0

--- Comment #5 from Jakub Jelinek  ---
We have many loops that assume the constraints are sane and it is safe to skip
all the CONSTRAINT_LEN characters, so I think it is desirable to catch this
early.
asm_operand_ok already has:
  len = CONSTRAINT_LEN (c, constraint);
  do
constraint++;
  while (--len && *constraint);
  if (len)
return 0;
which catches multi-character constraints with '\0' in the middle of it, and
rejects those during vregs pass that also removes them:
  if (asm_noperands (PATTERN (insn)) >= 0)
{
  if (!check_asm_operands (PATTERN (insn)))
{
  error_for_asm (insn, "impossible constraint in %");
  /* For asm goto, instead of fixing up all the edges
 just clear the template and clear input operands
 (asm goto doesn't have any output operands).  */
  if (JUMP_P (insn))
{
  rtx asm_op = extract_asm_operands (PATTERN (insn));
  ASM_OPERANDS_TEMPLATE (asm_op) = ggc_strdup ("");
  ASM_OPERANDS_INPUT_VEC (asm_op) = rtvec_alloc (0);
  ASM_OPERANDS_INPUT_CONSTRAINT_VEC (asm_op) = rtvec_alloc (0);
}
  else
delete_insn (insn);
}
}
So I'm just adding a check for ',' inside such constraints too.

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

[clyon at gcc dot gnu.org]

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

--- Comment #35 from Christophe Lyon  ---
It took me a while to reproduce manually: there is an ICE at r258321, which is
fixed by the next backport (r258322), at which point there 6 failures on
aarch64-none-elf:
FAIL: g++.dg/lto/20081125 cp_lto_20081125_0.o-cp_lto_20081125_1.o link, -flto
-flto-partition=1to1
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0
-flto -flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/20090311 cp_lto_20090311_0.o-cp_lto_20090311_1.o link, -O0
-flto -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link,
-O0 -flto -flto-partition=none -fuse-linker-plugin
FAIL: g++.dg/lto/20091210-1 cp_lto_20091210-1_0.o-cp_lto_20091210-1_1.o link,
-O0 -flto -fuse-linker-plugin -fno-fat-lto-objects 
FAIL: g++.dg/torture/pr67600.C   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

But my first manual attempt at r258359 had no failure, so the above ones a
probably fixed between r258322 and r258359.

My validation is triggered at every commit on the release branches, so
sometimes this gives too much detail it seems :)

[Bug inline-asm/84742] internal compiler error: in process_alt_operands, at lra-constraints.c:2112

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 43599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43599&action=edit
gcc8-pr84742.patch

Untested fix.

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
Just having chat with Honza and he is curious why IPA passes should maintain
points-to-sets info as it's rebuild in pass_build_alias quite soon in post IPA
passes? Another question is why the pass_rebuild_alias isn't the first one and
is sitting after CCP?

Isn't also possible to release all points-to-sets before IPA passes? That can
save some memory.

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
How would IPA-PTA work then?

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[marxin at gcc dot gnu.org]

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

--- Comment #21 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #20)
> How would IPA-PTA work then?

Not having experience how that works, but I would expect a complete rebuild.
Similar to what the tree PTA does?

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #36 from Martin Liška  ---
That said it's fixed.

[Bug c++/80452] [DR 1579] incorrect value category deduced for return value

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
  return std::move(cv);

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[marxin at gcc dot gnu.org]

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

--- Comment #22 from Martin Liška  ---
(In reply to Martin Liška from comment #21)
> (In reply to Jakub Jelinek from comment #20)
> > How would IPA-PTA work then?
> 
> Not having experience how that works, but I would expect a complete rebuild.
> Similar to what the tree PTA does?

Note that the TREE PTA is just a TODO_rebuild_alias flag. Thus I would expect
IPA PTA is also a rebuild of PTA information.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[rai...@emrich-ebersheim.de]

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

--- Comment #15 from Rainer Emrich  ---
Hi Eric,

thanks for all your work.

Unfortunately your changes introduced an ICE while building binutils 2.19.1:

make[4]: Entering directory
'/opt/devel/SCRATCH/tmp.5VoInHZZvv/gcc-8.0.0/binutils-2.29.1/opcodes'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes  -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd  -I./../intl 
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
-o i386-dis.lo
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd -I./../intl
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c -o
i386-dis.o
during RTL pass: final
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c: In
function 'print_insn':
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c:13471:1:
internal compiler error: in i386_pe_seh_cold_init, at config/i386/winnt.c:913
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [Makefile:1005: i386-dis.lo] Error 1
make[4]: Leaving directory
'/opt/devel/SCRATCH/tmp.5VoInHZZvv/gcc-8.0.0/binutils-2.29.1/opcodes'

I did not run the testsuite so far. I always bootstrap gcc, build all
prerequisites with the just bootstrapped gcc and boostrap again using the
bootstrapped gcc as bootstrap compiler. This process has uncovered several
issues in the past, including this one.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[4]: *** [Makefile:1005: i386-dis.lo] Error 1
> make[4]: Leaving directory
> '/opt/devel/SCRATCH/tmp.5VoInHZZvv/gcc-8.0.0/binutils-2.29.1/opcodes'

Then do as indicated and open a new bug report.

[Bug target/84760] New: Finish implementation of __builtin_altivec_lvx_v1ti

[kelvin at gcc dot gnu.org]

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

Bug ID: 84760
   Summary: Finish implementation of __builtin_altivec_lvx_v1ti
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

The gcc/config/rs6000/rs6000-builtin.def source file contains an entry that
introduces the enumeration constant ALTIVEC_BUILTIN_LVX_V1TI and the built-in
function __builtin_atlivec_lvx_v1ti:

BU_ALTIVEC_X (LVX_V1TI, "lvx_v1ti", MEM)

The remainder of the implementation, which is required to define the prototype
for this function and to connect the function with its implementation, is
missing.  This was an apparent oversight at the time that this definition was
introduced.  T

[Bug ipa/84658] [7/8 Regression] -O3 -fmerge-all-constants causes incorrect for-each loop generation.

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de  ---
On Thu, 8 Mar 2018, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
> 
> --- Comment #22 from Martin Liška  ---
> (In reply to Martin Liška from comment #21)
> > (In reply to Jakub Jelinek from comment #20)
> > > How would IPA-PTA work then?
> > 
> > Not having experience how that works, but I would expect a complete rebuild.
> > Similar to what the tree PTA does?
> 
> Note that the TREE PTA is just a TODO_rebuild_alias flag. Thus I would expect
> IPA PTA is also a rebuild of PTA information.

IPA PTA rebuilds everything (and with -fipa-pta we should be fine).  The 
issue is the time between IPA ICF and the late pass_build_alias,
we do the "invalid" folding in pass_ccp.

And yes, we do want to do some scalar cleanup before running PTA.

If we'd decide not to then the "proper" place would probably be
pass_ipa_pta which then either would do local PTA or IPA PTA based
on the flag.

But that's too much for GCC 8 or 7.

[Bug sanitizer/84761] New: AddressSanitizer is not compatible with glibc 2.27 on x86

[vincent-gcc at vinc17 dot net]

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

Bug ID: 84761
   Summary: AddressSanitizer is not compatible with glibc 2.27 on
x86
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

After an upgrade to glibc 2.27 on a Debian/unstable machine, on a program that
does nothing, the AddressSanitizer segfaults with the 32-bit x86 ABI.

I have the following gcc-snapshot script:

#!/bin/sh
LD_LIBRARY_PATH=/usr/lib/gcc-snapshot/lib:$LD_LIBRARY_PATH
PATH=/usr/lib/gcc-snapshot/bin:$PATH
rpath=""
OLD_IFS="$IFS"
IFS=:
for i in $LD_RUN_PATH
do
  rpath="$rpath -Wl,-rpath -Wl,$i"
done
IFS="$OLD_IFS"
exec gcc -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/lib32 \
 -Wl,-rpath -Wl,/usr/lib/gcc-snapshot/libx32 $rpath "$@"

cventin:~> gcc-snapshot --version
gcc (Debian 20180216-1) 8.0.1 20180216 (experimental) [trunk revision 257720]
[...]
cventin:~> cat tst.c
int main (void)
{
  return 0;
}
cventin:~> gcc-snapshot -m32 -fsanitize=address tst.c -o tst
cventin:~> ./tst
AddressSanitizer:DEADLYSIGNAL
=
==25032==ERROR: AddressSanitizer: SEGV on unknown address 0xf7fa7e70 (pc
0xf7fa7e84 bp 0xffbf40ac sp 0xffbf406c T16777215)
==25032==The signal is caused by a WRITE memory access.
#0 0xf7fa7e83 in _dl_get_tls_static_info (/lib/ld-linux.so.2+0x11e83)
#1 0xf7ac147d  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0x10e47d)
#2 0xf7aafd27  (/usr/lib/gcc-snapshot/lib32/libasan.so.5+0xfcd27)
#3 0xf7fa591a  (/lib/ld-linux.so.2+0xf91a)
#4 0xf7f96cb9  (/lib/ld-linux.so.2+0xcb9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/ld-linux.so.2+0x11e83) in
_dl_get_tls_static_info
==25032==ABORTING

My original bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892096

The explanations given by Aurelien Jarno:


The AddressSanitizer is using glibc internal functions though dlsym(), and such
functions have the right to change in new major versions:

From libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:
|  void *get_tls_static_info_ptr = dlsym(RTLD_NEXT, "_dl_get_tls_static_info");

And on the glibc side:
| $ readelf -s /lib/ld-linux.so.2  | grep _dl_get_tls_static_info
|  4: 00011e7035 FUNCGLOBAL DEFAULT   12
_dl_get_tls_static_info@@GLIBC_PRIVATE

This has been discussed for example there:
https://www.sourceware.org/ml/libc-alpha/2018-02/msg00611.html

The AddressSanitizer people should discuss for a public API so that it doesn't
happen again. Otherwise it might break at every new glibc version.


In the mean time, it should at least be made compatible with glibc 2.27.

[Bug tree-optimization/84552] [6/7/8 Regression] Compile time hog w/ -O2 -floop-nest-optimize -fno-tree-copy-prop -fno-tree-fre -fno-tree-loop-ivcanon

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu Mar  8 14:41:39 2018
New Revision: 258365

URL: https://gcc.gnu.org/viewcvs?rev=258365&root=gcc&view=rev
Log:
2018-03-08  Richard Biener  

PR middle-end/84552
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Do not follow SSA names registered
for update.

* gcc.dg/graphite/pr84552.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/graphite/pr84552.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c

[Bug c++/84569] [6 Regression] g++ -g -O3 consumes all memory

[jorrit at jorrit dot de]

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

--- Comment #5 from Jö  ---
I can report that that indeed fixes the issue for us; the unit test now
compiles fine with gcc revision 258359.  Thanks a lot!

[Bug c/84762] New: GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

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

Bug ID: 84762
   Summary: GCC for PowerPC32 violates the SysV ABI spec for small
struct returns
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: powerpc-eabi

For an example like:

struct smallstruct { char a; char b; char c; };

struct smallstruct f(void)
{
  struct smallstruct s = { 0x11, 0x22, 0x33 };

  return s;
}

r3 should look like 0x11223300, but GCC returns 0x00112233 in r3 (with the '00'
part actually being undefined).

The relevant part of the spec
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf:

Aggregates or unions whose size is less than or equal to eight bytes shall be
returned in r3 and r4, as if they were first stored in memory area and then the
low-addressed word were loaded in r3 and the high-addressed word were loaded
into r4. Bits beyond the last member of the structure or union are not defined.

Or the older http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf says
nearly the same (with an additional alignment clause):

A structure or union whose size is less than or equal to 8 bytes shall be
returned in r3 and r4, as if it were first stored in an 8-byte aligned memory
area and then the low-addressed word were loaded into r3 and the high-addressed
word into r4. Bits beyond the last member of the structure or union are not
defined.

This was discovered during parameter passing tests as a difference to a
proprietary compiler.

As it is probably too late in the game to change GCC, this is more a
documentation request I guess.
Eventually -msvr4-struct-return could be extended to
-msvr4-struct-return={sysv,gnu} with 'gnu' as the (compile-time configurable?)
default.

[Bug target/84748] [8 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu Mar  8 15:50:25 2018
New Revision: 258366

URL: https://gcc.gnu.org/viewcvs?rev=258366&root=gcc&view=rev
Log:
[AArch64] PR target/84748: Mark *compare_cstore_insn as clobbering CC reg

In this wrong-code PR the combine pass ends up moving a CC-using instruction
past a *compare_cstore_insn
insn_and_split. After reload the *compare_cstore_insn splitter ends up
generating a SUBS instruction that
clobbers the condition flags, and things go bad.

The solution is simple, the *compare_cstore_insn pattern should specify
that it clobbers the CC register
so that combine (or any other pass) does not assume that it can move CC-using
patterns across it.

This patch does that and fixes the testcase.

The testcase FAILs on GCC 8 only, but the buggy pattern is in GCC 6 onwards, so
we should backport this as
a latent bug fix after it's had some time to bake in trunk.

Bootstrapped and tested on aarch64-none-linux-gnu.

PR target/84748
* config/aarch64/aarch64.md (*compare_cstore_insn): Mark pattern
as clobbering CC_REGNUM.

* gcc.c-torture/execute/pr84748.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr84748.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[wschmidt at gcc dot gnu.org]

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

--- Comment #1 from Bill Schmidt  ---
Hm.  For this one I think I would recommend we just remove the partial
implementation, provided that vec_ld already supports vector __int128.

[Bug target/84748] [6/7 Regression] wrong code with u128 at aarch64 at -O and and above

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P1  |P2
  Known to work||6.4.1
Summary|[8 Regression] wrong code   |[6/7 Regression] wrong code
   |with u128 at aarch64 at -O  |with u128 at aarch64 at -O
   |and and above   |and and above

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed on trunk. The testcase doesn't abort on the branches but the buggy
pattern is there so the fix is worth backporting. I'll do it once it's baked on
trunk for a bit

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #6 from Bill Schmidt  ---
We should keep this issue open for a different problem, though.  When swap
optimization doesn't succeed on such a loop, we don't end up optimizing away
the xxlnand associated with the vperm on Power8.  Currently that is only done
as part of swap optimization.  It's a minor savings but worth doing.

[Bug rtl-optimization/84753] GCC does not fold xxswapd followed by vperm

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
(In reply to sudi from comment #17)
> I looked up what other targets were doing and one thing found to be
> interesting was that a lot of them are defining the target hook
> TARGET_BUILTIN_SETJMP_FRAME_VALUE. In AArch64 case I am suggesting to define
> it to return the hard frame pointer. That seems to solve the issue with both
> the attached test case and the test that Wilco mentioned.
> 
> Does this look like it solves "mid-end versus back-end : who fixes this
> issue" problem?
> 
> I am still pretty new to knowing how the stack should actually look. So
> calling for some help!

This is not about stack layout but ensuring we don't corrupt the frame pointer
or the stack pointer. Any changes to SP/FP are inherently extremely risky and
need to be done exactly right or lots of things will fail.

There are too many issues to make a full list, but here are a few obvious ones:

1. The TARGET_BUILTIN_SETJMP_FRAME_VALUE only fixes the store of the frame
pointer, however it does not fix the landing pad, I see code like this:

str x29, [x3, #:lo12:.LANCHOR0]
mov x0, sp
stp x1, x0, [x2, 8]
bl  baz
.p2align 2
.L7:
sub x29, x29, #176
ldr w0, [x29, 172]
mov sp, x29

So now the store is correct, but when returning at L2 we corrupt the frame
pointer badly (and then the stack pointer as well)... This is basically the
same as pr60003.c but with an alloca added.

2. We still need to force the frame pointer to be saved,
TARGET_BUILTIN_SETJMP_FRAME_VALUE doesn't fix that.

3. __builtin_longjmp is still incorrect, like I showed in PR64242, it also
fails on AArch64:

#include 
#include 
void bug (jmp_buf buf)
{
  jmp_buf buf2;
  memcpy (buf2, buf, sizeof (jmp_buf));
  __builtin_longjmp (buf2, 1);
}

bug:
stp x29, x30, [sp, -336]!
mov x1, x0
mov x2, 312
mov x29, sp
add x0, x29, 24
bl  memcpy
ldr x0, [x29, 32]
ldr x29, [x29, 24]  // oops
ldr x1, [x29, 40]
mov sp, x1
br  x0

4. Trying to use setjmp and longjmp in the same function often gives this ICE:

during RTL pass: cse1
setjmp.c: In function ‘bug1’:
setjmp.c:86:1: internal compiler error: in mark_jump_label_1, at jump.c:1151
 }
 ^
0xa598f7 mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1151
0xa59a6b mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1211
0xa59a6b mark_jump_label_1
/home/wdijkstr/gcc/gcc/jump.c:1211
0xa59e17 mark_all_labels
/home/wdijkstr/gcc/gcc/jump.c:305
0xa59e17 rebuild_jump_labels_1
/home/wdijkstr/gcc/gcc/jump.c:74
0x128ce23 rest_of_handle_cse
/home/wdijkstr/gcc/gcc/cse.c:7628
0x128ce23 execute
/home/wdijkstr/gcc/gcc/cse.c:7662

5. Things get really interesting on ARM and Thumb-2 where there are multiple
frame pointer registers. This shows again why it is wrong to change the sp/fp
in the longjmp - for it to work correctly it must be done in the landing pad in
the function that has the setjmp.

[Bug target/84763] New: [8 Regression] ICE in i386_pe_seh_cold_init

[rai...@emrich-ebersheim.de]

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

Bug ID: 84763
   Summary: [8 Regression] ICE in i386_pe_seh_cold_init
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rai...@emrich-ebersheim.de
  Target Milestone: ---

Created attachment 43600
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43600&action=edit
preprocessed source

Building binutils 2.29.1 there's an ICE in i386_pe_seh_cold_init.

make[2]: Entering directory '/opt/devel/SCRATCH/tmp/opcodes'
/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes  -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd  -I./../intl 
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
-o i386-dis.lo
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I.
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes -I../bfd
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../include
-I/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/../bfd -I./../intl
-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144
-g -O2 -D__USE_MINGW_ACCESS -MT i386-dis.lo -MD -MP -MF .deps/i386-dis.Tpo -c
/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c -o
i386-dis.o
during RTL pass: final
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c: In
function 'print_insn':
D:/opt/devel/gnu/src/gcc-mingw-w64/binutils-2.29.1/opcodes/i386-dis.c:13471:1:
internal compiler error: in i386_pe_seh_cold_init, at config/i386/winnt.c:913
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1005: i386-dis.lo] Error 1
make[2]: Leaving directory '/opt/devel/SCRATCH/tmp/opcodes'

Caused by r258338.

[Bug target/84763] [8 Regression] ICE in i386_pe_seh_cold_init

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Started with my r204516 change aka
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00768.html
The changes in *.optimized dump look reasonable, fewer IVs:
   :
+  # RANGE [16, 4294967280]
+  _18 = _22 * 16;
+  # RANGE [0, 4294967295]
+  _9 = _18 + _6;
+  _3 = (void *) _9;

   :
   # PT = nonlocal 
   # ALIGN = 16, MISALIGN = 0
   # addr_23 = PHI 
-  # RANGE [0, 4294967295] NONZERO 0x00fff
-  # i_24 = PHI 
   __asm__ __volatile__("dcbf 0, %0" :  : "r" addr_23 : "memory");
-  # RANGE [0, 4294967295] NONZERO 0x00fff
-  i_14 = i_24 + 1;
   # PT = nonlocal 
   # ALIGN = 16, MISALIGN = 0
   addr_15 = addr_23 + 16;
-  if (i_14 != _22)
+  if (addr_15 != _3)

The * 16 is present in GIMPLE, but the right shift by 4 / division by 16 is
something added in the doloop pass later on, so this doesn't seem to be
something that can be optimized in GIMPLE.
On the trunk, we have in *.optimized:
  # RANGE [0, 268435455] NONZERO 268435455
  _20 = size_12 >> 4;
  if (_20 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 105119325]:
  # RANGE [16, 4294967280]
  _6 = _20 * 16;
  _4 = _1 + _6;
  _3 = (void *) _4;

   [local count: 955630224]:
  # PT = nonlocal null
  # ALIGN = 16, MISALIGN = 0
  # addr_21 = PHI 
  __asm__ __volatile__("dcbf 0, %0" :  : "r" addr_21 : "memory");
  # PT = nonlocal null
  # ALIGN = 16, MISALIGN = 0
  addr_15 = addr_21 + 16;
  if (_3 != addr_15)
goto ; [89.00%]
  else
goto ; [11.00%]
To optimize this on RTL we'd need to have accurate value range info, otherwise
optimizing (unsigned) (x << 4 + (cst << 4)) >> 4 into x + cst is not valid.
Before *.combine we have:
(insn 16 15 17 3 (set (reg:SI 135)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4]))) 269 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 128 [ _20 ])
(nil)))
(insn 17 16 42 3 (set (reg/f:SI 122 [ _3 ])
(plus:SI (reg:SI 135)
(reg/v/f:SI 127 [ addr ]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 135)
(nil)))
(insn 42 17 43 3 (set (reg:SI 138)
(minus:SI (reg/f:SI 122 [ _3 ])
(reg/v/f:SI 127 [ addr ]))) -1
 (expr_list:REG_DEAD (reg/f:SI 122 [ _3 ])
(nil)))
(insn 43 42 44 3 (set (reg:SI 139)
(plus:SI (reg:SI 138)
(const_int -16 [0xfff0]))) -1
 (expr_list:REG_DEAD (reg:SI 138)
(nil)))
(insn 44 43 45 3 (set (reg:SI 140)
(lshiftrt:SI (reg:SI 139)
(const_int 4 [0x4]))) -1
 (expr_list:REG_DEAD (reg:SI 139)
(nil)))
and only combine turns that into:
(insn 42 17 43 3 (set (reg:SI 138)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4]))) 269 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 128 [ _20 ])
(nil)))
(insn 43 42 44 3 (set (reg:SI 139)
(plus:SI (reg:SI 138)
(const_int -16 [0xfff0]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 138)
(nil)))
(insn 44 43 45 3 (set (reg:SI 140)
(lshiftrt:SI (reg:SI 139)
(const_int 4 [0x4]))) 279 {lshrsi3}
 (expr_list:REG_DEAD (reg:SI 139)
(nil)))
(insn 45 44 21 3 (set (reg:SI 137)
(plus:SI (reg:SI 140)
(const_int 1 [0x1]))) 72 {*addsi3}
 (expr_list:REG_DEAD (reg:SI 140)
(nil)))

While reg:SI 128 is set only once and thus in theory we could in theory use in
RTL the corresponding GIMPLE value ranges for that SSA_NAME, the SSA_NAME for
_20 is [0, 268435455] and thus only allows us to figure out that << 4 will not
shift away any bits out of it (i.e. that (r128 << 4) >> 4 is equal to r128.  We
need to know that it can't be zero as well, which on GIMPLE is present in the
value range of _6 - [16, 4294967280], but unfortunately that info is lost
during TER, pseudo 135 doesn't really have REG_EXPR set.

Maybe that would be fixable by some expander work.

Then the question is if we actually can use GIMPLE VRP info during RTL
optimizations, and whether all optimizations on RTL that would invalidate that
reset REG_EXPR or could in some other way signal that the VRP info can't be
trusted.

The combiner first optimizes:
Trying 17 -> 42:
   17: r122:SI=r135:SI+r127:SI
  REG_DEAD r135:SI
   42: r138:SI=r122:SI-r127:SI
  REG_DEAD r122:SI
Successfully matched this instruction:
(set (reg:SI 138)
(reg:SI 135))

and then:
Trying 16 -> 42:
   16: r135:SI=r128:SI<<0x4
  REG_DEAD r128:SI
   42: r138:SI=r135:SI
  REG_DEAD r135:SI
Successfully matched this instruction:
(set (reg:SI 138)
(ashift:SI (reg:SI 128 [ _20 ])
(const_int 4 [0x4])))
so if we had VRP info on _6 aka (reg:SI 135 [ _6 ]) we'd need to signal that it
is the same on r138.
And then have some way

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #20 from Jakub Jelinek  ---
You can use __builtin_setjmp and __builtin_longjmp in the same function, only
if they use a different buffer.  Otherwise it is invalid.  So, while we
shouldn't ICE on invalid code, not sure why you are listing 4 here.

CCing Eric for the other __builtin_setjmp related issues.

[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-08
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
Summary|[8 Regression] ICE in   |[8 regression] ICE in
   |i386_pe_seh_cold_init   |i386_pe_seh_cold_init
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Thanks, I'm going to have a look.

[Bug target/84521] [8 Regression] aarch64: Frame-pointer corruption with __builtin_setjmp/__builtin_longjmp and -fomit-frame-pointer

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou  ---
> You can use __builtin_setjmp and __builtin_longjmp in the same function,
> only if they use a different buffer.  Otherwise it is invalid.

Yes, that's invalid.

> CCing Eric for the other __builtin_setjmp related issues.

I don't see anything special with Aarch64 that would make it impossible to
support __builtin_setjmp/__builtin_longjmp properly.  You can parameterize a
lot of things in the back-end with TARGET_BUILTIN_SETJMP_FRAME_VALUE and
various patterns like:
  save_stack_nonlocal
  restore_stack_nonlocal,
  nonlocal_goto_receiver,
  builtin_setjmp_setup,
  builtin_setjmp_receiver,
  builtin_longjmp
See the documentation and existing ports.

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[kelvin at gcc dot gnu.org]

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

--- Comment #2 from kelvin at gcc dot gnu.org ---
I don't argue either way on this, but it looks to me like we do not currently
have support for __int128 with vec_ld.

1. I can't fine it in the rs6000-c tables.

2. This test fails to compile:

#include 
#include 

static vector unsigned char uc;
static vector __int128 v;
static vector __int128 *pi;

void
doInitialization ()
{
  v[0] = -1;
  pi = &v;
}

int
main (int argc, char *argv)
{
  __int128 entry;
  int i;

  /* Apparent usage:
   *   result = vec_ld (int index, vector v)
   * is equivalent to:  
   *  result = v [index];   
   */
  doInitialization ();
  entry = vec_ld (0, pi);
  i = (int) entry;
  printf ("result of vec_ld is %d\n", i);
  return 0;
}

$GCC_BUILD/gcc/xgcc -B$GCC_BUILD/gcc/ -O1 -o kelvin-1 kelvin-1.c
kelvin-1.c: In function ‘main’:
kelvin-1.c:36:3: error: invalid parameter combination for AltiVec intrinsic
‘__builtin_vec_ld’
   entry = vec_ld (0, pi);
   ^
Makefile:26: recipe for target 'kelvin-1' failed
make: *** [kelvin-1] Error 1


By the way, it's probably obvious everyone else what vec_ld is supposed to do,
but it's not documented anywhere that I can find...

The Hotel Show Saudi Arabia is Back!

[The Hotel Show Saudi Arabia]

This email newsletter was sent to you in graphical HTML format.
If you're seeing this version, your email program prefers plain text emails.
You can read the original version online:
http://ymlpsend3.com/zZdRJa



REGISTRATION FOR THE HOTEL SHOW SAUDI ARABIA IS NOW OPEN (
http://dmg-events.msgfocus.com/c/1a30BT5lE2es7wT )
View in browser

The Kingdom’s premier event for the hospitality and food industry is
back in Jeddah from 10th – 12th April for three days of inspiration,
innovation, education and networking opportunities.

Yes, that’s right, registration for THE HOTEL SHOW SAUDI ARABIA 2018
( http://dmg-events.msgfocus.com/c/1a30D5LfMNDmkyZ ) is now OPEN.
REGISTER FOR FREE NOW! (
http://dmg-events.msgfocus.com/c/1a30DH6cRbkOr52 )

The show is the only business event in the Kingdom which is dedicated
to the hospitality industry and promises a range of stunning features,
CPD seminars along with a gathering of industry experts to share
ideas, trends and insights. 100s of global brands will be on show,
giving you the best opportunity to source the very latest cutting-edge
supplies and products designed to create a truly unforgettable
experience for your customers.

Also, following the success of 2017’s live-cooking competition, the
INTER-HOTEL CULINARY COMPETITION (
http://dmg-events.msgfocus.com/c/1a30Eir9Vz2gxB5 ) is returning bigger
and better for 2018. A panel of highly experienced judges from the
endorsing bodies; World Association of Chefs Societies and the Saudi
Arabian Chefs Association will determine the winners after three-days
of tasting various unique dishes.

THE HOTEL SHOW SAUDI ARABIA is a must-attend on the list of industry
events. As an Owner, Developer, Architect, Engineer, Procurement
Manager, Distributor or Chef in the hospitality industry, you need to
be there. REGISTER NOW! (
http://dmg-events.msgfocus.com/c/1a30ETM6ZWJIE78 )

يعود الحدث
الرائد في
المملكة
لمجال
الضيافة
وخدمات
تقديم
الطعام في
جدة في
الفترة من 10
إلى 12 أبريل
لمدة ثلاثة
أيام من
الإلهام
والابتكار
والتعليم
وفرص
التواصل.

نعم، الأمر
صحيح؛ أصبح
باب
التسجيل
لحضور معرض
الفنادق
بالمملكة
العربية
السعودية (
http://dmg-events.msgfocus.com/c/1a30G6s18I8CR9e
)2018مفتوحًا
الآن. سجِّل
بياناتك
مجانًا
الآن! (
http://dmg-events.msgfocus.com/c/1a30GHMYd5Q4XFh )

هذا المعرض
هو حدث
الأعمال
الوحيد
المخصص
لمجال
الضيافة في
المملكة،
ويعد
بتقديم
مجموعة من
الفعاليات
المذهلة،
والندوات
المعتمدة
للتطوير
المهني
المستمر،
إضافةً إلى
تجمّع من
خبراء
المجال
لتبادل
الأفكار
والاتجاهات
والرؤى.
وستشارك في
المعرض
المئات من
العلامات
التجارية
العالمية؛
ما سيمنحك
أفضل فرصة
لاستعراض
أحدث
الإمدادات
والمنتجات
المتطورة
التي تهدف
إلى تزويد
عملائك
بتجربة لا
تُنسى حقًا.

علاوةً على
ذلك، بعد
نجاح دورة 2017
من مسابقة
الطهي
المباشر،
ستعودمسابقة
الطهي بين
الفنادق (
http://dmg-events.msgfocus.com/c/1a30Hj7Vhtxx4bk ) في
شكل أكبر
وأفضل لعام 2018.
وسيحدَّد
أسماء
الفائزين
بواسطة
فريق من
المحكمين
ذوي الخبرة
العالية من
الهيئات
المصادقة -
الرابطة
العالمية
لجمعيات
الطهاة
وجمعية
الطهاة
السعوديين -
بعد ثلاثة
أيام من
تذوق مختلف
الأطباق
الفريدة.

معرض
الفنادق
بالمملكة
العربية
السعودية
هو حدث لا
غنى عن
حضوره ضمن
قائمة
الأحداث
المتخصصة
في مجال
الضيافة.
وإذا كنت
أحد
المالكين
أو
المطوّرين
أو
المعماريين
أو
المهندسين
أو مديري
المشتريات
أو
الموزّعين
أو الطهاة
في مجال
الضيافة،
فإنه يتعين
عليك حضور
الفعاليات
بكل تأكيد.
سجِّل
بياناتك
الآن! (
http://dmg-events.msgfocus.com/c/1a30HUsSlReZaHn )

INDUSTRY SUPPORT

SUPPORTED BY

HOST VENUE

ENDORSED BY

ENDORSED BY

ORGANISER

CO - ORGANISER

HOTEL PARTNER

CULINARY PARTNER

OFFICIAL TABLEWARE SPONSOR

The Hotel Show Saudi Arabia
dmg events Middle East, Asia & Africa
T: +971 4 4380355
E: thehotelshow...@dmgeventsme.com
W: thehotelshowsaudiarabia.com (
http://dmg-events.msgfocus.com/c/1a30IvNPqeWrhdq )

(
http://www.dmg-eventsme.com/dmgdbms/UnSub.aspx?id=exam...@emailaddress.test,,12,Example
Sf Contact Id,Example Sf Show Id,Example Sf Edition Id,Example Sf
Campaignmember Id )

_
Unsubscribe / Change Profile: http://ymlpsend3.com/ugmwhmbhgsgmsbqmgyqwggubuhw
Powered by YourMailingListProvider

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[rai...@emrich-ebersheim.de]

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

--- Comment #17 from Rainer Emrich  ---
Otherwise this looks good:

=== acats Summary ===
# of expected passes2315
# of unexpected failures5
*** FAILURES: c23003b c23003g c23003i c250002 c380004

That's on par with 7.3.0.

[Bug tree-optimization/84737] [8 Regression] 20% degradation in CPU2000 172.mgrid starting with r256888

[pthaugen at gcc dot gnu.org]

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

--- Comment #5 from Pat Haugen  ---
Created attachment 43601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43601&action=edit
ipa-cp dump (r256887)

(In reply to Martin Liška from comment #4)
> Thank you, may I please ask you for the IPA CP dump file for not affected
> revision (r256887). Do I understand the numbers right that version with
> .resid_.constprop.1 is slower?

Dump attached. And yes, the version with resid_.constprop.1 is slower.

Also, I tried the patch from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149#c5 and didn't see any
difference in execution time.

[Bug target/84277] [8 Regression] A lot of new acats testsuite failures

[ebotcazou at gcc dot gnu.org]

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

--- Comment #18 from Eric Botcazou  ---
> Otherwise this looks good:
> 
>   === acats Summary ===
> # of expected passes  2315
> # of unexpected failures  5
> *** FAILURES: c23003b c23003g c23003i c250002 c380004
> 
> That's on par with 7.3.0.

Wunderbar! :-) Danke schön.

[Bug c/84764] New: Wrong warning "so large that it is unsigned" for __int128 constant

[pascal_cuoq at hotmail dot com]

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

Bug ID: 84764
   Summary: Wrong warning "so large that it is unsigned" for
__int128 constant
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pascal_cuoq at hotmail dot com
  Target Milestone: ---

According to the output of the following program, the type of the constant
1000 is __int128, which is a signed type:

Compiler Explorer link: https://godbolt.org/g/kFTNaz

#include 

#define prtype(X) \
  _Generic((X),   \
   int: "int",\
   long: "long",  \
   long long: "long long",\
   unsigned int: "unsigned int",  \
   unsigned long: "unsigned long",\
   unsigned long long: "unsigned long long",  \
   __int128: "__int128",  \
  default: "?")

int main(void) {
  printf("1 %s\n", prtype(1));
  printf("30 %s\n", prtype(30));
  printf("1000 %s\n", prtype(1000));
}

___
Output:

1 int
30 long
1000 __int128

However a warning is emitted on the last line for the constant
1000:

prtype.c:17:66: warning: integer constant is so large that it is unsigned

This warning implies that the constant is typed as long long, which has been
the case either historically or with other -std= settings. However, for the
compilation settings at hand, the warning is wrong. It should at most say that
the constant is typed with a type outside of the "int, long, long long"
hierarchy of standard types.

For reference the relevant clause of the C11 standard is 6.4.4:
https://port70.net/~nsz/c/c11/n1570.html#6.4.4

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[pascal_cuoq at hotmail dot com]

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

--- Comment #1 from Pascal Cuoq  ---
I meant "the warning implies that the constant is typed as unsigned long
long...".

[Bug c/84764] Wrong warning "so large that it is unsigned" for __int128 constant

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
__int128 is not an extended integer type in the C sense.  The main reason is
because intmax_t is not defined as __int128.

[Bug target/84760] Finish implementation of __builtin_altivec_lvx_v1ti

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Schmidt  ---
Sorry.  vec_ld is direct access to the lvx instruction.

Given what you found, I think we should add signed and unsigned V1TImode
versions of vec_ld and remove this partial implementation of an undocumented
function.

[Bug fortran/64124] [F95] Valid constant expr rejected

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:01:23 2018
New Revision: 258367

URL: https://gcc.gnu.org/viewcvs?rev=258367&root=gcc&view=rev
Log:
2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/70409] Silent truncation of character parameters with len=huge()

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Mar  8 19:01:23 2018
New Revision: 258367

URL: https://gcc.gnu.org/viewcvs?rev=258367&root=gcc&view=rev
Log:
2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* decl.c (gfc_match_char_spec): Try to reduce a charlen to a constant.

2018-03-08  Steven G. Kargl  

PR fortran/64124
PR fortran/70409
* gfortran.dg/pr64124.f90: New tests.
* gfortran.dg/pr70409.f90: New tests.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr64124.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70409.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog