[Bug bootstrap/54128] [4.8 Regression] GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-21 19:31:58 UTC --- Fixed then.
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-22 23:06:42 UTC --- Can you please attach random.i and what exact gcc options were used to compile random.c ?
[Bug inline-asm/55775] [4.8 Regression] ICE when building pari
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55775 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-27 08:45:48 UTC --- Fixed.
[Bug java/55764] [4.8 Regression] ICE when building frysk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug tree-optimization/55831] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-31 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-31 14:34:11 UTC --- Created attachment 29065 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29065 gcc48-pr55831.patch Untested fix.
[Bug tree-optimization/55831] [4.8 Regression] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|ICE: verify_flow_info |[4.8 Regression] ICE: |failed |verify_flow_info failed --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-31 15:19:57 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=193882
[Bug tree-optimization/55831] [4.8 Regression] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-31 15:24:29 UTC --- Though, with (a = a + 1) instead of a++ it started ICEing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=167378 or http://gcc.gnu.org/viewcvs?root=gccview=revrev=167377 .
[Bug tree-optimization/55831] [4.8 Regression] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-31 23:50:06 UTC --- Author: jakub Date: Mon Dec 31 23:50:00 2012 New Revision: 194764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194764 Log: PR tree-optimization/55831 * tree-vect-loop.c (get_initial_def_for_induction): Use gsi_after_labels instead of gsi_start_bb. * gcc.dg/pr55831.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55831.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/55831] [4.8 Regression] ICE: verify_flow_info failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55831 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-01 13:59:00 UTC --- Fixed.
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 07:30:55 UTC --- http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01179.html
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rakdver at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 08:24:34 UTC --- I wonder if that isn't unnecessarily pessimizing, plus it won't catch all cases anyway, steps can be added etc. afterwards, in the extend_mode/comp_mode. The following fixes the ICE for me too, the second hunk is supposedly not enough, because in some places afterwards we e.g. count inc from iv0.step and iv1.step directly, plus for say comp_mode SImode and mode QImode with iv0.step 256 we supposedly want to bail out early (infinite loop or zero iterations). --- gcc/loop-iv.c.jj2012-10-22 08:42:25.0 +0200 +++ gcc/loop-iv.c2013-01-02 09:17:42.215591646 +0100 @@ -2406,6 +2406,9 @@ iv_number_of_iterations (struct loop *lo iv1.step = const0_rtx; } + iv0.step = lowpart_subreg (mode, iv0.step, comp_mode); + iv1.step = lowpart_subreg (mode, iv1.step, comp_mode); + /* This is either infinite loop or the one that ends immediately, depending on initial values. Unswitching should remove this kind of conditions. */ if (iv0.step == const0_rtx iv1.step == const0_rtx) @@ -2516,6 +2519,7 @@ iv_number_of_iterations (struct loop *lo step = simplify_gen_unary (NEG, comp_mode, iv1.step, comp_mode); else step = iv0.step; + step = lowpart_subreg (mode, step, comp_mode); delta = simplify_gen_binary (MINUS, comp_mode, iv1.base, iv0.base); delta = lowpart_subreg (mode, delta, comp_mode); delta = simplify_gen_binary (UMOD, mode, delta, step);
[Bug middle-end/55832] [4.8 Regression] ICE in fold_convert_loc, at fold-const.c:1967
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55832 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 #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 09:07:06 UTC --- Created attachment 29072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29072 gcc48-pr55832.patch Indeed, and omit_one_operand_loc can deal with converting integer_zero_node to a zero vector, but can't cope with converting integer_one_node into a constant boolean true vector. I've slightly adjusted the testcase, so that it at least doesn't violate strict aliasing, unfortunately without the uninitialized c it doesn't trigger. And I couldn't find a way to create ABS_EXPR of vectors using vector types directly.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 09:43:29 UTC --- The formatting in the patch is wrong (multiple issues). I don't see a point in the __atomic_load_n (addr, MEMMODEL_RELAXED), for aligned ints or pointers the loads are atomic on all architectures libgomp is supported on, after all kernel is also using just a normal load in the futex syscall, not __atomic_load_n (which expands to the normal load only anyway).
[Bug middle-end/23868] [4.6/4.7/4.8 regression] builtin_apply uses wrong mode for multi-hard-register return values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 17:55:14 UTC --- SH is neither primary nor secondary target.
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 21:07:21 UTC --- Could you please do an extra merge soon, even before switching the default? You've raised some cases where on ubuntu _Unwind_* based backtrace wasn't accurrate, it would be nice to check it out on other distros and find out the reason. BTW, glibc backtrace(3) on i?86 (32-bit only) uses a combination of _Unwind_* based backtrace for as long as unwind info is provided, and then grabs ebp from the unwind info at the outermost frame before unwind info isn't provided, and from there attempts to use the fast backtrace method (for cases where older i?86 code when gcc still didn't default to asynchronous unwind tables on i?86 calls newer code where gcc defaults to it). On x86_64 this isn't done, as asynchronous unwind tables have been the default basically for the whole support of the architecture.
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 21:17:01 UTC --- Assuming fixed.
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 08:52:17 UTC --- Author: jakub Date: Thu Jan 3 08:52:10 2013 New Revision: 194834 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194834 Log: PR debug/54402 * params.def (PARAM_MAX_VARTRACK_REVERSE_OP_SIZE): New param. * var-tracking.c (reverse_op): Don't add reverse ops to VALUEs that have already PARAM_VALUE (PARAM_MAX_VARTRACK_REVERSE_OP_SIZE) or longer locs list. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def trunk/gcc/var-tracking.c
[Bug middle-end/55832] [4.8 Regression] ICE in fold_convert_loc, at fold-const.c:1967
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55832
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03
09:02:51 UTC ---
Author: jakub
Date: Thu Jan 3 09:02:41 2013
New Revision: 194836
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194836
Log:
PR tree-optimization/55832
* fold-const.c (fold_binary_loc): For ABS_EXPRx = 0 and
ABS_EXPRx 0 folding use constant_boolean_node instead of
integer_{one,zero}_node.
* gcc.c-torture/compile/pr55832.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr55832.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 09:05:49 UTC --- Author: jakub Date: Thu Jan 3 09:05:43 2013 New Revision: 194837 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194837 Log: PR rtl-optimization/55838 * loop-iv.c (iv_number_of_iterations): Call lowpart_subreg on iv0.step, iv1.step and step. * gcc.dg/pr55838.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55838.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/55832] [4.8 Regression] ICE in fold_convert_loc, at fold-const.c:1967
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55832 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-03 09:09:58 UTC --- Fixed.
[Bug rtl-optimization/55838] [4.6/4.7 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 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] ICE in |ICE in extract_insn |extract_insn |(unrecognizable insn) with |(unrecognizable insn) with |-O -funroll-loops |-O -funroll-loops Known to fail|4.8.0 | --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 09:10:46 UTC --- Fixed for trunk so far.
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|c |middle-end --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 14:47:37 UTC --- The C FE is innocent, it has TYPE_SIZE_UNIT nop_expr sizetype something. The problem is in the gimplifier, gimplify_one_sizepos, because sizetype is types_compatible_p with the ENUMERAL_TYPE (with -m32), replaces the sizetype typed TYPE_SIZE_UNIT with the enumeral one. So, either we'd need to special case this in gimplify_one_sizepos or so and if it turns an INTEGER_TYPE expr into something with different type TREE_CODE, do something (what exactly? If we turn it into a NOP_EXPR of the VAR_DECL, it will not satisfy is_gimple_sizepos and we'll try to regimplify it again and again, or shall we adjust is_gimple_sizepos too to allow that special case of a NOP_EXPR of is_gimple_sizepos if the types are compatible?). Or adjust whatever code is assuming that TYPE_SIZE_UNIT must be INTEGER_TYPE.
[Bug inline-asm/55864] Optimization cause asm code to wrong behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55864 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-03 15:29:27 UTC --- The testcase is buggy. You aren't telling the compiler you are modifying the %mm0 and %mm1 registers (why you do anything with MMX at this point BTW? that is simply a very bad idea), and even if you did, you can't expect the registers to keep their values in between the different inline asm statements, you aren't using the required emms for MMX (and not telling the compiler that you are invalidating the whole i387 register state), and the operands of the second inline asm are completely bogus.
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 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 #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 15:32:16 UTC --- Created attachment 29078 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29078 gcc48-pr55851.patch Untested patch (which I don't like very much, but we can't even use something like get_initialized_tmp_var which would strip the cast as useless too).
[Bug libstdc++/55866] New: [4.8 Regression] #include auto_ptr.h in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866 Bug #: 55866 Summary: [4.8 Regression] #include auto_ptr.h in C++11 mode Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org echo '#include auto_ptr.h' | g++ -std=gnu++0x -S -o /tmp/a.s -xc++ - worked in 4.7, but doesn't work any longer in 4.8. Apparently the snapper package does this in one of the translation units (no idea why). Is that an error in the package and it isn't supposed to include that header, or is that something to fix on the libstdc++ side? The problem started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=190109 where auto_ptr.h relies on a couple of headers it doesn't include itself (so _Lock_policy, __shared_count etc. aren't defined).
[Bug libstdc++/55866] [4.8 Regression] #include auto_ptr.h in C++11 mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55866 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-03 17:10:07 UTC --- I have no problem with that, just noticed this during mass rebuild with gcc 4.8 and wanted to double check where the bug is.
[Bug tree-optimization/55875] New: [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875
Bug #: 55875
Summary: [4.8 Regression] IVopts caused miscompilation
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
The following testcase is miscompiled at -O3 on x86_64-linux starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=192989
(ok, that revision doesn't compile, needs r192900 follow-up).
struct A
{
short int a1;
unsigned char a2;
unsigned int a3;
};
struct B
{
unsigned short b1;
const A *b2;
};
B b;
__attribute__((noinline, noclone))
int foo (unsigned x)
{
__asm volatile ( : +r (x) : : memory);
return x;
}
inline void
bar (const int )
{
}
__attribute__((noinline)) void
baz ()
{
const A *a = b.b2;
unsigned int i;
unsigned short n = b.b1;
for (i = 0; i n; ++i)
if (a[i].a1 == 11)
{
if (i 0 (a[i - 1].a2 1))
continue;
bar (foo (2));
return;
}
}
int
main ()
{
A a[4] = { { 10, 0, 0 }, { 11, 1, 0 }, { 11, 1, 0 }, { 11, 1, 0 } };
b.b1 = 4;
b.b2 = a;
baz ();
return 0;
}
In *.slp we have:
bb 5:
if (i_21 != 0)
goto bb 6;
else
goto bb 7;
bb 6:
_11 = i_21 + 4294967295;
_12 = (long unsigned int) _11;
_13 = _12 * 8;
_14 = a_4 + _13;
_15 = _14-a2;
but ivopts turns that into:
bb 5:
i_25 = (unsigned int) ivtmp.9_31;
if (i_25 != 0)
goto bb 6;
else
goto bb 7;
bb 6:
_28 = ivtmp.9_31 * 8;
_27 = a_4 + _28;
_26 = _27 + 34359738362;
_15 = MEM[base: _26, offset: 0B];
which is wrong, i_21 + -1U wrapped around (and wasn't executed for i_21 being
0), while 34359738362 is 0xULL * 8 + 2, thus it ignores the wrapping
and does what the original code would do for
_12 = (long unsigned int) i_21;
_77 = _12 + 4294967295;
_13 = _77 * 8;
i.e. as if the -1U addition was done in the wider precision.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-04 12:24:12 UTC --- ssa name _12 type long unsigned int base 4294967295 step 1 ssa name _13 type long unsigned int base 34359738360 step 8 ssa name _14 type const struct A * base a_4 + 34359738360 step 8 base object (void *) a_4 all look wrong to me, it ignores the wrapping in the narrower type. OT, I wonder why number of iterations analysis doesn't figure out smaller number: Analyzing # of iterations of loop 1 exit condition [1, + , 1] (unsigned int) n_5 bounds on difference of bases: 0 ... 4294967294 result: # of iterations (unsigned int) n_5 + 4294967295, bounded by 4294967294 The loop condition is: i_18 = i_21 + 1; if (i_18 _20) and _20 is: _20 = (unsigned int) n_5; where short unsigned int n; thus, I'd thought we should figure out from that that i_18 will be at most 0x (highest possible n_5 is 0x). But that is 4.9 material likely, while the ivopts? bug is a severe 4.8 issue.
[Bug c++/55877] New: [4.6/4.7/4.8 Regression] Anon visibility issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55877
Bug #: 55877
Summary: [4.6/4.7/4.8 Regression] Anon visibility issues
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
typedef struct {
typedef enum { X, Y } A;
typedef struct { } B;
struct C { };
} D;
void foo (D) {}
void foo (D::A) {}
void foo (D::B) {}
void foo (D::C) {}
Starting with PR54883 the foo (D::A) gets anon visibility, in 4.4 all 4 foo
functions had default visibility, starting with 4.5 the last two had anon
visibility.
[Bug c++/55877] [4.6/4.7/4.8 Regression] Anon visibility issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55877 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug c/25702] feature request: generate a warning for sizeof on a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702 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-04 15:55:13 UTC --- See -Wsizeof-pointer-memaccess warning added in GCC 4.8. Currently it only warns about a handful of builtin functions there is no attribute to annotate user functions if they want similar behavior, but at least for various memory/string functions, s*printf etc. you'll get warnings.
[Bug c++/55877] [4.6 Regression] Anon visibility issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55877
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-04
17:07:55 UTC ---
The reason for listing 4.6 was that the PR54883 change has been applied to 4.6
branch fairly recently, making it for the enum case a recent 4.6 regression.
BTW, what about:
typedef struct {
typedef enum { X, Y } A;
typedef struct { } B;
struct C {
static void fn1 (B) { }
static void fn2 (C) { }
};
} D;
void foo (D) {}
void foo (D::A) {}
void foo (D::B) {}
void foo (D::C) {}
void *p = (void *) D::C::fn1;
void *q = (void *) D::C::fn2;
which is still rejected even with this patch?
error: anonymous type with no linkage used to declare function ‘static
voidanonymous struct::C::fn1(anonymous struct::B)’ with linkage
[-fpermissive]
and similarly for fn2. If typedef struct { is changed to typedef struct D {
on the first line, it compiles just fine and everything is exported.
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/55878] New: [4.7/4.8 Regression] --enable-checking=yes rejection of typeid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55878
Bug #: 55878
Summary: [4.7/4.8 Regression] --enable-checking=yes rejection
of typeid
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org
// { dg-do compile }
// { dg-options -std=gnu++0x }
#include typeinfo
struct S;
template typename T
static bool fn (S *s)
{
return typeid (*s) == typeid (T);
}
struct S
{
};
bool x = fnS (__null);
is rejected with --enable-checking=yes compilers (but accepted with release
checking compilers), starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=173679
Is this code valid C++ or not, i.e. is the FE allowed to warn about incomplete
types even in the uninstantiated template?
[Bug libstdc++/55594] [4.8 Regression] -Wa,-nH incorrectly added to compile line of all targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55594 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-06 15:10:01 UTC --- So, can we restrict the -Wa,-nH check to *-*-solaris*, or do also say -Wa,-V or whatever with Solaris as prints version and scan its output?
[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
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07
12:50:56 UTC ---
Guess related to -fintrinsic-module-path.
In some spots it still has the right argument:
-fintrinsic-modules-path /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgomp
but in other spots that argument is gone:
-fintrinsic-modules-path -B ...
thus -B is taken as -fintrinsic-modules-path argument and the original -B
argument is considered another source file.
Can you try perhaps:
--- libgomp/testsuite/libgomp.fortran/fortran.exp2012-12-20
11:38:48.663282599 +0100
+++ libgomp/testsuite/libgomp.fortran/fortran.exp2013-01-07
13:45:51.557361907 +0100
@@ -14,7 +14,7 @@ set quadmath_library_path ../libquadmat
dg-init
if { $blddir != } {
-lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path
${blddir}
+lappend ALWAYS_CFLAGS additional_flags=-fintrinsic-modules-path${blddir}
# Look for a static libgfortran first.
if [file exists ${blddir}/${lang_library_path}/libgfortran.a] {
set lang_test_file ${lang_library_path}/libgfortran.a
? Though, I'd say using Joined Separate for such named option is just wrong,
it is fine for single letter options like -B, -A, -D, -U etc., but for options
of this kind I think it would be much better if it was
fintrinsic-modules-path
Fortran RejectNegative Separate
Specify where to find the compiled intrinsic modules
fintrinsic-modules-path=
Fortran RejectNegative Joined
Specify where to find the compiled intrinsic modules
instead and handle OPT_fintrinsic_modules_path_ the same as
OPT_fintrinsic_modules_path. But given that the option has been added already
back in 2007, it is probably too late for that.
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07 12:55:39 UTC --- But that is not a requirement. The requirement is using a C++ compiler that works out of the box (compiler configured in a path where its shared libraries aren't found by the dynamic linker isn't), or making sure through LD_LIBRARY_PATH or tweaking spec (to add -rpath) that the compiler works out of the box, or compiler which supports -static-libstdc++.
[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07 13:01:38 UTC --- .
[Bug target/55894] No constant propagation in Intel intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55894
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-07
14:25:33 UTC ---
The reason why it doesn't happen during combine is that the insns don't allow
constants, they require loads from memory, so while the compiler is aware
of the folded constant, e.g. in the g function:
(insn 12 7 15 2 (set (reg/i:V2DF 21 xmm0)
(subreg:V2DF (reg:V2DI 65 [ D.4526 ]) 0)) pr55894.c:16 1157
{*movv2df_internal}
(expr_list:REG_DEAD (reg:V2DI 65 [ D.4526 ])
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF +QNaN [+QNaN])
(const_double:DF +QNaN [+QNaN])
])
(nil
it fails to match and thus isn't actually used in the code. A pass that would
see you load a constant from memory, do some transformations on it which are
all foldable by the compiler and transforming that into just load of a
different constant could handle this (or do it in combine?), but the problem
with that is that it could in theory increase the constant pool too much.
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07 14:51:26 UTC --- I don't see any differences in assembly, when I compile either version of random.i with -std=gnu99 -fcx-fortran-rules -g -O2 with a r189365 vs. r189366 x86_64-linux - hppa2.0w-hp-hpux11.11 cross. Can try i686-linux - hppa2.0w-hp-hpux11.11 cross in case it is HWINT related...
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07
16:34:14 UTC ---
Ah, ok, seems indeed to be HWI size related and also (due to an earlier bug)
related to the revision you've mentioned.
So, with an i686-linux - hppa2.0w-hp-hpux11.11 cross this is reproduceable
with -O2 on:
extern unsigned int *kiss_seed_1;
extern unsigned int *kiss_seed_2;
unsigned int kiss_random_kernel(unsigned int * seed);
void
foo (double *x)
{
unsigned long long mask, kiss = ((unsigned long long) kiss_random_kernel
(kiss_seed_1)) 32;
kiss += kiss_random_kernel (kiss_seed_2);
mask = ~ (unsigned long long) 0u (64 - 53);
kiss = kiss mask;
*x = (double) kiss * (0x1.p-64);
}
and the problem is that starting with r189366 VRP incorrectly does:
kiss_9 = kiss_8 0xf800;
- D.1358_10 = (double) kiss_9;
+ D.1363_17 = (signed int) kiss_9;
+ D.1358_10 = (double) D.1363_17;
The bugs seem to be in simplify_float_conversion_using_ranges and
range_fits_type_p. The simplify_float_conversion_using_ranges bug (now just
code consistency issue, before r189366 a real bug) is that the second
can_float_p is tested for != 0 (implicitly) instead of != CODE_FOR_nothing.
Starting with r189366 it doesn't make a real difference, before that
CODE_FOR_nothing was some big number and this fact hid the other bug.
From the kiss_9 assignment, VRP determines vr to be
[0, 0xf800]
(in unsigned long long type).
And now the bug is that while range_fits_type_p (vr, 8, 0) and
range_fits_type_p (vr, 64, 0) correctly return false, such big 64-bit range
really doesn't fit into signed 8-bit or signed 64-bit range,
range_fits_type_p (vr, 16, 0) and range_fits_type_p (vr, 32, 0) incorrectly
return true - and for floatsidf2 there is a pattern, which is why we miscompile
it.
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-07 17:27:56 UTC --- Created attachment 29100 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29100 gcc48-pr54120.patch So, I wrote a fix against r189366, only to find out that Richard Sandiford already fixed it the same way (just different comment): http://gcc.gnu.org/viewcvs?root=gccview=revrev=194800 I'm thus attaching just the unimportant other two changes (unimportant because right now range_fits_type_p is always called with unsigned_p = false (so the first problem never happens, the issue is that while say unsigned 8-bit src_type always fits into signed 16-bit, the same isn't true for signed 8-bit src_type and unsigned 16-bit - if min or max is negative in the signed type, it won't fit). And the second issue is after r189366 only pure consistency issue, as CODE_FOR_nothing is always 0. I'd say after with r194800 or later you shouldn't get this failure.
[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
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08
08:13:02 UTC ---
On HP-UX or Linux? The test is guarded with
! { dg-require-effective-target tls_runtime }
does the OS have assembly/linker and runtime TLS support?
Can you attach libgomp.log ?
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:14:12 UTC --- Author: jakub Date: Tue Jan 8 08:14:04 2013 New Revision: 195005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195005 Log: PR sanitizer/55844 * c-c++-common/asan/null-deref-1.c: Add -fno-shrink-wrap to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/null-deref-1.c
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:32:21 UTC --- Author: jakub Date: Tue Jan 8 08:32:12 2013 New Revision: 195006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195006 Log: PR middle-end/55851 * fold-const.c (int_binop_types_match_p): Allow all INTEGRAL_TYPE_P types instead of just INTEGER_TYPE types. * gcc.c-torture/compile/pr55851.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55851.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:33:50 UTC --- Author: jakub Date: Tue Jan 8 08:33:43 2013 New Revision: 195007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195007 Log: PR tree-optimization/54120 * tree-vrp.c (range_fits_type_p): Don't allow src_precision precision from signed vr to unsigned_p if vr-min or vr-max is negative. (simplify_float_conversion_using_ranges): Test can_float_p against CODE_FOR_nothing. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/55890] [4.7 Regression] calling a builtin func through a cast triggers an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55890 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:38:58 UTC --- Author: jakub Date: Tue Jan 8 08:38:50 2013 New Revision: 195008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195008 Log: PR middle-end/55890 * tree-ssa-ccp.c (evaluate_stmt): Use gimple_call_builtin_p. * gcc.dg/torture/pr55890-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr55890-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:44:44 UTC --- Worked around, likely going to be fixed with switch to unwind based backtrace for fatal backtraces.
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 08:45:27 UTC --- Fixed.
[Bug middle-end/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:08:58 UTC --- Fixed.
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 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-08 09:13:12 UTC --- I'd say GFC_PREFIX wouldn't improve this, I'd keep using $ unless NO_DOLLAR_IN_LABEL, otherwise fallback to . if NO_DOT_IN_LABEL and as last fallback use _ in this case.
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:41:29 UTC --- Fine with me. Just a note, sprintf (dt_name, %s, STAR); would be better written as strcpy (dt_name, STAR);
[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 09:58:05 UTC --- Created attachment 29103 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29103 gcc48-pr55829.patch Yeah, comparing the vec_dupv2df and *vec_concatv2df patterns shows that for the former we accept for sse3 but not avx x - 0, x - x and x - m, while for the latter only x - 0, x and x - m, 1 and not x - x, 1, when movddup has 2 different register arguments. With this change it doesn't ICE anymore, even when it actually doesn't emit that form of movddup (the vec_concat of 2x (reg:DF 62) pseudo where (reg:DF 62) is assigned r12 (it is used in the following loop which contains calls), it is LRA reloaded into two stores of r12 into mem, once loaded into xmm1 and used from mem, i.e. for whatever reason the x - 0, m alternative is chosen, but postreload then turns it into movddup with both arguments xmm1 (x - 0, 0). I think this patch can be useful and does give the RA more freedom, but it is unclear whether it doesn't make some LRA bug latent. Vlad?
[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 10:02:16 UTC --- BTW, there is a slight inconsistency between the two patterns, the first pattern uses sselog1 type for both the unpckldp %0, %0 and %vmovddup %1, %0 and V2DFmode mode attribute, while the second pattern uses sselog type for both of those and DFmode mode attribute for the movddup case.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||steven at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 11:03:50 UTC --- Broken by Steven's PCH changes. http://gcc.gnu.org/viewcvs?root=gccview=revrev=188856 http://gcc.gnu.org/viewcvs?root=gccview=revrev=189482 (from r188856 to r189481 this ICEd, afterwards it just results in assembly comparison differences. Can be reproduced even on x86_64-linux, e.g. with make check-gcc RUNTESTFLAGS='--target_board=unix/-m32/-gstabs pch.exp=decl-3*' The saving/restoring of assembly directives has been there clearly for a reason, so needs to be replaced or the changes reverted. Not sure if stabs + PCH warrants a P1 regression though.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 11:27:12 UTC --- The problem is that dbxout.c (unlike dwarf2out.c; not sure about other debug backends) emits assembly immediately into asm_out_file, pretty much everywhere, instead of creating data structures from it and emitting everything only during the finish debughook. So, if you'd like to avoid reversion of the patch, I'm afraid you'd pretty much need to implement the same thing, at least for dbxout (that, in between pch_init (but not earlier, you don't want to duplicate the stabs created before that) and pch_write the stabs will be say queued into some GC memory block and that GC memory block will be printed into assembly upon reading of pch or so. I doubt fmemopen or similar is portable enough, so you'd need to rewrite all the dbxout.c code that right now uses fwrite/fputc/putc etc. to use some other interfaces and conditionally either append to the GC string, or write into asm_out_file. Or rewrite dbxout.c to queue up everything, not sure if it wouldn't break anything if emitted at the end of assembly though.
[Bug middle-end/55889] [4.8 Regression] ICE: in move_op_ascend, at sel-sched.c:6153 with -fschedule-insns -fselective-scheduling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55889 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-08 12:19:16 UTC --- Can't reproduce (with a cross). Is this when compiling 32-bit or 64-bit? What kind of CPU tuning by default?
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 12:42:06 UTC --- dbxout.c already defines a handle_pch hook, so it is apparently told when pch_init and write_pch are called, so in theory this could be handled in dbxout.c only (still, the question is if other debug backends don't have similar issue).
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 13:28:56 UTC --- Note this isn't limited to dbxout.c, pretty much all *out.c debug backends but dwarf2out.c suffer from these issues, they all emit assembly immediately, only dwarf2out.c just creates data structures to be used later on.
[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||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 13:42:30 UTC --- Caused by http://gcc.gnu.org/PR49673 I believe. Perhaps instead of testing whether TYPE_NEEDS_CONSTRUCTING we need to check if the type has non-trivial destructor (is a user destructor on const qualified vars allowed to store into the var anywhere?) or just a special case virtual dtors that do change the vtable pointer?
[Bug c/48418] [4.6/4.7/4.8 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 14:44:51 UTC --- Created attachment 29104 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29104 gcc48-pr48418.patch Untested fix. To avoid warning twice, this warns in c_fully_fold_internal only if orig_op1 isn't INTEGER_CST, but op1 is. And on the testcase I found that in 4.8 my SIZEOF_EXPR C++ changes regressed the testcase too.
[Bug tree-optimization/48189] [4.6/4.7/4.8 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 15:02:52 UTC --- Created attachment 29105 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29105 gcc48-pr48189.patch I'd say this isn't difficult to solve enough to warrant having it open for years.
[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 #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 15:16:52 UTC --- But then, won't the exact same issues potentially happen in very large functions where ira_conflicts_p isn't also true, because the conflict table would be too big? I'd say zero MB conflict table is reasonable parameter value, it says don't use the conflict table. If table larger than the param would be needed, no table is created at all.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 --- Comment #48 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:02:13 UTC --- Author: jakub Date: Tue Jan 8 17:01:58 2013 New Revision: 195025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195025 Log: PR fortran/55341 * asan.c (asan_clear_shadow): New function. (asan_emit_stack_protection): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #49 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:17:26 UTC --- Fixed.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 17:51:10 UTC --- All that to avoid one #include output.h in one file? That doesn't seem appropriate to me. I'm not questioning it is a desirable change, but I'd reapply it only when all the *out.c backends are converted to emit delayed info, or when (if ever) a dwarf2 - something else converters are written.
[Bug rtl-optimization/55845] [4.8 Regression] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:00:30 UTC --- Author: jakub Date: Tue Jan 8 18:00:10 2013 New Revision: 195028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195028 Log: PR rtl-optimization/55845 * df-problems.c (can_move_insns_across): Stop scanning at volatile_insn_p source instruction or give up if across_from .. across_to range contains any volatile_insn_p instructions. * gcc.target/i386/pr55845.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55845.c Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55845] [4.8 Regression] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:03:48 UTC --- Fixed.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-08 18:27:44 UTC --- FYI, the execute/pr55875.c with -O1 started failing with http://gcc.gnu.org/viewcvs?root=gccview=revrev=138207 aka tuples merge.
[Bug tree-optimization/48189] [4.6/4.7/4.8 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 09:00:32 UTC --- Author: jakub Date: Wed Jan 9 09:00:22 2013 New Revision: 195046 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195046 Log: PR tree-optimization/48189 * predict.c (predict_loops): If max is 0, don't call compare_tree_int. If nitercst is 0, don't predict the exit edge. * gcc.dg/pr48189.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48189.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/48189] [4.6/4.7 Regression] ICE: SIGFPE (division by zero) in in predict_loops () at predict.c:991 with --param max-predicted-iterations=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189 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] ICE: |ICE: SIGFPE (division by|SIGFPE (division by zero) |zero) in in predict_loops |in in predict_loops () at |() at predict.c:991 with|predict.c:991 with --param |--param |max-predicted-iterations=0 |max-predicted-iterations=0 | --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 09:03:38 UTC --- Fixed on the trunk so far.
[Bug fortran/55916] New: Alignment issues with real(16) on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 Bug #: 55916 Summary: Alignment issues with real(16) on i686 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org The following testcase with -m32 -msse4 -g -O3 -fno-inline may segfault (depending on whether malloc returns just 8-byte or 16-byte aligned pointer). real(16), allocatable :: (:) real(16) :: x(10) integer :: i,n=10 allocate((n)) do i = 1,n (i) = 8.0 enddo call foo () deallocate() contains subroutine foo () real(16), allocatable :: (:) (1) = (1) + 1 end subroutine end The problem is that __float128 aka real(16) has alignment 128 bits, but on i686-linux malloc only guarantees 64 bit alignment (2 * sizeof (void *) byte alignment). As __float128 is outside of the scope of C/C++, this is not a bug on the C library side. Guess for real(16) allocatables or any allocatables that require alignment bigger than that of standard types Fortran should use posix_memalign (or perhaps some libgfortran wrapper) that will be passed not just the size to allocate, but also required alignment.
[Bug c/48418] [4.6/4.7/4.8 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 14:51:17 UTC --- Author: jakub Date: Wed Jan 9 14:51:09 2013 New Revision: 195051 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195051 Log: PR c/48418 * c-common.c (c_fully_fold_internal): Warn for LSHIFT_EXPR and RSHIFT_EXPR, if orig_op1 isn't INTEGER_CST, op1 is INTEGER_CST and is either negative or bigger or equal to type precision of the first operand. * typeck.c (cp_build_binary_op): For LSHIFT_EXPR and RSHIFT_EXPR, call maybe_constant_value for the negative or too big shift count warnings. * c-c++-common/pr48418.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr48418.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/48418] [4.6/4.7 Regression] Bit shift operator =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48418 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Bit |Bit shift operator = |shift operator = --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 15:03:09 UTC --- Warning regression fixed for 4.8+ for now.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 15:13:20 UTC --- Fixed, thanks.
[Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 16:35:13 UTC --- Yes, but I'd say under a different PR.
[Bug tree-optimization/55920] 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 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 17:47:08 UTC --- Seems the bug is that the DEBUG stmt created by SRA has var_decl 0x719a4e40 from$s_addr type integer_type 0x71996690 unsigned int sizes-gimplified asm_written public unsigned SI as the first operand, but mem_ref 0x717e0f78 type record_type 0x717df1f8 in_addr sizes-gimplified asm_written no-force-blk packed type_0 BLK as the second operand (note the first one is SImode, the latter BLKmode). Perhaps the packed attribute is what causes this, dunno. But we probably just shouldn't emit a debug stmt if the mode is different, unless we can e.g. use a COMPONENT_REF on it to get at the right mode. Also, as the aggregate is actually used (in the call stmt a few stmts later), I'd say SRA shouldn't emit the debug stmts for it at all, ideally for PR55579 we'd emit those only either if we'd SRA it anyway in the code (disregarding debug), or if we have just stores but no uses of the aggregate. Right now on trunk every SRA pass adds another set of debug stmts, because the aggregate assignments aren't DCEd (as they are used). Looking at this, perhaps we should defer PR55579 resolution for stage1 of 4.9, so we have more time to e.g. think about some size limits what we still emit as debug stmts and what not, etc. Martin, what are your thoughts?
[Bug rtl-optimization/55829] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 17:49:56 UTC --- Fixed, thanks.
[Bug middle-end/55921] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-09 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 18:38:04 UTC --- expand_complex_operations_1 needs to handle inline asm like expand_complex_move.
[Bug middle-end/55921] [4.6/4.7/4.8 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Last reconfirmed|2013-01-09 00:00:00 | AssignedTo|jakub at gcc dot gnu.org|unassigned at gcc dot ||gnu.org Target Milestone|--- |4.6.4 Summary|Crash in verify_ssa for asm |[4.6/4.7/4.8 Regression] |to side-steps complex |Crash in verify_ssa for asm |pessimization |to side-steps complex ||pessimization Ever Confirmed|1 |0 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 20:29:03 UTC --- For -O0 this regressed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=160903 for -O2 the ICE started between r10 and r102000.
[Bug middle-end/55921] [4.6/4.7/4.8 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-01-09 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-09 20:31:36 UTC --- Created attachment 29131 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29131 gcc48-pr55921.patch Untested fix.
[Bug middle-end/55921] [4.6/4.7/4.8 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 09:25:27 UTC --- Author: jakub Date: Thu Jan 10 09:25:12 2013 New Revision: 195080 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195080 Log: PR tree-optimization/55921 * tree-complex.c (expand_complex_asm): New function. (expand_complex_operations_1): Call it for GIMPLE_ASM. * gcc.c-torture/compile/pr55921.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55921.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-complex.c
[Bug middle-end/55921] [4.6/4.7 Regression] Crash in verify_ssa for asm to side-steps complex pessimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] Crash |Crash in verify_ssa for asm |in verify_ssa for asm to |to side-steps complex |side-steps complex |pessimization |pessimization --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 09:31:53 UTC --- Fixed for 4.8+ so far.
[Bug inline-asm/55934] New: [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
Bug #: 55934
Summary: [4.8 Regression] LRA inline asm error recovery
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
_Complex float
foo (void)
{
_Complex float x;
__asm ( : =x (x)); /* { dg-error impossible register constraint } */
return x;
}
on x86_64 used to ICE since the introduction of LRA (before that it has been
just issuing error on the asm). Starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=193871
this got fixed, but already (guess) starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=193901
it issues both the expected error and also ICE after it.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ra Priority|P3 |P2 CC||vmakarov at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug tree-optimization/32306] [4.6/4.7/4.8 Regression] redundant || not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 11:26:09 UTC --- It generally depends on the branch cost, e.g. out of #c19 testcase on x86_64 we generate: D.1729 = b1 != 0; D.1730 = b2 != 0; D.1731 = D.1729 D.1730; if (D.1731 != 0) goto D.1732; else goto D.1727; D.1732: D.1733 = b3 != 0; D.1734 = b4 != 0; D.1735 = D.1733 D.1734; if (D.1735 != 0) goto D.1736; else goto D.1727; D.1736: etc., but on other targets it could have just one comparison per conditional jump, or on the other side 4. While the tests don't have side-effects, turning too many s into s wouldn't result in very good code, though of course would make it easier to perform some optimizations. Anyway, you can write it in the source as a series of ifs: array[0] = 1; if (!b1) array[0] = 0; else if (!b2) array[0] = 0; else if (!b3) array[0] = 0; ... and we wouldn't be able to optimize it anyway.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #35 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 11:37:08 UTC --- For config/posix it is not that easy, because you can't assume that atomics are available. You'd need to guard it with #ifdef HAVE_SYNC_BUILTINS and do something else (nothing?) otherwise. Those targets don't support tsan anyway...
[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 CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 16:29:17 UTC --- Supposedly ADDR_EXPR is shared between several functions or something similar.
[Bug tree-optimization/52448] [4.6/4.7/4.8 Regression] cselim broken with calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10 16:49:26 UTC --- Any progress with this?
[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|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
09:18:41 UTC ---
Created attachment 29142
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29142
gcc48-pr55935.patch
Untested fix. Although the FE perhaps could unshare_expr_without_location so
that ADDR_EXPRs in the ctor don't have location, IMHO gimple-fold.c still has
to at least unshare_expr those expressions it copies from the constructors,
otherwise we'll end up with invalid sharing of ADDR_EXPRs etc. between
different functions (or within the same function).
This can be reproduced even with C:
void foo (void);
struct S { int i; void (*fn) (); };
const struct S s = { 5, foo };
void *fn1 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn2 (int x) { if (x 0) return s.fn; if (x) return 0; return s.fn; }
void *fn3 (void) { return s.fn; }
void *fn4 (void) { return s.fn; }
at -O2, in *.copyrename1 pass all 6 ADDR_EXPRs in the IL are still shared.
ccp1 for whatever reason unshares them all (surprisingly).
[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 #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 10:03:09 UTC --- Created attachment 29143 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29143 gcc48-pr55935.patch Or alternative patch that ensures in the FE there are no locations in the ctor expressions, and just unshare_expr in the middle-end. But I tend to prefer the other patch.
[Bug rtl-optimization/55672] [4.8 Regression] -fstack-check=generic ICEs in print_reg, at config/i386/i386.c:13868
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 10:44:34 UTC --- Assuming fixed.
[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 #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 11:52:59 UTC --- Created attachment 29144 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29144 hackish attempt
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
12:59:33 UTC ---
Please also consider asm goto like:
void bar (int);
void
foo (_Complex float x)
{
asm volatile goto ( : : x (x) : : foo); /* { dg-error impossible
constraint } */
bar (1);
foo:
bar (2);
}
Turning a JUMP_INSN pattern into (use (const_int 0)) might not work well,
though apparently reload.c does that too. Perhaps it is lucky enough with it,
as if reload results in errors, following passes are skipped.
[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 #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 14:40:45 UTC --- Created attachment 29148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29148 gimple-fold Alternative to alternative canonicalize_constructor_val fix which I'm afraid could sometimes unshare up to 3 times. Or we could just tree orig_cval = cval = unshare_expr (cval); as the first thing in the function (and drop the unshare_expr in fold_gimple_assign of course).
[Bug target/55941] [4.8 Regression] Strange copy of double (in struct) to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-11 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 14:44:23 UTC --- This first regressed with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190492 into: movsd %xmm0, -8(%rsp) addsd %xmm2, %xmm0 and then we regress again with: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190847 into: addsd %xmm0, %xmm2 movsd %xmm0, -8(%rsp) movapd %xmm2, %xmm0
[Bug target/55941] [4.8 Regression] Strange copy of double (in struct) to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11
15:01:18 UTC ---
I'd hope that the subreg pass could be able to figure out something out of:
(insn 4 3 5 2 (set (reg:TI 63 [ x ])
(const_int 0 [0])) pr55941.c:2 85 {*movti_internal_rex64}
(nil))
(insn 5 4 6 2 (set (subreg:DF (reg:TI 63 [ x ]) 0)
(reg:DF 64 [ x ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 64 [ x ])
(nil)))
(insn 6 5 8 2 (set (subreg:DF (reg:TI 63 [ x ]) 8)
(reg:DF 22 xmm1 [ x+8 ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 22 xmm1 [ x+8 ])
(nil)))
(insn 8 6 9 2 (set (reg:DF 67 [ D.1730 ])
(reg:DF 23 xmm2 [ y ])) pr55941.c:2 131 {*movdf_internal_rex64}
(expr_list:REG_DEAD (reg:DF 23 xmm2 [ y ])
(nil)))
(note 9 8 12 2 NOTE_INSN_FUNCTION_BEG)
(insn 12 9 17 2 (set (reg:DF 67 [ D.1730 ])
(plus:DF (reg:DF 67 [ D.1730 ])
(subreg:DF (reg:TI 63 [ x ]) 0))) pr55941.c:2 785
{*fop_df_comm_sse}
(expr_list:REG_DEAD (reg:TI 63 [ x ])
(nil)))
(all accesses to pseudo 63 in the listed insns), but it only drops the insn 6,
but doesn't figure out the only user uses the low part and thus propagate the
setter. Or perhaps should forwprop propagate something like that?
[Bug debug/55608] [4.6/4.7/4.8/4.9 Regression] Debug info quality regressions with file scope vars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55608 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|4.6.4 |4.9.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7/4.8/4.9 |Debug info quality |Regression] Debug info |regressions with file scope |quality regressions with |vars|file scope vars --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 15:55:17 UTC --- Cary said on gcc-patches this is a stage1 material, so let's defer it for 4.9 then.
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-11 15:57:40 UTC --- So, what are we going to do with this? Defer for 4.9, or fix for 4.8?
