[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #4 from Jakub Jelinek --- On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #29 from Jakub Jelinek --- Friday 13th's test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #24 from Jakub Jelinek --- Yet another test. --- Comment #25 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #23 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #22 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #19 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #18 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #17 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #16 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #15 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #14 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #13 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #12 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #11 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #10 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #8 from Jakub Jelinek --- Yet another test. --- Comment #9 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #7 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #6 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #5 from Jakub Jelinek --- Yet another test.
[Bug c/93218] Test bug for testing git email integration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93218 --- Comment #4 from Jakub Jelinek --- Yet another test.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #12 from Jakub Jelinek jakub at redhat dot com --- On Mon, Oct 06, 2014 at 10:22:21PM +0200, Jan Hubicka wrote: this patch implements the lowring. Each call with warn attribute triggers code in cgraphunit that inserts call to bulitin_warning/error that is output at expansion time. Do we have way to define bulitin that is not user accessible? internal-fn* builtins are not user accessible. Jakub
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #14 from Jakub Jelinek jakub at redhat dot com --- On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote: Hi, I am testing this variant of the patch. For gcc-4.9 branch it may make sense to enable the new patch for LTO only. Not printing the inlining backtrace would be IMHO a significant regression. Jakub
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #16 from Jakub Jelinek jakub at redhat dot com --- On Tue, Oct 07, 2014 at 12:18:24AM +0200, Jan Hubicka wrote: On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote: Hi, I am testing this variant of the patch. For gcc-4.9 branch it may make sense to enable the new patch for LTO only. Not printing the inlining backtrace would be IMHO a significant regression. OK, how do I print it? I keep the BLOCK of the original expresison, so it is there. %K in the format string, assuming the call has locus with the right block, should do that. At least with -g, without -g or with LTO it will be less accurate. Jakub
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #46 from jakub at redhat dot com 2009-11-24 13:11 --- Subject: Re: [4.5 Regression] dsymutil Assertion failed ... assembly for problem object file in libssp.0.dylib that causes dsymutil to assert You forgot -dA, without that it is not very readable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug tree-optimization/34005] [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object)
--- Comment #8 from jakub at redhat dot com 2007-11-27 15:59 --- Subject: Re: [4.3 Regression] ICE: verify_ssa failed (expected an SSA_NAME object) I think the problems only appeared if allow_rhs_cond_expr was enabled for the gimplification pass (when called from the loop optimizer, the expressions passed to gimplifier do not have any side effects, so you would not detect any problem even if you removed the TREE_SIDE_EFFECTS check). Even then, what failure was it? gimplify_pure_cond_expr gimplifies all the 3 arguments anyway, so if they have side-effects, they just end up being evaluated into temporaries which are then used in the COND_EXPR. Anyway, can you please follow up to Diego's mail, either agree to remove that, or justify it? Apart from a typo in ChangeLog entry that was his only objection and it would be good to have this P1 fixed ASAP. yes, although making it work that way is more complicated; it would require changes in the # of iterations analysis, to get Ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34005
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
--- Comment #9 from jakub at redhat dot com 2007-11-02 14:24 --- The only at least partially workable way of linking statically against NPTL libpthread.a is -Wl,--whole-archive -lpthread -Wl,--no-whole-archive. There is just a huge amount of issues if you don't have everything in there in (e.g. the various cancellation wrappers, which for dynamically linked code can handle cancellation even in libc.so, but not so for the heavily unsupported static linking. Guess we should just change glibc Makefiles to ld -r all libpthread.a objects together and install that as libpthread.a instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
[Bug tree-optimization/33136] [4.1/4.2/4.3 Regression] wrong code due to alias with allocation in loop
--- Comment #18 from jakub at redhat dot com 2007-08-23 14:49 ---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On Thu, Aug 23, 2007 at 01:45:11PM -, dberlin at dberlin dot org wrote:
If you take address of the whole struct rather than some specific field and
that address doesn't escape the CU, then that still doesn't explain how
could a pointer var with first field's type point to the struct.
Say for
struct A { int i; float f; } you still need (int *) ptrA
Uh, no.
ptrA will do just fine. You can clobber all fields through it if it escapes.
See that address doesn't escape the CU above I wrote. But if so,
it will be in global_types_full_escape and so
ipa_type_escape_field_does_not_clobber_p will return false.
If ipa_type_escape_star_count_of_interesting_type (var_type) 0 (i.e. var
is
a pointer to struct/union rather than struct/union itself, how is the fact
that
something took address of fields within the struct itself relevant to
whether
some pointer may point to the pointer var or not?
If the address was never taken anywhere, it can't be pointed to.
Type-escape tries to go a little further, and see if, when the address
of a field is taken, if that address is ever cast'd,
incremented/decremented, or escapes. If not, then only that field is
clobbbered, not the entire structure. Otherwise, it is equivalent to
calculating TREE_ADDRESSABLE.
I was talking about say
struct S { int i; float f; struct S **s1; struct S ***s2; struct S s3; };
struct S ***var;
struct S ptr;
If we are asking whether
may_alias (ptr, get_alias_set (TREE_TYPE (TREE_TYPE (ptr))), var, get_alias_set
(var), false)
then we are only interested in whether var is TREE_ADDRESSABLE,
and this is IMHO exactly the same as asking in case of:
void ***var;
void ptr;
But in the former case ipa_type_escape_star_count_of_interesting_type
(var_type) == 3 and so we will call
ipa_type_escape_field_does_not_clobber_p, in the latter case
not. How are these two different?
In the c#8 testcase this is similar,
ipa_type_escape_star_count_of_interesting_type (var_type) == 1,
we have
struct S *var;
struct S **ptr;
again, why does it matter if *var is a struct or not? What matters
is if var is TREE_ADDRESSABLE, if there is no var, then it can't
point to it, otherwise it can. The same as for
void *var;
void **ptr;
But if var isn't TREE_ADDRESSABLE, I'd bet nothing ever calls
may_alias_p with it as third argument.
So, do you agree the only case may_alias_p should handle with
ipa_type_escape_field_does_not_clobber_p is
ipa_type_escape_star_count_of_interesting_type (var_type) == 0 ?
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
[Bug c++/28407] New: [4.2 regression] Issue with anonymous namespace
templateconst char *str
const char *baz ()
{
return str;
}
namespace { char foo[] = foo; };
const char *
bar ()
{
return bazfoo ();
}
used to compile before the make anon-namespace non-public changes and still
compiles when the anon namespace is changed for a named namespace and using
namespace below it.
--
Summary: [4.2 regression] Issue with anonymous namespace
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c++/28409] New: extern C and anonymous namespace
namespace
{
extern C int shouldIbevisible()
{
return 101;
}
}
extern C int Iamvisible()
{
return 101;
}
Is shouldIbevisible supposed to be a visible symbol outside of the current
compilation unit, so that other cu that does say
extern C int shouldIbevisible();
int foo () { return shouldIbevisible(); }
would link with it? If yes, we need to change determine_visibility and
push_namespace_with_attribs to take DECL_EXTERN_C_FUNCTION_P into account.
--
Summary: extern C and anonymous namespace
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #12 from jakub at redhat dot com 2006-07-17 12:21 --- The patch in #4 is insufficient. Consider paths like ././../.././../etc/passwd which satisfies the depth tests, yet clearly escapes the current dir tree. Another question is about symlinks, if there is a foo - ../../../../etc symlink in the current tree, then I believe fastjar will happily store foo/passwd into ../../../../etc/passwd, is that something that can be declared as user's fault or should fastjar always canonicalize the filename and don't allow leaving the current directory tree in any way? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #4 from jakub at redhat dot com 2006-07-17 20:04 --- Well, C++ implies unit-at-a-time, so when gimplifying we could very well change the TREE_PUBLIC bits of anon namespace objects. Till then this either could be always recomputed using decl_anon_ns_mem_p etc., or be stored in some new lang specific bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #95 from jakub at redhat dot com 2006-07-15 10:34 --- Can this be revisited now? namespaces now can have the visibility attribute, although it has to be present on each opening namespace. Guess sticking __attribute__((__visibility__(default))) into _GLIBCXX_BEGIN_NAMESPACE and similar macros could do the trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug fortran/28390] New: Broken !$omp parallel do lastprivate(iterationvar)
! see OpenMP 2.5 spec, page 64 and A.30 on page 175 program tst_lastpriv integer nc parameter (nc=100) integer a(nc),i !$omp parallel do lastprivate(i) do i=1,nc a(i) = i end do if (i.ne.nc+1) then print *,'failed, i=',i else print *,'success ',a(nc),i endif end fails with current trunk and -fopenmp. -- Summary: Broken !$omp parallel do lastprivate(iterationvar) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28390
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #23 from jakub at redhat dot com 2005-12-15 10:48 ---
The problem seems to be that strength_reduce - loop_givs_reduce reduces a giv
that is not always_computable (and as shown on the segfault, it really can't be
computed unconditionally).
p *bl-giv
$16 = {insn = 0x2dc389b0, new_reg = 0x2dc3d3e0, src_reg =
0x2dc30d60, giv_type = DEST_REG,
dest_reg = 0x2dc30da0, location = 0x0, mode = SImode, mem = 0x0, mult_val
= 0x2dc3b2c0, add_val = 0x2da5a400,
benefit = 16, final_value = 0x0, combined_with = 0, replaceable = 0,
not_replaceable = 0, ignore = 0, always_computable = 0,
always_executed = 0, maybe_multiple = 0, cant_derive = 1, maybe_dead = 0,
auto_inc_opt = 0, shared = 0, no_const_addval = 1,
lifetime = 18, derive_adjustment = 0x0, ext_dependent = 0x0, next_iv = 0x0,
same = 0x0, same_insn = 0x0, last_use = 0x0}
p debug_rtx (bl-giv-add_val)
(const_int 0 [0x0])
p debug_rtx (bl-giv-mult_val)
(mem:SI (reg/v/f:DI 67 [ z ]) [2 S4 A32])
I'm not sure though if just adding
if (!v-always_computable)
{
if (loop_dump_stream)
fprintf (loop_dump_stream,
giv of insn %d: not always computable.\n,
INSN_UID (v-insn));
v-ignore = 1;
bl-all_reduced = 0;
}
to the loop in strength_reduce a few lines above loop_givs_reduce call
wouldn't be a too big hammer for this.
Alternatively check if (!v-always_computable (may_trap_or_fault_p
(v-add_val) || (may_trap_or_fault_p (v-mult_val)).
BTW, I don't think P3 is the right priority here, IMHO P1 would be more
suitable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug rtl-optimization/23478] New: Miscompilation due to reloading of a var that is also used in EH pad
The following testcase is miscompiled on x86_64-linux at -O2. Before global alloc/reload, the interesting part of code is: (reg:DI %rax) = (call _Znwm (1)) (reg:DI 81) = (reg:DI %rax) ... (reg:DI %rdi) = (reg:DI 81) (call _ZN2C1C1ERK2C3S2_S2_RPS1_ (%rdi, ...)) - may throw, EH pad .Leh ... (reg:DI %rdi) = (reg:DI 81) ... (barrier) .Leh: (reg:DI %rdi) = (reg:DI 81) (call _ZdlPv (%rdi)) Now, as the register preassure is pretty high, there don't appear to be any free usable call saved registers for pseudo 81, so global alloc assigns pseudo 81 into (reg:DI %r10), which is call clobbered. Then reload saves it into stack before the _ZN2C1C1ERK2C3S2_S2_RPS1_ call and restores it from the stack slot after the call. But doesn't restore it on the EH path as well. So we end up with: (reg:DI %rax) = (call _Znwm (1)) (reg:DI %r10 (81)) = (reg:DI %rax) ... (reg:DI %rdi) = (reg:DI %r10 (81)) (mem:DI %rsp+24) = (reg:DI %r10 (81)) (call _ZN2C1C1ERK2C3S2_S2_RPS1_ (%rdi, ...)) - may throw, EH pad .Leh (reg:DI %r10 (81)) = (mem:DI %rsp+24) ... (reg:DI %rdi) = (reg:DI %r10 (81)) ... (barrier) .Leh: (reg:DI %rdi) = (reg:DI %r10 (81)) (call _ZdlPv (%rdi)) As this is a reload bug, it is not reproduceable on != 3.4.x compilers I have tried, which doesn't mean the bug is present on 3.4.x only though. -- Summary: Miscompilation due to reloading of a var that is also used in EH pad Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: critical Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at redhat dot com CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug rtl-optimization/23478] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 11:09 --- Created an attachment (id=9546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9546action=view) pr23478.C Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 13:36 --- caller-save.c inserts the restore insns after the can_throw_internal () CALL_INSN and as the rest of reload excepts fixup_abnormal_edges to fix the mess up. But, fixup_abnormal_edges only inserts the instructions on the fallthrough edge, not on the fallthrough edge and the EH edge. Is the bug in fixup_abnormal_edges then (which ought to insert the insns on all the edges rather than just one) or is the bug in caller-save.c which would need to take care of this and inserts the restore instructions not only after the call insn (awaiting fixup_abnormal_edges moving it to next resp. new bb), but also to the abnormal edge? It doesn't seem reload.c nor reload1.c (except fixup_abnormal_edges) bothers with this at all, so my guess would be that fixup_abnormal_edges needs to be changed, on the other side it surprises me this didn't cause (reported) problems for so long. -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug rtl-optimization/23478] [3.4 regression] Miscompilation due to reloading of a var that is also used in EH pad
--- Additional Comments From jakub at redhat dot com 2005-08-19 18:51 --- It can't be inserted just on abnormal critical edges: gcc_assert (!((e-flags EDGE_ABNORMAL) EDGE_CRITICAL_P (e))); So I guess we could insert it on the EH edges if !EDGE_CRITICAL_P and only only avoid caller-saving it if EDGE_CRITICAL_P. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23478
[Bug middle-end/23484] __builtin___memcpy_chk miscompilation
--- Additional Comments From jakub at redhat dot com 2005-08-19 19:16 --- I have a preliminary fix, will work on testcases now, then test it thoroughly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23484
[Bug middle-end/23299] New: GCSE? caused miscompilation
The following testcase is miscompiled on ppc and ppc64 at -Os.
In E::~E() GCSE changes:
(insn 3 6 4 0 (set (reg/f:DI 121 [ this ])
(reg:DI 3 3 [ this ])) 297 {*movdi_internal64} (nil)
(nil))
...
(insn 22 46 23 1 (set (reg/f:DI 125)
(plus:DI (reg/f:DI 121 [ this ])
(const_int 16 [0x10]))) 208 {*adddi3_internal1} (nil)
(nil))
...
(insn 30 29 31 2 (set (reg/f:DI 129)
(plus:DI (reg/f:DI 121 [ this ])
(const_int 16 [0x10]))) 208 {*adddi3_internal1} (nil)
(nil))
(each insn in a different bb, the last in EH bb) into:
(insn 57 6 3 0 (set (reg/f:DI 130)
(plus:DI (reg/f:DI 121 [ this ])
(const_int 16 [0x10]))) 208 {*adddi3_internal1} (nil)
(nil))
(insn 3 57 4 0 (set (reg/f:DI 121 [ this ])
(reg:DI 3 3 [ this ])) 297 {*movdi_internal64} (nil)
(nil))
and using pseudo 130 in place of 125 and 129.
--
Summary: GCSE? caused miscompilation
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc{,64}-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
[Bug middle-end/23299] GCSE? caused miscompilation
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:02 --- Created an attachment (id=9456) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9456action=view) pr23299.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
[Bug rtl-optimization/23299] [4.0 Regression] classic GCSE caused miscompilation
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:27 --- The problem is in insert_insn_end_bb. That function is called to hoist the common expression to the end of bb0. But, bb0 ends with a call that can throw, so insert_insn_end_bb decides not to put it after the call, but before it and load of its parameters. And that's the problem here, because that callee's argument (this) is the same as caller's argument (this) and CSE already removed that parameter load (as the argument is in r3 already from the entry block). insert_insn_end_bb keeps searching for parameter loads, until it reaches the beginning of the bb0 and inserts it there, without checking whether it crosses any setter of pseudos it uses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
[Bug rtl-optimization/23299] [4.0 Regression] classic GCSE caused miscompilation
--- Additional Comments From jakub at redhat dot com 2005-08-09 17:43 --- Fixed on mainline with http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01416.html I'll add the testcase, test the patch and submit for gcc-4_0-branch inclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23299
[Bug c++/23260] New: ICE on foo[-1]
g++ crashes on invalid: int foo[16]; int *bar = foo[-1]; trying to emit instructions outside of function context. -- Summary: ICE on foo[-1] Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at redhat dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23260
[Bug target/17828] -O2 -fPIC doesn't work with switches in linkonce functions and new binutils
--- Additional Comments From jakub at redhat dot com 2005-07-29 06:54 --- Do we want to check the comdat5* testcase in? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17828
[Bug fortran/18833] ICE 'missing spec' on integer/char equivalence
--- Additional Comments From jakub at redhat dot com 2005-07-22 12:37 --- I have partly written patch, but would like to understand whether ordering matters or not. Is the following all valid f77/f90/f95? subroutine foo character*8 c character*1 d, f dimension d(2), f(2) character*4 e equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2)) c='abcdefgh' if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort end subroutine foo subroutine bar equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2)) character*8 c character*1 d, f dimension d(2), f(2) character*4 e c='abcdefgh' if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort end subroutine bar subroutine baz character*8 c character*1 d, f character*4 e equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2)) dimension d(2), f(2) c='abcdefgh' if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort end subroutine baz subroutine another dimension d(2), f(2) equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2)) character*8 c character*1 d, f character*4 e c='abcdefgh' if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort end subroutine another program main call foo call bar call baz call another end program main Can equivalence contain sym%name or is that forbidden? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From jakub at redhat dot com 2005-07-20 11:41 --- I have done a binary search and at least for the failures and at least those problems mentioned in PR c++/18556 are fixed by PR middle-end/17799 without the need for PR c++/18556 patch. Now, the question is I think if there is a testcase that still needs PR c++/18556 patch. If not, at least for gcc-4_0-branch IMHO the easiest would be simply to revert that patch. If yes, but it is C++ only and there can't be a case when something like that is needed in C, a quick fix would be /* Do not emit debug information about variables that are in static storage, but not defined. */ if (TREE_CODE (decl) == VAR_DECL + (cgraph_global_info_ready || !flag_unit_at_a_time) TREE_STATIC (decl) !TREE_ASM_WRITTEN (decl)) DECL_IGNORED_P (decl) = 1; so we would not force no debugging for a var decl that has not been written, unless cgraph_optimize has been called already or -fno-unit-at-a-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug fortran/20842] can't use 'END=' in output statement
--- Additional Comments From jakub at redhat dot com 2005-07-20 21:23 --- Can you please also backport http://gcc.gnu.org/ml/gcc-cvs/2005-07/msg00126.html to gcc-4_0-branch? The testcase fails on gcc-4_0-branch ATM. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20842
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at redhat dot com 2005-07-14 12:46 --- First patch posted here http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00478.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at redhat dot com 2005-07-14 12:48
---
That patch fixes the original testcase, but unfortunately does not fix
the following one.
cat P.c EOF
#include dlfcn.h
#include pthread.h
void *
tf (void *arg)
{
void *h = dlopen (./libP.so, RTLD_LAZY);
void (*fn) (void);
if (!h) return 0;
fn = dlsym (h, foo);
fn ();
void *h2 = dlopen (libstdc++.so.6, RTLD_LAZY);
if (!h2) return 0;
dlclose (h);
return 0;
}
int
main (void)
{
pthread_t th;
pthread_create (th, NULL, tf, NULL);
pthread_join (th, NULL);
return 0;
}
EOF
cat libP.C EOF
#include string
#include ext/mt_allocator.h
template class __gnu_cxx::__mt_allocshort,
__gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ;
typedef std::char_traitschar my_traits_type;
typedef __gnu_cxx::__mt_allocshort,
__gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true my_allocator_type;
typedef std::basic_stringchar, my_traits_type, my_allocator_type my_string;
extern C void
foo (void)
{
my_string s;
s += hello;
}
EOF
g++ -g -O2 -shared -fpic -o libP.so libP.C
gcc -g -O2 -o P P.c -ldl -lpthread
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at redhat dot com 2005-07-14 13:37
---
Another patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00993.html
To test whether _M_get_thread_id/_M_initialize/_M_destroy_thread_key works
I was using following testcase under debugger:
#include pthread.h
#include unistd.h
#include memory
#include ext/mt_allocator.h
using __gnu_cxx::__pool;
using __gnu_cxx::__common_pool_policy;
using __gnu_cxx::__per_type_pool_policy;
typedef __common_pool_policy__pool, true cpolicy_type;
typedef __per_type_pool_policychar, __pool, true tpolicy_type;
typedef __per_type_pool_policyunsigned char, __pool, true upolicy_type;
typedef __gnu_cxx::__mt_allocchar, cpolicy_type callocator_type;
typedef __gnu_cxx::__mt_allocchar, tpolicy_type tallocator_type;
typedef __gnu_cxx::__mt_allocchar, upolicy_type uallocator_type;
typedef __gnu_cxx::__pool_base::_Tune tune_type;
callocator_type ca;
tallocator_type ta;
uallocator_type ua;
void *tf(void *arg)
{
callocator_type::pointer p1 = ca.allocate(128);
callocator_type::pointer p2 = ca.allocate(5128);
ca.deallocate(p1, 128);
ca.deallocate(p2, 5128);
int idx = (int) (long) arg;
if (idx 1)
sleep (1);
else
sleep (1024);
return NULL;
}
void *tf2(void *arg)
{
tallocator_type::pointer p1 = ta.allocate(128);
tallocator_type::pointer p2 = ta.allocate(5128);
ta.deallocate(p1, 128);
ta.deallocate(p2, 5128);
int idx = (int) (long) arg;
if (idx 1)
sleep (1);
else
sleep (1024);
return NULL;
}
void *tf3(void *arg)
{
uallocator_type::pointer p1 = ua.allocate(128);
uallocator_type::pointer p2 = ua.allocate(5128);
ua.deallocate(p1, 128);
ua.deallocate(p2, 5128);
int idx = (int) (long) arg;
if (idx 1)
sleep (1);
else
sleep (1024);
return NULL;
}
int main()
{
tune_type t_opt(16, 5120, 32, 5120, 20, 10, false);
ca._M_set_options(t_opt);
pthread_t th[48];
for (int i = 0; i 16; ++i)
pthread_create (th[i], NULL, tf, (void *) (long) i);
callocator_type::pointer p1 = ca.allocate(128);
callocator_type::pointer p2 = ca.allocate(5128);
ca.deallocate(p1, 128);
ca.deallocate(p2, 5128);
sleep (3);
tune_type t_opt2(16, 5120, 32, 5120, 36, 10, false);
ta._M_set_options(t_opt2);
for (int i = 16; i 32; ++i)
pthread_create (th[i], NULL, tf2, (void *) (long) i);
tallocator_type::pointer p3 = ta.allocate(128);
tallocator_type::pointer p4 = ta.allocate(5128);
ta.deallocate(p3, 128);
ta.deallocate(p4, 5128);
sleep (3);
tune_type t_opt3(16, 5120, 32, 5120, 52, 10, false);
ua._M_set_options(t_opt3);
for (int i = 32; i 48; ++i)
pthread_create (th[i], NULL, tf3, (void *) (long) i);
uallocator_type::pointer p5 = ua.allocate(128);
uallocator_type::pointer p6 = ua.allocate(5128);
ua.deallocate(p5, 128);
ua.deallocate(p6, 5128);
sleep (3);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug debug/22489] New: [4.0/4.1 Regression] ICE in dwarf2out_finish
The following testcase ICEs on various (dwarf2 using) targets with -g:
namespace N
{
};
struct T
{
T ()
{
using namespace N;
}
};
void
bar ()
{
struct U : public T
{
void baz ()
{
using namespace N;
}
} u;
}
This is a regression from GCC 3.4.x, present on both gcc-4_0-branch and on
HEAD.
--
Summary: [4.0/4.1 Regression] ICE in dwarf2out_finish
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22489
[Bug libstdc++/22482] -fvisibility=hidden and stl - SEGV in __gnu_cxx::__pooltrue::_M_reclaim_block
--- Additional Comments From jakub at redhat dot com 2005-07-14 15:24
---
IMHO either we want to just force what must have default visibility to have
the default visibility (in mt_allocator.h case it is _S_get_pool), as in:
--- ext/mt_allocator.h 2005-05-20 03:36:29.0 +0200
+++ ext/mt_allocator.h 2005-07-14 17:17:49.0 +0200
@@ -413,7 +413,7 @@ namespace __gnu_cxx
struct _M_rebind
{ typedef __common_pool_policy_PoolTp1, _Thread1 other; };
- static pool_type
+ static __attribute__((visibility (default))) pool_type
_S_get_pool()
{
static pool_type _S_pool;
@@ -444,7 +444,7 @@ namespace __gnu_cxx
struct _M_rebind
{ typedef __common_pool_policy_PoolTp1, _Thread1 other; };
- static pool_type
+ static __attribute__((visibility (default))) pool_type
_S_get_pool()
{
static pool_type _S_pool;
@@ -490,7 +490,7 @@ namespace __gnu_cxx
struct _M_rebind
{ typedef __per_type_pool_policy_Tp1, _PoolTp1, _Thread1 other; };
- static pool_type
+ static __attribute__((visibility (default))) pool_type
_S_get_pool()
{
// Sane defaults for the _PoolTp.
@@ -536,7 +536,7 @@ namespace __gnu_cxx
struct _M_rebind
{ typedef __per_type_pool_policy_Tp1, _PoolTp1, _Thread1 other; };
- static pool_type
+ static __attribute__((visibility (default))) pool_type
_S_get_pool()
{
// Sane defaults for the _PoolTp.
(of course together with a libstdc++-v3/configure check for visibility
attribute and using a macro for that, __gxx_default_visibility or something
like that).
Not sure what other places in libstdc++-v3 headers rely on having the default
visibility.
Alternatively, we claim that all of libstdc++-v3 header stuff (or most of it)
needs default visibility and add
#pragma GCC visibility push(default) ... #pragma GCC visibility pop
markers around (most of) libstdc++-v3 headers, like it has been already
added for libsupc++ headers. This wasn't possible earlier when we had the
16 GCC visibility pragmas stacking limit, but now that it is gone, we can
fix that up. Of course the issues Roger raised need to be solved as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22482
[Bug c/20303] Can't push more than 16 nested visibility
--- Additional Comments From jakub at redhat dot com 2005-07-14 15:33 --- Any reason why this hasn't been fixed on gcc-4_0-branch as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303
[Bug c++/22434] New: ICE in simplify_{,gen_}subreg
#include ostream
#include string
#include vector
std::string bar (unsigned int x);
template class T
std::ostream baz (std::ostream os, const T v, bool lit)
{
typename T::const_iterator i = v.begin ();
os (lit ? bar (*i) : *i);
return os;
}
void foo (std::ostream os, const std::vectorint v)
{
baz (os, v, false);
}
ICEs in 3.4.4, 4.0.1 and HEAD, trying to generate a BLKmode SUBREG.
--
Summary: ICE in simplify_{,gen_}subreg
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
[Bug c/22441] New: ICE on redefined inline function
static inline __attribute__ ((always_inline))
int baz (const unsigned char *addr)
{
return addr[0] 0x01;
}
static inline __attribute__ ((always_inline))
int bar (const unsigned char *addr)
{
return !baz (addr);
}
extern inline __attribute__ ((always_inline))
int baz (const unsigned char *addr)
{
return addr[0] != 0xff (0x01 addr[0]);
}
int
foo (unsigned char *p)
{
return bar (p);
}
ICEs at -O2 -fno-unit-at-a-time and issues a sorry message with -O2.
Both GCC 3.4.4 and HEAD reject this as invalid.
--
Summary: ICE on redefined inline function
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22441
[Bug tree-optimization/22415] New: ICE in coalesce_abnormal_edges
struct C
{
int a;
int *b;
int *c1 (int x) { return new int[sizeof (int) * x]; }
void c2 (int *x, int *y, int z)
{
for (int i = 0; i z; i++)
y[i] = x[i];
}
C (int x = 0) : a (x)
{
if (a)
{
b = c1 (a);
for (int i = 0; i a; i++)
b[i] = 0;
}
}
C (const C x) : a (x.a)
{
if (a)
{
b = c1 (a);
c2 (x.b, b, a);
}
}
~C (void) { if (a) delete b; }
int operator [] (int x)
{
if (a == 0 x == 0)
{
a = 1;
b = c1 (1);
b[0] = 0;
}
else
{
C e (*this);
a = x + 1;
b = c1 (a);
c2 (e.b, b, e.a);
for (int i = e.a; i a; i++)
b[i] = 0;
}
return b[x];
}
C operator (int x) { (*this)[a] = x; return *this; }
};
int
bar (void)
{
C a;
int f = 1;
while (f != -1)
{
f = 0;
a 1;
}
return 0;
}
ICEs at -O2 in coalesce_abnormal_edges. The bug is not present on HEAD
and 3.4.x compiles it just fine as well.
--
Summary: ICE in coalesce_abnormal_edges
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
[Bug fortran/22417] [4.0/4.1 Regression] gfortran preprocessing regression: nonsense warning about file left but not entered
--- Additional Comments From jakub at redhat dot com 2005-07-11 22:28
---
Oops. Untested patch, will do more testing tomorrow^Wtoday:
2005-07-12 Jakub Jelinek [EMAIL PROTECTED]
PR fortran/22417
* scanner.c (preprocessor_line): Fix file left but not entered
warning.
--- gcc/fortran/scanner.c.jj2005-07-07 17:56:30.0 +0200
+++ gcc/fortran/scanner.c 2005-07-12 00:25:07.0 +0200
@@ -908,15 +908,15 @@ preprocessor_line (char *c)
if (flag[2]) /* Ending current file. */
{
- if (strcmp (current_file-filename, filename) != 0)
+ if (!current_file-up
+ || strcmp (current_file-up-filename, filename) != 0)
{
gfc_warning_now (%s:%d: file %s left but not entered,
current_file-filename, current_file-line,
filename);
return;
}
- if (current_file-up)
- current_file = current_file-up;
+ current_file = current_file-up;
}
/* The name of the file can be a temporary file produced by
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22417
[Bug libstdc++/22309] New: mt allocator doesn't pthread_key_delete it's keys
With libstdc++ configured with --enable-libstdcxx-allocator=mt (on 4.0 branch
or on HEAD for linux even without it, as mt is the default there), following
testcase crashes:
cat O.c EOF
#include dlfcn.h
#include pthread.h
void *
tf (void *arg)
{
void *h = dlopen (./libO.so, RTLD_LAZY);
void (*fn) (void);
if (!h) return 0;
fn = dlsym (h, foo);
fn ();
dlclose (h);
return 0;
}
int
main (void)
{
pthread_t th;
pthread_create (th, NULL, tf, NULL);
pthread_join (th, NULL);
return 0;
}
EOF
cat libO.C EOF
#include string
extern C void
foo (void)
{
std::string s;
s += hello;
}
EOF
g++ -g -O2 -shared -fpic -o libO.so libO.C
gcc -g -O2 -o O O.c -ldl -lpthread
The problem is that __gnu_cxx::__pooltrue::_M_initialize () calls
pthread_key_create but doesn't ensure pthread_key_delete is called when
libstdc++.so is unloaded. So when glibc attempts destroys a thread or program
and calls the registered key cleanup routine (_S_destroy_thread_key), if
libstdc++.so is not mapped at that moment any longer, either whatever other
code happens to be mapped at that address is run, or the program crashes
immediately.
mt_allocator.cc should ensure that gthread_key_delete is called on the key
after all users of the key have been destroyed.
--
Summary: mt allocator doesn't pthread_key_delete it's keys
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at redhat dot com 2005-07-05 16:48 --- Yes, that's the same thing apparently. I'm pretty sure a reproducer can be written even for libstdc++ not configured to default to the mt allocator, by including ext/mt_allocator.h etc. or however you explicitely choose a specific allocator for some template instantiation. If init_priority attribute works, it could be perhaps used to make sure the destructor of some dummy object that calls gthread_key_delete in mt_allocator.cc will be run as last destructor in libstdc++.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug c++/22284] [4.1 Regression] Many C++ testsuite failures
--- Additional Comments From jakub at redhat dot com 2005-07-03 12:08 --- Strange, I have certainly bootstrapped/regtested the initial -fstack-protector patch on ia64-linux and there were no regressions, neither on HEAD (20050625 tree + those patches) nor in the 4.0.1 backport. g++.dg/eh/cond1.C compiles/runs just fine for me. -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
[Bug c++/22284] [4.1 Regression] Many C++ testsuite failures
--- Additional Comments From jakub at redhat dot com 2005-07-03 13:40 --- Ok, I can now reproduce the g++.dg/eh/cond1.C failure with trunk GCC. It works well when run against 4.0 libstdc++.so, or 20050625 HEAD one (but in that case built with the -fstack-protector patch in). Now, g++ 4.0 compiled/linked g++.dg/eh/cond1 also works when run against 4.0 libstdc++.so, or 20050625 HEAD one, but segfaults when using 20050703 HEAD libstdc++.so (FYI, libgcc_s exact version doesn't matter). cond1.s compiled by 20050703 HEAD and 4.0 is in fact identical except .ident and COMDAT section names. I have also built 20050703 HEAD libstdc++.so with g++ 4.0 (had to add #include ia64intrin.h into ia64/atomicity.h), and cond1 also segfaults against such built libstdc++.so. That g++ 4.0 was without -fstack-protector patches FYI. So I'm pretty positive this is caused by some libstdc++ EH change, with http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg01019.html being the suspected one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22284
[Bug tree-optimization/22219] New: ICE when compiling gcc.dg/builtin-object-size-[1234].c
With current GCC CVS 4 of the added tests
(gcc.dg/builtin-object-size-{1,2,3,4}.c) fail with:
/usr/src/gcc/gcc/testsuite/gcc.dg/builtin-object-size-1.c: In function 'test2':
/usr/src/gcc/gcc/testsuite/gcc.dg/builtin-object-size-1.c:159: error:
Pointers with a memory tag, should have points-to sets or r_1, name memory tag:
NMT.52, points-to vars: { } r, UID 0, char *
/usr/src/gcc/gcc/testsuite/gcc.dg/builtin-object-size-1.c:159: internal
compiler error: verify_flow_sensitive_alias_info failed.Please submit a full bug
report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
but a) that looks like a tree-ssa-alias bug to me (see below)
b) it is a checking only failure, when not checking, it works
c) it is not something people usually do with the builtins.
Usually the builtin result is passed to a function that also uses
the pointer passed to the __builtin_object_size (ptr, cst) function
and therefore the pointer use is usually not completely optimized
away when __builtin_object_size (ptr, cst) is optimized into a
constant.
In gcc.dg/builtin-object-size{1,2,3,4}.c I'm only testing
the __builtin_object_size builtin, so e.g. in test2 function
__builtin_object_size is the only place that uses the r variable.
At alias4 time, the variable is:
rD.1709_1, name memory tag: NMT.52D.2245, is dereferenced, its value escapes,
points-to vars: { buf3D.1710 aD.1708 }
...
# rD.1709_1 = PHI aD.1708.buf1D.1706[1](1), aD.1708.buf2D.1707[7](2),
buf3D.1710[5](3), rD.1709_40(4),
+aD.1708.buf1D.1706[9](5);
...
D.1726_12 = __builtin_object_size (rD.1709_1, 0);
Now, objsz pass (but similarly could optimize e.g. a fab pass) optimizes
the last line into:
D.1726_12 = 20;
and when alias5 starts, in init_alias_info it clears
rD.1709_1's is_dereferenced, clears pi-pt_vars
bitmap etc., but does not clear it's pi-name_mem_tag
(this is I guess desirable, so that in the likely case the mem tag
will be needed again a new mem tag is not created again).
Next collect_points_to_info_for is called for pointer uses
and collect_points_to_info_for leads to populating the processed_ptrs
array (and for pointers in processed_ptrs varray it clears pi-name_mem_tag
in create_name_tags). The problem here is that rD.1709_1
is not used any longer, so pi-name_mem_tag is not cleared,
while pi-is_dereferenced is 0, pi-pt_vars is empty bitmap
and verify_flow_sensitive_alias_info complains.
PR tree-optimization/21584 sounds like the same problem.
Now, unless we require a DCE pass right before every may_alias
pass, I'm afraid we have to live with pointers that had a name_mem_tag
set, but after some optimization are no longer used anywhere, but not yet
eliminated as dead code. So, either create_name_tags would need to
walk over all SSA names with pointer type and do:
if (pi-pt_anything || !pi-is_dereferenced)
{
/* No name tags for pointers that have not been
dereferenced or point to an arbitrary location. */
pi-name_mem_tag = NULL_TREE;
continue;
}
on them, not just on those in ai-processed_ptrs,
or verify_flow_sensitive_alias_info should allow non-NULL
name_mem_tag if pt_anything != 0 || pi-is_dereferenced = NULL.
--
Summary: ICE when compiling gcc.dg/builtin-object-size-[1234].c
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: dnovillo at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22219
[Bug tree-optimization/22043] New: [4.0/4.1 Regression] Fields not initialized for automatic structs with flexible array members
In:
extern void abort (void);
struct A { int i; int j; int k; int l; };
struct B { struct A a; int r[1]; };
struct C { struct A a; int r[0]; };
struct D { struct A a; int r[]; };
void
foo (struct A *x)
{
if (x-i != 0 || x-j != 5 || x-k != 0 || x-l != 0)
abort ();
}
int
main ()
{
struct B b = { .a.j = 5 };
struct C c = { .a.j = 5 };
struct D d = { .a.j = 5 };
foo (b.a);
foo (c.a);
foo (d.a);
return 0;
}
GCC 4.0/HEAD only zero initialize a.i, a.k and a.l for the b variable, not for
c nor d, while 3.4.x and older initialized them for all 3 variables.
This causes miscompilation of glibc by GCC 4.0+.
--
Summary: [4.0/4.1 Regression] Fields not initialized for
automatic structs with flexible array members
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22043
[Bug tree-optimization/22050] New: [4.0/4.1 Regression] ICE in gimple_add_tmp_var
void bar (const unsigned short *const);
void foo (void)
{
const unsigned short *const p
= (const unsigned short []){ 'F', 'o', 'o', 0 };
bar (p);
}
at -O and higher results in ICE in gimple_add_tmp_var.
--
Summary: [4.0/4.1 Regression] ICE in gimple_add_tmp_var
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22050
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-04-13 09:46
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Tue, Apr 12, 2005 at 05:54:58PM -, mmitchel at gcc dot gnu dot org wrote:
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-12
17:54 ---
I like the simpler approach. If someone would test that for 4.0, I'd be
ecstatic.
Here is what I have bootstrapped/regtested on
{i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux.
2005-04-13 Alexandre Oliva [EMAIL PROTECTED]
Roger Sayle [EMAIL PROTECTED]
PR target/20126
* loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
set the original address pseudo to the correct value before the
original insn, if possible, and leave the insn alone, otherwise
create a new pseudo, set it and replace it in the insn.
* recog.c (validate_change_maybe_volatile): New.
* recog.h (validate_change_maybe_volatile): Declare.
* gcc.dg/pr20126.c: New.
--- gcc/loop.c.jj 2005-04-03 10:33:24.0 +0200
+++ gcc/loop.c 2005-04-12 23:22:06.0 +0200
@@ -5478,9 +5478,20 @@ loop_givs_rescan (struct loop *loop, str
mark_reg_pointer (v-new_reg, 0);
if (v-giv_type == DEST_ADDR)
- /* Store reduced reg as the address in the memref where we found
- this giv. */
- validate_change (v-insn, v-location, v-new_reg, 0);
+ {
+ /* Store reduced reg as the address in the memref where we found
+this giv. */
+ if (!validate_change (v-insn, v-location, v-new_reg, 0))
+ {
+ if (loop_dump_stream)
+ fprintf (loop_dump_stream,
+unable to reduce iv to register in insn %d\n,
+INSN_UID (v-insn));
+ bl-all_reduced = 0;
+ v-ignore = 1;
+ continue;
+ }
+ }
else if (v-replaceable)
{
reg_map[REGNO (v-dest_reg)] = v-new_reg;
--- gcc/testsuite/gcc.dg/pr20126.c 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/pr20126.c 10 Mar 2005 11:24:16 -
@@ -0,0 +1,50 @@
+/* dg-do run */
+/* dg-options -O2 */
+
+/* PR target/20126 was not really target-specific, but rather a loop's
+ failure to take into account the possibility that a DEST_ADDR giv
+ replacement might fail, such as when you attempt to replace a REG
+ with a PLUS in one of the register_operands of cmpstrqi_rex_1. */
+
+extern void abort (void);
+
+typedef struct { int a; char b[3]; } S;
+S c = { 2, aa }, d = { 2, aa };
+
+void *
+bar (const void *x, int y, int z)
+{
+ return (void *) 0;
+}
+
+int
+foo (S *x, S *y)
+{
+ const char *e, *f, *g;
+ int h;
+
+ h = y-a;
+ f = y-b;
+ e = x-b;
+
+ if (h == 1)
+return bar (e, *f, x-a) != 0;
+
+ g = e + x-a - h;
+ while (e = g)
+{
+ const char *t = e + 1;
+ if (__builtin_memcmp (e, f, h) == 0)
+ return 1;
+ e = t;
+}
+ return 0;
+}
+
+int
+main (void)
+{
+ if (foo (c, d) != 1)
+abort ();
+ return 0;
+}
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-04-13 11:38 --- Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry On Wed, Apr 13, 2005 at 12:05:35PM +0200, Bernd Schmidt wrote: Jakub Jelinek wrote: PR target/20126 * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, set the original address pseudo to the correct value before the original insn, if possible, and leave the insn alone, otherwise create a new pseudo, set it and replace it in the insn. * recog.c (validate_change_maybe_volatile): New. * recog.h (validate_change_maybe_volatile): Declare. This doesn't appear to match the patch you posted. Oops. Is: 2005-04-13 Alexandre Oliva [EMAIL PROTECTED] Roger Sayle [EMAIL PROTECTED] PR target/20126 * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed, signal that all GIVs couldn't be reduced. * gcc.dg/pr20126.c: New. better? Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 10:19
---
Subject: [PATCH] Fix PR preprocessor/19475
Hi!
This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn,
for ISO C99 if there is no whitespace between macro definition and
replacement, but replacement starts with a basic character set character.
Ok to commit?
Unfortunately, the testcases provided fail in dejagnu (although the
preprocessor behaviour is correct).
Executing on host: /usr/src/gcc/obj/gcc/xgcc -B/usr/src/gcc/obj/gcc/
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c -std=iso9899:1990
-pedantic-errors -E -o macspace1.i(timeout = 300)
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:5:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:6:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:7:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:8:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:9:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:10:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:11:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:12:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:13:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:14:10: warning: missing
whitespace after the macro name
/usr/src/gcc/gcc/testsuite/gcc.dg/cpp/macspace1.c:15:10: warning: missing
whitespace after the macro name
...
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 5)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 6)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 7)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 8)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 9)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 10)
PASS: gcc.dg/cpp/macspace1.c (test for warnings, line 11)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 12)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 13)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 14)
FAIL: gcc.dg/cpp/macspace1.c (test for warnings, line 15)
...
Is there some limitation on how many bytes or error messages
dejagnu groks or something?
When I split the tests into 6 warnings (resp. errors) chunks, it succeeds.
I'm using dejagnu 1.4.4, expect 5.42.1 and tcl 8.4.7.
2005-04-05 Jakub Jelinek [EMAIL PROTECTED]
PR preprocessor/19475
* libcpp/macro.c (create_iso_definition): For ISO C99, don't
pedwarn if there is no whitespace between macro name and its
replacement, but the replacement starts with a basic character
set character.
* gcc.dg/cpp/macspace1.c: New test.
* gcc.dg/cpp/macspace2.c: New test.
--- gcc/libcpp/macro.c.jj 2005-03-17 13:39:12.0 +0100
+++ gcc/libcpp/macro.c 2005-04-05 11:39:57.0 +0200
@@ -1430,8 +1430,39 @@ create_iso_definition (cpp_reader *pfile
macro-fun_like = 1;
}
else if (ctoken-type != CPP_EOF !(ctoken-flags PREV_WHITE))
-cpp_error (pfile, CPP_DL_PEDWARN,
- ISO C requires whitespace after the macro name);
+{
+ /* While ISO C99 requires whitespace before replacement text
+in a macro definition, ISO C90 with TC1 allows there characters
+from the basic source character set. */
+ if (CPP_OPTION (pfile, c99))
+ cpp_error (pfile, CPP_DL_PEDWARN,
+ ISO C99 requires whitespace after the macro name);
+ else
+ {
+ int warntype = CPP_DL_WARNING;
+ switch (ctoken-type)
+ {
+ case CPP_ATSIGN:
+ case CPP_AT_NAME:
+ case CPP_OBJC_STRING:
+ /* '@' is not in basic character set. */
+ warntype = CPP_DL_PEDWARN;
+ break;
+ case CPP_OTHER:
+ /* Basic character set sans letters, digits and _. */
+ if (strchr (!\#%'()*+,-./:;=?[\\]^{|}~,
+ ctoken-val.str.text[0]) == NULL)
+ warntype = CPP_DL_PEDWARN;
+ break;
+ default:
+ /* All other tokens start with a character from basic
+character set. */
+ break;
+ }
+ cpp_error (pfile, warntype,
+missing whitespace after the macro name);
+ }
+}
if (macro-fun_like)
token = lex_expansion_token (pfile, macro);
--- gcc/gcc/testsuite/gcc.dg/cpp/macspace2.c.jj 2005-04-05 11:45:18.0
+0200
+++ gcc/gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 11:46:41.0
+0200
@@ -0,0 +1,65 @@
+/* PR
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 11:57
---
Subject: Re: [PATCH] Fix PR preprocessor/19475
On Tue, Apr 05, 2005 at 08:32:58PM +0900, Neil Booth wrote:
Jakub Jelinek wrote:-
Is there some limitation on how many bytes or error messages
dejagnu groks or something?
I think it gets confused by the column numbers; if you add
-fno-columns (or whatever it is) the problem would probably
go away.
Thanks, you're right. With following incremental patch
it passes just fine (and fails with cc1 built without the patch).
diff -u gcc/testsuite/gcc.dg/cpp/macspace2.c
gcc/testsuite/gcc.dg/cpp/macspace2.c
--- gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 11:46:41.0
+0200
+++ gcc/testsuite/gcc.dg/cpp/macspace2.c2005-04-05 13:51:02.0
+0200
@@ -1,6 +1,6 @@
/* PR preprocessor/19475 */
/* { dg-do preprocess } */
-/* { dg-options -std=iso9899:1999 -pedantic-errors } */
+/* { dg-options -std=iso9899:1999 -pedantic-errors -fno-show-column } */
#define a! /* { dg-error requires whitespace } */
#define b /* { dg-error requires whitespace } */
diff -u gcc/testsuite/gcc.dg/cpp/macspace1.c
gcc/testsuite/gcc.dg/cpp/macspace1.c
--- gcc/testsuite/gcc.dg/cpp/macspace1.c2005-04-05 11:54:16.0
+0200
+++ gcc/testsuite/gcc.dg/cpp/macspace1.c2005-04-05 13:50:54.0
+0200
@@ -1,6 +1,6 @@
/* PR preprocessor/19475 */
/* { dg-do preprocess } */
-/* { dg-options -std=iso9899:1990 -pedantic-errors } */
+/* { dg-options -std=iso9899:1990 -pedantic-errors -fno-show-column } */
#define a! /* { dg-warning missing whitespace } */
#define b /* { dg-warning missing whitespace } */
Jakub
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug preprocessor/19475] [3.3/3.4/4.0/4.1 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From jakub at redhat dot com 2005-04-05 16:54 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 On Tue, Apr 05, 2005 at 09:49:19AM -0700, Zack Weinberg wrote: This patch fixes PR preprocessor/19475 by issuing just warning, not pedwarn, for ISO C99 if there is no whitespace between macro definition and replacement, but replacement starts with a basic character set character. Ok to commit? OK except please remove the ?, ?, ?=, ?= testcases as those tokens are probably going to be removed in the near future. I know, but that IMHO shouldn't matter for the testcase. #define a? should be still treated like #define a ? in C90 (with a warning), no matter whether ? is a cpp token or 2 tokens. Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug tree-optimization/20640] [4.0 Regression] ICE on NULL PHI_ARG_DEF
--- Additional Comments From jakub at redhat dot com 2005-03-30 07:56 --- Subject: Re: [PR tree-optimization/20640] add phi args to dests of dce-redirected edges On Wed, Mar 30, 2005 at 02:56:24AM -0300, Alexandre Oliva wrote: When remove_dead_stmt() redirects a control stmt, the edge redirection reserves space for the phi arg for the new incoming edge in all phi nodes, but, instead of filling them in with information obtained from the edge redirection, we simply discard this information. This leaves NULL in the phi args, which may cause crashes later on. This patch fixes the problem by filling in the phi args using the PENDING_STMT list created during edge redirection. This appears to be the intended use for this information, and it is used similarly in e.g. loop unrolling. Bootstrapping mainline and 4.0 branch on amd64-linux-gnu, and mainline on i686-pc-linux-gnu. Ok to install if bootstrap and regtesting pass? The patch below is for the 4.0 branch, but it applies cleanly and correctly in mainline as well, since it's just a few lines off. Note this is PR tree-optimization/20640, not PR 20460 (typo in ChangeLog as well as subject line, while the testcase is ok). Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20640
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-03-09 08:51 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote: On Mar 8, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote: Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: Odd... It surely completed bootstrap for me with default build flags. Hmm... FORTIFY_SOURCE? This is Ada, stage1/xgcc -Bstage1/ -B/usr/i386-redhat-linux/bin/ -c -O2 -Wall -g -pipe \ -march=i386 -mtune=pentium4 -fprofile-generate -gnatpg -gnata -I- -I. \ -Iada -I../../gcc/ada ../../gcc/ada/ali.adb -o ada/ali.o in particular, so -D_FORTIFY_SOURCE=2 definitely isn't in the game. Were you bootstrapping with Ada (which is not on by default)? Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-03-09 09:23 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Wed, Mar 09, 2005 at 01:02:08AM -0300, Alexandre Oliva wrote: On Mar 8, 2005, Jakub Jelinek [EMAIL PROTECTED] wrote: Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: Odd... It surely completed bootstrap for me with default build flags. Your code hits just once on ali.adb stage1/gnat1 -I- -I. -Iada -I../../gcc/ada -quiet -dumpbase ali.adb -O2 -gnatpg \ -gnata -gnatO ada/ali.o ../../gcc/ada/ali.adb -o foo.s (gdb) p debug_rtx(v-insn) (insn 1571 1568 1573 (set (mem/s/v/j:QI (plus:SI (reg:SI 349 [ D.4388 ]) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7c0ea8c ali__cumulative_restrictions)) [5 ali__cumulative_restrictions.set S1 A8]) (const_int 1 [0x1])) -1 (nil) (nil)) (gdb) p debug_rtx(*v-location) (plus:SI (reg:SI 349 [ D.4388 ]) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7c0ea8c ali__cumulative_restrictions)) (gdb) p debug_rtx(v-new_reg) (plus:SI (reg:SI 1953) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7c0ea8c ali__cumulative_restrictions)) Note that recog_memoized (v-insn) is -1 even without the change, not sure what would fix that up. But it certainly shows that *v-location doesn't have to be a simple pseudo, so gen_move_insn might not work. Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
--- Additional Comments From jakub at redhat dot com 2005-03-09 01:47 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Mon, Mar 07, 2005 at 06:56:19PM -0300, Alexandre Oliva wrote: loop attempts to eliminate a biv represented by a pseudo in favor of a giv represented by (plus (reg) (const_int -1)). Unfortunately, the biv pseudo appears in an insn that doesn't accept anything but a register, so validate_change fails and the error goes unnoticed. The patch below fixes the problem and passed bootstrap on x86_64-linux-gnu (testing still pending), but I'm not very comfortable with the use of location for the assignment. Is this a safe change? Any loop experts around willing to take a second look on this? Thanks in advance, Unfortunately, it seems to break ada bootstrap on at least x86-64 and i386: ../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': ../../gcc/ada/ali.adb:2070: error: unrecognizable insn: (insn:HI 5987 1558 1560 230 ../../gcc/ada/ali.adb:996 (set (plus:SI (reg:SI 2074) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7e2b360 ali__cumulative_restrictions)) (plus:SI (reg:SI 2074) (symbol_ref:SI (ali__cumulative_restrictions) [flags 0x2] var_decl 0xb7e2b360 ali__cumulative_restrictions))) -1 (nil) (nil)) ../../gcc/ada/ali.adb: In function 'ALI.SCAN_ALI': ../../gcc/ada/ali.adb:2070: error: unrecognizable insn: (insn:HI 6040 1461 1463 230 ../../gcc/ada/ali.adb:992 (set (plus:DI (plus:DI (reg:DI 2096) (reg/f:DI 726)) (const_int 12 [0xc])) (plus:DI (reg:DI 2096) (const:DI (plus:DI (symbol_ref:DI (ali__cumulative_restrictions) [flags 0x2] var_decl 0x2a96136ea0 ali__cumulative_restrictions) (const_int 92 [0x5c]) -1 (nil) (nil)) Jakub -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
