[Bug middle-end/50199] [4.7/4.8 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 16:02:24 UTC --- I guess it is again too late to really fix this for 4.8, can we at least error out on -fno-merge-constants used together with -flto ? We'll still fail for targets that don't support mergeable string sections, but generally, it makes no sense to use -fno-merge-constants together with -flto.
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 17:04:45 UTC --- I'd very much prefer to keep PR54971 fix in. As for #c3, I believe it would be enough to test the mode, so perhaps tree repl = get_access_replacement (lacc); enum machine_mode mode = DECL_MODE (repl); and compare that to TYPE_MODE (TREE_TYPE (rhs)). At least that would match what cfgexpand.c is actually checking, otherwise it looks reasonable. And if #c4 works, that would be even better.
[Bug target/55947] non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 21:23:11 UTC --- Yeah, that is intentional. If you want HLE acquire/release, you really should pass it as constant. What do you think we should emit instead? Runtime switch based on the memory model?
[Bug tree-optimization/55949] __builtin_object_size size passed to memcpy_chk is incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55949
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
22:14:09 UTC ---
Looks like a bug in whatever string.h headers you are using.
The second parameter for __builtin_object_size for memcpy should be always 0,
not __USE_FORTIFY_LEVEL 1 (that is used for functions like strcpy and has the
additional restriction that the copying isn't allowed to cross array/field
boundaries).
In glibc there is
#define __bos(ptr) __builtin_object_size (ptr, __USE_FORTIFY_LEVEL 1)
#define __bos0(ptr) __builtin_object_size (ptr, 0)
and
__extern_always_inline void *
__NTH (memcpy (void *__restrict __dest, __const void *__restrict __src,
size_t __len))
{
return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
}
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-12
20:14:59 UTC ---
Yeah, started with my http://gcc.gnu.org/viewcvs?root=gccview=revrev=188656
Slightly reduced testcase:
int b;
void
f (int x)
{
int a;
for (a = x; a 2; a++)
for (b = 0; b 2; b++)
*(unsigned short *) 0x10UL %= 46;
}
Will have a look on Monday.
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-13 11:29:13 UTC --- Yeah, what bootstrap compiler are you using? And are you sure your tree is in consistent state? $ grep gimple_call_builtin_p gimple.h extern bool gimple_call_builtin_p (gimple, enum built_in_class); extern bool gimple_call_builtin_p (gimple, enum built_in_function);
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #42 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-13 11:31:35 UTC --- TLS is supported in Fedora glibc obviously, the issue is likely with the sorry state of the Fedora/SPARC port, which is essentially unmaintained. So it must be something SPARC specific.
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-13 12:33:49 UTC --- Author: jakub Date: Sun Jan 13 12:33:43 2013 New Revision: 195136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195136 Log: PR fortran/55935 * gimple-fold.c (get_symbol_constant_value): Call unshare_expr. (fold_gimple_assign): Don't call unshare_expr here. (fold_ctor_reference): Call unshare_expr. * trans-expr.c (gfc_conv_structure): Call unshare_expr_without_location on the ctor elements. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/gimple-fold.c
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-13 16:54:28 UTC --- Fixed.
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.3 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:33:36 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172
[Bug tree-optimization/55964] [4.7/4.8 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-14 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.3 Summary|Segmentation fault with -O |[4.7/4.8 Regression] |-ftree-loop-distribution|Segmentation fault with -O |-funswitch-loops|-ftree-loop-distribution ||-funswitch-loops Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:34:08 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.3 |4.8.0 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:35:19 UTC --- Please ignore previous comment, it was meant for PR55964.
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 12:42:33 UTC --- Created attachment 29159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29159 gcc48-pr55955.patch Untested fix.
[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 13:02:12 UTC --- The testcase is invalid, the bug is only on the side of the testcase.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 14:24:32 UTC --- Created attachment 29161 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29161 gcc48-pr48766.patch Untested fix. Seems in the previous option processing the negative options cancel their corresponding positive options (and vice versa), and only the last occurrence of the option from the command line remains and the patch just disables -fwrapv if -ftrapv comes after -fwrapv, and vice versa. So e.g. -fwrapv -ftrapv -fwrapv results in -fwrapv -fwrapv -ftrapv results in -ftrapv -fwrapv -ftrapv -fno-wrapv results in -ftrapv -ftrapv -fwrapv -fno-trapv results in -fwrapv etc.
[Bug middle-end/50199] [4.7/4.8 Regression] wrong code with -flto -fno-merge-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50199 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 14:55:45 UTC --- (In reply to comment #14) I'm not sure this isn't an issue without LTO though (possibly way harder to trigger though). I don't see how. -fno-merge-constants doesn't say that constants aren't merged within the same TU, they are merged always, -fno-merge-constants is about not allowing constants to be merged between different object files. As without LTO we operate at the level of individual TUs, we don't have issues with that. -fno-merge-constants is the only possible thing on targets that don't have needed support on the assembler/linker side though.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 15:13:47 UTC --- Either use a different name of the attribute (replace target with mv_target or whatever), or require a new attribute (mv?) to be present for multi-versioning (mv attribute on any of the decls would enable it, if mv attribute isn't present on either of the two decls being merged, then the target attribute is merged as before 4.8).
[Bug middle-end/55943] [4.6/4.7/4.8 Regression] ICE in gen_reg_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55943 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.8 Regression] ICE in |[4.6/4.7/4.8 Regression] |gen_reg_rtx |ICE in gen_reg_rtx Known to fail||4.4.1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 15:44:50 UTC --- I don't have 4.3 around, but 4.4.1 certainly ICEs on this, both with -O0 and with optimizations. The ICE is during reload, similarly to the trunk ICE. I guess the testcase in the testsuite should be just limited to x86_64/i686 and perhaps few others where the r resp. =r constraint can be handled.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 16:01:36 UTC --- Because it behaves differently. ./xgcc -B ./ -fwrapv -ftrapv -fno-trapv -fverbose-asm -S -xc /dev/null -o - 21 | grep rapv # -march=x86-64 -auxbase-strip - -fno-trapv -fverbose-asm with Negative(fwrapv) resp. Negative(ftrapv) added instead of this patch, while with that patch it was -fwrapv.
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 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 2013-01-14 16:35:52 UTC --- That's not the case, because most of the raw string support is in the preprocessor.
[Bug tree-optimization/53342] [4.8 Regression] rnflow.f90 is ~5% slower after revision 187340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53342 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 16:45:11 UTC --- Can't we then compute the final values of the bases after the peeling loop, and add those gimplified after the peeling loop, then use them in the next loop?
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||tromey at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14
17:33:02 UTC ---
This is about:
if (pfile-state.in_directive
|| pfile-state.parsing_args
|| pfile-state.in_deferred_pragma)
{
cur--;
type = CPP_OTHER;
cpp_error_with_line (pfile, CPP_DL_ERROR, token-src_loc, 0,
unterminated raw string);
break;
}
in lex_raw_string, in this case state.in_directive is true, as it is in #define
directive. But just removing state.in_directive from that condition isn't
enough,
1537 _cpp_process_line_notes (pfile, false);
1538 if (!_cpp_get_fresh_line (pfile))
doesn't handle this case correctly.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 18:25:41 UTC --- I guess if for multiversioning you want the two decls to be independent, like overloaded functions with different argument types are, then IMHO the mv attribute alternative and not merging anything at all in that case (neither the decls, nor any of the attributes (not just target attribute) is better.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 18:32:44 UTC --- Actually, what you'd merge is everything as usually if mv attribute isn't on either of the decls, or if mv attribute is present on either one, and both decls have either the same target attribute, or no target attribute at all. If mv attribute is on newdecl or olddecl, and target attribute is either present on just one of the decls, or on both, but with different argument, it would treat them as decls that mangle differently and won't be merged.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-14 20:23:54 UTC --- That wouldn't work, because you would then have the default (non-mv) version, possibly mv version with no target attribute, and then some other mv versions with target attributes. The problem with that is that the first two mangle the same. This means that a non-mv and mv with no target attribute needs to be treated as the same decl (i.e. merged together).
[Bug c/55967] rightshift an unsigned value (X) by it's number of bits does not always yield 0, when X is an unsigned that's leftshifted by it's number of bits and offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55967 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 07:55:06 UTC --- Please google around on undefined behavior, you'll find various FAQs about it. When a program triggers undefined behavior, anything can happen, the compiler can optimize based on the fact that such behavior won't happen in a program, as a bonus in this case you get a warning telling you your bug. There is no graceful/expected behavior for undefined behavior, otherwise it wouldn't be undefined.
[Bug tree-optimization/48766] [4.6/4.7/4.8 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 08:17:09 UTC --- Author: jakub Date: Tue Jan 15 08:16:56 2013 New Revision: 195186 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195186 Log: PR tree-optimization/48766 * opts.c (common_handle_option): For -fwrapv disable -ftrapv, for -ftrapv disable -fwrapv. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug tree-optimization/48766] [4.6/4.7 Regression] Infinite recursion in fold_binary_loc()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48766 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] |Infinite recursion in |Infinite recursion in |fold_binary_loc() |fold_binary_loc() --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 08:34:59 UTC --- Fixed on the trunk so far.
[Bug c++/55988] Incorrect code generation with const and -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55988 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 08:41:00 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55893 ***
[Bug c++/55893] [4.7/4.8 Regression][C++11] runtime segfault with static const object with virtual destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55893 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||pavel.zbitskiy at gmail dot ||com --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 08:41:00 UTC --- *** Bug 55988 has been marked as a duplicate of this bug. ***
[Bug testsuite/54139] [4.8 regression] some ARM Thumb-2 tests appear to be run on ARMv5TE hardware causing unhandled exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139 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 2013-01-15 09:25:45 UTC --- http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01425.html as an example of armv5tel-*-linux-gnueabi shows FAIL: gcc.target/arm/ftest-armv6t2-arm.c execution test FAIL: gcc.target/arm/ftest-armv6t2-thumb.c execution test FAIL: gcc.target/arm/ftest-armv7a-arm.c execution test FAIL: gcc.target/arm/ftest-armv7a-thumb.c execution test FAIL: gcc.target/arm/ftest-armv7r-arm.c execution test FAIL: gcc.target/arm/ftest-armv7r-thumb.c execution test (not sure on what hw has it been run) and http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg01494.html (armv7hl-*-linux-gnueabi), which shows FAIL: gcc.target/arm/ftest-armv4t-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv4t-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/ftest-armv5t-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv5t-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/ftest-armv5te-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv5te-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/ftest-armv6-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv6-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/ftest-armv6k-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv6k-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/ftest-armv6z-thumb.c (test for excess errors) UNRESOLVED: gcc.target/arm/ftest-armv6z-thumb.c compilation failed to produce executable FAIL: gcc.target/arm/mmx-2.c (internal compiler error) FAIL: gcc.target/arm/mmx-2.c (test for excess errors) All these tests are new for 4.8 and all test new functionality in 4.8, so the regression status (beyond having some extra FAILs) is questionable.
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 09:31:43 UTC --- Author: jakub Date: Tue Jan 15 09:31:28 2013 New Revision: 195190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195190 Log: PR tree-optimization/55955 * tree-vect-loop.c (vectorizable_reduction): Give up early on *SHIFT_EXPR and *ROTATE_EXPR codes. * gcc.c-torture/compile/pr55955.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55955.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 09:36:14 UTC --- Fixed.
[Bug fortran/54767] [4.7/4.8 Regression] Incorrect code generated with -O2 -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54767
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15
10:47:36 UTC ---
Yeah, indeed. The bug seems to be in the second vrp pass on xxx function.
iaii_23: [_79, _79] EQUIVALENCES: { } (0 elements)
looks wrong (iaii_23 is only conditionally equal to _79 (in the first iteration
that sets iaii, i.e. ia = 2, second iteration), it can be the value from
previous cycle too (in the ia = 3, third iteration).
This then leads to
_35 = prephitmp_50 - iaii_23;
being
_35: [0, 0]
(again, wrong) and that is why we end up with 1 instead of 2 in the second row.
There is:
Visiting PHI node: iaii_23 = PHI iaii_1(11), prephitmp_50(10)
Argument #0 (11 - 12 not executable)
Argument #1 (10 - 12 executable)
prephitmp_50
Value: [_79, _79] EQUIVALENCES: { _79 } (1 elements)
Found new range for iaii_23: [_79, _79]
which is wrong, but not sure if this is the first spot in the dump. iaii_1
here is only conditionally UNDEFINED, it might be iaii value from previous
iteration too.
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 12:04:13 UTC --- Created attachment 29168 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29168 gcc48-pr55920.patch Looking at the #c3 patch, I wonder if this wouldn't be more appropriate (untested so far). It tries to match roughly what the modify_this_stmt case does a few lines before.
[Bug middle-end/48087] [4.6/4.7/4.8 Regression] -Wall -Werror adds warnings over and above those generated by -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48087 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 15:11:40 UTC --- Created attachment 29170 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29170 gcc48-pr48087.patch Untested fix. That said, it seems that on the provided testcase g++ already generates the same set of warnings/errors for -Wreturn-type vs. -Werror=return-type, starting with http://gcc.gnu.org/viewcvs?root=gccview=revrev=186687 so supposedly you'd need to find a different testcase for this to still claim 4.8 Regression status. Not sure if this can be stage4 material, I think it is more stage1-ish material.
[Bug target/55940] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 15:22:14 UTC --- You haven't provided the preprocessed testcase, so it is hard to guess, but generally, if you have say a static function and call it also from assembly, you need __attribute__((used)) to prevent the compiler from using different calling conventions. Otherwise, if the compiler can see all possible callers (inline asm doesn't count, then you have to use the used attribute), it can decide not to emit the function at all, or use whatever calling convention it thinks are best for the function.
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 16:33:38 UTC --- Author: jakub Date: Tue Jan 15 16:33:24 2013 New Revision: 195209 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195209 Log: PR tree-optimization/55920 * tree-sra.c (sra_modify_assign): If for lacc-grp_to_be_debug_replaced there is non-useless type conversion needed from debug rhs to lhs, use build_debug_ref_for_model and/or VIEW_CONVERT_EXPR. * gcc.c-torture/compile/pr55920.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55920.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug target/55940] [4.7/4.8 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
Target Milestone|--- |4.7.3
Summary|Incorrect code for |[4.7/4.8 Regression]
|accessing parameters with |Incorrect code for
|32-bit Intel hosts |accessing parameters with
||32-bit Intel hosts
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15
17:45:48 UTC ---
Sounds like shrink-wrapping bug to me:
/* { dg-options -Os } */
/* { dg-additional-options -mpreferred-stack-boundary=2 { target { { i?86-*-*
x86_64-*-* } ia32 } } } */
struct S { int s; unsigned long t; };
__attribute__ ((visibility (hidden))) unsigned long long bar (struct S *x,
unsigned long y);
unsigned long long
foo (struct S *x, unsigned long y)
{
unsigned long a;
if (__builtin_expect (((unsigned long) (x) + 0x1000U 0x2000U), 0))
return ~0ULL;
if (__builtin_expect (x-s = 0 || x-s 9, 0))
return ~0ULL;
a = x-t 12;
if (y = a y == a)
return ~0ULL;
if (x-s == 3)
return x-t + y * 4096;
return bar (x, y);
}
The pre-prologue code can't use registers initialized in the prologue.
[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 17:56:05 UTC --- You're wrong, the code in #c2 is not valid C. ISO C99 6.5.2.1 says that d[++k] is equivalent to: (*((d)+(++k))) and ++k in the last iteration is 16, so it is (*(d+16)) and then 6.5.6/8 (last sentence) applies: If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated. So, if you ever enter this loop, you'll invoke undefined behavior and anything can happen.
[Bug target/55940] [4.7/4.8 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 18:28:31 UTC --- I think: --- gcc/function.c.jj2013-01-11 09:02:55.0 +0100 +++ gcc/function.c2013-01-15 19:23:20.648826011 +0100 @@ -6029,7 +6029,7 @@ thread_prologue_and_epilogue_insns (void if (pic_offset_table_rtx) add_to_hard_reg_set (set_up_by_prologue.set, Pmode, PIC_OFFSET_TABLE_REGNUM); - if (stack_realign_drap crtl-drap_reg) + if (crtl-drap_reg) add_to_hard_reg_set (set_up_by_prologue.set, GET_MODE (crtl-drap_reg), REGNO (crtl-drap_reg)); should fix it, in this case we pessimistically assume we might need to realign the stack and because of -Os we create vDRAP, but then find out we don't actually need to realign anything.
[Bug tree-optimization/55920] [4.8 Regression] ICE in expand_debug_locations, at cfgexpand.c:3753
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55920 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 18:36:36 UTC --- Fixed.
[Bug tree-optimization/55936] [4.6/4.7/4.8/4.9 Regression] Missed VRP optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|4.6.4 |4.9.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7/4.8/4.9 |Missed VRP optimization |Regression] Missed VRP ||optimization --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 19:42:10 UTC --- Deferring for 4.9 then.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 21:51:36 UTC --- Thanks for working on this. Unfortunately it seems the http://gcc.gnu.org/viewcvs?root=gccview=revrev=195211 change (commit message didn't make it into this PR because of an extra pr after / ) regressed i386/pr45352.c testcase on i?86. ./cc1 -m32 -O3 -march=amdfam10 -fselective-scheduling2 -fsel-sched-pipelining -funroll-all-loops gcc.target/i386/pr45352.c ICEs now with: internal compiler error: in add_insn_mem_dependence, at sched-deps.c:1717
[Bug target/55940] [4.7/4.8 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-15 22:58:28 UTC --- Author: jakub Date: Tue Jan 15 22:58:21 2013 New Revision: 195220 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195220 Log: PR target/55940 * function.c (thread_prologue_and_epilogue_insns): Always add crtl-drap_reg to set_up_by_prologue.set, even if stack_realign_drap is false. * gcc.dg/pr55940.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55940.c Modified: trunk/gcc/ChangeLog trunk/gcc/function.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56000] [4.8 Regression] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 07:58:09 UTC --- These are all new tests, so why do you consider that a regression? E.g. the va_1.c test is xfailed even on x86_64-*-*, so I'd guess it isn't very portable. All these tests were added for aarch64, so I bet they haven't been tested much on targets beyond that and a few most common ones.
[Bug target/55940] [4.7 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Summary|[4.7/4.8 Regression]|[4.7 Regression] Incorrect |Incorrect code for |code for accessing |accessing parameters with |parameters with 32-bit |32-bit Intel hosts |Intel hosts --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 07:59:51 UTC --- Fixed on the trunk so far.
[Bug c++/55998] [4.8 Regression] [C++11] 'integral expression .. is not constant' when instantiating template alias in a template using a parameter of an encapsulating template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55998 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 2013-01-16 08:02:44 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=191412
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 08:11:42 UTC --- Merging of target attribute is what gcc/g++ did though, the function would get then both target attributes (seems later decl's target wins), and the first target attribute in DECL_ATTRIBUTES would be the one to be used. Perhaps we can add a -Wattributes warning for that case if mv attribute isn't present and are merging target attributes with different strings.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 09:08:51 UTC --- I'd say it is too late for autoconf update for 4.8 now, if this is about LN_S uses in a single Makefile (are we talking about libada/Makefile.in ? ), you could temporarily use something like ifeq (cp -p,$(LN_S)) LN_S_RECURSIVE = cp -pR else LN_S_RECURSIVE = $(LN_S) endif (or even limit it to targets known to support cp -pR well that don't have ln -s) and use $(LN_S_RECURSIVE) in $(LN_S) $(ADA_RTS_DIR) adainclude $(LN_S) $(ADA_RTS_DIR) adalib (2x) instead $(LN_S). Then for 4.9 we can upgrade autoconf requirements and revert this.
[Bug target/55940] [4.7 Regression] Incorrect code for accessing parameters with 32-bit Intel hosts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55940 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 09:16:15 UTC --- As a workaround, you can use something like #if __GNUC__ == 4 __GNUC_MINOR__ == 7 __attribute__((__optimize__ (no-shrink-wrap))) #endif on the VBoxHost_RTR0MemObjGetPagePhysAddr function or don't use long long for the return type here (pass it by reference etc., that is the reason why gcc even thought about potentially needing the stack realignment), don't use -mpreferred-stack-boundary=2, or -Os, or use optimize (2) attribute, there are lots of options.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:25:48 UTC --- countm1.0 type is unsigned, thus + 0x is effectively - 1.
[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:38:01 UTC --- Sounds like a recent change: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=048ee0993ec8360abb0b51bdf8f8721e9ed62ec4 The question is what to do about that on the libasan side. Can we keep + (1ULL 41) asan_shadow_offset for both 44-bit and 46-bit user address spaces? If we just increase kHighMemEnd to 0x3fffUL, it will mean that on older kernels half of the user address space will be the shadow memory (from 0x200 to 0x9ff). Perhaps that is still acceptable, but if ever the address space grows again, we'd need to make size of shadow memory region and kHighMemEnd dynamic.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 10:47:18 UTC --- BTW, does Fortran have well defined number of iterations if say a do loop goes from (unknown to compiler): integer :: i, m, n m = huge(0) - 7 n = huge(0) - 2 do i = m, n, 4 ... end do ? If it must iterate exactly twice (for i = huge(0) - 7 and i = huge(0) - 3), then it can't be expressed as a corresponding C loop (which would end up with undefined behavior). But using a temporary, increment and then test of the temporary should be doable in the FE, the question is if it does cure this.
[Bug rtl-optimization/50176] [4.7/4.8 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:22:23 UTC --- Created attachment 29177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29177 gcc48-pr50176.patch Are you sure about it? For me on the http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088 testcase with -m32 -O2 with the attached patch I get just minor RA changes: - movl(%esp), %edi + movl(%esp), %esi addl$3, %ecx - movl4(%esp), %esi - movzbl(%edi,%eax), %ebx + movl4(%esp), %edi + movzbl(%esi,%eax), %ebx + movzbl(%edi,%eax), %esi movzbl0(%ebp,%eax), %edi - movzbl(%esi,%eax), %esi The fwprop extension is performed as can be seen in the dump, but the overall effect isn't there.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:31:51 UTC --- Author: vmakarov Date: Tue Jan 15 16:47:36 2013 New Revision: 195211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195211 Log: 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * sched-deps.c (sched_analyze_2): Add pending reads for prefetch. 2013-01-15 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/pr55153 * gcc.dg/pr55153.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr55153.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:50:47 UTC --- I think for 44-46 bits we can still make it constant. But generally, the constructors of libasan are usually run from the stack of the initial thread, so it should be enough to look at address of any local variable and check if it is around (1 44) - epsilon or (1 46) - epsilon.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 11:59:29 UTC --- Created attachment 29178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29178 gcc48-pr52865.patch This untested patch makes the loop vectorizable. Not sure if it is better this way, or with doing assignment of the condition result into a bool and using it later (as done in the patch for the other PR).
[Bug tree-optimization/55964] [4.7 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|[4.7 Regression] |Segmentation fault with -O |Segmentation fault with -O |-ftree-loop-distribution|-ftree-loop-distribution |-funswitch-loops|-funswitch-loops --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 14:22:49 UTC --- Fixed for 4.8+ so far.
[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:19:47 UTC --- Unfortunately the fix caused some guality regressions, on x86_64 -m32 +FAIL: gcc.dg/guality/drap.c -O1 line 21 a == 5 +FAIL: gcc.dg/guality/drap.c -O1 line 22 b == 6 up to -Os, and +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 16 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-1.c -O1 line 18 arg7 == 30 (up to -Os), +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 16 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-2.c -O1 line 18 arg7 == 30 (up to -Os), +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 14 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-3.c -O1 line 16 arg7 == 30 (up to -Os) and finally +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 14 arg7 == 30 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg1 == 1 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg2 == 2 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg3 == 3 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg4 == 4 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg5 == 5 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg6 == 6 +FAIL: gcc.dg/guality/pr36728-4.c -O1 line 16 arg7 == 30 (up to -Os), and similarly for x86_64 -m64 (fewer 36728-*.c regressions, but still some and all drap.c regressions).
[Bug target/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:40:46 UTC --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153#c4 Let's close PR55153 as fixed and keep this PR to track the regression the fix caused.
[Bug rtl-optimization/55153] [4.8 Regression] ICE: in begin_move_insn, at sched-ebb.c:205 with -fsched2-use-superblocks and __builtin_prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55153 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 15:41:46 UTC --- Fixed, the regression caused by the fix is tracked now as PR56005.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
16:02:35 UTC ---
The actual merging of target attribute isn't that important, what would be more
important is that other attributes are merged together in that case and the
decls treated as the same thing.
Anyway, with target(any) attribute, what would happen for
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (any)));
void foo () {}
Is the definition any, something else?
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:05:42 UTC --- Author: jakub Date: Wed Jan 16 16:05:27 2013 New Revision: 195241 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195241 Log: PR fortran/52865 * trans-stmt.c (gfc_trans_do): Put countm1-- before conditional and use value of countm1 before the decrement in the condition. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c
[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:31:10 UTC --- Ah, hjl opened PR56006 to track #c11.
[Bug debug/56006] [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-16 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:33:47 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=195227 See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547#c11
[Bug driver/55884] [4.8 Regression] FAIL: libgomp.fortran/omp_parse3.f90 -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55884 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:35:30 UTC --- Assuming fixed.
[Bug rtl-optimization/56005] [4.8 Regression] FAIL: gcc.target/i386/pr45352.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56005 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 18:36:47 UTC --- Fixed.
[Bug debug/56006] [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 19:06:09 UTC --- The second patch in http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00822.html (which is waiting for Uros' bootstrap/regtest on alpha AFAIK) seems to fix these regressions.
[Bug rtl-optimization/48181] [4.6/4.7/4.8 Regression] wrong code with -O -fgcse --param ira-max-conflict-table-size=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 23:07:19 UTC --- http://gcc.gnu.org/viewcvs?root=gccview=revrev=192719 fixed this (so, most likely reproduceable by disabling LRA).
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Known to work||4.1.2 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 Summary|expand expands p[9] = |[4.6/4.7/4.8 Regression] |COMPLEX_EXPR|expand expands p[9] = |-IMAGPART_EXPR p[9], |COMPLEX_EXPR |REALPART_EXPR p[9]; |-IMAGPART_EXPR p[9], |incorrectly.|REALPART_EXPR p[9]; ||incorrectly. --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:30:11 UTC --- Works correctly with 4.1.2, where we had CR.108 = REALPART_EXPR p[0]; REALPART_EXPR p[0] = -IMAGPART_EXPR p[0]; IMAGPART_EXPR p[0] = CR.108; in the *.optimized dump. Thus a regression.
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:31:08 UTC --- Created attachment 29189 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29189 gcc48-pr56015.patch Untested fix.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:45:20 UTC --- I don't care much about the error wording, I've put into dg-error just what gcc was reporting before (and after it emitted ICE).
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:59:08 UTC --- Seems the elf_platform () returned strings need some adjustment to match the RS6000_CPU names. Grepping Linux kernel, elf_platform can return e.g. pa6t power3 power4 power5 power5+ power6 power6x power7 power7+ power8 powerpc ppc403 ppc405 ppc440 ppc440gp ppc470 ppc5554 ppc601 ppc603 ppc604 ppc7400 ppc7450 ppc750 ppc823 ppc8540 ppc8548 ppc970 ppca2 ppc-cell-be ppce500mc ppce5500 ppce6500 so, supposedly initialy ppc prefix, if any, should be dropped, ppc-cell-be should be replaced by cell and most likely the string checked against the asm_names[].cpu strings. There are other minor differences, e.g. kernel has ppc440 and ppc440gp, while gcc 440fp and 440 (do they match in this order, or differently?).
[Bug c/56018] Access to member of unnamed union variable in structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56018
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||INVALID
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
11:14:13 UTC ---
This has nothing to do with gcc, the header file has:
union
{
/* Used if SA_SIGINFO is not set. */
__sighandler_t sa_handler;
/* Used if SA_SIGINFO is set. */
void (*sa_sigaction) (int, siginfo_t *, void *);
}
__sigaction_handler;
# define sa_handler __sigaction_handler.sa_handler
# define sa_sigaction __sigaction_handler.sa_sigaction
And, using __sigaction_handler.sa_handler in your source file is wrong,
__sigaction_handler is reserved for the implementation (and so is sa_handler in
POSIX if you include signal.h header).
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #174 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 12:42:06 UTC --- lto_post_options ?
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||nickc at gcc dot gnu.org,
||ramana at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
15:55:26 UTC ---
The issue isn't latent, can be still reproduced with:
/* PR target/49069 */
/* { dg-do compile } */
/* { dg-options -Os -fno-tree-forwprop -Wno-div-by-zero } */
int a;
const unsigned long long b[1] = { 1ULL };
extern void bar (int);
void
foo (void)
{
for (a = 0; a == 1; a = 2)
;
bar (b[0] == (a == 0 ? a : a / 0));
}
Which also shows that the middle-end usually optimizes that well (cf. #c4), but
the arm backend relying on that always happening is just a very bad assumption.
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:08:15 UTC --- Created attachment 29193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29193 gcc48-pr49069-1.patch One possible fix.
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:10:45 UTC --- Created attachment 29194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29194 gcc48-pr49069-2.patch Another possible fix. Or Steven's fix (+ testcase) if it works. It will be optimized by RTL optimizers anyway. Just asserting that an unlikely, but possible thing, won't happen, is wrong. Can we get this fixed for 4.8?
[Bug rtl-optimization/55273] [4.8 Regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:36:53 UTC --- Author: jakub Date: Thu Jan 17 16:36:43 2013 New Revision: 195275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195275 Log: PR tree-optimizatoin/55273 * gcc.c-torture/compile/pr55273.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55273.c - copied unchanged from r195274, trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Removed: trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55273] [4.8 Regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:38:28 UTC --- Author: hubicka Date: Thu Jan 17 16:27:23 2013 New Revision: 195274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195274 Log: PR tree-optimizatoin/51083 * gcc.c-torture/compile/pr51083.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:49:58 UTC --- Ugh, no, that is way too premature. This really shouldn't be a dynamic relocation. And asan shouldn't be registering the same (common or in the end non-common) var multiple times from different shared libraries or binaries. For this we should have a way to refer using non-dynamic relocation to the common symbol (like R_*_32 or R_*_64, but resolved to the local copy of the symbol, not global one; or can we have .hidden aliases to common symbols?), and this size relocation should be also resolved at link time.
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 17:48:18 UTC --- No idea why you keep mentioning .quadcommon_data .quadcommon_data@size .quadcommon_data@size + 40 That is nothing even close to what asan needs. Asan for what is normally emitted e.g. as: .comm common_data,15,4 needs to emit .comm common_data,64,32 instead, and then a hidden alias to common_data (currently not allowed by as) or some new relocations which will result in the address of the common_data copy in current executable resp. shared library, followed by 15 (the size of the real common_data), followed by common_data@size (which will be either 15 or 64, depending on how large is common_data actually allocated). This still relies on the the linker always choosing the highest alignment from all the alignments of the same var (because libasan relies that all such variables are at least 32 bytes aligned), and if merging of common vars in whatever order always results in highest size being picked, then we even don't need any of this @size stuff at all. The problem is that if you link say a shared library or executable where you have some -fsanitize=address compiled common vars and then some non-sanitized object with the var initialized (i.e. non-common), then the non-common var wins, but a) doesn't get appropriately aligned (so, impossible to be passed to asan register function), and b) not appropriately sized. Consider: 1.c: asm (.globl foo; .comm foo,4,4;); 2.c: asm (.globl foo; .comm foo,64,32;); 3.c: asm (.globl foo; .comm foo,4,4;); 4.c: int foo = 6; (1.c and 3.c emulate -fno-sanitize=address common var, 4.c non-sanitized non-common var, 2.c sanitized common var). Now, gcc -shared -fpic -o test.so 1.c 2.c 3.c seems to DTRT, foo is 32-byte aligned and 64-bytes long, so we could register it as foo's hidden alias, 4, 64. But if you gcc -shared -fpic -o test.so 1.c 2.c 3.c 4.c you get: /usr/bin/ld: Warning: alignment 4 of symbol `foo' in /tmp/ccoadfJM.o is smaller than 32 in /tmp/cc8Dhbe7.o /usr/bin/ld: Warning: size of symbol `foo' changed from 64 in /tmp/cc8Dhbe7.o to 4 in /tmp/ccoadfJM.o No @size stuff helps with this.
[Bug libffi/56000] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 18:27:47 UTC --- Should be fixed now.
[Bug debug/56006] [4.8 Regression] Many guality testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56006 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 11:06:49 UTC --- Author: aoliva Date: Fri Jan 18 10:57:36 2013 New Revision: 195289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195289 Log: PR rtl-optimization/55547 PR rtl-optimization/53827 PR debug/53671 PR debug/49888 * alias.c (offset_overlap_p): New, factored out of... (memrefs_conflict_p): ... this. Use absolute sizes. Retain the conservative special case for symbolic constants. Don't adjust zero sizes on alignment. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug middle-end/56022] [4.8 regression] ICE (segfault) at convert_memory_address_addr_space (explow.c:334)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56022 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 11:11:51 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=191577
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 13:02:41 UTC --- But why doesn't the 1 41 version work with both 44 and 46-bit VA? It should be: || `[0x0a00, 0x3fff]` || HighMem|| || `[0x0340, 0x09ff]` || HighShadow || || `[0x0240, 0x033f]` || ShadowGap || || `[0x0200, 0x023f]` || LowShadow || || `[0x, 0x01ff]` || LowMem || then, which IMHO should work just fine even if 0x1000 through 0x3fff is unavailable.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 13:52:02 UTC --- Ah yes, it can't be | SHADOW_OFFSET then, but has to be + SHADOW_OFFSET. + is what gcc emits (the reason for that was primarily that it resulted in better code on x86_64/i686). So perhaps for targets where SHADOW_OFFSET is non-zero and below (or equal to) 12.5% of maximum user address space, we are free to use either | or +, but for other targets (for now ppc64) it must use +?
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
--- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18
14:18:58 UTC ---
Created attachment 29207
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29207
gcc48-pr55742.patch
This bug is open for way too long given its severity, so let's start talking
over patches.
This patch attempts to implement what I understand from Jason's comments, just
with default instead of any, because it is indeed the default target
attribute (whatever you specify on the command line).
Say on:
void foo ();
void foo () __attribute__((target (avx)));
void foo () __attribute__((target (default)));
__attribute__((target (default))) void foo ()
{
}
__attribute__((target (avx))) void foo ()
{
}
void (*fn) () = foo;
first we merge the first two decls, because only if target attribute is present
on both, we consider it for multi-versioning, for compatibility with 4.7 and
older. On e.g.
void foo ();
void foo () __attribute__((target (sse4)));
void foo () __attribute__((target (default)));
void foo ()
{
}
we reject the last fn definition, because at that point foo is already known to
be multi-versioned, thus it is required that target attribute is specified for
foo (either default, or some other). Unfortunately, for this case the error
is reported twice for some reason.
The #c0 testcase now compiles.
Now, the issues I discovered with multiversioning, still unfixed by the patch:
1) the mv*.C testcases should be moved, probably to g++.dg/ext/mv*.C
2) can you please explain the mess in handle_target_attribute?
/* Do not strip invalid target attributes for targets which support function
multiversioning as the target string is used to determine versioned
functions. */
else if (! targetm.target_option.valid_attribute_p (*node, name, args,
flags)
! targetm.target_option.supports_function_versions ())
*no_add_attrs = true;
Why do you need that? Consider complete garbage in target attribute arguments,
which is errored about, but the above for i386/x86_64 keeps the target
attribute around anyway, leading to lots of ICEs everywhere:
Consider e.g.:
__attribute__((target (default))) void foo (void)
{
}
__attribute__((target (128))) void foo (void)
{
}
3) the multiversioning code assumes that target has a single argument, but it
can have more than one. Say for:
__attribute__((target (avx,popcnt))) void foo (void)
{
}
__attribute__((target (popcnt,avx))) void bar (void)
{
}
the compiler handles those two as equivalent, but with -Dbar=foo
multi-versioning only considers the first string out of that.
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 15:41:09 UTC --- Forcing everything to be built as -pie is a non-starter. The 5% just aren't worth the trouble. Especially, how are you going to deal with say a -fsanitize=address shared library built with 1 44 shadow offset and a PIE binary built with 0 shadow offset?
[Bug tree-optimization/56029] [4.8 Regression] ICE: verify_gimple failed, location references block not in block tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56029 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 16:54:56 UTC --- Created attachment 29209 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29209 gcc48-pr56029.patch The bug is that neither reserve_phi_args_for_new_edge nor remove_phi_arg_num clears gimple_phi_arg_location (only resize_phi_node does), so if some GIMPLE_PHI references some BLOCK in some argument, then that phi is shrunk a little bit where that argument is no longer used, then we remove unused blocks and then grow the same PHI again and nothing overrides gimple_phi_arg_location of the added argument, the old location magically reappears. This patch fixes this on the reserve_phi_args_for_new_edge side. Of course the question is also why the caller doesn't set gimple_phi_arg_location for something, but I'd say the code just should be robust in any case and when it isn't called explicitly, UNKNOWN_LOCATION should be in there.
[Bug tree-optimization/56029] [4.8 Regression] ICE: verify_gimple failed, location references block not in block tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56029 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 16:56:34 UTC --- Created attachment 29210 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29210 gcc48-pr56029-2.patch Alternatively the location can be reset when shrinking the PHI node. I prefer the first patch though (and am going to bootstrap/regtest it).
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 17:15:17 UTC --- Author: jakub Date: Fri Jan 18 17:15:07 2013 New Revision: 195301 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195301 Log: PR middle-end/56015 * expr.c (expand_expr_real_2) case COMPLEX_EXPR: Handle the case where writing real complex part of target modifies op1. * gfortran.dg/pr56015.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr56015.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56015] [4.6/4.7 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] expand |expand expands p[9] = |expands p[9] = COMPLEX_EXPR |COMPLEX_EXPR|-IMAGPART_EXPR p[9], |-IMAGPART_EXPR p[9], |REALPART_EXPR p[9]; |REALPART_EXPR p[9]; |incorrectly. |incorrectly.| Known to fail|4.8.0 | --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 17:25:46 UTC --- Fixed on the trunk so far.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #35 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 17:51:42 UTC --- Created attachment 29211 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29211 gcc48-pr55742.patch Updated patch with ChangeLog entry and code to prevent issuing errors for the same bug multiple times. As for documentation, the multiversioning was checked in without proper documentation, so there is nothing to adjust in documentation, the feature simply needs documentation written. 1), 2) and 3) are unsolved by the patch, similarly extensive test coverage (the current one is insufficient). Perhaps that can be solved incrementally? I'm going to bootstrap/regtest this version now.
[Bug tree-optimization/56029] [4.8 Regression] ICE: verify_gimple failed, location references block not in block tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56029 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 20:24:49 UTC --- Author: jakub Date: Fri Jan 18 20:24:34 2013 New Revision: 195304 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195304 Log: PR tree-optimization/56029 * tree-phinodes.c (reserve_phi_args_for_new_edge): Set gimple_phi_arg_location for the new arg to UNKNOWN_LOCATION. * g++.dg/torture/pr56029.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr56029.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-phinodes.c
[Bug tree-optimization/56029] [4.8 Regression] ICE: verify_gimple failed, location references block not in block tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56029 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 20:28:12 UTC --- Fixed.
[Bug target/55433] [4.8 Regression][LRA] ICE on excessive reloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55433 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18 20:30:39 UTC --- Fixed.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #39 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-19 10:14:04 UTC --- Then to fix that perhaps we want to change ix86_valid_target_attribute_tree and its caller. Currently ix86_valid_target_attribute_tree returns NULL_TREE both when the target string(s) are invalid (i.e. when ix86_valid_target_attribute_inner_p returned false) and when the target flags match the default ones. So, let's change ix86_valid_target_attribute_tree to e.g. return error_mark_node instead of NULL_TREE if the attribute is invalid, and NULL_TREE only if it matches the default. Then, ix86_valid_target_attribute_p could treat new_target == error_mark_node similarly to new_target == NULL_TREE with the exception of ret.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #29207|0 |1 is obsolete|| --- Comment #40 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-19 10:28:02 UTC --- Created attachment 29217 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29217 gcc48-pr55742-2.patch The following I mean (incremental patch). No test coverage for that, of course that needs to be added. BTW, I've noticed wrong ChangeLog entries, your gcc/ChangeLog-2012 CL entries refer to c-family/ (and cp/) files, while those should be moved (without prefix) to corresponding c-family/ChangeLog resp. cp/ChangeLog-2012.
