[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 Rene Koecher changed: What|Removed |Added CC||rene.koecher@wincor-nixdorf ||.com --- Comment #11 from Rene Koecher --- Hi, I want to chime in on this - is there anything new regarding the issue? The current state marks it as UNCONFIRMED however there is some definite performance loss even in the current 4.9.1 and 4.9.2 gcc releases. My employer switched to gcc 4.9.1 recently and our codebase (mostly C++, heave users of stl / boost) has almost doubled it's compile time. We're up to 60min for a clean compile - and that is with ccache enabled. Plain, no-ccache compiles are even worse. Compiling with -ftime-report shows that g++ is spending significant ammounts of time in the 'parsing' stage (mostly between 1.8 and 2.8sec/per file). Currently we're using 4.9.1 on CentOS 5 (custom build) but I also confirmed the same increase in compile time on a Gentoo and Debian system.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 --- Comment #22 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #21) > Another option is not to add -mdynamic-no-pic for clang and other compilers > that don't support -mno-dynamic-no-pic. clang supports (and generates appropriate code for) -mdynamic-no-pic. as wee see (at present) it doesn't support -mno-dynamic-no-pic [(In reply to Jakub Jelinek from comment #21) > Another option is not to add -mdynamic-no-pic for clang and other compilers > that don't support -mno-dynamic-no-pic. Yeah, that seems like the safest bet :-(. (will try to get a patch together to fix future clang versions, but that won't alter the ones out in the wild).
[Bug target/29256] [4.8/4.9/5 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 --- Comment #50 from rguenther at suse dot de --- On Tue, 7 Apr 2015, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 > > --- Comment #49 from Jeffrey A. Law --- > Richi, see c#45. Basically the regression is "gone" for the testcase > as-is... > But it's pretty easy to twiddle it slightly and show the regression. It's > also > important to note this is e500 code, so you need to configure your toolchain > appropriately. Please provide a testcase that shows the regression then and instructions how to configure a cross cc1.
[Bug target/65660] [5 Regression] 252.eon regression on bdver2 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65660 --- Comment #18 from Richard Biener --- (In reply to Jan Hubicka from comment #17) > Actually it seems that the tester was used to test the change and it was > applied at Note that frescobaldi (or vangelis) both don't use -march=native and thus are using generic tuning and bare SSE2. The regression seen has nothing to do with $summary.
[Bug jit/65691] New: libgccjit documentation typo in gcc_jit_context_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65691 Bug ID: 65691 Summary: libgccjit documentation typo in gcc_jit_context_one Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: rur...@x-ray.at Copy & Paste problem. gcc_jit_rvalue *gcc_jit_context_one(gcc_jit_context *ctxt, gcc_jit_type *numeric_type) Given a numeric type (integer or floating point), get the rvalue for zero. Essentially this is just a shortcut for: gcc_jit_context_new_rvalue_from_int (ctxt, numeric_type, 1) => Replace "zero" with "one". Seen at https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html
[Bug c++/65690] [5 Regression] typedef alignment lost since r219705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690 --- Comment #7 from Jakub Jelinek --- Created attachment 35250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35250&action=edit gcc5-pr65690.patch So what about this? The first hunk being a fix for the 4.9 -> 5 regression, the second hunk to fix alignof (const T). Or instead of layout_type we could just copy over all of TYPE_SIZE/TYPE_SIZE_UNIT/TYPE_ALIGN/TYPE_USER_ALIGN/TYPE_PRECISION/TYPE_MODE.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
--- Comment #23 from Iain Sandoe ---
something like this
dnl Check if the current compiler supports -mno-dynamic-no-pic.
AC_DEFUN([GCC_CHECK_FLAG_NO_DYNAMIC_NO_PIC], [
AC_CACHE_CHECK([whether the current compiler supports -mno-dynamic-no-pic],
ac_cv_have_mno_dynamic_no_pic, [
mno_dynamic_no_pic_saved_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS -mno-dynamic-no-pic"
AC_TRY_COMPILE([void foo(void) { }],
[], ac_cv_have_mno_dynamic_no_pic=yes,
ac_cv_have_mno_dynamic_no_pic=no)
CFLAGS="$mno_dynamic_no_pic_saved_CFLAGS"])
if test x"$ac_cv_have_mno_dynamic_no_pic" = xyes; then
MDYNAMIC_NO_PIC=-mdynamic-no-pic
MNO_DYNAMIC_NO_PIC=-mno-dynamic-no-pic
else
MDYNAMIC_NO_PIC=
MNO_DYNAMIC_NO_PIC=
fi])
but .. the results need to be available to the mh-darwin
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #26 from drikosev at otenet dot gr --- Hello, It was my impression that small changes can be accepted by FSF without a copyright disclaimer or a copyright assignment on file, according to: https://gcc.gnu.org/contribute.html#legal So, my question is what the next action should be? Regards, Ev. Drikos On Apr 7, 2015, at 9:57 PM, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 > > Jerry DeLisle changed: > > What|Removed |Added > > CC||jvdelisle at gcc dot gnu.org > > --- Comment #25 from Jerry DeLisle --- > Can we and do we commit this patch? I do very much appreciate Evangelos work > here. I just do not understand where we are with copy right assignment > status. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/65692] New: Repeating error for each array entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65692
Bug ID: 65692
Summary: Repeating error for each array entry
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: developm...@faf-ltd.com
#include
typedef struct
{
boolbValid;
charsDateTime [20];
std::atomic bReadyToFlush;
} LogEntries;
typedef struct
{
LogEntries leLogEntries [1] {};
} LogThreads;
Compiled with: gcc t.cpp -c -std=c++11 -Wall -Werror -Wextra
gcc displayes 3! error messages - 3 for each array entry. Even -Werror is
set the -fmax-errors option does not work in this case [may be this is on
purpose because the error is basing on a warning].
The above example is reported here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512 as fixed in 5.0 and is NOT
the subject of this post --> The repeating error message can be reviewed.
[Bug c++/65692] Repeating error for each array entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65692 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.2 Severity|trivial |normal --- Comment #1 from Richard Biener --- Confirmed with GCC 4.9 and 4.8. GCC 5 doesn't emit any error or warning.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 CC||rguenth at gcc dot gnu.org Target Milestone|6.0 |5.0
[Bug rtl-optimization/57032] [4.9/5 Regression]: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57032
Uroš Bizjak changed:
What|Removed |Added
Keywords|ra |
CC||rth at gcc dot gnu.org
--- Comment #8 from Uroš Bizjak ---
This is not a LRA problem.
The problem is in definition of "Q" constraint, AKA "normal_memory_operand":
(define_constraint "Q"
"@internal A normal_memory_operand"
(match_operand 0 "normal_memory_operand"))
;; Return 1 is OP is a memory location that is not a reference
;; (using an AND) to an unaligned location. Take into account
;; what reload will do.
(define_special_predicate "normal_memory_operand"
(ior (match_test "op = resolve_reload_operand (op), 0")
(and (match_code "mem")
(match_test "GET_CODE (XEXP (op, 0)) != AND"
This constraint calls "resolve_reload_operand":
/* Used by aligned_memory_operand and unaligned_memory_operand to
resolve what reload is going to do with OP if it's a register. */
rtx
resolve_reload_operand (rtx op)
{
if (reload_in_progress)
{
rtx tmp = op;
if (GET_CODE (tmp) == SUBREG)
tmp = SUBREG_REG (tmp);
if (REG_P (tmp)
&& REGNO (tmp) >= FIRST_PSEUDO_REGISTER)
{
op = reg_equiv_memory_loc (REGNO (tmp));
if (op == 0)
return 0;
}
}
return op;
}
LRA does not set reload_in_progress, and also doesn't allow to use
reg_equiv_memory_loc. So, the "Q" constraint is effectively dead when LRA is
used.
Using the "m" constraint instead of "Q" in:
(define_insn "*movdi"
[(set (match_operand:DI 0 "nonimmediate_operand"
"=r,r,r,r,r,r,r,r, m, *f,*f, Q, r,*f")
(match_operand:DI 1 "input_operand"
"rJ,K,L,T,s,n,s,m,rJ,*fJ, Q,*f,*f, r"))]
"register_operand (operands[0], DImode)
|| reg_or_0_operand (operands[1], DImode)"
solves this particular failure.
Probably we need to redefine "Q" as a memory constraint. Also
{aligned,unaligned,normal}_memory_operand shouldn't use resolve_reload_operand
anymore. Richard, do you have any insight into this issue?
[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #14 from Richard Biener --- too bad :/ As this doesn't reproduce with a cross it's impossible to debug for me as well (are there instructions somewhere how to "install" x86_64-w64-mingw32 using wine ...? would that even work and reproduce the issue?) I'll leave this for Kai to debug.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
--- Comment #24 from Jakub Jelinek ---
So perhaps for the top level something like:
--- config/mh-darwin2013-09-30 22:13:57.243907474 +0200
+++ config/mh-darwin2015-04-08 10:36:58.100665592 +0200
@@ -1,18 +1,29 @@
# The -mdynamic-no-pic ensures that the compiler executable is built without
# position-independent-code -- the usual default on Darwin. This fix speeds
-# compiles by 3-5%.
-BOOT_CFLAGS += \
+# compiles by 3-5%. Don't add it if the compiler doesn't also support
+# -mno-dynamic-no-pic to undo it.
+DARWIN_MDYNAMIC_NO_PIC := \
`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
- echo -mdynamic-no-pic ;; esac;`
+ $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2>/dev/null \
+ && echo -mdynamic-no-pic ;; esac`
+DARWIN_GCC_MDYNAMIC_NO_PIC := \
+`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
+ $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2>/dev/null \
+ || echo -mdynamic-no-pic ;; esac`
# ld on Darwin versions >= 10.7 defaults to PIE executables. Disable this for
# gcc components, since it is incompatible with our pch implementation.
-BOOT_LDFLAGS += \
-`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
+DARWIN_NO_PIE := `case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;;
esac;`
+
+BOOT_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
+BOOT_LDFLAGS += $(DARWIN_NO_PIE)
# Similarly, for cross-compilation.
-STAGE1_CFLAGS += \
-`case ${host} in i?86-*-darwin* | powerpc-*-darwin*)\
- echo -mdynamic-no-pic ;; esac;`
-STAGE1_LDFLAGS += \
-`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
+STAGE1_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
+STAGE1_LDFLAGS += $(DARWIN_NO_PIE)
+
+# Without -mno-dynamic-no-pic support, add -mdynamic-no-pic just to later
+# stages when we know it is built with gcc.
+STAGE2_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
+STAGE3_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
+STAGE4_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
Thus, add -mdynamic-no-pic for gcc (or fixed clang) bootstrap compiler to
BOOT_CFLAGS and STAGE1_CFLAGS, but only to STAGE{2,3,4}_CFLAGS otherwise?
Then GCC_PICFLAG, being a configure snippet, can surely just use normal
autoconfy way.
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #12 from Markus Trippelsdorf --- As Jonathan wrote, the standard library must conform to the C++ standard. You simply cannot expect fast compile times out of the box when you make heavy use of stl/boost. (Although careful analysis might bring it down considerably. (e.g., bundling most template instantiations into a single compilation unit)) For the attached testcase clang's libc++ is even 30% slower than gcc-4.9 libstdc++.
[Bug c++/65690] [5 Regression] typedef alignment lost since r219705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690 --- Comment #8 from Jan Hubicka --- I also considered just copying over the stuff that layout_decl fills. I guess it is better than calling it and copying back TYPE_SIZE, but this is far from being my area. I think we also want to preserve attribute lists.
[Bug lto/65559] [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #15 from Kai Tietz --- That is my issue too. I try to reproduce this issue with cross and native. But I see some issues only in combination with upstream binutils, and here only in native case, which is the curious part ... I am still on to find the underlying issue ...
[Bug c++/65690] [5 Regression] typedef alignment lost since r219705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65690 --- Comment #9 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #8) > I also considered just copying over the stuff that layout_decl fills. I > guess it is better than calling it and copying back TYPE_SIZE, but this is > far from being my area. Sure, that works for me too. In build_cplus_array_type we know the TYPE_ATTRIBUTES is NULL. > I think we also want to preserve attribute lists. Seems usually ../tree.c builds a distinct type for it instead, rather than variant type. And, I just think it is way too risky to also try to deal with those at this point, perhaps for stage1, but also verify what the C FE does with those, add testcases etc.
[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976 --- Comment #13 from Jonathan Wakely --- I spent several hours trying to find the cause of the slowdown, without success. Currently I am focused on fixing regressions and conformance errors. I will come back to this when I can.
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Honestly, do you really find that > forrtl: severe (66): output statement overflows record, unit -5, > file Internal List-Directed Write is more helpful than > At line 5 of file test.F90 > Fortran runtime error: End of record ? Personally I don't. fortran directs the user to the line and file leading to the run time error, then if the user does not understand what's wrong with 'write(str,*) 100', (s)he must really learn elementary Fortran. > I agree we have no concern over compliance of gfortran here and the error > message is accurate. So this is not a bug, but a request to enhance the error > message in the case of the writing to a string. So, under the principle of > being helpful to users, I will be willing to do this. It will have to wait > until after the next release happens. Several months ago I have browsed the bug list for fortran, libfortran (817 entries today) and I have seen about three dozens entries containing "message" in their summary. I think a fraction of them are more urgent/easy to fix than this one. Now, if you really think this PR is important, nothing prevents you to submit a patch!
[Bug libstdc++/65420] Enumerators in std::regex_constants should be constexpr variables instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65420 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #2 from Jonathan Wakely --- Fixed
[Bug c++/64704] software crashed when using vectorizing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64704 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #10 from Marek Polacek --- Doesn't look like a GCC bug.
[Bug c++/64570] error: non-trivial conversion at assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64570 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #7 from Marek Polacek --- Looks like a dup. *** This bug has been marked as a duplicate of bug 65554 ***
[Bug c++/65554] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554 Marek Polacek changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #13 from Marek Polacek --- *** Bug 64570 has been marked as a duplicate of this bug. ***
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #6 from Alexander Vogt --- Fair enough... I have no experience in coding for GCC. Could you give me a hint where (which file) to start? I would propose a message like > At line 5 of file test.F90 > Fortran runtime error: End of record (number of characters to be written > exceeds the length of the record)
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
--- Comment #25 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #24)
> So perhaps for the top level something like:
yeah looks better than what i was drafting.
> --- config/mh-darwin 2013-09-30 22:13:57.243907474 +0200
> +++ config/mh-darwin 2015-04-08 10:36:58.100665592 +0200
> @@ -1,18 +1,29 @@
> # The -mdynamic-no-pic ensures that the compiler executable is built without
> # position-independent-code -- the usual default on Darwin. This fix speeds
> -# compiles by 3-5%.
> -BOOT_CFLAGS += \
> +# compiles by 3-5%. Don't add it if the compiler doesn't also support
> +# -mno-dynamic-no-pic to undo it.
> +DARWIN_MDYNAMIC_NO_PIC := \
> `case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
> - echo -mdynamic-no-pic ;; esac;`
> + $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2>/dev/null \
> + && echo -mdynamic-no-pic ;; esac`
> +DARWIN_GCC_MDYNAMIC_NO_PIC := \
> +`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
> + $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2>/dev/null \
> + || echo -mdynamic-no-pic ;; esac`
I don't think we need the test here ^ ?
> # ld on Darwin versions >= 10.7 defaults to PIE executables. Disable this
> for
> # gcc components, since it is incompatible with our pch implementation.
> -BOOT_LDFLAGS += \
> -`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
> +DARWIN_NO_PIE := `case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;;
> esac;`
> +
> +BOOT_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
> +BOOT_LDFLAGS += $(DARWIN_NO_PIE)
>
> # Similarly, for cross-compilation.
> -STAGE1_CFLAGS += \
> -`case ${host} in i?86-*-darwin* | powerpc-*-darwin*)\
> - echo -mdynamic-no-pic ;; esac;`
> -STAGE1_LDFLAGS += \
> -`case ${host} in *-*-darwin[1][1-9]*) echo -Wl,-no_pie ;; esac;`
> +STAGE1_CFLAGS += $(DARWIN_MDYNAMIC_NO_PIC)
> +STAGE1_LDFLAGS += $(DARWIN_NO_PIE)
> +
> +# Without -mno-dynamic-no-pic support, add -mdynamic-no-pic just to later
> +# stages when we know it is built with gcc.
> +STAGE2_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
> +STAGE3_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
> +STAGE4_CFLAGS += $(DARWIN_GCC_MDYNAMIC_NO_PIC)
>
> Thus, add -mdynamic-no-pic for gcc (or fixed clang) bootstrap compiler to
> BOOT_CFLAGS and STAGE1_CFLAGS, but only to STAGE{2,3,4}_CFLAGS otherwise?
>
> Then GCC_PICFLAG, being a configure snippet, can surely just use normal
> autoconfy way.
well, GCC_PICFLAG is not really very autoconf-y at present, just a bunch of
tests of triple. Will try to find some cycles later on.
[Bug c++/65422] [C++11] Rejected valid double expansion packs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65422 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/58950] Missing "statement has no effect"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #21 from Marek Polacek --- Should this be P1?
[Bug c++/65693] New: [5.0 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Bug ID: 65693 Summary: [5.0 Regression] ICE in assign_by_spills, at lra-assigns.c:1419 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: costamagnagianfranco at yahoo dot it Created attachment 35251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35251&action=edit snip of the build log I can't build anymore virtualbox with gcc 5-20150404-1 in experimental (medium) (debian experimental) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5-20150404-1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --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-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-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=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Debian 5-20150404-1) attaching the build log, the build log2 with -Wall -Wextra -fno-strict-aliasing and the preprocessed source
[Bug c++/65693] [5.0 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 --- Comment #1 from Gianfranco --- Created attachment 35252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35252&action=edit log with -Wall -Wextra -fno-strict-aliasing -fwrapv
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351
--- Comment #26 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #25)
> > +DARWIN_GCC_MDYNAMIC_NO_PIC := \
> > +`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
> > + $(CC) -S -xc /dev/null -o /dev/null -mno-dynamic-no-pic 2>/dev/null \
> > + || echo -mdynamic-no-pic ;; esac`
>
> I don't think we need the test here ^ ?
I wanted to avoid adding -mdynamic-no-pic twice for the case when bootstrap
compiler is gcc (once in BOOT_CFLAGS, once in STAGE{2,3,4}_CFLAGS.
Sure, the test could be
DARWIN_GCC_MDYNAMIC_NO_PIC := \
`case ${host} in i?86-*-darwin* | powerpc-*-darwin*) \
test -z "$(DARWIN_MDYNAMIC_NO_PIC)" && echo -mdynamic-no-pic ;; esac`
instead or similar.
> > Thus, add -mdynamic-no-pic for gcc (or fixed clang) bootstrap compiler to
> > BOOT_CFLAGS and STAGE1_CFLAGS, but only to STAGE{2,3,4}_CFLAGS otherwise?
> >
> > Then GCC_PICFLAG, being a configure snippet, can surely just use normal
> > autoconfy way.
>
> well, GCC_PICFLAG is not really very autoconf-y at present, just a bunch of
> tests of triple. Will try to find some cycles later on.
What I meant is that it is processed by autoconf.
Anyway, perhaps an alternative would be to just add -mdynamic-no-pic if
-mdynamic-no-pic is in CFLAGS.
Like
$1=-fno-common
case "${CFLAGS}" in *-mdynamic-no-pic*) \
$1='-fno-common -mno-dynamic no-pic';; esac
in config/picflag.m4 ?
Needs verification that -mdynamic-no-pic is really in CFLAGS when it should and
not when it should not be.
[Bug c++/65693] [5.0 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Gianfranco changed: What|Removed |Added CC||costamagnagianfranco@yahoo. ||it --- Comment #2 from Gianfranco --- Created attachment 35253 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35253&action=edit preprocessed source
[Bug target/65644] Assembler errors on Solaris 10 x86-64: `(%eXX)' is not a valid 64 bit base/index expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65644 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Daniel Richard G. --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> >> Looking closer, you are *not* using the Solaris assembler (/usr/ccs/bin/as): > > Good call, Rainer. GCC is in fact using /usr/sfw/bin/gas, which identifies as > > $ /usr/sfw/bin/gas --version > GNU assembler 2.15 > Copyright 2002 Free Software Foundation, Inc. ... which is pretty ancient by now. No idea when I last tried to bootstrap with that version, although install.texi claims that it does work ;-( > I am bootstrapping again with explicit use of the Solaris assembler to confirm > that everything works that way, but am running into stage2 != stage3 errors > and > am currently sorting those out. Ok, let me know how things work out and if I can help to get you going. Rainer
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #7 from Dominique d'Humieres --- > Fair enough... I have no experience in coding for GCC. Could you give me > a hint where (which file) to start? The content of the message is set by 'translate_error (int code)' (line 412 of libgfortran/runtime/error.c). > I would propose a message like > > > At line 5 of file test.F90 > > Fortran runtime error: End of record (number of characters to be written > > exceeds the length of the record) I did not looked further to the code (you can grep for LIBERROR_EOR libgfortran/runtime/* libgfortran/io/*, and gcc/fortran/* to find where it is set) but I am not sure that "End of record" cannot be emitted when reading or for unformatted files. If so your message will be misleading.
[Bug rtl-optimization/65693] [5.0 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-08
CC||trippels at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Component|c++ |rtl-optimization
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #3 from Markus Trippelsdorf ---
markus@x4 tmp % cat t.ii
int a;
unsigned b;
void
VBoxNsxpXPTC_InvokeByIndex ()
{
unsigned long *c = (unsigned long *) __builtin_alloca (b);
a = *c;
register int d asm("rdx")
= ((int (*) (int, int, int, int, int, int)) 0)(0, 0, d, 0, 0, 0);
}
markus@x4 tmp % g++ -c t.ii
t.ii: In function ‘void VBoxNsxpXPTC_InvokeByIndex()’:
t.ii:10:1: error: unable to find a register to spill
}
^
t.ii:10:1: error: this is the insn:
(insn 10 37 11 2 (parallel [
(set (reg:DI 97)
(udiv:DI (reg:DI 95)
(reg:DI 107)))
(set (reg:DI 108 [98])
(umod:DI (reg:DI 95)
(reg:DI 107)))
(clobber (reg:CC 17 flags))
]) t.ii:6 352 {*udivmoddi4}
(expr_list:REG_UNUSED (reg:DI 108 [98])
(expr_list:REG_DEAD (reg:DI 107)
(expr_list:REG_DEAD (reg:DI 95)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
t.ii:10: confused by earlier errors, bailing out
[Bug c/65653] cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- Confirmed.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Priority|P1 |P2
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #3 from Jakub Jelinek --- I don't see why this should compile with -O0 actually, it assumes optimization being performed at -O0.
[Bug rtl-optimization/65693] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Summary|[5.0 Regression] ICE in |ICE in assign_by_spills, at |assign_by_spills, at|lra-assigns.c:1419 |lra-assigns.c:1419 | --- Comment #4 from Marek Polacek --- I don't think this is a 5 Regression, even 4.6 ICEs for me.
[Bug rtl-optimization/65693] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Marek Polacek changed: What|Removed |Added Severity|major |normal
[Bug target/65694] New: [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 Bug ID: 65694 Summary: [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 35254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35254&action=edit preprocessed source I'm aware of PR65321, but this is with r221867 on arm-linux-gnueabihf. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5-20150404-0ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-libitm --disable-libquadmath --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-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=yes --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Ubuntu 5-20150404-0ubuntu11) $ g++ -c -g -O2 -std=c++98 dnaclust.ii dnaclust.cpp: In function 'Index twoMeans(Index, Index)': dnaclust.cpp:753:1: internal compiler error: in decompose, at rtl.h:2007 } // twoMeans ^ 0x65c651 wi::int_traits >::decompose(long long*, unsigned int, std::pair const&) ../../src/gcc/rtl.h:2005 0x65c651 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&, unsigned int) ../../src/gcc/wide-int.h:957 0x65c651 generic_wide_int >::generic_wide_int >(std::pair const&, unsigned int) ../../src/gcc/wide-int.h:733 0x65c651 bool wi::eq_p, std::pair >(std::pair const&, std::pair const&) ../../src/gcc/wide-int.h:1715 0x65c651 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../src/gcc/simplify-rtx.c:4919 0x65c6b3 simplify_relational_operation(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../src/gcc/simplify-rtx.c:4413 0x65cced simplify_gen_relational(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../src/gcc/simplify-rtx.c:441 0x66054f simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def* (*)(rtx_def*, rtx_def const*, void*), void*) ../../src/gcc/simplify-rtx.c:501 0x6604cb simplify_replace_fn_rtx(rtx_def*, rtx_def const*, rtx_def* (*)(rtx_def*, rtx_def const*, void*), void*) ../../src/gcc/simplify-rtx.c:507 0x9f43d9 bypass_block ../../src/gcc/cprop.c:1608 0x9f43d9 bypass_conditional_jumps ../../src/gcc/cprop.c:1726 0x9f43d9 one_cprop_pass ../../src/gcc/cprop.c:1887 0x9f43d9 execute_rtl_cprop ../../src/gcc/cprop.c:1931 0x9f43d9 execute ../../src/gcc/cprop.c:1969 Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 --- Comment #1 from Matthias Klose --- seen when building the dnaclust package, also seen in the qtbase-opensource-src package. currently reducing
[Bug rtl-optimization/65693] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693
--- Comment #5 from Markus Trippelsdorf ---
Well, this testcase only ICEs with gcc-5:
markus@x4 tmp % < foo.ii
int a, b;
unsigned c;
static void
invoke_copy_to_stack (unsigned long *p1, int, int)
{
for (; b;)
if (a)
*p1 = 0;
}
void
VBoxNsxpXPTC_InvokeByIndex ()
{
unsigned long *d = (unsigned long *) __builtin_alloca (c);
invoke_copy_to_stack (d, 0, 0);
register int e asm("rdx")
= ((int (*) (int, int, int, int, int, int)) 0)(0, 0, e, 0, 0, 0);
}
markus@x4 tmp % g++ -O -c foo.ii
foo.ii: In function ‘void VBoxNsxpXPTC_InvokeByIndex()’:
foo.ii:18:1: error: unable to find a register to spill
}
^
foo.ii:18:1: error: this is the insn:
(insn 9 8 10 2 (parallel [
(set (reg:DI 98)
(udiv:DI (reg:DI 96)
(reg:DI 106)))
(set (reg:DI 109 [99])
(umod:DI (reg:DI 96)
(reg:DI 106)))
(clobber (reg:CC 17 flags))
]) foo.ii:14 352 {*udivmoddi4}
(expr_list:REG_UNUSED (reg:DI 109 [99])
(expr_list:REG_DEAD (reg:DI 106)
(expr_list:REG_DEAD (reg:DI 96)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
foo.ii:18: confused by earlier errors, bailing out
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Richard Biener changed: What|Removed |Added Keywords||ra Priority|P3 |P2 Known to work||4.3.4, 4.5.4 Target Milestone|5.0 |4.8.5 Summary|ICE in assign_by_spills, at |[4.8/4.9/5 Regression] ICE |lra-assigns.c:1419 |in assign_by_spills, at ||lra-assigns.c:1419 Known to fail||4.6.4, 5.0 --- Comment #6 from Richard Biener --- 4.3 works for me so does 4.5.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693
--- Comment #7 from Uroš Bizjak ---
gcc-4.9 combines udivmoddi4 to :
(insn 30 5 8 2 (set (reg:DI 103)
(const_int 16 [0x10])) pr65693.ii:6 -1
(nil))
[...]
(insn 9 8 10 2 (parallel [
(set (reg:DI 94)
(udiv:DI (reg:DI 92)
(reg:DI 103)))
(set (reg:DI 95)
(umod:DI (reg:DI 92)
(reg:DI 103)))
(clobber (reg:CC 17 flags))
]) pr65693.ii:6 348 {*udivmoddi4}
(expr_list:REG_DEAD (reg:DI 103)
(expr_list:REG_DEAD (reg:DI 92)
(expr_list:REG_UNUSED (reg:DI 95)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
Trying 30 -> 9:
...
Successfully matched this instruction:
(set (reg:DI 94)
(lshiftrt:DI (reg:DI 92)
(const_int 4 [0x4])))
For some reason gcc-5 doesn't do this conversion anymore.
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684
--- Comment #8 from Alexander Vogt ---
I think this happens in io/transfer.c:
413 void *
414 read_block_form (st_parameter_dt *dtp, int * nbytes)
415 {
...
419 if (!is_stream_io (dtp))
420 {
421 if (dtp->u.p.current_unit->bytes_left < (gfc_offset) *nbytes)
422 {
...
430 if (unlikely (dtp->u.p.current_unit->pad_status ==
PAD_NO)
431 && !is_internal_unit (dtp))
432 {
433 /* Not enough data left. */
434 generate_error (&dtp->common, LIBERROR_EOR, NULL);
435 return NULL;
436 }
437 }
...
I'm a little confused, though... Aren't we writing to an internal unit here?
This case seems not to be covered.
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 --- Comment #8 from Gianfranco --- Nope, I can build on debian (I'm the maintainer BTW) with 4.9 successfully. https://buildd.debian.org/status/fetch.php?pkg=virtualbox&arch=amd64&ver=4.3.26-dfsg-1&stamp=1426696248 for now I forced gcc-4.9 as a gcc version and the build completes with no problems. This is why I think this is a gcc-5.0 specific regression. Also gcc 4.8 and 4.7 are fine (I maintain a backport on ubuntu too, and they all build correctly). This is a snapshot of virtualbox 5.0.0_BETA1, but the ICE occurs with virtualbox 4.3.26 and older releases (but *only* with gcc-5)
[Bug fortran/65684] Wrong error message when writing to a string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65684 --- Comment #9 from Alexander Vogt --- Then, it would be as simple as passing generate_error the message instead of NULL.
[Bug c++/65695] New: [4.9/5 Regression] calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695
Bug ID: 65695
Summary: [4.9/5 Regression] calling constexpr constructor with
pointer-to-member is not a constant expression
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
From https://gcc.gnu.org/ml/gcc-help/2015-04/msg00034.html
template
struct Bar
{
using MemberFuncT = int (T::*)();
MemberFuncT h_;
constexpr Bar(MemberFuncT h) : h_{h}
{
}
};
struct Foo
{
int test()
{
return -1;
}
// this causes the brace-enclosed initializer error message:
static constexpr Bar bar = Bar(&Foo::test);
// but this line does not:
// static constexpr Bar bar = Bar(nullptr);
// this line also causes the error message, unless you remove the
// explict constructor in Bar.
// static constexpr Bar bar = {&Foo::test};
};
constexpr Bar Foo::bar;
// the line below does not cause any problems, either:
// static constexpr Bar bar = Bar(&Foo::test);
int main(void)
{
Foo f;
return (f.*(Foo::bar.h_))();
}
c.cc:20:56: error: ‘Bar{&Foo::test}’ is not a constant expression
static constexpr Bar bar = Bar(&Foo::test);
^
Clang and EDG accept the code.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Adding a hack where stmt.c (parse_input_constraint) so that it handles
case 'S':
the same as say case 'i':
fixes the test, so it is all about whether the expander and middle-end thinks
that "S" constraint allows_reg || allows_mem (right now both, ideally none).
So, to fix this, perhaps hack up genpreds.c, so that it generates another
function or two which returns true if the constraint can be easily proved not
to allow reg (or not to allow mem).
Say "S" is:
(and (match_code "const,symbol_ref,label_ref")
(match_test "aarch64_symbolic_address_p (op)")))
and so genpreds can conservatively assume match_test can return anything, but
match_code clearly doesn't satisfy a reg/subreg nor mem (requires something
other), so process_{input,output}_constraint should be able to safely set both
of those to false.
[Bug c++/65695] [4.9/5 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-08
Summary|[4.9/5 Regression] calling |[4.9/5 Regression] NSDMI
|constexpr constructor with |calling constexpr
|pointer-to-member is not a |constructor with
|constant expression |pointer-to-member is not a
||constant expression
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Reduced:
struct Foo;
struct Bar
{
using MemberT = int Foo::*;
MemberT h_;
constexpr Bar(MemberT h) : h_{h}
{
}
};
struct Foo
{
int test = 0;
static constexpr Bar bar {&Foo::test};
};
constexpr Bar Foo::bar;
[Bug c++/65695] [4.9/5 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695 Jonathan Wakely changed: What|Removed |Added Known to work||4.8.3 --- Comment #2 from Jonathan Wakely --- 4.8 gives an ICE on my reduced testcase in comment 1, but compiles the original testcase in comment 0 OK.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed with r221914. A gcc from 27Mar works though for me.
[Bug target/65671] Assembly failure (invalid register operand) with -O3 -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65671 Kirill Yukhin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-08 CC||kyukhin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/65695] [4.9/5 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695
Jonathan Wakely changed:
What|Removed |Added
Known to fail||4.9.2, 5.0
--- Comment #3 from Jonathan Wakely ---
4.8 ICEs when using a pointer-to-data-member but not with
pointer-to-member-function, so here is a slightly less reduced version that
compiles with 4.8:
struct Foo;
struct Bar
{
using MemberFuncT = int (Foo::*)();
MemberFuncT h_;
constexpr Bar(MemberFuncT h) : h_{h}
{
}
};
struct Foo
{
int test()
{
return -1;
}
static constexpr Bar bar {&Foo::test};
};
constexpr Bar Foo::bar;
With 4.9.2:
c.cc:20:41: error: ‘const Bar{&Foo::test}’ is not a constant expression
static constexpr Bar bar {&Foo::test};
^
With 5.0:
c.cc:20:41: error: ‘Bar{&Foo::test}’ is not a constant expression
static constexpr Bar bar {&Foo::test};
^
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Markus Trippelsdorf changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf --- Started with r218248.
[Bug c++/65695] [4.9/5 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 Iain Sandoe changed: What|Removed |Added Attachment #35249|0 |1 is obsolete|| --- Comment #27 from Iain Sandoe --- Created attachment 35255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35255&action=edit patch against 221916 Jakub's suggested approach to picflag.m4 seems reasonable. AFAIK, the only place that GCC adds the flag is in mh-darwin which is now checked. If someone building GCC passes "-mdynamic-no-pic" on the command line for (say) an i686-darwin12 native cross with clang as the compiler - then it will, presumably, fail but that's something easy for the person doing the build to rectify (and someone building native crosses is probably not a novice anyway) checking on powerpc-darwin9 (GCC 5 bootstrap) x86_64-darwin12 (gcc 5 bootstrap) x86_64-darwin13 (clang XCode6 bootstrap) i686-darwin10 (gcc-4.2.1 bootstrap).
[Bug ada/65696] New: ASAN reports global-buffer-overrun for local tagged types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65696 Bug ID: 65696 Summary: ASAN reports global-buffer-overrun for local tagged types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: demoonlit at panathenaia dot halfmoon.jp package pkg_a is type Root is tagged null record; end pkg_a; with pkg_a; procedure main is type Derived is new pkg_a.Root with null record; begin null; end main; % gnatmake main.adb -cargs -fsanitize=address -largs -lasan.1 gcc -c -fsanitize=address main.adb gcc -c -fsanitize=address pkg_a.ads gnatbind -x main.ali gnatlink main.ali -lasan.1 % ./main = ==78928==ERROR: AddressSanitizer: unknown-crash on address 0x0001000174c8 at pc 0x1303d bp 0x7fff5fbfed10 sp 0x7fff5fbfed08 READ of size 120 at 0x0001000174c8 thread T0 #0 0x1303c (main+0x1303c) #1 0x123d4 (main+0x123d4) #2 0x119d7 (main+0x119d7) #3 0x0 (main+0x0) 0x000100017510 is located 0 bytes to the right of global variable 'pkg_a__rootR38s___UNC' from 'pkg_a.ads' (0x1000174c0) of size 80 SUMMARY: AddressSanitizer: unknown-crash ??:0 ?? Shadow bytes around the buggy address: 0x100020002e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020002e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020002e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020002e70: 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 0x100020002e80: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 =>0x100020002e90: 00 00 f9 f9 f9 f9 f9 f9 00[00]00 00 00 00 00 00 0x100020002ea0: 00 00 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 0x100020002eb0: 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x100020002ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020002ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100020002ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Contiguous container OOB:fc ASan internal: fe ==78928==ABORTING Perhaps, a cause is the implicit code for making a child type's dispatching table. The size of copying of a parent type's predefined primitives to a child's is Max_Predef_Prims (15), but the real number of a parent type's predefined primitives seems 9.
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 --- Comment #10 from Gianfranco --- Hi @Markus, I'm *really* impressed about your efficiency. I reported the progresses on the vbox official mail list, thanks!
[Bug target/65697] New: __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
Bug ID: 65697
Summary: __atomic memory barriers not strong enough for __sync
builtins
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthew.wahab at arm dot com
The __sync builtins are implemented by expanding them to the equivalent
__atomic builtins, using MEMMODEL_SEQ_CST for those that are full barriers.
This is too weak since __atomic operations with MEMMODEL_SEQ_CST still allow
some data references to move across the operation (see
https://gcc.gnu.org/ml/gcc/2014-02/msg00058.html) while a __sync full barrier
should block all movement
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins).
This is problem for Aarch64 where data references after the barrier could be
speculated ahead of it.
For example, compiling with aarch64-none-linux-gnu at -O2,
-
int foo = 0;
int bar = 0;
int T1(void)
{
int x = __sync_fetch_and_add(&foo, 1);
return bar;
}
produces
T1:
adrpx0, .LANCHOR0
addx0, x0, :lo12:.LANCHOR0
.L2:
ldaxrw1, [x0] ; load-acquire (__sync_fetch_and_add)
addw1, w1, 1
stlxrw2, w1, [x0] ; store-release (__sync_fetch_and_add)
cbnzw2, .L2
ldrw0, [x0, 4]; load (return bar)
ret
With this code, the load can be executed ahead of the store-release which ends
the __sync_fetch_and_add. A correct implementation should emit a dmb
instruction after the cbnz.
GCC info:
gcc version 5.0.0 20150407 (experimental)
Target: aarch64-none-linux-gnu
[Bug rtl-optimization/65698] New: Non-optimal code for simple compare function for x86 32-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65698 Bug ID: 65698 Summary: Non-optimal code for simple compare function for x86 32-bit target Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com For attached test-case in inner loop we can see the following deficiencies: 1. 2 redundant fills and one spill in comparison part of loop - I assume that only 4 registers needs to keep the base of 'v1' and 'v2' and inexes 'i1' and 'i2', one more register is required to keep 'c1' or 's1'. 2. @ redundant lea instructions to perform multiplication on 2. Here is optimal binaries produced by icc compiler( with deleted increment part): 2e:8a 04 3b mov(%ebx,%edi,1),%al 31:3a 04 3e cmp(%esi,%edi,1),%al 34:75 53jne89 36:0f b7 04 5a movzwl (%edx,%ebx,2),%eax 3a:0f b7 2c 72 movzwl (%edx,%esi,2),%ebp 3e:3b c5cmp%ebp,%eax 40:75 47jne89 42:8a 44 3b 01 mov0x1(%ebx,%edi,1),%al 46:3a 44 3e 01 cmp0x1(%esi,%edi,1),%al 4a:75 3djne89 4c:0f b7 44 5a 02 movzwl 0x2(%edx,%ebx,2),%eax 51:0f b7 6c 72 02 movzwl 0x2(%edx,%esi,2),%ebp 56:3b c5cmp%ebp,%eax 58:75 2fjne89 5a:83 c3 02 add$0x2,%ebx ... 7b:7f b1jg 2e Note aalso that if we commented out 2 lines if (i1 > n) i1 -= n; if (i2 > n) i2 -= n; we get optimal code with gcc compiler.
[Bug rtl-optimization/65698] Non-optimal code for simple compare function for x86 32-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65698 --- Comment #1 from Yuri Rumyantsev --- Created attachment 35256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35256&action=edit test-case to reproduce It needs to be compiled with "-O3 -m32" options.
[Bug rtl-optimization/65698] Non-optimal code for simple compare function for x86 32-bit target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65698 --- Comment #2 from Yuri Rumyantsev --- Created attachment 35257 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35257&action=edit assembly for test.c Additional option '-march=slm' was used for it but it is non-essential.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #1 from Matthew Wahab --- I'm working on this but it isn't obvious how to fix it. The strong barriers aren't needed for the __atomics and will have an effect on performance so simply strengthening the MEMMODEL_SEQ_CST implementation in the backend isn't a good solution. It looks like the __sync builtins are always expanded out to the __atomics. This is done in the middle-end and there doesn't seem to be any way for a backend to intervene. I'm currently preparing a patch that introduces a new MEMMODEL tag to coretypes.h/memmodel to specify the __sync style full barriers. This can then be used in the __sync to __atomic expansions and, because the MEMMODEL argument to the __atomics is eventually passed to the backends, this is enough to enable backends to know when the stronger barrier is needed. The drawback with this is that a number of backends need to be updated to recognize the new MEMMODEL tag. For each, the minimum change is to make the new MEMMODEL tag a synonym for MEMMODEL_SEQ_CST. The backends that would need updating are arm, aarch64, i386, ia64, pa, rs6000, s390, sparc. (A subsequent patch would make the aarch64 backend generate the stronger barrier for the new MEMMODEL tag.) If there's a better way of doing it, let me know.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #5 from Jakub Jelinek --- Created attachment 35258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35258&action=edit gcc5-pr65689.patch Untested fix. For aarch64, there are lots of constraints determined by this patch to not allow either reg or mem: S, Y, Ush, Uss, Usn, Usd, Usf, Ui3, Up3, Ufc, Dn, Dh, Dq, Dl, Dr, Dz, Dd and then V, <, > determined as only *allows_mem. But '<' and '>' are already handled in process_*_constraint earlier, so it is just V. The rest are determined (conservatively) to allow either. On x86_64, G is determined to allow neither, V, <, > similarly to aarch64 to only *allows_mem, the rest maybe both.
[Bug target/65351] [5 Regression] libiberty's pic version contains non-pic code on m32 darwin; causes bootstrap fail building libcc1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 --- Comment #28 from Dominique d'Humieres --- I have successfully bootstrapped r221917 on x86_64-apple-darwin14 with the patch in comment 27.
[Bug web/65699] New: online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 Bug ID: 65699 Summary: online docs lacks version that it documents Product: gcc Version: unknown URL: https://gcc.gnu.org/onlinedocs/gccint/ Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de CC: goswin-v-b at web dot de The online docs do not mention what version of the compiler they document. When something doesn't work as documented this makes it hard to see if that something is no longer valid in the local version or describes something not yet present in the local version.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 --- Comment #3 from Matthias Klose --- Created attachment 35259 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35259&action=edit reduced file
[Bug web/65700] New: Documentation of internals is inconsistent in itself and diverges from reality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65700 Bug ID: 65700 Summary: Documentation of internals is inconsistent in itself and diverges from reality Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: goswin-v-b at web dot de https://gcc.gnu.org/onlinedocs/gccint/Collect2.html says when collect2 is used it generates a temporary file listing the constructors and destructors and that the actual calls to the constructors are done from __main(). https://gcc.gnu.org/onlinedocs/gccint/Initialization.html now tells a quite different storry, including the .ctros/.dtors that are actually used on x86/x86_64. It still mentions __main() in connection with collect2 being used. On ARM what actually happens is that there is a .init_array section and the libc startup files are supposed to process that itself. Despite collect2 being used there is no __main() function that gets called for this. There is no .init section but still gcc does NOT insert a call to __main() when compiling main() like the docs say it would. Further the .init_array does not hold the constructors in reverse order. It actually holds a automatic constructor generated by gcc first and then all the functions manually declared as constructors. Care must be taken by the linker script to sort them by priority or they are random. So in the case of ARM the cinstructors need to be called in order, not in reverse order. Overall I have to say the documentation confuses things more than it actually helps. I don't know if that is because it hasn't been updated in a long time or never was complete or internally consistent in the first place. But it sure could use some love. If they can't be improved please at least add a comment where they are outdated or when they where last synced against the source so it becomes clear to the reader where they are lacking.
[Bug ipa/65701] New: r221530 makes 187.facerec drop with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65701 Bug ID: 65701 Summary: r221530 makes 187.facerec drop with -Ofast -flto Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: lto, missed-optimization Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: hubicka at gcc dot gnu.org +2015-03-20 Jan Hubicka + + * ipa-inline.c (can_inline_edge_p): Short circuit if inline_failed + already is final. + (ipa_inline): Recompute inline_failed codes. + * cif-code.def (FUNCTION_NOT_OPTIMIZED, REDEFINED_EXTERN_INLINE, + USES_COMDAT_LOCAL, ATTRIBUTE_MISMATCH, UNREACHABLE): Declare as + CIF_FINAL_ERROR. makes 187.facerec drop in http://gcc.opensuse.org/SPEC/CFP/sb-megrez-head-64/recent.html, but only for LTO. revision range is 221529 (good) 221531 (bad).
[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65089 --- Comment #7 from Jakub Jelinek --- Sounds like either libgfortran bug, or fortran FE bug. What asan_finish_file sees for .LC3 is: unit size align 8 symtab -244602288 alias set -1 canonical type 0x715083f0 precision 8 min max pointer_to_this > string-flag SI size unit size align 8 symtab 0 alias set -1 canonical type 0x716c7d20 domain SI size unit size align 32 symtab 0 alias set -1 canonical type 0x716c7c78 precision 32 min max >> constant asm_written "(z0)"> i.e. a 4 bytes long string literal, which is not NUL terminated. If you compile without -fsanitize=address, you can see that (z0) is directly followed by unrelated strings: 696f5f72 65616c5f 626f7a5f 352e6639 io_real_boz_5.f9 0010 3000287a 30295800 0.(z0)X. 0020 0201 9b01 0030 0100 0100 0040 1f00 803f...? so calling strlen on this is obviously undefined behavior. Doesn't the FE pass format_len which tells you how long the string is? It really doesn't seem to be NUL terminated unless by accident. Isn't: character(len=32) :: str1 character(len=4) :: str2 str2 = '(z0)' x = 1.0_16 + 2.0_16**(-105) write (str1,str2) 'X' end equivalent to that (again, with no NUL termination)?
[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65701 --- Comment #1 from Richard Biener --- -Ofast -march=native, that is. (which may be the key to the issue?)
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #6 from alalaw01 at gcc dot gnu.org --- Whilst I think this probably would fix the problem - surely this will change the meaning of loads of constraints, on loads of platforms? I will of course defer to the release manager(s) (!), but IMHO this feels rather risky to do at this late stage, i.e. potentially "the cure is worse than the disease"...? Secondly, do I understand correctly, that the constraint-parsing mechanism will only come into play for plain ol' define_constraints, whereeas define_register_constraint / define_memory_constraint would provide/override with their own values? Does this still leave us with consistent meaning for all three kinds of define...constraint?
[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65701 --- Comment #2 from Richard Biener --- build log /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o FaceRecTypes.o -Ofast -march=native -flto=8 -fno-fat-lto-objects FaceRecTypes.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o parameterRoutines.o -Ofast -march=native -flto=8 -fno-fat-lto-objects parameterRoutines.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o cfftb.o -Ofast -march=native -flto=8 -fno-fat-lto-objects cfftb.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o cfftf.o -Ofast -march=native -flto=8 -fno-fat-lto-objects cfftf.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o cffti.o -Ofast -march=native -flto=8 -fno-fat-lto-objects cffti.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o fft2d.o -Ofast -march=native -flto=8 -fno-fat-lto-objects fft2d.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o gaborRoutines.o -Ofast -march=native -flto=8 -fno-fat-lto-objects gaborRoutines.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o imageRoutines.o -Ofast -march=native -flto=8 -fno-fat-lto-objects imageRoutines.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o graphRoutines.o -Ofast -march=native -flto=8 -fno-fat-lto-objects graphRoutines.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -c -o FaceRec.o -Ofast -march=native -flto=8 -fno-fat-lto-objects FaceRec.f90 /gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/bin/gfortran -Wl,-rpath=/gcc/spec/sb-megrez-head-64/x86_64/install-201503200620/lib64 -Ofast -march=native -flto=8 -fno-fat-lto-objects FaceRecTypes.o parameterRoutines.o cfftb.o cfftf.o cffti.o fft2d.o gaborRoutines.o imageRoutines.o graphRoutines.o FaceRec.o -o facerec
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #7 from Jakub Jelinek --- (In reply to alalaw01 from comment #6) > Whilst I think this probably would fix the problem - surely this will change > the meaning of loads of constraints, on loads of platforms? I will of course > defer to the release manager(s) (!), but IMHO this feels rather risky to do > at this late stage, i.e. potentially "the cure is worse than the disease"...? The patch doesn't change meaning of any constraints, just attempts to provide more precise answers on what constraints allow registers and what allow memory. > Secondly, do I understand correctly, that the constraint-parsing mechanism > will only come into play for plain ol' define_constraints, whereeas > define_register_constraint / define_memory_constraint would provide/override > with their own values? Does this still leave us with consistent meaning for > all three kinds of define...constraint? The new generated function is only used for define_constraint, sure, define_register_constraint registered constraints are always handled as *allows_reg = true;, define_memory_constraint are always handled as *allows_mem = true;, define_address_constraint is handled also like *allows_reg = true;, all 3 already before and still after the patch unchanged. Similarly most of the hardcoded well known architecture independent constraints. The patch is only about the case where it previously just made a very conservative last bet, with the patch it still handles a couple of obvious constraints right and falls back just for the rest where even genpreds.c doesn't safely know.
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 --- Comment #11 from Segher Boessenkool --- I see GCC not trying to throw away the useless arm of the parallel, just as comment 7 mentions. I wonder why that is, investigating. This isn't the root cause; it is just exposing a problem in the RA :-(
[Bug fortran/64118] Strange warning about unused function/subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64118 --- Comment #2 from Angelo Graziosi --- In my original test case, if I move the definition of function f(x) before the subroutine foo(), does not produce warnings. In other words: real(dp) function f(x) result(y) real(dp), intent(in) :: x y = sin(x) end function f subroutine foo() use integrals, only: simpson print *, simpson(f, 0.0_dp, 2.0_dp) print *, simpson(f, 0.0_dp, 4.0_dp) end subroutine foo DOES NOT produce warnings. Instead: subroutine foo() use integrals, only: simpson print *, simpson(f, 0.0_dp, 2.0_dp) print *, simpson(f, 0.0_dp, 4.0_dp) end subroutine foo real(dp) function f(x) result(y) real(dp), intent(in) :: x y = sin(x) end function f DORES PRODUCE warnings! Ciao, Angelo.
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- Well, the RA issue is hard to deal with, there is a local register var that uses a register some instruction needs while the local register is live. Anyway, this alloca/VLA division issue is what I meant to fix with PR65220, but here unfortunately the RTL cprop isn't performed because the function has a single basic block and for some reason RTL cprop doesn't perform even the local cprop subpass then. And, at combine time, combiner attempts to simplify the insn, so the *udivmod4_pow2 pattern no longer matches. One possibility to fix this would be to add *udivmod4_pow2_1 pattern that would just have the lshiftrt and and instructions in PARALLEL until reload, then split them.
[Bug go/63731] Fallback to netgo does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63731 --- Comment #37 from boger at us dot ibm.com --- Created attachment 35260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35260&action=edit libgo/go/go/build/doc.go documentation update Adding comments about the use of the netgo tag and the equivalent method for use with gccgo.
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 --- Comment #1 from Andrew Pinski --- That link is always the trunk.
[Bug rtl-optimization/65693] [4.8/4.9/5 Regression] ICE in assign_by_spills, at lra-assigns.c:1419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65693 --- Comment #13 from Jakub Jelinek --- Created attachment 35261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35261&action=edit gcc5-pr65693.patch Untested fix.
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 --- Comment #2 from Jonathan Wakely --- (In reply to Goswin von Brederlow from comment #0) > The online docs do not mention what version of the compiler they document. The latest one. > When something doesn't work as documented this makes it hard to see if that > something is no longer valid in the local version Impossible, since the online ones are for the latest sources. > or describes something not > yet present in the local version. Adding a version number to the onlinedocs/gccint pages won't change that. The internals docs for the local version are in the local sources, so use them not the online ones. I don't see anything that can be usefully done here.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- This looks similar to PR 64600. The problem seems to be arm_canonicalize_comparison that canonicalizes a comparison with 2147483647 (0x7fff) into a comparison with that +1, that is 0x8000 without properly sign-extending it into 0x8000 (which would make it -2147483648). I have a fix, but it needs more testing
[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60333 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Created attachment 35262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35262&action=edit Fix make_signed / make_unsigned for enumeration types This patch handles enumeration types larger than long and preserves cv-qualifiers (which is currently not done). I'll check this in after the 5.1 release.
[Bug libstdc++/59969] std::pair nonstandard constructor interferes when calling map::emplace with noncopyable nonmovable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59969
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
The attached example builds fine, I think you mean this:
#include
struct A
{
int bla;
A(int blub):bla(blub){}
A(A&&) = delete;
A(const A&) = delete;
A& operator=(A&&) = delete;
A& operator=(const A&) = delete;
};
int main()
{
std::map map;
map.emplace(1, 1);
}
That code isn't valid.
(In reply to gcc.gnu.org.49489419 from comment #0)
> is preferred over the standard constructor
>
> template class = typename enable_if<__and_,
>is_convertible<_U2, _T2>
> >::value
>>::type>
> constexpr pair(_U1&& __x, _U2&& __y)
> : first(std::forward<_U1>(__x)), second(std::forward<_U2>(__y)) { }
That constructor isn't valid because is_convertible is false, because
is_convertible is always false for non-movable types.
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rth at gcc dot gnu.org, ||torvald at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I doubt the __sync_* builtins are meant to be any stronger than __ATOMIC_SEQ_CST is.
[Bug libstdc++/59969] std::pair nonstandard constructor interferes when calling map::emplace with noncopyable nonmovable object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59969 --- Comment #2 from Jonathan Wakely --- P.S. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4064.html will improve things in this area, but isn't implemented yet.
[Bug libstdc++/41759] [C++0x] static_assert phrasing should be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- (In reply to Paolo Carlini from comment #2) > Or, if we really wants positive forms, I would suggest: > > "template parameter _UIntType is an unsigned integral type" Or maybe: "template parameter _UIntType must be an unsigned integral type"
[Bug libstdc++/41759] [C++0x] static_assert phrasing should be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759 --- Comment #5 from Jonathan Wakely --- And we could replace the clunky "template argument substituting _UIntType" with simply "result_type" e.g. "result_type must be an unsigned integer type"
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #4) > This looks similar to PR 64600. > The problem seems to be arm_canonicalize_comparison that > canonicalizes a comparison with 2147483647 (0x7fff) > into a comparison with that +1, that is 0x8000 without properly > sign-extending it into 0x8000 (which would make it -2147483648). That's not right logic, need to think a bit harder on what to do here...
[Bug ipa/65701] r221530 makes 187.facerec drop with -Ofast -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65701 --- Comment #3 from Jan Hubicka --- Yep, I looked into this regression a bit. The patch just avoids some "false positives" of inlining functions called once (i.e. case where we think the function will optimize out but it really won't so we end up with duplication) and also some "false negatives". As such, it can affect pretty large functions to be or not be inlined. I will oprofile to figure out which one it is here.
[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61645 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-08 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- Definitely not a bug, but we might as well add the noexcept.
[Bug target/65694] [5 Regression] ICE (in decompose, at rtl.h:2007) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65694 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #5) > (In reply to ktkachov from comment #4) > > This looks similar to PR 64600. > > The problem seems to be arm_canonicalize_comparison that > > canonicalizes a comparison with 2147483647 (0x7fff) > > into a comparison with that +1, that is 0x8000 without properly > > sign-extending it into 0x8000 (which would make it -2147483648). > > That's not right logic, need to think a bit harder on what to do here... err... Ignore this. I think doing the sign-extend here is the right thing to do. All these numbers close to INT_MIN/MAX are very fiddly :(
[Bug web/65699] online docs lacks version that it documents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- Note that we also store gccint for previous versions: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gccint/ but we do not link to them from https://gcc.gnu.org/onlinedocs In addition, perhaps we could simply add: This file documents the internals of the GNU compilers (GCC version $VERSION). at the top of the index.html file?
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #3 from Andrew Macleod --- Note that atomic MEMMODEL_SEQ_CST is the original implementation of __sync. It was expanded to allow other memory models and the name was changed... but under the covers it still implemented the same as it was before.
[Bug libstdc++/41759] [C++0x] static_assert phrasing should be positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41759 --- Comment #6 from W E Brown --- I hadn't realized this was still open :) FWIW, my paper N3846 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3846.pdf) summarizes on p. 3 my recommended "guidelines for programmers to follow in crafting diagnostic messages for users" as follows: • Provide explicit indication that something has gone wrong: – Users are lost when they make mistakes with no feedback. – Be specific in describing the exact problem; avoid vague generalities or generic messages (e.g., "syntax error"). • Use human-readable (i.e., comprehensible) language: – Avoid abbr’s and codes (e.g., "type 2 error"). – Use polite and grammatically correct phrasing. – Neither blame users nor imply they are stupid or doing something wrong (e.g., "illegal command"). – Be affirmative. • Above all, be helpful; provide constructive advice: – Tell users how to address the problem. – Use error messages as an educational resource to impart a small amount of knowledge to users. [To give due credit, I many years ago paraphrased, rearranged, and reformatted these based in significant part on Jakob Nielsen's article “Error Message Guidelines.” (Nielsen Norman Group, 2001-06-24. http://www. nngroup.com/articles/error-message-guidelines/).]
[Bug middle-end/65702] New: [5 Regression] ICE (tree check: expected ssa_name, have var_decl in expand_gimple_basic_block, at cfgexpand.c:5506) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65702
Bug ID: 65702
Summary: [5 Regression] ICE (tree check: expected ssa_name,
have var_decl in expand_gimple_basic_block, at
cfgexpand.c:5506) on arm-linux-gnueabihf
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
seen with r221867 on arm-linux-gbueabihf
$cat palette.ii
class A {
int m_fn1() const;
};
int a[1];
int b;
int A::m_fn1() const {
register int c asm("");
while (b)
if (a[5])
c = b;
return c;
}
$ g++ -c -g -O2 -std=gnu++11 palette.ii
palette.ii: In member function 'int A::m_fn1() const':
palette.ii:7:16: error: invalid register name for 'c'
register int c asm("");
^
palette.ii:6:5: internal compiler error: tree check: expected ssa_name, have
var_decl in expand_gimple_basic_block, at cfgexpand.c:5506
int A::m_fn1() const {
^
0x8243dd tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src/gcc/tree.c:9297
0x39e455 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../src/gcc/tree.h:2846
0x39e455 expand_gimple_basic_block
../../src/gcc/cfgexpand.c:5506
0x39ec81 execute
../../src/gcc/cfgexpand.c:6127
Please submit a full bug report,
with preprocessed source if appropriate.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5-20150404-0ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --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-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=yes
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 5.0.0 20150404 (experimental) [trunk revision 221867] (Ubuntu
5-20150404-0ubuntu11)
[Bug middle-end/65702] [5 Regression] ICE (tree check: expected ssa_name, have var_decl in expand_gimple_basic_block, at cfgexpand.c:5506) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65702 --- Comment #1 from Matthias Klose --- seen building the aseprite package on armhf
