[Bug c/65231] Dead link in man page to the status of C99 features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65231 Roman Proskuryakov humbug at deeptown dot org changed: What|Removed |Added Keywords||documentation Severity|normal |trivial
[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150 --- Comment #24 from Jan Hubicka hubicka at gcc dot gnu.org --- I beleive so, at least I can bootstrap w/o the aliases.
Re: [Bug target/63890] [4.9/5 regression] Compiling trivial program with -O -p leads to misaligned stack
Hi,
the problem is that darwin output profiler after prologue.
With ACCUMULATE_OUTGOING_ARGS we leave stack pointer aligned to boundary - 4
(for return pointer) without we leave it aligned.
I guess it is possible to compensate this in FUNCTION_PROFILER, but I am not
convinced this will work reliably. Probably disabling combine-stack-adjustments
would be needed, too.
(I do not think it is reliable with ACCUMULATE_OUTGOING_ARGS either)
Honza
Index: config/i386/darwin.h
===
--- config/i386/darwin.h(revision 221034)
+++ config/i386/darwin.h(working copy)
@@ -210,6 +210,8 @@ extern int darwin_emit_branch_islands;
#undef FUNCTION_PROFILER
#define FUNCTION_PROFILER(FILE, LABELNO) \
do { \
+ if (!ACCUMULATE_OUTGOING_ARGS) \
+fprintf (FILE, \tpushl %%ebx\n); /* Align stack */
\
if (TARGET_MACHO_BRANCH_ISLANDS \
MACHOPIC_INDIRECT !TARGET_64BIT) \
{ \
@@ -218,6 +220,8 @@ extern int darwin_emit_branch_islands;
machopic_validate_stub_or_non_lazy_ptr (name);\
} \
else fprintf (FILE, \tcall mcount\n); \
+ if (!ACCUMULATE_OUTGOING_ARGS) \
+ fprintf (FILE, \tpopl %%ebx\n); /* Align stack */ \
} while (0)
#define C_COMMON_OVERRIDE_OPTIONS \
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 221034)
+++ config/i386/i386.c (working copy)
@@ -10061,6 +10061,13 @@ ix86_compute_frame_layout (struct ix86_f
if (crtl-stack_alignment_needed PREFERRED_STACK_BOUNDARY)
crtl-stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
}
+ /* Be sure we get stack aligned for mcount call. */
+ else if (crtl-profile flag_fentry)
+{
+ crtl-preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
+ if (crtl-stack_alignment_needed PREFERRED_STACK_BOUNDARY)
+ crtl-stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
+}
stack_alignment_needed = crtl-stack_alignment_needed / BITS_PER_UNIT;
preferred_alignment = crtl-preferred_stack_boundary / BITS_PER_UNIT;
[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Also happens with gcc-5 when linking two different LibreOffice libraries. (libscfiltlo.so and libooxlo.so) The undefined symbol is: x4 ~ # c++filt _ZThn40_N3utl28OSeekableOutputStreamWrapper7acquireEv non-virtual thunk to utl::OSeekableOutputStreamWrapper::acquire() But the symbol is defined in workdir/CxxObject/unotools/source/streaming/streamwrap.o and adding this object file to the link object file list fixes the problem. So it looks like a LibreOffice issue in this case.
[Bug bootstrap/65232] New: [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65232 Bug ID: 65232 Summary: [5 Regression] bootstrap failure (ICE in change_symbol_block, at varasm.c:1230) on arm-linux-gnueabihf, in libstdc++ stage1 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with r221042 configured with --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb ../../../../../src/libstdc++-v3/src/c++98/valarray.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o valarray.o ../../../../../src/libstdc++-v3/src/c++98/strstream.cc:417:1: internal compiler error: in change_symbol_block, at varasm.c:1230 } // namespace ^ 0x9dfd7d change_symbol_block ../../src/gcc/varasm.c:1230 0x9e0045 make_decl_rtl(tree_node*) ../../src/gcc/varasm.c:1346 0x9e79cf do_assemble_alias(tree_node*, tree_node*) ../../src/gcc/varasm.c:5608 0x9efc41 varpool_node::assemble_aliases() ../../src/gcc/varpool.c:557 0x9efd61 varpool_node::assemble_decl() ../../src/gcc/varpool.c:600 0x9f01e9 symbol_table::output_variables() ../../src/gcc/varpool.c:750 0x47d2eb symbol_table::compile() ../../src/gcc/cgraphunit.c:2360 0x47d3b7 symbol_table::finalize_compilation_unit() ../../src/gcc/cgraphunit.c:2436 0x2fb569 cp_write_global_declarations() ../../src/gcc/cp/decl2.c:4754 Please submit a full bug report, with preprocessed source if appropriate. complete build log at https://launchpadlibrarian.net/198874381/buildlog_ubuntu-vivid-armhf.gcc-5_5-20150227-1ubuntu11_BUILDING.txt.gz
[Bug c/65231] New: Dead link in man page to the status of C99 features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65231
Bug ID: 65231
Summary: Dead link in man page to the status of C99 features
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: humbug at deeptown dot org
In man page c99-gcc.1.gz there is a dead link to
http://gcc.gnu.org/gcc-4.8/c99status.html
$ zgrep c99status /usr/share/man/man1/c99-gcc.1.gz
.I http://gcc.gnu.org/gcc-4.8/c99status.html
$ curl --fail http://gcc.gnu.org/gcc-4.8/c99status.html
curl: (22) The requested URL returned error: 404 Not Found
Script to check for other dead links:
$ find /usr/share/man -name *g[+c][+c]* -exec zgrep -Ho http://.*.html; {}
\; | xargs -P4 -I{} bash -c 'IFS=: read file url {}; request=`curl -m3
-LfgsS --head $url 21` || echo url: \$url\ in: \$file\ error:
\$request\ '
Version info:
$ dpkg -S c99-gcc.1.gz
gcc: /usr/share/man/man1/c99-gcc.1.gz
$ aptitude show gcc
Version: 4:4.8.2-1ubuntu6
$ c99 -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
[Bug web/65231] Dead link in man page to the status of C99 features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65231 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-27 Component|c |web Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Someone needs to add the redirect from http://gcc.gnu.org/gcc-4.8/c99status.html to http://gcc.gnu.org/c99status.html . Most likely http://gcc.gnu.org/gcc-4.9/c99status.html might need one too.
[Bug c/65088] Does GCC has load/store widening phase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088 --- Comment #3 from Marat Zakirov m.zakirov at samsung dot com --- I think this has been discussed on the gcc mailing list Marek could you please share some resuting conclusion at least for x86 platform? Why didn't x86 GCC RTL fold these loads/stores?
[Bug target/63890] [4.9/5 regression] Compiling trivial program with -O -p leads to misaligned stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63890
--- Comment #12 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
the problem is that darwin output profiler after prologue.
With ACCUMULATE_OUTGOING_ARGS we leave stack pointer aligned to boundary - 4
(for return pointer) without we leave it aligned.
I guess it is possible to compensate this in FUNCTION_PROFILER, but I am not
convinced this will work reliably. Probably disabling combine-stack-adjustments
would be needed, too.
(I do not think it is reliable with ACCUMULATE_OUTGOING_ARGS either)
Honza
Index: config/i386/darwin.h
===
--- config/i386/darwin.h(revision 221034)
+++ config/i386/darwin.h(working copy)
@@ -210,6 +210,8 @@ extern int darwin_emit_branch_islands;
#undef FUNCTION_PROFILER
#define FUNCTION_PROFILER(FILE, LABELNO)\
do {\
+ if (!ACCUMULATE_OUTGOING_ARGS)\
+fprintf (FILE, \tpushl %%ebx\n); /* Align stack */\
if (TARGET_MACHO_BRANCH_ISLANDS \
MACHOPIC_INDIRECT !TARGET_64BIT)\
{\
@@ -218,6 +220,8 @@ extern int darwin_emit_branch_islands;
machopic_validate_stub_or_non_lazy_ptr (name);\
}\
else fprintf (FILE, \tcall mcount\n);\
+ if (!ACCUMULATE_OUTGOING_ARGS)\
+ fprintf (FILE, \tpopl %%ebx\n); /* Align stack */\
} while (0)
#define C_COMMON_OVERRIDE_OPTIONS\
Index: config/i386/i386.c
===
--- config/i386/i386.c(revision 221034)
+++ config/i386/i386.c(working copy)
@@ -10061,6 +10061,13 @@ ix86_compute_frame_layout (struct ix86_f
if (crtl-stack_alignment_needed PREFERRED_STACK_BOUNDARY)
crtl-stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
}
+ /* Be sure we get stack aligned for mcount call. */
+ else if (crtl-profile flag_fentry)
+{
+ crtl-preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
+ if (crtl-stack_alignment_needed PREFERRED_STACK_BOUNDARY)
+crtl-stack_alignment_needed = PREFERRED_STACK_BOUNDARY;
+}
stack_alignment_needed = crtl-stack_alignment_needed / BITS_PER_UNIT;
preferred_alignment = crtl-preferred_stack_boundary / BITS_PER_UNIT;
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892 Bug 63892 depends on bug 65150, which changed state. Bug 65150 Summary: [5 Regression] r220875 causes bootstrap failure on x86_64 darwin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/65150] [5 Regression] r220875 causes bootstrap failure on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Fixed?
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- The pr62199-2.c test is tweaked in the posted version of the patch: https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01237.html
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Fedora gcc is built with --enable-checking=release, so performs less self-checking than trunk.
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220 --- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org --- Created attachment 34886 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34886action=edit corrected patch I cheated and looked at test results before bootstrap. There I found that gcc.dg/torture/calleesave-sse.c failed because main() was trying to read %rdx uninitialized. This happened because the splitter was reading from operand 0 which had garbage in it. What perhaps was wanted was operand 2. Also, I saw somewhere else that a division by zero was being generated, which later caused an unrecognizable insn ICE. This was easy to fix with UINTVAL (operands[3]) != 0. Corrected patch attached and being tested.
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4 Version|unknown |5.0 Keywords||missed-optimization Last reconfirmed||2015-02-26 Ever confirmed|0 |1 Summary|Regression: integer |[4.8/4.9/5 Regression] |division in stack alignment |integer division in stack |for VLA allocation |alignment for VLA ||allocation Target Milestone|--- |4.8.5 Known to fail||4.7.4, 5.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It's expansion of __builtin_alloca_with_align that produces the division. Confirmed. I can confirm that with 4.3 there is no such division.
[Bug c++/65221] New: typedef-name identifier not resolved in static member instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65221
Bug ID: 65221
Summary: typedef-name identifier not resolved in static member
instantiation
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pit at shgn dot de
Consider the following minimal example:
template typename A
struct X
{
using this_type = XA;
// typedef XA this_type;
static this_type inst;
};
template typename A
XA XA::inst;
g++ 4.9.1 (Debian 4.9.1-19) produces the following error:
$ g++ --std=c++11 -c test.cpp
test.cpp:10:12: error: conflicting declaration ‘XA XA::inst’
XA XA::inst;
^
test.cpp:6:20: note: previous declaration as ‘XA::this_type XA::inst’
static this_type inst;
^
test.cpp:10:12: error: declaration of ‘XA::this_type XA::inst’
outside of class is not definition [-fpermissive]
XA XA::inst;
I expected the compiler to resolve the typedef-name from the
alias-declaration when instantiating the static member. If we
use this_type instead of the type directly:
template typename A
const typename XA::this_type XA::inst;
the code compiles again. I assume that gcc is unable to map XA to the
alias-declaration this_type. Commenting out the alias declaration and
using the typedef line solves the problem. The standard however states
in §7.1.3 (2):
A typedef-name can also be introduced by an alias-declaration. The
identifier following the using keyword becomes a typedef-name and the
optional attribute-specifier-seq following the identifier appertains to
that typedef-name. It has the same semantics as if it were introduced by
the typedef specifier. In particular, it does not define a new type and
it shall not appear in the type-id.
[Bug target/64997] [AArch64] Illegal EON on SIMD registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64997 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from alalaw01 at gcc dot gnu.org --- Fixed r220969
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
We hit
rtx
allocate_dynamic_stack_space (rtx size, unsigned size_align,
unsigned required_align, bool cannot_accumulate)
{
...
/* ??? STACK_POINTER_OFFSET is always defined now. */
#if defined (STACK_DYNAMIC_OFFSET) || defined (STACK_POINTER_OFFSET)
must_align = true;
extra_align = BITS_PER_UNIT;
#endif
...
if (must_align)
{
/* CEIL_DIV_EXPR needs to worry about the addition overflowing,
but we know it can't. So add ourselves and then do
TRUNC_DIV_EXPR. */
target = expand_binop (Pmode, add_optab, target,
gen_int_mode (required_align / BITS_PER_UNIT - 1,
Pmode),
NULL_RTX, 1, OPTAB_LIB_WIDEN);
target = expand_divmod (0, TRUNC_DIV_EXPR, Pmode, target,
gen_int_mode (required_align / BITS_PER_UNIT,
Pmode),
NULL_RTX, 1);
target = expand_mult (Pmode, target,
gen_int_mode (required_align / BITS_PER_UNIT,
Pmode),
NULL_RTX, 1);
}
thus unconditionally trigger the must_align path (even if in this case
alignment is 32 and thus already properly aligned?). expand_divmod
doesn't handle power-of-two divisions it seems.
[Bug c++/65175] [4.9.2] ICE forming a typedef with an alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65175 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-26 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I can reproduce, but bisecting didn't pan out. ICEs with 5/4.9/4.8, but the 4.8 ICE is different.
[Bug middle-end/65224] New: fprofile-reorder-functions reorders using expand order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65224 Bug ID: 65224 Summary: fprofile-reorder-functions reorders using expand order Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org fprofile-reorder-functions reorders functions in the assembly file by changing the order of expansion of the functions. This interacts badly with -fipa-ra, which benefits from having all callees expanded before expanding the caller. See also: 1. https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02097.html ... Note that this patch will interfere rather badly with Martin's work to order functions in execution order, since it wants to have callee before caller. I wonder if we can't add support for GAS section fragments in this case to order functions in a way we want. ... 2. https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01979.html ... What happened with the plans for linker support? Perhaps we can implement the numbered sections by Carry's proposal and hope that binutils will catch up in next release? ...
[Bug sanitizer/65112] [5 Regression] -fsanitized=thread Fortran program crashes at startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65112 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Closing; please reopen if you can still reproduce.
[Bug target/65225] [AArch64] Various aarch64_rtx_costs improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktietz at gcc dot gnu.org --- Comment #11 from Kai Tietz ktietz at gcc dot gnu.org --- Mine.
[Bug c++/65202] [5 Regression] ICE segfault with constexpr/noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65202 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #31 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I have generated a test case that includes all possible combinations and found some issues with the patch related to Real (KIND 10). I am working this now.
[Bug target/65225] New: [AArch64] Various aarch64_rtx_costs improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65225 Bug ID: 65225 Summary: [AArch64] Various aarch64_rtx_costs improvements Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target: aarch64* The aarch64 rtx costs walker could be improved. Some particular areas: - In the MINUS case, the cost of new_op1 is not included at all - In the PLUS and MINUS case, extends and extended shifts are costed as alu_arith rather than extend_arith - In the PLUS and MINUS case if there is a ASHIFT or MULT after an extend/extended shift, the cost calculated in rtx_mult_cost is as if it was a plain PLUS/MINUS. If the multiply is by a power of 2, it calculates the cost as a arith_shift rather than extend_arith. If it was ASHIFT the cost is wrong as it expects a MULT rather than ASHIFT, so shift immediates which happen to be a power of 2 get a different cost. - In the ASHIFT case, if there is an extend the cost of extend should be used rather than a shift. ASHIFT 1 should use alu cost rather than shift cost (we emit an add if shift cost is higher than alu cost) - In the ASHIFRT/LSHIFTRT case the extend logic is missing. - In the ABS case for integer, speed cost should be 2 ALU instructions rather than 4. - In the and-immediate case look into handling ZERO_EXTRACT. - The NOT case misses logic for shifts (despite the comment, calculating shift cost separately is not correct) - this can be costed as ORN with zero similar to the way NEG works.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #32 from Ian Lance Taylor ian at airs dot com --- I don't think it is a good idea to add code in multiple places to fix up the pc values after calling runtime.Callers. That seems prone to error and confusing for future updates to the code. Right, which is why I never suggested that. I suggested changing runtime.Callers itself to adjust the values that it gets from libbacktrace. - Add a wrapper function to the libgo code to call backtrace_full and then adjust the pc value based on the GOARCH value, understanding what backtrace_full might have done and what the GO code expects. Then there should be no direct calls to backtrace_full in libgo, but only calls to this wrapper function. Yes, that is exactly what I have been trying to say, but we don't need to introduce a new function. We already only call backtrace_full from a single place in libgo: runtime_callers (which, to be clear, is not the same as runtime.Callers). I think the pc mapping for inlined functions is a separate issue. Inlining happens in gccgo and not gc and happens on all gcc compilers so the mapping of pc values to line numbers for inlined code is not an issue specific to gccgo and that is not the issue in this testcase. Maybe it just needs to be documented so users understand that can happen or maybe inlining should be disabled by default for gccgo and then if users enable it they understand what could happen. To be clear, libbacktrace can handle inlined functions just fine, and libgo does the right thing for things like the stack traces dumped when a program crashes. It also does the right thing when handling the skip parameter to runtime.Caller and runtime.Callers. The problem arises when converting the libbacktrace values into the single PC value expected by Go functions like runtime.Callers. I am not going to disable inlining by default for gccgo. That would be a performance killer.
[Bug libstdc++/64367] [5 Regression] g++-v5/stdexcept:52:28: error: invalid use of non-static data member '_M_p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64367 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-02-26 Resolution|FIXED |--- Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- There's another instance of the same error later in the file: /../lib/gcc/x86_64-redhat-linux/5.0.0/../../../../include/c++/5.0.0/stdexcept:83:28: error: invalid use of non-static data member '_M_s' char _M_bytes[sizeof(_M_s)]; ^~~~
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #33 from boger at us dot ibm.com --- (In reply to Ian Lance Taylor from comment #32) I don't think it is a good idea to add code in multiple places to fix up the pc values after calling runtime.Callers. That seems prone to error and confusing for future updates to the code. Right, which is why I never suggested that. I suggested changing runtime.Callers itself to adjust the values that it gets from libbacktrace. - Add a wrapper function to the libgo code to call backtrace_full and then adjust the pc value based on the GOARCH value, understanding what backtrace_full might have done and what the GO code expects. Then there should be no direct calls to backtrace_full in libgo, but only calls to this wrapper function. Yes, that is exactly what I have been trying to say, but we don't need to introduce a new function. We already only call backtrace_full from a single place in libgo: runtime_callers (which, to be clear, is not the same as runtime.Callers). In comments 21 23 it sounded there were plans to make changes in other locations too. I agree with what you just said here, that you could just make a change in runtime_callers after it calls backtrace_full to adjust the pc and then no other changes should be needed anywhere else. Yes I realize runtime_callers and runtime.Callers are different and I was being sloppy when I mentioned them. I think the pc mapping for inlined functions is a separate issue. Inlining happens in gccgo and not gc and happens on all gcc compilers so the mapping of pc values to line numbers for inlined code is not an issue specific to gccgo and that is not the issue in this testcase. Maybe it just needs to be documented so users understand that can happen or maybe inlining should be disabled by default for gccgo and then if users enable it they understand what could happen. To be clear, libbacktrace can handle inlined functions just fine, and libgo does the right thing for things like the stack traces dumped when a program crashes. It also does the right thing when handling the skip parameter to runtime.Caller and runtime.Callers. The problem arises when converting the libbacktrace values into the single PC value expected by Go functions like runtime.Callers. I am not going to disable inlining by default for gccgo. That would be a performance killer.
[Bug c++/55993] [C++11] derived-to-base conversion fails in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55993
--- Comment #12 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to splinterofchaos from comment #11)
I still get an error with 4.9 when using one of the less reduced cases,
although not when using the test cases in that patch.
#include tuple
struct A {};
constexpr auto t = std::get0( std::make_tuple( A(), A() ) );
This seems to be fixed on the trunk (GCC 5).
[Bug fortran/65223] New: Regresion on elemental type-bound procedure's passed object with INTENT(OUT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65223 Bug ID: 65223 Summary: Regresion on elemental type-bound procedure's passed object with INTENT(OUT) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jwmwalrus at gmail dot com The code below compiles just fine with gfortran 4.9, but throws an error with gfortran 5.0: module storage_mod implicit none private save type, public :: StorageClass character(20) :: name = 'default' contains procedure :: destroy = destroyStorage end type contains elemental subroutine destroyStorage(this) class(StorageClass), intent(OUT) :: this end subroutine end module storage_mod The output I get is: $ ll `which gfortran` lrwxrwxrwx 1 root root 12 Oct 18 04:03 /usr/bin/gfortran - gfortran-4.9* $ gfortran -c storage_mod.f90 $ gfortran-5.0 -c storage_mod.f90 storage_mod.f90:12:44: elemental subroutine destroyStorage(this) 1 Error: INTENT(OUT) argument 'this' of pure procedure 'destroystorage' at (1) may not be polymorphic The error goes away by removing the ELEMENTAL attribute, so it seems like a regression on valid code. The compiler and system information is: $ lsb_release -rd Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 $ gfortran-5.0 -v Using built-in specs. COLLECT_GCC=gfortran-5.0 COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20150211-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5.0-snap-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --disable-werror --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150211 (experimental) [trunk revision 220605] (Debian 20150211-1)
[Bug c++/55993] [C++11] derived-to-base conversion fails in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55993
splinterofchaos at gmail dot com changed:
What|Removed |Added
CC||splinterofchaos at gmail dot
com
--- Comment #11 from splinterofchaos at gmail dot com ---
I still get an error with 4.9 when using one of the less reduced cases,
although not when using the test cases in that patch.
#include tuple
struct A {};
constexpr auto t = std::get0( std::make_tuple( A(), A() ) );
$ g++ test.cpp -std=c++14 -Wall -Wextra; and ./a.out; echo $status
test.cpp:3:61: in constexpr expansion of ‘std::get0ul, {A, A}((*
std::make_tuple(_Elements ...) [with _Elements = {A, A}]((* A()’
/usr/include/c++/4.9/tuple:774:44: in constexpr expansion of ‘std::get0ul,
{A, A}((* __t))’
/usr/include/c++/4.9/tuple:757:40: in constexpr expansion of
‘std::__get_helper0ul, A, {A}((*(std::_Tuple_impl0ul, A, A*)( __t)))’
/usr/include/c++/4.9/tuple:744:60: in constexpr expansion of
‘std::_Tuple_impl_Idx, _Head, _Tail ...::_M_head0ul, A, {A}((* __t))’
test.cpp:3:61: error: ‘(std::_Head_base0ul, A, true*)( std::tupleA, A())’
is not a constant expression
constexpr auto t = std::get0( std::make_tuple( A(), A() ) );
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.1-16ubuntu6'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6)
[Bug debug/46102] [4.8/4.9/5 Regression] ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102 --- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org --- Author: aldyh Date: Thu Feb 26 15:31:52 2015 New Revision: 221016 URL: https://gcc.gnu.org/viewcvs?rev=221016root=gccview=rev Log: PR debug/46102 * dwarf2out.c (dwarf2out_init): Disable -feliminate-dwarf2-dups. testsuite/ PR debug/46102 * g++.dg/debug/dwarf2-1.C: XFAIL and move... * g++.dg/debug/dwarf2/dwarf2-1.C: ...here. * g++.dg/debug/dwarf2-2.C: XFAIL and move... * g++.dg/debug/dwarf2/dwarf2-2.C: ...here. * g++.dg/debug/dwarf2/typedef5.C: XFAIL. * g++.dg/debug/pr46123.C: XFAIL and move... * g++.dg/debug/dwarf2/pr46123-2.C: ...here. * gcc.dg/debug/dwarf2-3.c: Move... * gcc.dg/debug/dwarf2/dwarf2-3.c: ...here. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-1.C - copied, changed from r221015, trunk/gcc/testsuite/g++.dg/debug/dwarf2-1.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/dwarf2-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr46123-2.C - copied, changed from r221015, trunk/gcc/testsuite/g++.dg/debug/pr46123.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-3.c - copied, changed from r221015, trunk/gcc/testsuite/gcc.dg/debug/dwarf2-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2/dwarf2-3.h - copied, changed from r221015, trunk/gcc/testsuite/gcc.dg/debug/dwarf2-3.h Removed: trunk/gcc/testsuite/g++.dg/debug/dwarf2-1.C trunk/gcc/testsuite/g++.dg/debug/dwarf2-2.C trunk/gcc/testsuite/g++.dg/debug/pr46123.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2-3.c trunk/gcc/testsuite/gcc.dg/debug/dwarf2-3.h Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef5.C
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- Suggested patch send at https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01615.html
[Bug c++/64570] error: non-trivial conversion at assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64570 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Richard Biener from comment #2) Fails everywhere, 4.6 rejects the testcase. Looks more like a C++ frontend issue to me. Still goes wrong over a month later with trunk dated 20150225.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #31 from Ian Lance Taylor ian at airs dot com --- Why is it important to be able to map a file:line to a single PC? The problem is that the Go code in the runtime/pprof package assumes that it can take a single PC value and map that to a meaningful file/line. Which it can, but with gccgo it loses inlining information. But there is no useful file/line information in a signal handler anyhow. I would imagine file:line information *is* useful for user written signal handlers and in case of a panic or crash. Sorry, I misspoke. I meant signal trampoline--the code in the C library that is invoked by the kernel--not signal handler.
[Bug c++/65202] [5 Regression] ICE segfault with constexpr/noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65202 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Feb 26 15:03:23 2015 New Revision: 221015 URL: https://gcc.gnu.org/viewcvs?rev=221015root=gccview=rev Log: PR c++/65202 * constexpr.c (cxx_eval_constant_expression): Don't evaluate a RETURN_EXPR if its operand is null. * g++.dg/cpp1y/pr65202.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr65202.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34884 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34884action=edit gcc5-pr65520.patch Untested patch for the i386.md change.
[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - abs vectorization fails for char/short types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946 --- Comment #9 from vekumar at gcc dot gnu.org --- This match.pd pattern vectorizes the PR but works only with -fwrapv. (simplify ( convert (abs (convert@1 @0))) ( if (INTEGRAL_TYPE_P (type) /* We check for type compatibility between @0 and @1 below, so there's no need to check that @1/@3 are integral types. */ INTEGRAL_TYPE_P (TREE_TYPE (@0)) INTEGRAL_TYPE_P (TREE_TYPE (@1)) /* The precision of the type of each operand must match the precision of the mode of each operand, similarly for the result. */ (TYPE_PRECISION (TREE_TYPE (@0)) == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@0 (TYPE_PRECISION (TREE_TYPE (@1)) == GET_MODE_PRECISION (TYPE_MODE (TREE_TYPE (@1 TYPE_PRECISION (type) == GET_MODE_PRECISION (TYPE_MODE (type)) /* The inner conversion must be a widening conversion. */ TYPE_PRECISION (TREE_TYPE (@1)) TYPE_PRECISION (TREE_TYPE (@0)) ((GENERIC (TYPE_MAIN_VARIANT (TREE_TYPE (@0)) == TYPE_MAIN_VARIANT (type))) || (GIMPLE types_compatible_p (TREE_TYPE (@0), type (if (TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))) (abs @0 For default cases (when no -fwrapv is given), doing ABSE_EXPR(shorttype) will invoke undefined behaviour when value is -32678. similarly for signed char min. As per Richard suggestion we need to move to a new tree code ABSU_EXPR to do this type of folding optimization.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #30 from boger at us dot ibm.com --- I don't think it is a good idea to add code in multiple places to fix up the pc values after calling runtime.Callers. That seems prone to error and confusing for future updates to the code. From what I can tell, the problem originates with the use of backtrace_full from the libgo code to find the pc stack values for some platforms. I think if the pc was never decremented in the backtrace code then I think the values are right. However I understand you can't just change that behavior due to other existing users of this code that might expect it to continue working as before. Here are some options: - Add a new function to libbacktrace for this situation where the pc is never decremented. - Add a flag to one of the backtrace structures to indicate you don't want the pc decremented in libbacktrace and then use that flag in libbacktrace to control whether the pc is decremented. - Add a wrapper function to the libgo code to call backtrace_full and then adjust the pc value based on the GOARCH value, understanding what backtrace_full might have done and what the GO code expects. Then there should be no direct calls to backtrace_full in libgo, but only calls to this wrapper function. Once the stack pc values are generated as expected then runtime.Callers has the correct values according to what its callers would expect, how it is documented, and matches gc behavior. I think the pc mapping for inlined functions is a separate issue. Inlining happens in gccgo and not gc and happens on all gcc compilers so the mapping of pc values to line numbers for inlined code is not an issue specific to gccgo and that is not the issue in this testcase. Maybe it just needs to be documented so users understand that can happen or maybe inlining should be disabled by default for gccgo and then if users enable it they understand what could happen.
[Bug debug/46102] [4.8/4.9/5 Regression] ICE: SIGSEGV in dwarf2out_finish (dwarf2out.c:8490) with -feliminate-dwarf2-dups when using precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46102 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Aldy Hernandez aldyh at gcc dot gnu.org --- Fixed and closed. For further details on -feliminate-dwarf2-dups on C++ as a whole, please see PR53118.
[Bug debug/53118] [4.8/4.9/5 regression] -feliminate-dwarf2-dups is broken for C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53118 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 CC||aldyh at gcc dot gnu.org --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org --- -feliminate-dwarf2-dups has been disabled for C++ (see PR46102). However, as noted by Ian in the thread in #c1, there are better ways of removing duplicates in dwarf4. Consequently, I don't believe this should be in the serious regression category. Downgrading.
[Bug tree-optimization/61634] [4.8 Regression] ICE in in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61634 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Feb 26 13:28:48 2015 New Revision: 221006 URL: https://gcc.gnu.org/viewcvs?rev=221006root=gccview=rev Log: 2015-02-26 Richard Biener rguent...@suse.de Backport from mainline 2014-11-27 Richard Biener rguent...@suse.de PR tree-optimization/61634 * tree-vect-slp.c: (vect_detect_hybrid_slp_stmts): Rewrite to propagate hybrid down the SLP tree for one scalar statement. (vect_detect_hybrid_slp_1): New walker function. (vect_detect_hybrid_slp_2): Likewise. (vect_detect_hybrid_slp): Properly handle pattern statements in a pre-scan over all loop stmts. * gcc.dg/vect/pr61634.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/vect/pr61634.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-slp.c
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Fixed by Sebastain's change on the trunk.
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law law at redhat dot com --- Per c#3/c#4.
[Bug libgcc/65038] [regression 5] Unable to find ftw.h for libgcov-util.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-26 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. I have a patch for it
[Bug c/65217] __builtin_unreachable in if statement causes bad assembly generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65217 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Thu Feb 26 14:17:06 2015 New Revision: 221010 URL: https://gcc.gnu.org/viewcvs?rev=221010root=gccview=rev Log: Add a testcase for PR target/65217 PR target/65217 * gcc.target/i386/pr65217.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr65217.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug other/63509] Misleading error message when building gcc without C++ compiler installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509 Richard W.M. Jones rjones at redhat dot com changed: What|Removed |Added CC||rjones at redhat dot com --- Comment #3 from Richard W.M. Jones rjones at redhat dot com --- Can confirm this happens also on Fedora 23. Installing gcc-c++ fixes it.
[Bug target/65222] New: [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 Bug ID: 65222 Summary: [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org At least the following options for -mtune= or -march= are not documented: slm, knl, shanghai, istanbul Marked as regression as knl is new since GCC 5. slm should be simple as it is an alias of silvermont (new since GCC 4.9). shanghai and istanbul seem to exist since GCC 4.8.
[Bug target/65171] [5 Regression] r214254 causes thousands of std::length_errors running boost testsuite on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65171 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- Yes, this is unrelated and not really a problem. Something has caused us to recently start spilling a couple of nonvolatile vector registers to the stack for this test case, resulting in the failure. I'm going to look into why this occurred (introduced on 2/13). Bill
[Bug tree-optimization/65193] [4.9 Regression] ICE: Segmentation fault with -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65193
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
I already get
./xg++ -B. -nostdlib -fPIC -flto -shared t.ii -O2 -g
t.ii: In function ‘float_next_imp’:
t.ii:33:7: error: address taken, but ADDRESSABLE bit not set
float_next_imp (T p1, Policy p2)
^
d
t.ii:38:4: note: in statement
frexp (p1, d);
^
# .MEM_13 = VDEF .MEM_11
frexp (p1_5(D), d);
t.ii:33:7: internal compiler error: verify_gimple failed
float_next_imp (T p1, Policy p2)
^
0xaf39de verify_gimple_in_cfg(function*)
Ok. It is the execute_update_addresses_taken () call in the TODO of the
IPA inline transform pass that re-sets TREE_ADDRESSABLE here. Somehow
we have merged 'd' from two different places it seems (the optimization
is in _GLOBAL__sub_I_t.ii).
The duplicate appears in _GLOBAL__sub_I_t.ii after inlining:
{ Scope block #21 t.ii:13 Originating from : static long doubleD.2801
get_min_shift_valueD.2829 (void);
{ Scope block #23 Originating from :#0
voidD.2802 Unknown tree: imported_decl = ldexpD.2839;
intD.2788 dD.2905; (nonlocalized)
...
_GLOBAL__sub_I_t.ii ()
{
...
}
...
float_next_imp (intD.2788 p1D.2902, struct AD.2830 p2D.2903)
{
struct AD.2830 D.2919;
intD.2788 D.2918;
const intD.2833 ISRA.9D.2915;
intD.2788 dD.2905;
const intD.2833 D.2904;
something is messed up. The decl is streamed via streaming struct function
local-decls from float_next_imp (as expected). No idea how it ends up in
the vars for _GLOBAL__sub_I_t.ii.
Ah. We inline
(gdb) p debug_gimple_stmt (stmt)
# .MEM = VDEF .MEM
get_min_shift_value ();
$91 = void
but somehow we end up with
(gdb) p debug_tree (old_var)
var_decl 0x7683c8e8 d
type integer_type 0x766b2690 int asm_written public SI
size integer_cst 0x766b53a0 constant 32
unit size integer_cst 0x766b53c0 constant 4
align 32 symtab -159219552 alias set -1 canonical type 0x766b2690
precision 32 min integer_cst 0x766b5340 -2147483648 max integer_cst
0x766b5360 2147483647
pointer_to_this pointer_type 0x766bd738
addressable SI file t.ii line 36 col 8 size integer_cst 0x766b53a0 32
unit size integer_cst 0x766b53c0 4
align 32 context function_decl 0x76821b00 float_next_imp
in its BLOCK tree. Which gets populated by
Old value = tree 0x0
New value = block 0x76828fa0
0x00cd9194 in lto_input_ts_block_tree_pointers (ib=0x7fffd610,
data_in=0x1bee6a0, expr=block 0x76828fa0)
at /space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-streamer-in.c:928
928 BLOCK_SUBBLOCKS (BLOCK_SUPERCONTEXT (expr)) = expr;
but finally the valid block tree
(gdb) p debug_tree (expr)
block 0x76828fa0
vars imported_decl 0x7681e8a0 D.2856
type void_type 0x766bd000 void asm_written VOID
align 8 symtab 0 alias set -1 canonical type 0x766bd000
pointer_to_this pointer_type 0x766bd0a8
VOID file t.ii line 39 col 2
align 1 initial function_decl 0x7682a100 ldexp
chain var_decl 0x766abd10 c type real_type 0x766bd498 long
double
public static weak XF file t.ii line 28 col 13
size integer_cst 0x766b50a0 constant 128
unit size integer_cst 0x766b50c0 constant 16
align 128 context function_decl 0x76821a00
get_min_shift_value
gets invalid by
Hardware watchpoint 16: *$111
Old value = var_decl 0x766abd10 c
New value = var_decl 0x7683c8e8 d
0x00cd579b in streamer_read_chain (ib=0x7fffd990,
data_in=0x1bee740)
at /space/rguenther/src/svn/gcc-4_9-branch/gcc/tree-streamer-in.c:85
85 TREE_CHAIN (prev) = curr;
where 'prev' is that IMPORTED_DECL which is streamed globally it seems (ups).
And we miss r212992 on the branch.
[Bug c++/65221] typedef-name identifier not resolved in static member instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65221 --- Comment #1 from Philipp Ittershagen gcc-bugzilla at mail dot shgn.de --- $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-19' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.1 (Debian 4.9.1-19)
[Bug tree-optimization/61634] [4.8 Regression] ICE in in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61634 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.5 Resolution|--- |FIXED Known to fail||4.8.4 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/65048] [5 Regression] ICE in add_phi_args_after_copy_edge, at tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65048 --- Comment #3 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Thu Feb 26 13:56:39 2015 New Revision: 221007 URL: https://gcc.gnu.org/viewcvs?rev=221007root=gccview=rev Log: PR tree-optimization/65048 * tree-ssa-threadupdate.c (valid_jump_thread_path): New. (thread_through_all_blocks): Call valid_jump_thread_path. Remove invalid FSM jump-thread paths. PR tree-optimization/65048 * gcc.dg/tree-ssa/ssa-dom-thread-9.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- See r164593. expand_divmod works just fine, but here we aren't dividing by CONST_INT, but virtual reg. One way to improve this, if crtl-preferred_stack_boundary is always a power of two, would be to add another virtual register, virtual_preferred_stack_boundary_log_rtx, which would be substituted with exact_log2 (crtl-preferred_stack_boundary / BITS_PER_UNIT). Another possibility is to tweak i?86 udivmod* patterns, so that they would accept non-immediates and power of two CONST_INTs, but because that patterns computes both division and modulus, we'd need to split that into LSHIFTRT and AND. As i?86 is the only target with SUPPORTS_STACK_ALIGNMENT support, perhaps this change would be more kind to all other targets.
[Bug target/43701] [4.8/4.9/5 Regression] ICE: SIGSEGV (too deep recursion) with -mno-sse and __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43701 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||ktietz at gcc dot gnu.org Known to work|| Known to fail|| --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Can't reproduce the segmentation-fault anymore on 4.8, 4.9, and 5.0. Testcase is fixed for 5.0, just 4.8, and 4.9 are still reporting SE register return with SSE disabled. So I would suggest to close bug, as it is unlikely that 5.0 changes getting backmerged for this to older branches
[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed then.
[Bug c/57647] lvalue required as increment operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57647 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems there's nothing to do here.
[Bug c/49748] char * const * cannot be assigned to char const * const *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49748 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Tim Ruehsen from comment #3) This is much work that could be avoided by an apropriate -W option. GCC 5 has now the -Wincompatible-pointer-types option that can be used to quiet the warning.
[Bug target/65171] [5 Regression] r214254 causes thousands of std::length_errors running boost testsuite on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65171 --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- Author: wschmidt Date: Thu Feb 26 17:43:03 2015 New Revision: 221022 URL: https://gcc.gnu.org/viewcvs?rev=221022root=gccview=rev Log: 2015-02-26 Bill Schmidt wschm...@linux.vnet.ibm.com PR target/65171 * config/rs6000/rs6000.c (rs6000_analyze_swaps): Ensure instructions with TImode operands are included in the analysis. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/65171] [5 Regression] r214254 causes thousands of std::length_errors running boost testsuite on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65171 Bill Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org --- Fixed.
[Bug c/63420] GCC 4.8.2: Bitshift second operand range not as per manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- That words come from http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html That is not a part of GCC though, so closing.
[Bug c/35330] [4.8/4.9/5 regression] ICE with invalid pragma weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
--- Comment #12 from Kai Tietz ktietz at gcc dot gnu.org ---
issue seems to be that in declare_weak we don't check that DECL is actually
either a function, or a variable declaration.
Fix would be to add an error-message in declare_weak ().
Index: varasm.c
===
@@ -5398,6 +5399,12 @@ void
declare_weak (tree decl)
{
gcc_assert (TREE_CODE (decl) != FUNCTION_DECL || !TREE_ASM_WRITTEN (decl));
+ if (TREE_CODE (decl) != FUNCTION_DECL TREE_CODE (decl) != VAR_DECL)
+{
+ error (weak declaration of %q+D has to be either a function,
+ or a variable declaration, decl);
+ return;
+}
if (! TREE_PUBLIC (decl))
error (weak declaration of %q+D must be public, decl);
else if (!TARGET_SUPPORTS_WEAK)
[Bug c/58288] Incorrect error message on malformed section attribute syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58288 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Please post patches to gcc-patches mailing list.
[Bug go/64999] s390x libgo test failure in TestMemoryProfiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999 --- Comment #34 from Ian Lance Taylor ian at airs dot com --- You're right, we could just change runtime_callers. Or, simpler still, just change callback in libgo/runtime/go-callers.c. Good point.
[Bug c/58942] cilkplus internal compiler error: tree check __sec_reduce_max_ind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c/65088] Does GCC has load/store widening phase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I think this has been discussed on the gcc mailing list.
[Bug plugins/65226] New: hgcc-plugin.h is unusable when GCC was build with non-system or in-tree GMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65226 Bug ID: 65226 Summary: hgcc-plugin.h is unusable when GCC was build with non-system or in-tree GMP Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: Bert.Wesarg at googlemail dot com Created attachment 34885 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34885action=edit file which includes gcc-plugin.h When building a non-cross GCC with a non-system GMP (i.e., by specifying --with-gmp or --with-gmp-include) or an in-tree GMP (i.e., having a gmp directory in the source tree), and no system GMP is avaiable, than the installed plugin headers are unusable. The following excersices the problem with an in-tree GMP. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/wesarg/opt/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/wesarg/opt/gcc-4.9.2 --enable-languages=c,c++,fortran --disable-nls --enable-checking=yes --disable-werror --disable-bootstrap Thread model: posix gcc version 4.9.2 (GCC) Compiling the attached test file, which just includes the gcc-plugin.h header, results in this error: $ g++ -save-temps -c -I$(g++ -print-file-name=plugin/include) include-gcc-plugin.cc In file included from /home/wesarg/opt/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/plugin/include/gcc-plugin.h:28:0, from include-gcc-plugin.cc:1: /home/wesarg/opt/gcc-4.9.2/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/plugin/include/system.h:647:17: fatal error: gmp.h: No such file or directory #include gmp.h ^ compilation terminated. This should be unralated to PR 55961, as this handled cross builds, i.e., build != host.
[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65227
--- Comment #2 from Bert Wesarg Bert.Wesarg at googlemail dot com ---
(In reply to Andrew Pinski from comment #1)
You should always include gcc-plugin.h first when compiling plugins.
But the documentation in gcc/doc/plugins.texi only reads:
The header @file{gcc-plugin.h} must be the first gcc header to be included.
Thus it does it not required that gcc-plugin.h is the first header at all to be
included. And this doesn't changed between GCC 4.9.2 and the GCC 5 snapshot.
[Bug other/65228] New: libcc1: ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Bug ID: 65228 Summary: libcc1: ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com CC: pmuldoon at redhat dot com Host: x86_64-linux-gnu Target: x86_64-linux-gnu FAIL: gcc (GCC) 5.0.0 20150226 (experimental) PATH=/home/jkratoch/redhat/gcchead-root/bin:$PATH LD_LIBRARY_PATH=/home/jkratoch/redhat/gcchead-root/lib64 /home/jkratoch/redhat/gdb-clean/gdb/gdb -nx gdb -ex start -ex 'compile code -r __auto_type qwe = def' gdb command line:1:19: error: ‘def’ undeclared here (not in a function) *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event| Plugins PLUGIN_PRE_GENERICIZE| libcc1plugin PLUGIN_GGC_MARKING | libcc1plugin PLUGIN_PRAGMAS | libcc1plugin gdb command line:2:1: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl, at c/c-decl.c:4469 0xd41bd4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /home/jkratoch/redhat/gcchead/gcc/tree.c:9462 0x605649 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /home/jkratoch/redhat/gcchead/gcc/tree.h:2960 0x605649 start_decl(c_declarator*, c_declspecs*, bool, tree_node*) /home/jkratoch/redhat/gcchead/gcc/c/c-decl.c:4469 0x640dec c_parser_declaration_or_fndef /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1802 0x65d317 c_parser_external_declaration /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1452 0x65dbd9 c_parser_translation_unit /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:1339 0x65dbd9 c_parse_file() /home/jkratoch/redhat/gcchead/gcc/c/c-parser.c:15418 0x6b4062 c_common_parse_file() /home/jkratoch/redhat/gcchead/gcc/c-family/c-opts.c:1057 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Compilation failed. (gdb) _ For gcc-5.0.0-0.15.fc23.x86_64 the same reproducer hangs due to FD not closed by the driver but that is a different bug. Filing as a tracker, I guess it is libcc1 specific so we should fix it.
[Bug lto/64693] [5 Regression] PCH failed with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64693 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.
[Bug lto/64693] [5 Regression] PCH failed with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64693 --- Comment #8 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Thu Feb 26 20:21:38 2015 New Revision: 221031 URL: https://gcc.gnu.org/viewcvs?rev=221031root=gccview=rev Log: Fix PR ipa/64693 PR ipa/64693 * ipa-icf.c (symbol_compare_collection::symbol_compare_collection): New. (sem_item_optimizer::subdivide_classes_by_sensitive_refs): New function. (sem_item_optimizer::process_cong_reduction): Include division by sensitive references. * ipa-icf.h (struct symbol_compare_hashmap_traits): New class. * ipa-ref.c (ipa_ref::address_matters_p): New function. * ipa-ref.h (ipa_ref::address_matters_p): Likewise. * g++.dg/ipa/pr64146.C: Update expected results. * gcc.dg/ipa/ipa-icf-26.c: Update test. * gcc.dg/ipa/ipa-icf-33.c: Remove redundant line. * gcc.dg/ipa/ipa-icf-34.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/ipa-icf.h trunk/gcc/ipa-ref.c trunk/gcc/ipa-ref.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/pr64146.C trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-26.c trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-33.c
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added Component|other |c Host|x86_64-linux-gnu| Summary|libcc1: ICE: expected tree |ICE: expected tree that |that contains ‘decl |contains ‘decl minimal’ |minimal’ structure, have|structure, have |‘error_mark’ in start_decl |‘error_mark’ in start_decl --- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com --- echo '__auto_type qwe = def'|/home/jkratoch/redhat/gcchead-root/bin/gcc -x c - produces the same internal error
[Bug target/65192] [avr-tiny] ICE in tiny_valid_direct_memory_access_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65192 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed.
[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65227 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- You should always include gcc-plugin.h first when compiling plugins.
[Bug rtl-optimization/65220] [4.8/4.9/5 Regression] integer division in stack alignment for VLA allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65220 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org --- Investigating why Jakub's patch fails bootstrap.
[Bug ipa/65008] [5 Regression] ICE: in estimate_edge_growth, at ipa-inline.h:298 with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65008 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Feb 26 18:59:50 2015 New Revision: 221025 URL: https://gcc.gnu.org/viewcvs?rev=221025root=gccview=rev Log: PR ipa/65008 * ipa-inline.c (early_inliner): Recompute inline parameters. * g++.dg/ipa/pr65008.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr65008.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug plugins/65227] New: Plugin headers are unusable when included after inttypes.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65227 Bug ID: 65227 Summary: Plugin headers are unusable when included after inttypes.h Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: Bert.Wesarg at googlemail dot com GCC 5 20150215 Snapshot. When the gcc-plugin.h header is included after the inttypes.h header, than the compilation breaks. Used compiler: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/wesarg/opt/gcc-5-20150215/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/home/wesarg/opt/gcc-5-20150215 --enable-languages=c,c++,fortran --disable-nls --enable-checking=yes --disable-werror Thread model: posix gcc version 5.0.0 20150215 (experimental) (GCC) Compiling the attached file, which includes inttypes.h before gcc-plugin.h results in this error: $ g++ -save-temps -c -I$(g++ -print-file-name=plugin/include) no-inttypes-pri-macros.cc In file included from /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/double-int.h:23:0, from /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/gcc-plugin.h:52, from no-inttypes-pri-macros.cc:2: /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h: In member function 'void generic_wide_intT::dump() const': /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h:877:26: error: expected ')' before 'PRIx64' fprintf (stderr, HOST_WIDE_INT_PRINT_HEX ,, val[len - 1 - i]); ^ In file included from /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/double-int.h:23:0, from /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/gcc-plugin.h:52, from no-inttypes-pri-macros.cc:2: /home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h:878:24: error: expected ')' before 'PRIx64' fprintf (stderr, HOST_WIDE_INT_PRINT_HEX ], precision = %d\n, ^ The reason seems to be, that system.h defines __STDC_FORMAT_MACROS, than conditionally includes inttypes.h, and later hwint.h relys that this conditional include has resulted in the definition of the PRI macros. But that is not the case as the the include inttypes.h in system.h is not the first inclusion of this header.
[Bug target/65192] [avr-tiny] ICE in tiny_valid_direct_memory_access_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65192 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Thu Feb 26 19:43:54 2015 New Revision: 221029 URL: https://gcc.gnu.org/viewcvs?rev=221029root=gccview=rev Log: PR target/65192 * config/avr/avr-protos.h (tiny_valid_direct_memory_access_range): Remove. * config/avr/avr.c: Same. (avr_legitimate_address_p) AVR_TINY, CONSTANT_ADDRESS_P: Refuse any constant address not in 0..0xbf. * config/avr/avr.md (*movmode, *movsf): Remove tiny_valid_direct_memory_access_range from insn conditions. (movmode): Don't special-case expansion of avrtiny addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md
[Bug target/61142] [SH] QImode/HImode @(R0,Rm),Rn does not load to Rn = R0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61142 --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Thu Feb 26 19:14:23 2015 New Revision: 221026 URL: https://gcc.gnu.org/viewcvs?rev=221026root=gccview=rev Log: gcc/ PR target/61142 * config/sh/sh.c (sh_check_add_incdec_notes): New function. * config/sh/sh-protos.h (sh_check_add_incdec_notes): Declare it. * config/sh/predicates.md (const_logical_operand): New predicate. * config/sh/sh.md: Add new peephole2 patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh-protos.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug ipa/65008] [5 Regression] ICE: in estimate_edge_growth, at ipa-inline.h:298 with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65008 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/65061] [4.8/4.9/5 Regression] Issue with using declaration and member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65061 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||fabien.chene at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Let's add Fabien in CC.
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-26 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, mine.
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 26 21:03:14 2015 New Revision: 221034 URL: https://gcc.gnu.org/viewcvs?rev=221034root=gccview=rev Log: PR tree-optimization/65216 * tree-ssa-reassoc.c (rewrite_expr_tree): Force creation of new stmt and new SSA_NAME for lhs whenever the arguments have changed and weren't just swapped. Fix comment typo. * gcc.c-torture/execute/pr65216.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65216.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Feb 26 21:01:59 2015 New Revision: 221033 URL: https://gcc.gnu.org/viewcvs?rev=221033root=gccview=rev Log: PR tree-optimization/65215 * tree-ssa-math-opts.c (find_bswap_or_nop_load): Return false for PDP endian targets. (perform_symbolic_merge, find_bswap_or_nop_1, find_bswap_or_nop): Fix up formatting issues. (bswap_replace): Likewise. For BYTES_BIG_ENDIAN, if the final access size is smaller than the original, adjust MEM_REF offset by the difference of sizes. Use is_gimple_mem_ref_addr instead of is_gimple_min_invariant test to avoid adding address temporaries. * gcc.c-torture/execute/pr65215-1.c: New test. * gcc.c-torture/execute/pr65215-2.c: New test. * gcc.c-torture/execute/pr65215-3.c: New test. * gcc.c-torture/execute/pr65215-4.c: New test. * gcc.c-torture/execute/pr65215-5.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr65215-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr65215-2.c trunk/gcc/testsuite/gcc.c-torture/execute/pr65215-3.c trunk/gcc/testsuite/gcc.c-torture/execute/pr65215-4.c trunk/gcc/testsuite/gcc.c-torture/execute/pr65215-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug c/65228] ICE: expected tree that contains ‘decl minimal’ structure, have ‘error_mark’ in start_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228 --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com --- Interesting that FSF GCC r220934 which should be gcc-5.0.0-0.16.fc23.x86_64 still crashes while that Fedora GCC does not crash.
[Bug tree-optimization/65216] [5 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65216 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) Started with r220164, will have a look. Yeah, I also pushed this to make issues like this pop up so we can fix them (VRP is really the pass that should expose bogus range info best).
[Bug c++/65202] [5 Regression] ICE segfault with constexpr/noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65202 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-26 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Summary|[5.0 regression]ICE |[5 Regression] ICE segfault |segfault with |with constexpr/noexcept |constexpr/noexcept | Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with mine r218220.
[Bug c++/65202] [5 Regression] ICE segfault with constexpr/noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65202 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- So taking.
[Bug c++/65154] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-26 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 34878 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34878action=edit patch I am testing the following (further testing appreciated).
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34879 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34879action=edit gcc5-pr65215.patch Untested fix. There are still issues left, e.g. I can't understand the bswap part in if (bswap align GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; Don't you use the new MEM_REF even for the !bswap (aka nop) case? So, I don't see how it would be safe to generate that. And the testsuite coverage of this is definitely suboptimal, from endianity POV, bitfields etc.
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
I mean something like:
unsigned int
foo (unsigned char *p)
{
return ((unsigned int) p[0] 24) | (p[1] 16) | (p[2] 8) | p[3];
}
on strict align big endian machines, let me add another testcase.
[Bug testsuite/63175] [4.9/5 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a.c scan-tree-dump-times slp2 basic block vectorized using SLP 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Looking at the original description - note that copying cannot be optimized away, the accesses are to global variables (well, unless you build with -flto or -fwhole-program which will privatize the stmts). But of course the correctness test is optimized away very early. So the testcase should get a __asm__ volatile ( : : memory); inbetween the copying and the correctness verification. Currently vectorization is entered with the IL bb 2: _8 = MEM[(unsigned int *)in + 4B]; MEM[(unsigned int *)out] = _8; _14 = MEM[(unsigned int *)in + 8B]; MEM[(unsigned int *)out + 4B] = _14; _20 = MEM[(unsigned int *)in + 12B]; MEM[(unsigned int *)out + 8B] = _20; _26 = MEM[(unsigned int *)in + 16B]; MEM[(unsigned int *)out + 12B] = _26; return 0; (see - no check anymore) We generate (with -mcpu=e6500 -m64 -maltivec -mabi=altivec, just to pick one example) bb 2: vect__2.12_11 = __builtin_altivec_mask_for_load (MEM[(unsigned int *)in + 4B]); vectp.14_13 = MEM[(unsigned int *)in + 4B] -16B; vect__2.15_14 = MEM[(unsigned int *)vectp.14_13]; vectp.14_16 = MEM[(void *)in + 16B] -16B; vect__2.16_17 = MEM[(unsigned int *)vectp.14_16]; vect__2.17_18 = REALIGN_LOAD vect__2.15_14, vect__2.16_17, vect__2.12_11; MEM[(unsigned int *)out] = vect__2.17_18; return 0; and (insn 16 15 17 (set (subreg:DI (reg:V4SI 171 [ vect__2.15 ]) 8) (mem:DI (plus:DI (reg:DI 170) (const_int 8 [0x8])) [1 MEM[(unsigned int *)MEM[(unsigned int *)in + 4B] -16B]+8 S8 A32])) t.c:14 -1 (nil)) (insn 17 16 18 (set (subreg:DI (reg:V4SI 171 [ vect__2.15 ]) 0) (mem:DI (reg:DI 170) [1 MEM[(unsigned int *)MEM[(unsigned int *)in + 4B] -16B]+0 S8 A32])) t.c:14 -1 (nil)) (insn 21 20 22 (set (reg:V4SI 176) (mem:V4SI (reg:DI 174) [1 MEM[(unsigned int *)MEM[(void *)in + 16B] -16B]+0 S16 A128])) t.c:14 -1 (nil)) so for some reason we expand the first aligned load using two DI loads. Investigating. I have a fix which ends up producing .L.main1: addis 9,2,.LANCHOR0@toc@ha li 3,0 addi 9,9,.LANCHOR0@toc@l addi 10,9,4 addi 9,9,16 neg 8,10 lvx 0,0,9 lvsr 13,0,8 addis 9,2,.LANCHOR1@toc@ha lvx 1,0,10 addi 9,9,.LANCHOR1@toc@l vperm 0,1,0,13 stvx 0,0,9 blr not sure if that is the same as with 4.8 though (don't have a cross ready to verify - but the RTL looks good).
[Bug c++/64959] SFINAE in UDLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64959 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 Known to fail|5.0 | --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- I suppose we can close this.
[Bug target/57982] GetModuleHandle in __register_frame_info causes abort on unload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57982 Jean-Pierre Flori jpflori at gmail dot com changed: What|Removed |Added CC||jpflori at gmail dot com --- Comment #2 from Jean-Pierre Flori jpflori at gmail dot com --- (In reply to Kai Tietz from comment #1) Ups, this bug didn't shown up in my search-list ... Issue fixed for 4.7, 4.8, and trunk at rev 204635-204637. I recently stumbled on a similar problem again with a recent Cygwin/GCC combination. Looking at the fix included in GCC, it does look slightly different from what was first suggested here. Could someone more knowledgeable than me have a look and tell whether the included fix is fine or incomplete? If incomplete, I'll be happy to open a new bug report. See here for my report on cygwin's mailing-list: https://cygwin.com/ml/cygwin-apps/2015-01/msg00062.html
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #34879|0 |1 is obsolete|| --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34880 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34880action=edit gcc5-pr65215.patch Updated patch that performs the alignment check unconditionally.
[Bug tree-optimization/65215] [5 Regression] Bswap load miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65215 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) Created attachment 34879 [details] gcc5-pr65215.patch Untested fix. There are still issues left, e.g. I can't understand the bswap part in if (bswap align GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; Don't you use the new MEM_REF even for the !bswap (aka nop) case? So, I don't see how it would be safe to generate that. And the testsuite coverage of this is definitely suboptimal, from endianity POV, bitfields etc. I suggested that change (remove bswap ) multiple times, but it got lost appearantly. (I even remember applying that change myself!?)
