[Bug target/52898] SH Target: Inefficient DImode comparisons

[olegendo at gcc dot gnu.org]

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

--- Comment #11 from Oleg Endo  ---
Author: olegendo
Date: Mon May  2 05:25:46 2016
New Revision: 235698

URL: https://gcc.gnu.org/viewcvs?rev=235698=gcc=rev
Log:
gcc/
PR target/52898
* config/sh/sh.c (sh_option_override): Remove TARGET_CBRANCHDI4,
TARGET_CMPEQDI_T.
(prepare_cbranch_operands): Don't use scratch register.  Assume that
function is used when pseudos can be created.
(expand_cbranchdi4): Likewise.  Remove unused TARGET_CMPEQDI_T paths.
* config/sh/sh.md (cbranchsi4): Allow only when pseudos can be created.
(cbranchdi4, cbranchdi4_i): Simplify to single cbranchdi4
define_expand.  Allow it only when pseudos can be created.
* config/sh/sh.opt (mcbranchdi, mcmpeqdi): Delete.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.md
trunk/gcc/config/sh/sh.opt

[Bug libstdc++/70898] Stateful Compare objects are very slow

[gccbugs at jbapple dot com]

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

--- Comment #1 from gccbugs at jbapple dot com ---
*** Bug 70899 has been marked as a duplicate of this bug. ***

[Bug libstdc++/70899] Stateful Compare objects are very slow

[gccbugs at jbapple dot com]

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

gccbugs at jbapple dot com changed:

   What|Removed |Added

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

--- Comment #1 from gccbugs at jbapple dot com ---
Accidental double-post of identical bug report.

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

[Bug libstdc++/70899] New: Stateful Compare objects are very slow

[gccbugs at jbapple dot com]

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

Bug ID: 70899
   Summary: Stateful Compare objects are very slow
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugs at jbapple dot com
  Target Milestone: ---

/*

The following code is four times slower with libstdc++ than with libc++.

I think the problem is partially too many copies in stl_heap.h. Instrumenting
the code with a copy constructor and a destructor shows two copies of a Comp
and two destructions for every call to push, while in libc++ it's only one call
to a copy constructor and one call to the destructor. It seems like zero calls
should be sufficient, as the Compare object could be kept around between push
calls and reused.

*/

#include 
#include 
#include 

using namespace std;

struct Comp {
  vector data;
  Comp(int n) : data(n,n) {}
  bool operator()(const double , const double ) const { return x < y; } 
};  

int main() {
  vector data;
  Comp comp(15);
  priority_queue pq(comp, data);
  for (int i = 0; i < 10; ++i) {
pq.push(i);
  } 
  cout << pq.top() << endl;
}

[Bug libstdc++/70898] New: Stateful Compare objects are very slow

[gccbugs at jbapple dot com]

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

Bug ID: 70898
   Summary: Stateful Compare objects are very slow
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugs at jbapple dot com
  Target Milestone: ---

/*

The following code is four times slower with libstdc++ than with libc++.

I think the problem is partially too many copies in stl_heap.h. Instrumenting
the code with a copy constructor and a destructor shows two copies of a Comp
and two destructions for every call to push, while in libc++ it's only one call
to a copy constructor and one call to the destructor. It seems like zero calls
should be sufficient, as the Compare object could be kept around between push
calls and reused.

*/

#include 
#include 
#include 

using namespace std;

struct Comp {
  vector data;
  Comp(int n) : data(n,n) {}
  bool operator()(const double , const double ) const { return x < y; } 
};  

int main() {
  vector data;
  Comp comp(15);
  priority_queue pq(comp, data);
  for (int i = 0; i < 10; ++i) {
pq.push(i);
  } 
  cout << pq.top() << endl;
}

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
Until it failed again during the fortran part:

../../../libgfortran/io/transfer.c: In function ‘bswap_array’:
../../../libgfortran/io/transfer.c:915:25: fatal error: You must enable NEON
instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics.
  ((uint16_t*)dest)[i] = __builtin_bswap16 (((uint16_t*)src)[i]);
 ^~~
compilation terminated.
make[3]: *** [transfer.lo] Error 1

but that looks like user error. It would be nice if `configure` could abort or
at least warn on not finding `-mfpu=neon` among CFLAGS if fortran was enabled.

Is there a way to salvage the C/C++ build or do I have to start from scratch?

[Bug middle-end/70897] New: Confused branch predictors

[hubicka at gcc dot gnu.org]

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

Bug ID: 70897
   Summary: Confused branch predictors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Martin has collected predictor hitrates with current mainline. It seems that
some of predictors no longer works very well. In particular:

loop iv compare, continue, const return, fail alloc, zero-sized array, early
return (on trees), call all have very low hitrates.

This is a regression wrt early GCC 4.x releases when the regular predictor
testing broke.

SPECv6:
HEURISTICS   BRANCHES  (REL)  HITRATE   
COVERAGE COVERAGE  (REL)
loop iv compare70   0.1%  59.31% /  71.45% 
391732444  391.73M   0.0%
unconditional jump252   0.2% 100.00% / 100.00% 
62269   62.27K   0.0%
guess loop iv compare 362   0.3%  89.02% /  90.08%
27031841642.70G   0.2%
continue  429   0.4%  12.85% /  90.20%   
37779791284   37.78G   2.9%
negative return   919   0.8%  54.79% /  57.15%   
11577463479   11.58G   0.9%
null return  1083   1.0%  99.73% /  99.96% 
673967611  673.97M   0.1%
const return 1120   1.0%  11.66% /  96.19%
18561189021.86G   0.1%
fail alloc   1151   1.1%  57.13% / 100.00%
144823  144.82K   0.0%
zero-sized array 1960   1.8%  51.41% /  98.82%
104224  104.22K   0.0%
loop guard   3229   3.0%  76.78% /  82.17%   
60212618544   60.21G   4.6%
noreturn call3434   3.2% 100.00% / 100.00%
19105872531.91G   0.1%
overflow 3755   3.4% 100.00% / 100.00%
208357  208.36K   0.0%
opcode values positive (on trees)5759   5.3%  58.56% /  82.94%   
59387315517   59.39G   4.6%
loop iterations  7019   6.4%  87.65% /  87.65%  
229118021898  229.12G  17.6%
early return (on trees)  8564   7.9%  52.30% /  80.93%   
42808951372   42.81G   3.3%
loop exit9158   8.4%  89.47% /  92.47%  
230993449420  230.99G  17.7%
opcode values nonequal (on trees)9552   8.8%  85.86% /  91.56%   
92785638348   92.79G   7.1%
guessed loop iterations 10880  10.0%  94.45% /  94.78%  
367779299495  367.78G  28.2%
pointer (on trees)  18682  17.2%  80.01% /  94.69%   
18291859871   18.29G   1.4%
no prediction   20863  19.2%  40.36% /  83.66%  
203021057312  203.02G  15.6%
first match 33795  31.0%  91.59% /  92.17%  
820741493723  820.74G  63.0%
call34820  32.0%  56.19% /  90.09%   
62586683178   62.59G   4.8%
DS theory   54257  49.8%  66.02% /  86.54%  
280009272372  280.01G  21.5%
combined   108915 100.0%  78.12% /  89.63% 
13037718234071.30T 100.0%


HEURISTICS   BRANCHES  (REL)  HITRATE   
COVERAGE COVERAGE  (REL)
loop iv compare23   0.0%  52.06% /  52.15%   
88069018.81M   0.0%
unconditional jump103   0.2% 100.00% / 100.00%
491001  491.00K   0.0%
guess loop iv compare 133   0.3%  97.78% /  97.81%
42799368884.28G   0.4%
negative return   279   0.5%  97.87% /  99.23%
10626398751.06G   0.1%
const return  362   0.7%  34.63% /  89.75% 
380299097  380.30M   0.0%
null return   396   0.8%  91.47% /  93.08%
32686784533.27G   0.3%
continue  438   0.8%  33.36% /  82.86%
99852824129.99G   0.9%
fail alloc595   1.2%  62.18% / 100.00% 
  595   595.00   0.0%
zero-sized array  677   1.3% 100.00% / 100.00% 
112723789  112.72M   0.0%
overflow 1282   2.5% 100.00% / 100.00% 
175074149  175.07M   0.0%
loop guard   1806   3.5%  51.80% /  84.49%
52309263985.23G   0.5%
noreturn call2326   4.5% 100.00% / 100.00%
79304838607.93G   0.7%
loop iterations  2729   5.3%  75.43% /  75.43%  
531785147496  531.79G  47.8%
opcode values positive (on trees)3125   6.1%  60.97% /  90.49%   
15436912826   15.44G   1.4%
guessed loop iterations  5195  10.1%  93.61% /  94.10%  
209393449998  209.39G  18.8%
loop exit  

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
That option never caused me any troubles, btw. 

FWIW, once I've removed the `--disable-libstdcxx-dual-abi` option, the build
started chugging along quite nicely.

[Bug tree-optimization/70586] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Jan Hubicka  ---
Yep, pure/const function can trap and even throw an exception. We could cleanup
the way we store information about function body and propagate info whether
function can do trap/eh exception and such.
I wonder how desirable is however to turn code path that doesn't call function
into a code path that does. Is it a win?
Shouldn't tree-ssa-ifcombine have some cost model that should have caught this
and decide it unprofitable? Const/pure functions can be very slow.

Honza

[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #27 from Manuel López-Ibáñez  ---
(In reply to Steven Bosscher from comment #26)
> Maybe make something like "-Wno-unused-result=[pedantic|nodiscard]", make 
> strict the current semantics of the flag and nodiscard the C++17 semantics
> (and make that the default)?

I see two alternatives:

1) Keep nosdiscard and __wur semantics separated and use different flags for
them such as a new -Wdiscard which is enabled by default so that users can use
-Wno-discard to disable "nodiscard" attrib warnings. (Or should it be
-Wnodiscard and -Wno-nodiscard?).

This has the downside that users of existing libraries using __wur do not see
any benefit and this PR goes on.

2) Make __wur more strict than nodiscard only if some new flag
-Wstrict-unused-result is enabled (stricter warnings would print this flag and
users can use -Wno- version to disable it completely without disabling
nodiscard warnings).

This has the downside that users and library devs happy with the existing
behavior will have their default silently changed. The upside is that users can
decide on their own if they want the looser semantics by flipping a single
switch.

Option (2) is equivalent to what is proposed above. In that case
-Wstrict-unused-result will imply -Wunused-result (but not the other way
around) and the only question is whether  -Wstrict-unused-result or
-Wunused-result is enabled by default.


"pedantic" has a very precise meaning within GCC that is already quite
difficult to explain, let's not make it even more complex by overloading it.

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

--- Comment #2 from PeteVine  ---
I had this option in my environment FLAGS - is it problematic?

[Bug c/70859] Bad column number in type-generic function errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
These errors should use error_at instead of error() (input_location must die!)

Even with that change, constants and var_decl do not have locations (PR43486),
so input_location would still need to be used unless one manages to pass down
an array of location_t * args_loc to check_builtin_function_arguments.

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #3)
> There is no internals of GCC here.  Rather the user specified all warnings
> at link time.  If the user did not want that then they did not need to
> supply those options ...

That is very user-unfriendly and another reason why people might just
rationally decide that LTO is still not worth the pain.

If I understand correctly, the non-LTO compilation works without warning.
Adding -flto to your CFLAGS should not make your compilation fail in
unexplained ways unless your code is wrong. If LTO is not meant to handle
(some) warnings, then it should disable warnings internally (which would
speed-up compilation). GCC, not the user, should know which warnings work with
LTO and which ones don't, and ignore/disable them.

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
> -fipa-pta

Why are you using that option?

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > If you are going to be using lto you need to disable warnings as some
> > warnings don't happen until end of compiling.  stack usage is one of these
> > warnings.
> 
> How can a user know which warnings are those? GCC should disable on its own
> those warnings that cannot be handled by LTO (or emit a clear error that the
> warning is not valid with LTO). Same with invalid optimization options and
> attributes.
> 
> If LTO is ever going to be usable by anyone who is not a GCC developer, it
> needs to be usable without knowing the internals of the compiler.

There is no internals of GCC here.  Rather the user specified all warnings at
link time.  If the user did not want that then they did not need to supply
those options ...

[Bug bootstrap/70896] New: gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

Bug ID: 70896
   Summary: gcc4 ABI compatible bootstrap fails
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tulipawn at gmail dot com
  Target Milestone: ---

I've just tried bootstrapping gcc 6.1.0 on ARM Linux with gcc 4.9.3 using the
following options:

 --enable-languages=c,c++,fortran --prefix=/usr/gcc6 --program-suffix=-6
--enable-shared --enable-linker-build-id --libexecdir=/usr/gcc6/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/gcc6/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--enable-plugin --with-system-zlib --disable-browser-plugin --enable-multiarch
--enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a
--with-fpu=vfpv3 --with-float=hard --with-mode=thumb --disable-werror
--enable-multilib --enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf


but it failed like this:


make[6]: Entering directory
`gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/src/c++11'
/bin/bash ../../libtool --tag CXX --tag disable-shared   --mode=compile
/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/./gcc/xgcc -shared-libgcc
-B/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/./gcc -nostdinc++
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc6/arm-linux-gnueabihf/bin/ -B/usr/gcc6/arm-linux-gnueabihf/lib/
-isystem /usr/gcc6/arm-linux-gnueabihf/include -isystem
/usr/gcc6/arm-linux-gnueabihf/sys-include   
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/libstdc++-v3/../libgcc
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/include/arm-linux-gnueabihf
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/include
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/libstdc++-v3/libsupc++  
-std=gnu++11 -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=cow-stdexcept.lo -g -O2
-mcpu=cortex-a5 -O3 -marm -fomit-frame-pointer -fipa-pta -mfpu=vfpv4
-D_GNU_SOURCE  -c -o cow-stdexcept.lo
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc
libtool: compile:  /home/odroid/.phoronix-test-suite/gcc-6.1.0/build/./gcc/xgcc
-shared-libgcc -B/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/./gcc
-nostdinc++
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/src
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/src/.libs
-L/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/libsupc++/.libs
-B/usr/gcc6/arm-linux-gnueabihf/bin/ -B/usr/gcc6/arm-linux-gnueabihf/lib/
-isystem /usr/gcc6/arm-linux-gnueabihf/include -isystem
/usr/gcc6/arm-linux-gnueabihf/sys-include
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/libstdc++-v3/../libgcc
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/include/arm-linux-gnueabihf
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/build/arm-linux-gnueabihf/libstdc++-v3/include
-I/home/odroid/.phoronix-test-suite/gcc-6.1.0/libstdc++-v3/libsupc++
-std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -frandom-seed=cow-stdexcept.lo -g -O2
-mcpu=cortex-a5 -O3 -marm -fomit-frame-pointer -fipa-pta -mfpu=vfpv4
-D_GNU_SOURCE -c ../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc  -fPIC
-DPIC -D_GLIBCXX_SHARED -o cow-stdexcept.o
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc: In function ‘const
char* _txnal_sso_string_c_str(const void*)’:
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:300:40: error: ‘const
__sso_string {aka const class std::basic_string}’ has no member named
‘_M_s’; did you mean ‘_M_rep’?
&((const std::__sso_string*) that)->_M_s._M_p));
^~~~
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc: In function ‘void
_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE(std::logic_error*,
const __sso_string&)’:
../../../../../libstdc++-v3/src/c++11/cow-stdexcept.cc:378:43: warning: unused
parameter ‘s’ [-Wunused-parameter]
 CLASS* that, const std::__sso_string& s)\
   ^

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2016-05-01
 CC||manu at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #1)
> If you are going to be using lto you need to disable warnings as some
> warnings don't happen until end of compiling.  stack usage is one of these
> warnings.

How can a user know which warnings are those? GCC should disable on its own
those warnings that cannot be handled by LTO (or emit a clear error that the
warning is not valid with LTO). Same with invalid optimization options and
attributes.

If LTO is ever going to be usable by anyone who is not a GCC developer, it
needs to be usable without knowing the internals of the compiler.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #27 from Manuel López-Ibáñez  ---
*** Bug 70888 has been marked as a duplicate of this bug. ***

[Bug c++/70888] #pragma diagnostic ignored -Wlong-long ineffective with __LONG_LONG_MAX__ in c++98 mode

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez  ---
This is a well-known problem with the pragmas for C++ diagnostics in libcpp. I
tried to find a solution, but there were some issues I could not solve and I
ran out of time.

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

[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
The error happens here:

   0x4124cdd0 <+1936>:  [MMI]   adds r42=-1,r49
   0x4124cdd1 <+1937>:  adds r55=240,r12
   0x4124cdd2 <+1938>:  adds r32=16,r12;;
   0x4124cde0 <+1952>:  [MMI]   andcm r39=r42,r49
   0x4124cde1 <+1953>:  st8 [r55]=r32
   0x4124cde2 <+1954>:  nop.i 0x0
=> 0x4124cdf0 <+1968>:  [MMI]   ld8 r54=[r32];;
   0x4124cdf1 <+1969>:  nop.m 0x0
   0x4124cdf2 <+1970>:  popcnt r41=r39;;
   0x4124ce00 <+1984>:  [MII]   add r39=r47,r41
   0x4124ce01 <+1985>:  adds r47=44,r12;;
   0x4124ce02 <+1986>:  mov r56=r39
   0x4124ce10 <+2000>:  [MMB]   st4 [r47]=r39
   0x4124ce11 <+2001>:  nop.m 0x0
   0x4124ce12 <+2002>:  br.call.sptk.many
b0=0x41256f00 ::find_with_hash(tree_node* const&, unsigned int)>;;

The marked line loads candidates, but r32 contains 

[Bug fortran/70895] New: OpenACC: loop reduction does not work. Output is zero.

[ralph.trenkler at gmx dot de]

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

Bug ID: 70895
   Summary: OpenACC: loop reduction does not work. Output is zero.
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ralph.trenkler at gmx dot de
  Target Milestone: ---

Created attachment 38389
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38389=edit
compiler configure command line, compiler call, program in f90, *.i-file

Problem with OpenACC: The output of the attached fortran 90 program
"acc-test-04.f90" is zero but not "pi" (3.14...), as it should be. The compiler
version is 6.1.0.

[Bug c/68120] can't easily deal with integer overflow at compile time

[eggert at gnu dot org]

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

--- Comment #6 from Paul Eggert  ---
(In reply to Martin Sebor from comment #5)
> Patch posted for review:
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

Thanks. This patch appears to address almost all the request, and it is
definitely a step forward.

Even with the change, I see no easy way in a constant expression to compute the
bottom-order bits (ignoring overflow) of a signed integer value, but I can
raise this issue as a separate enhancement request if it turns into a problem
in practice.

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-01
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug hsa/70857] [6/7 Regression] ICE with -fopenmp -fopenacc in insert_vi_for_tree, at tree-ssa-structalias.c:2813

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
Not surprisingly, it is adding -fopenacc to the compile options that
causes this.  Because the testcase does not use any OpenACC
functionality, it should not matter.  So something seems to go wrong
at omp lowering/expansion phase.  I will have a look.

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
If you are going to be using lto you need to disable warnings as some warnings
don't happen until end of compiling.  stack usage is one of these warnings.

[Bug c/70883] inconsistent error message for calls to __builtin_add_overflow with too few arguments

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

[Bug c++/70507] integer overflow builtins not constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

[Bug c/68120] can't easily deal with integer overflow at compile time

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html

[Bug target/70894] New: ICE when using neon intrinsic with mabi=apcs-gnu

[g.hoogewerf at gmail dot com]

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

Bug ID: 70894
   Summary: ICE when using neon intrinsic with mabi=apcs-gnu
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g.hoogewerf at gmail dot com
  Target Milestone: ---

The following test case triggers an ICE on several versions of GCC, including
5.3.0 and 4.9.3.

void crashFunction(unsigned char val)
{
__builtin_neon_vdup_nv16qi ((__builtin_neon_qi) val);
}


To trigger the ICE, the source should be compiled with:
arm-none-eabi-gcc -c neon.c -mfpu=neon -mfloat-abi=softfp -mabi=apcs-gnu


When running with -v -save-temps, the output is:

Using built-in specs.
COLLECT_GCC=./GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/bin/arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: /home/ghoogewerf/GccBuild/src/gcc/configure
--prefix=/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi
--enable-languages=c,c++ --disable-libssp --disable-multilib --disable-nls
--disable-fixed-point --disable-decimal-float --disable-lto --with-newlib
--with-headers=/home/ghoogewerf/GccBuild/src/newlib/newlib/libc/include
Thread model: single
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mfpu=neon' '-mfloat-abi=softfp'
'-mabi=apcs-gnu'

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/libexec/gcc/arm-none-eabi/5.3.0/cc1
-E -quiet -v -D__USES_INITFINI__ neon.c -mfpu=neon -mfloat-abi=softfp
-mabi=apcs-gnu -fpch-preprocess -o neon.i
#include "..." search starts here:
#include <...> search starts here:

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/lib/gcc/arm-none-eabi/5.3.0/include

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/lib/gcc/arm-none-eabi/5.3.0/include-fixed

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/sys-include

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mfpu=neon' '-mfloat-abi=softfp'
'-mabi=apcs-gnu'

/home/ghoogewerf/GccBuild/build/arm-none-eabi-newlib/tools/i686-pc-linux-gnu/arm-none-eabi/libexec/gcc/arm-none-eabi/5.3.0/cc1
-fpreprocessed neon.i -quiet -dumpbase neon.c -mfpu=neon -mfloat-abi=softfp
-mabi=apcs-gnu -auxbase neon -version -o neon.s
GNU C11 (GCC) version 5.3.0 (arm-none-eabi)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.3.0 (arm-none-eabi)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 46d53ae1749a0f498e12cc1c3bd3e85f
neon.c: In function 'crashFunction':
neon.c:4:5: internal compiler error: in copy_to_mode_reg, at explow.c:617
 __builtin_neon_vdup_nv16qi ((__builtin_neon_qi) val);
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Thanks,
G. Hoogewerf

[Bug other/69412] bootstrap-ubsan profiledbootstrap issues

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Bug in comment 4 still in gcc 7

[Bug libgcc/68468] frv/bfin toolchain build error

[wbx at openadk dot org]

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

--- Comment #4 from Waldemar Brodkorb  ---
Both fr-v/bfin toolchains can be build by using something like this:

diff -Nur gcc-6.1.0.orig/libgcc/config.host gcc-6.1.0/libgcc/config.host
--- gcc-6.1.0.orig/libgcc/config.host   2016-02-26 21:02:28.0 +0100
+++ gcc-6.1.0/libgcc/config.host2016-04-30 20:49:06.542101273 +0200
@@ -231,7 +231,7 @@
   esac
   ;;
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu)
-  tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip t-slibgcc
t-slibgcc-gld t-slibgcc-elf-ver t-linux"
+  tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-slibgcc t-slibgcc-gld
t-slibgcc-elf-ver t-linux"
   extra_parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o"
   if test x$enable_vtable_verify = xyes; then
 extra_parts="$extra_parts vtv_start.o vtv_end.o vtv_start_preinit.o
vtv_end_preinit.o"

Who should have provided the missing struct?

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16

[kirillnow at gmail dot com]

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

--- Comment #2 from Кирилл  ---
...
Just realized its wrong endianness problem. 
codecvt_utf8_utf16 should assume utf16be by default, right? Apparently, no.

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16

[kirillnow at gmail dot com]

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

--- Comment #1 from Кирилл  ---
Bad guess on my part, sorry!
Actual problem is:
305:else if (is_low_surrogate(c))
306:  return invalid_mb_sequence;
Stand-alone low surrogates are not uncommon, and could be decoded as valid
utf-8.
Example: Thorn  U+00DE Þ Encoded by [iconv (GNU libc) 2.23] -> c=0xDE00

[Bug rtl-optimization/70886] -frename-registers causes boostrap comparison failures on ia64

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
It's an issue in the speculative machinery of the scheduler but fortunately
easy to fix once you pinpointed it...

[Bug libstdc++/70893] New: codecvt incorrectly decodes UTF-16 due to optimization

[kirillnow at gmail dot com]

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

Bug ID: 70893
   Summary: codecvt incorrectly decodes UTF-16 due to optimization
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kirillnow at gmail dot com
  Target Milestone: ---

In libstdc++ source codecvt.cc:
  inline bool  is_high_surrogate(char32_t c)
  {
return c >= 0xD800 && c <= 0xDBFF;
  }
compiles to:
  if (is_high_surrogate(c))
  0x77b4d275leaecx,[rsi-0xd800]
  0x77b4d27bcmpecx,0x3ff
  0x77b4d281ja 0x77b4d2ad 
  {
This code incorrectly decode code points like 0xDE00 (iconv can produce those).
GCC and library compilled with -Os. 
Possible solution:
  inline bool  is_high_surrogate(char32_t c)
  {
return (c&0xFC00)==0xD800;
  }

[Bug target/52898] SH Target: Inefficient DImode comparisons

[olegendo at gcc dot gnu.org]

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

--- Comment #10 from Oleg Endo  ---
For a case like 

int test3 (long long a)
{
  return a == 40;
}

what happens on SH2+ during RTL expansion:

cstoredi4
 -> sh_emit_compare_and_set
 -> sh_emit_scc_to_t
  -> force operands to regs
  -> emit cmpeqdi_t insn

Then combine tries e.g.

Trying 6 -> 7:
Failed to match this instruction:
(set (reg:SI 147 t)
(eq:SI (reg:DI 4 r4 [ a ])
(const_int 40 [0x28])))

and in split1 this pattern

(define_split
  [(set (reg:SI T_REG)
(eq:SI (match_operand:DI 0 "arith_reg_operand" "")
   (match_operand:DI 1 "arith_reg_or_0_operand" "")))]

splits everything up and the resulting code becomes:

mov #0,r3
cmp/eq  r3,r5
bt.s.L5
mov #40,r2
rts
movtr0
.align 1
.L5:
cmp/eq  r2,r4
rts
movtr0

if the split pattern is disabled, the cmpeqdi_t pattern survives until the end:

mov #40,r2
mov #0,r3
cmp/eq  r3,r5
bf  0f
cmp/eq  r2,r4
0:
rts
movtr0

which is obviously less code, but has one more branch in the execution path. 
This pattern probably should be used when optimizing for size or when
zero-displacement branches are fast.


On SH1 the cstoredi4 pattern is disabled because it might result in e.g.
cmpgtdi_t which needs branches with delay slots.  Because of that the middle
end expands some target independent code like:

mov #40,r1
xor r1,r4
or  r4,r5
tst r5,r5
rts
movtr0

which is actually a good branch-less alternative.

[Bug c++/70892] New: additional memory access generated in loop if destructor is inlined

[wr0112358 at gmail dot com]

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

Bug ID: 70892
   Summary: additional memory access generated in loop if
destructor is inlined
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wr0112358 at gmail dot com
  Target Milestone: ---

Created attachment 38388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38388=edit
testcase

The attached reduced testcase is compiled differently if a simple raii helper
type is used.

testcase:
double array[expected];
double sum = 0.0;
for(int j = 0; j < expected; j++)
array[j] = (double)j;

g++ -std=c++1y -O2 -Wall -Wextra -Werror double_bug_minimal.cc
  400950:   f2 0f 58 00 addsd  (%rax),%xmm0
  400954:   48 83 c0 08 add$0x8,%rax
  400958:   48 39 d0cmp%rdx,%rax
  40095b:   75 f3   jne400950 

g++ -std=c++1y -O2 -Wall -Wextra -Werror -DA double_bug_minimal.cc
  400a98:   f2 0f 10 4c 24 08   movsd  0x8(%rsp),%xmm1
  400a9e:   48 83 c0 08 add$0x8,%rax
  400aa2:   f2 0f 58 48 f8  addsd  -0x8(%rax),%xmm1
  400aa7:   48 39 d0cmp%rdx,%rax
  400aaa:   f2 0f 11 4c 24 08   movsd  %xmm1,0x8(%rsp)
  400ab0:   75 e6   jne400a98 


g++ --version | head -n1; cat /etc/fedora-release; uname -a
g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Fedora release 23 (Twenty Three)
Linux lautreamont 4.4.7-300.fc23.x86_64 #1 SMP Wed Apr 13 02:52:52 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

[Bug bootstrap/70704] [6 Regression] AIX bootstrap comparison failure

[jakub at gcc dot gnu.org]

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

--- Comment #53 from Jakub Jelinek  ---
Author: jakub
Date: Sun May  1 10:49:25 2016
New Revision: 235692

URL: https://gcc.gnu.org/viewcvs?rev=235692=gcc=rev
Log:
PR bootstrap/70704
* configure.ac (--enable-stage1-checking): Add missing
--enable-checking=.
* configure: Regenerated.

Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac

[Bug c/70891] New: "register name not specified" for const qualified register variable

[jens.gustedt at inria dot fr]

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

Bug ID: 70891
   Summary: "register name not specified" for const qualified
register variable
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.gustedt at inria dot fr
  Target Milestone: ---

Created attachment 38387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38387=edit
complete example to reproduce the bug

Gcc in different variants (I tried 4.8, 4.9 and 5.3) gives an error for

  register const struct large max4 = { .x0 = -1, .x1 = -1, };

Where large is just a struct consisting of two unsigned.
the error is

   gcc-register-const-bug.c:27:31: error: register name not specified for
'max4'

which seems to refer to the "asm register" extension of gcc, but which isn't
used here at all.

The example is minimal in the sense that *any* of the following has the bug
disappear

 - removing the const qualification
 - removing the register storage class
 - changing any of the initial values from -1 to 0

I attach a complete example that on my machine (x86_64) errors out exactly on
the line as indicated. All other variants in that file compile just fine.

As another data point, clang, in different versions, has no problem with this
code at all.
Thanks
Jens

[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Program received signal SIGSEGV, Segmentation fault.
hash_table::find_with_hash (this=0x80, 
comparable=@0x600eef10: 0x600eee30, hash=5673)
at ../../gcc/hash-table.h:825
825   value_type *entry = _entries[index];
(gdb) bt
#0  hash_table::find_with_hash (this=0x80, 
comparable=@0x600eef10: 0x600eee30, hash=5673)
at ../../gcc/hash-table.h:825
#1  0x4124bee0 in candidate (uid=5673) at ../../gcc/tree-sra.c:324
#2  analyze_all_variable_accesses () at ../../gcc/tree-sra.c:2682
#3  0x4124dd70 in perform_intra_sra () at ../../gcc/tree-sra.c:3734
#4  0x40dc4de0 in execute_one_pass (pass=0x6028d250)
at ../../gcc/passes.c:2348
#5  0x40dc5e80 in execute_pass_list_1 (pass=0x6028d250)
at ../../gcc/passes.c:2432
#6  0x40dc5ed0 in execute_pass_list_1 (pass=0x6028d050)
at ../../gcc/passes.c:2433
#7  0x40dc5ff0 in execute_pass_list (fn=0x20e7c6d8, 
pass=0x6028ced0) at ../../gcc/passes.c:2443
#8  0x40dc1820 in do_per_function_toporder (callback=, 
data=0x6028ced0) at ../../gcc/passes.c:1732
#9  0x40dc7490 in execute_ipa_pass_list (pass=0x6028ce70)
at ../../gcc/passes.c:2785
#10 0x405f1560 in ipa_passes () at ../../gcc/cgraphunit.c:2265
#11 symbol_table::compile (this=0x20be)
at ../../gcc/cgraphunit.c:2404
#12 0x405f8690 in compile (this=0x20be)
at ../../gcc/cgraphunit.c:2567
#13 symbol_table::finalize_compilation_unit (this=0x20be)
at ../../gcc/cgraphunit.c:2564
#14 0x40fe0f00 in compile_file () at ../../gcc/toplev.c:488
#15 0x401dd890 in do_compile () at ../../gcc/toplev.c:1987
#16 toplev::main (this=, argc=, 
argv=) at ../../gcc/toplev.c:2095
#17 0x401e1b50 in main (argc=6, argv=0x600ef328)
at ../../gcc/main.c:39

[Bug rtl-optimization/70890] New: [7 regression] r235660 miscompiles stage2 compiler on ia64

[sch...@linux-m68k.org]

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

Bug ID: 70890
   Summary: [7 regression] r235660 miscompiles stage2 compiler on
ia64
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: amodra at gmail dot com
  Target Milestone: ---
Target: ia64-*-*

Starting program: /usr/local/gcc/gcc-20160501/Build/gcc/cc1 -fpreprocessed
libgcc2.i -quiet -O2 -fbuilding-libgcc -fno-stack-protector -fPIC
-fvisibility=hidden
Failed to read a valid object file image from memory.

Program received signal SIGSEGV, Segmentation fault.
0x40ed2911 in hash_table<uid_decl_hasher,
xcallocator>::find_with_hash(tree_node* const&, unsigned int) ()
(gdb) bt
#0  0x40ed2911 in hash_table<uid_decl_hasher,
xcallocator>::find_with_hash(tree_node* const&, unsigned int) ()
#1  0x40ec7d60 in analyze_all_variable_accesses() ()
#2  0x40eca0f0 in perform_intra_sra() ()
#3  0x40b085e0 in execute_one_pass(opt_pass*) ()
#4  0x40b094c0 in execute_pass_list_1(opt_pass*) ()
#5  0x40b09510 in execute_pass_list_1(opt_pass*) ()
#6  0x40b09630 in execute_pass_list(function*, opt_pass*) ()
#7  0x40b05140 in do_per_function_toporder(void (*)(function*, void*),
void*) ()
#8  0x40b0aa10 in execute_ipa_pass_list(opt_pass*) ()
#9  0x4049a6e0 in symbol_table::compile() [clone .part.45] ()
#10 0x404a0310 in symbol_table::finalize_compilation_unit() ()
#11 0x40cef1c0 in compile_file() ()
#12 0x4019f590 in toplev::main(int, char**) ()
#13 0x401a3850 in main ()
(gdb) x/i $pc
=> 0x40ed2911
<_ZN10hash_tableI15uid_decl_hasher11xcallocatorE14find_with_hashERKP9tree_nodej+17>:
 ld8 r10=[r32]
(gdb) i reg r32
r320x   -1

[Bug tree-optimization/70700] ICE using -fdump-tree-all-graph option

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 38386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38386=edit
proposed patch

Patch with testcase included. I'll put this through testing.

[Bug tree-optimization/70700] ICE using -fdump-tree-all-graph option

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #6)
> Could be just
> 
> --- a/gcc/tree-ssa-structalias.c
> +++ b/gcc/tree-ssa-structalias.c
> @@ -2241,7 +2241,11 @@ dump_pred_graph (struct scc_info *si, FILE *file)
>if (graph->points_to[i]
>   && !bitmap_empty_p (graph->points_to[i]))
> {
> - fprintf (file, "[label=\"%s = {", get_varinfo (i)->name);
> + if (i < FIRST_REF_NODE)
> +   fprintf (file, "[label=\"%s = {", get_varinfo (i)->name);
> + else
> +   fprintf (file, "[label=\"*%s = {",
> +get_varinfo (i - FIRST_REF_NODE)->name);
>   unsigned j;
>   bitmap_iterator bi;
>   EXECUTE_IF_SET_IN_BITMAP (graph->points_to[i], 0, j, bi)
> 
> but someone would need to check whether we still print a correct info with
> this.

I've build the compiler with the patch, compiled the example from comment 4,
extracted the dot files using the script mentioned in PR70221 and generated pdf
files from those. They look ok to me.

Also, the patch itself looks good to me.