--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-17 07:54 ---
(In reply to comment #4)
> There was some history regarding legacy codes as the reason why this does not
> error out. ie looping back and trying again was a feature. I think I may put
> this behind -std=legacy. It d
--- Comment #9 from domob at gcc dot gnu dot org 2010-08-17 08:20 ---
Subject: Bug 38936
Author: domob
Date: Tue Aug 17 08:20:03 2010
New Revision: 163295
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163295
Log:
2010-08-17 Daniel Kraft
PR fortran/38936
* gf
--- Comment #10 from domob at gcc dot gnu dot org 2010-08-17 08:23 ---
This implements association to variables and removes the problems that were
still there with array expressions and bounds. What's still missing is:
* Association to polymorphic entities
* Association to strings (wor
--- Comment #1 from pzhao at gcc dot gnu dot org 2010-08-17 08:25 ---
Subject: Bug 40563
Author: pzhao
Date: Tue Aug 17 08:25:20 2010
New Revision: 163296
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163296
Log:
/gcc
2010-08-17 Shujing Zhao
PR c/40563
* c-d
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-08-17 08:28 ---
Fix on trunk
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #3 from pzhao at gcc dot gnu dot org 2010-08-17 08:30 ---
Fix on trunk
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
I have the following program:
main.cpp
--
struct Foo
{
void foobar() {}
};
typedef void (*plain_foobar_t)(Foo*);
int main()
{
asm("push %0;"
:
: "i"((plain_foobar_t)&Foo::foobar));
In:
subroutine foo (i, j)
integer :: i, j, k, l
k = i
l = j
i = i * 10
i = i + j
call baz (i)
i = i + j
end subroutine
subroutine bar (i, j)
integer :: i, j, k, l
k = i
l = j
i = i * 10
i = i + j
call baz (i)
i = i + j
end subroutine
subroutine fn ()
end subroutine fn
pr
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 08:59 ---
Created an attachment (id=21500)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21500&action=view)
gcc46-pr45304-partial.patch
The partial patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45304
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 09:21 ---
IMHO this isn't a bug, to simplify that into an integer you really need some
optimizations. The conversion looks very weird, if you use something saner
like (void *)&Foo::foobar, it will even work with -O0.
--
ht
--- Comment #11 from jakub at gcc dot gnu dot org 2010-08-17 09:25 ---
Should be fixed for 4.5.2, 4.6 will use a different approach.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-17 09:34 ---
(In reply to comment #0)
> shouldn't:
> call bar (i)
> call bar (f)
> warn not just about the argument mismatch to foo, but also about bar?
Yes. One should construct the function interface from the argument usage -
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-17 09:35 ---
Cf. PR 45304 for a partial fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44471
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-17 09:38 ---
(In reply to comment #1)
> IMHO this isn't a bug, to simplify that into an integer you really need some
> optimizations. The conversion looks very weird, if you use something saner
The conversion uses this extension
h
--- Comment #6 from ubizjak at gmail dot com 2010-08-17 09:38 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01226.html .
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
--- Comment #27 from pault at gcc dot gnu dot org 2010-08-17 09:42 ---
(In reply to comment #25)
> (In reply to comment #21)
> > In my opinion revision 162487 is only a partial fix of the problem. If I
> > split
> > a modified test case in two files: [...] I still get [...] Bus error
>
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-17 09:42 ---
Looking at the diagnostics issued when -pedantic is added, I think the right
conversion is
(void*)(plain_foobar_t)&Foo::foobar
That still uses the G++ extension, and doesn't give the asm error even without
optimisatio
--- Comment #24 from bernds at gcc dot gnu dot org 2010-08-17 09:47 ---
I think that's beginning to look reasonable. So the problem was that without
alternative 2, such an add would match alternative 3 instead and be split?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-08-17 09:47 ---
Subject: Bug 45266
Author: rguenth
Date: Tue Aug 17 09:47:44 2010
New Revision: 163297
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163297
Log:
2010-08-17 Richard Guenther
PR testsuite/45266
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 09:51 ---
The #c2 patch is problematic, because build_function_type shares function
types, so setting TYPE_ARG_TYPES on that I'm afraid will affect all functions
with
(...) arguments and the same return type. So, the arglist ne
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45301
--- Comment #4 from jobnoorman at gmail dot com 2010-08-17 10:04 ---
(In reply to comment #1)
> IMHO this isn't a bug, to simplify that into an integer you really need some
> optimizations. The conversion looks very weird, if you use something saner
> like (void *)&Foo::foobar, it will
--- Comment #6 from jakub at gcc dot gnu dot org 2010-08-17 10:06 ---
Sounds like a target bug.
After variable_tracking_main the notes look correct:
(note 88 23 89 2 (var_location array (reg:HI 0 R0 [ pass_through_array ]))
NOTE_INSN_VAR_LOCATION)
(note 89 88 90 2 (var_location size (re
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 10:16 ---
For inline-asm? Certainly not. Consider much simpler:
void foo (void)
{
int i;
i = 6;
asm volatile ("" : : "i" (i));
}
which will work with -O and above, but not for -O0, for exactly the same
reason.
--
ht
Found when looking at PR fortran/36158
If the argument is an initialization expression and not too large, it should be
expanded. While the following works:
real, parameteR :: bes(2) = bessel_jn([1,2], 1.0)
print *, bes
end
The "if" is never optimized away for:
if (any (abs(bessel_jn([1,2],
--- Comment #1 from burnus at gcc dot gnu dot org 2010-08-17 10:19 ---
Note: The middle end also does not see that the expression can be optimized -
and thus fails also to do so for -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45305
--- Comment #10 from jakub at gcc dot gnu dot org 2010-08-17 10:47 ---
Fixed then.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from jobnoorman at gmail dot com 2010-08-17 10:49 ---
(In reply to comment #5)
> For inline-asm? Certainly not. Consider much simpler:
> void foo (void)
> {
> int i;
> i = 6;
> asm volatile ("" : : "i" (i));
> }
> which will work with -O and above, but not for -O0,
--- Comment #5 from zsojka at seznam dot cz 2010-08-17 10:55 ---
Created an attachment (id=21501)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21501&action=view)
different testcase
This one has declaration of overloaded functions in function scope. The assert
is the same.
$ gcc
g++ -c -m64 -O2 -fgraphite-identity -DQT_USE_FAST_CONCATENATION
-DQT_USE_FAST_OPERATOR_PLUS -fPIC -Wall -W -D_REENTRANT -DNDEBUG
-DSIP_PROTECTED_IS_PUBLIC -Dprotected=public -DQT_NO_DEBUG -DQT_GUI_LIB
-DQT_CORE_LIB -I. -I/usr/src/ark/BUILD/PyQt-x11-gpl-4.7.3/qpy/QtGui
-I/usr/include/python2.7 -I/us
--- Comment #1 from bero at arklinux dot org 2010-08-17 11:13 ---
Created an attachment (id=21502)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21502&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
--- Comment #2 from bero at arklinux dot org 2010-08-17 11:14 ---
Seems to work on 32-bit x86
--
bero at arklinux dot org changed:
What|Removed |Added
GCC build triplet|
--- Comment #4 from john at quivinco dot com 2010-08-17 11:57 ---
The cause has been isolated to a problem with my C code. The DLL now works on
Windows XP, but not Vista 64!?
--
john at quivinco dot com changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2010-08-17 12:07 ---
(In reply to comment #1)
> Confirmed as a regression: it compiles with 4.2.4 (ppc-darwin), gives an ICE
> with 4.3.4, 4.4.2, 4.5.0 and trunk.
>
You did not mark the PR as confirmed :-)
Paul
--
pault at gcc dot
--- Comment #7 from uros at gcc dot gnu dot org 2010-08-17 12:25 ---
Subject: Bug 45296
Author: uros
Date: Tue Aug 17 12:25:24 2010
New Revision: 163303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163303
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject
Compilling:
./g++ -O2 ~/mozalloc.ii -S -m32
gives me:
.type _GLOBAL__I_moz_free, @function
_GLOBAL__I_moz_free:
.LFB58:
.cfi_startproc
rep
ret
.cfi_endproc
.LFE58:
.size _GLOBAL__I_moz_free, .-_GLOBAL__I_moz_free
.section.ctors,"
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-08-17 12:38 ---
Created an attachment (id=21503)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21503&action=view)
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-17 12:49 ---
It's the FEs job really.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The following program prints (with gfortran, NAG f95, ifort) something like
20100817145358.302aa
expected, the number is black padded, i.e.
20100817145659.787
(as g95, pathf95, openf95 do)
The problem was reported
--- Comment #11 from mikpe at it dot uu dot se 2010-08-17 13:01 ---
Should libstdc++-v3/include/{c_global,c_std}/cwchar also get the restrict ->
__restrict treatment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
--- Comment #12 from paolo dot carlini at oracle dot com 2010-08-17 13:07
---
Sure, I forgot to grep, was in an hurry because I'm leaving for a few days of
vacations, but will do it momentarily.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
--- Comment #49 from iains at gcc dot gnu dot org 2010-08-17 13:13 ---
the patch attached to
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01249.html
solves the problem by suppression of the epilogues in _eh_frames;
the patch might be an incomplete solution to darwin<->dwarf2 issues.
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 13:13 ---
Created an attachment (id=21504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504&action=view)
gcc46-pr45308.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45308
--- Comment #22 from bernds at gcc dot gnu dot org 2010-08-17 13:14 ---
(In reply to comment #19)
> x_addr is a VALUE that has no locs:
That happens because it's an autoincrement, and cselib_subst_to_values just
creates an empty value.
It seems to me that we simply need to add a VALUE
--- Comment #13 from paolo at gcc dot gnu dot org 2010-08-17 13:16 ---
Subject: Bug 45300
Author: paolo
Date: Tue Aug 17 13:15:41 2010
New Revision: 163304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163304
Log:
2010-08-17 Paolo Carlini
PR libstdc++/45300
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-17 13:19 ---
(In reply to comment #1)
> Created an attachment (id=21504)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21504&action=view) [edit]
> gcc46-pr45308.patch
That's quick.
However, I wonder whether one should modi
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-17 13:23 ---
(Add lost mid-air collision text)
As Clive Page notes in c.l.f, the non-padding is required for F95 while the
padding is required in F2003 - though, I would not care for the F95 version and
always pad.
(F95, 13.14.2
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-08-17 13:34 ---
Adding Mark and Jason to CC then, but Jakub seems right about -Wuninitialized
warnings.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-17 13:50 ---
Created an attachment (id=21505)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21505&action=view)
gcc46-pr45308.patch
Updated patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed
The test case for PR 40628 has:
! { dg-final { scan-tree-dump-times "memmove" 2 "original" } }
However, the original dump has:
__builtin_memmove ((void *) &a, (void *) pstr.0, 3);
__builtin_memmove ((void *) &a, (void *) pstr.0, (integer(kind=8)) D.1558);
__builtin_memmove ((void *) &c, (void *)
--- Comment #1 from domob at gcc dot gnu dot org 2010-08-17 14:14 ---
Confirmed (from my point of view)
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bero at arklinux dot org 2010-08-17 14:15 ---
Ignore the previous comment -- it working on x86 (32bit) was caused by not
having -fgraphite-identity in the CFLAGS there. It crashes everywhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
--- Comment #8 from uros at gcc dot gnu dot org 2010-08-17 14:22 ---
Subject: Bug 45296
Author: uros
Date: Tue Aug 17 14:22:16 2010
New Revision: 163306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163306
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject
--- Comment #9 from uros at gcc dot gnu dot org 2010-08-17 14:26 ---
Subject: Bug 45296
Author: uros
Date: Tue Aug 17 14:25:52 2010
New Revision: 163307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163307
Log:
PR target/45296
* reginfo.c (globalize_reg): Reject
--- Comment #10 from ubizjak at gmail dot com 2010-08-17 14:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from mmitchel at gcc dot gnu dot org 2010-08-17 14:41
---
I have no object to the FE removing trivial code if it can do so -- but I also
think that the middle-end should be able to deduce that a function is pure
later in the process and eliminate it then.
I don't underst
--- Comment #25 from hjl dot tools at gmail dot com 2010-08-17 14:47
---
(In reply to comment #24)
> I think that's beginning to look reasonable. So the problem was that without
> alternative 2, such an add would match alternative 3 instead and be split?
>
Yes.
--
http://gcc.gnu
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|4.5.2 |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
Command line:
$ gcc -O1 -fnon-call-exceptions testcase.C
Compiler output:
$ gcc -O1 -fnon-call-exceptions testcase.C
testcase.C: In function 'void foo()':
testcase.C:23:1: error: Dead STMT in EH table
# VUSE <.MEM_10>
D.2166_8 = *a_7;
testcase.C:23:1: internal compiler error: verify_stmts failed
--- Comment #1 from zsojka at seznam dot cz 2010-08-17 15:49 ---
Created an attachment (id=21506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21506&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45310
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-17 15:57 ---
I also wonder why we can't remove such stores based on ipa-reference analysis.
Reduced testcase:
struct __attribute__ ((visibility ("default"))) fallible_t { };
const fallible_t fallible = fallible_t();
--
rgue
--- Comment #3 from domob at gcc dot gnu dot org 2010-08-17 16:00 ---
Also working on this, as suggested by Tobias in PR 29785 maybe this can be done
together.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-17 16:03 ---
Confirmed. "Works" on the 4.1 branch (there is no such verification).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-08-17 16:42 ---
We are not removing write only vars because richi told me that there is no
convenient way to tell aliasing that variable is write only. It is easy to
detect for me, but bit harder to get rid of them, since at IPA pa
--- Comment #2 from mikael at gcc dot gnu dot org 2010-08-17 16:44 ---
I'm somewhat out of date (revision 163221) and I only see 2 memmoves.
I don't see any string_trim either.
Note that the -O option changes the original tree dump.
I thought it only impacted later dumps.
--
http:
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-08-17 16:45 ---
oops, I've left IRC sentence unfinished. At IRC Richi told that FEs should not
ever produce stores to empty structs at first place, so we don't need middle
end logic of taking them away. Jakub thought that those st
--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-17 16:53 ---
Perhaps related to PR43075, before that last commit there genericization was
removing empty struct assignments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45307
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-17 17:06 ---
(In reply to comment #2)
> Note that the -O option changes the original tree dump.
> I thought it only impacted later dumps.
OK, with -O I also only get
(MEM[(c_char * {ref-all})&b] = MEM[(c_char * {ref-all})"abcd"
I have a DLL which now works fine on Windows XP SP3 build with mingw GCC 4.4.0.
However on Vista my DLL will not even get to DllMain, so I assume the libgomp
is not being loaded successfully.
Do I need a Vista compatible build of gomp? Is there a difference in the msvcrt
maybe?
--
Su
--- Comment #4 from fang at csl dot cornell dot edu 2010-08-17 17:26
---
Created an attachment (id=21507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21507&action=view)
delta reduced, day 2
Slowly being reduced by delta, day 2 ...
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #7 from domob at gcc dot gnu dot org 2010-08-17 17:38 ---
Tobias (and all): Do you think we should check for "the size of data-target
shall not be less than the size of data-pointer-object" at runtime when
-fcheck=bounds is given?
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-17 17:41 ---
It is caused by revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #9 from jason at gcc dot gnu dot org 2010-08-17 17:41 ---
But that change was largely reversed by the fix for PR 43787.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from mmitchel at gcc dot gnu dot org 2010-08-17 17:50
---
The problem with -Wuninitialized might be the same problem I've been
sermonizing about for years -- we're trying to issue sensible warnings from our
optimizers, which means that as the optimizers are perturbed, th
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-17 18:06 ---
Subject: Bug 45304
Author: jakub
Date: Tue Aug 17 18:06:18 2010
New Revision: 163311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163311
Log:
PR fortran/45304
* trans-decl.c (build_library_fu
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-17 18:08 ---
Subject: Bug 45308
Author: jakub
Date: Tue Aug 17 18:08:05 2010
New Revision: 163312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163312
Log:
PR fortran/45308
* intrinsics/date_and_time.c (da
--- Comment #11 from jason at gcc dot gnu dot org 2010-08-17 18:09 ---
There are two issues here:
1) expand_static_init decides whether a variable needs static initialization
before gimplification, and
2) Richard's MEM_REF-related change to cp_gimplify_expr caused us to stop
removing th
This bug is described here: https://bugzilla.kernel.org/show_bug.cgi?id=16612
In two words: this patch:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.35.y.git;a=commitdiff;h=568132624386f53e87575195d868db9afb2e9316
makes kernel 2.6.35.2 unusable on my PC.
The particular file that ge
--- Comment #12 from jason at gcc dot gnu dot org 2010-08-17 18:18 ---
Actually, Richard's change didn't affect this; we were already missing it
because of the complex interoperation of cp_gimplify_expr and
gimplify_modify_expr_rhs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=453
--- Comment #8 from mikael at gcc dot gnu dot org 2010-08-17 18:21 ---
(In reply to comment #7)
> Tobias (and all): Do you think we should check for "the size of data-target
> shall not be less than the size of data-pointer-object" at runtime when
> -fcheck=bounds is given?
>
Yes.
The
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-17 18:24 ---
That is not a proper bug report, see http://gcc.gnu.org/bugs.html for what
needs to be provided.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312
In the graphite branch interchange-7.c is miscompiled with the following flags:
$ gcc -O3 -fgraphite -fno-loop-block -floop-strip-mine -floop-interchange
interchange-7.c
$ ./a.out
Aborted
--
Summary: [graphite] interchange-7.c is miscompiled
Product: gcc
Versi
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirme
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-17 19:07 ---
In particular, first bisect between object files compiled without/with the
patch to find one compilation unit where the problem is, provide preprocessed
source for it (both without and with the patch) and gcc command l
--- Comment #80 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-08-17 20:17 ---
Comment #79:
-mpreferred-stack-boundary=2 adheres to the sysv ABI but it doesn't adhere to
the Linux ABI (that requires 16-byte alignment), so if you compile anything
with -mpreferred-stack-bo
--- Comment #3 from spop at gcc dot gnu dot org 2010-08-17 20:41 ---
Subject: Bug 45229
Author: spop
Date: Tue Aug 17 20:41:26 2010
New Revision: 163319
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163319
Log:
Fix PR45229: gcc.c-torture/execute/2412-4.c ICEs with -fgraphit
--- Comment #81 from jasmin at revisionfx dot com 2010-08-17 21:03 ---
(In reply to comment #80)
> Comment #79:
>
> -mstackrealign does the right thing, it realigns the stack when needed, but
> keeps it 16-byte aligned on function output. It should be used.
>
I don't have that optio
--- Comment #82 from mikulas at artax dot karlin dot mff dot cuni dot cz
2010-08-17 21:17 ---
-mstackrealign is available from gcc 4.5.0. For gcc 4.4 you can use my patch
GCC-4.4.1-ALIGN-PATCH from this bugzilla or H.J.Lu's last patch. It basically
does the same as -mstackrealign (but i
i586-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../.. -I../../librender
-I../../libcore -I../../libcore/asobj -I../../libcore/asobj/flash
-I../../libcore/swf -I../../libcore/abc -I../../libcore/parser -I../../libbase
-I../../libmedia -I../../libsound -I../../libltdl -I/usr/include/glib-2.0
-I/usr/lib/
--- Comment #1 from bero at arklinux dot org 2010-08-17 22:27 ---
Created an attachment (id=21508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21508&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45314
Compiler output:
$ gcc testcase.C
testcase.C: In member function 'void B< >::foo()':
testcase.C:10:18: internal compiler error: tree check: expected aggr_init_expr,
have call_expr in build_value_init, at cp/init.c:317
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from zsojka at seznam dot cz 2010-08-17 23:32 ---
Created an attachment (id=21509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21509&action=view)
reduced testcase
I believe the code is valid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45315
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
Command line:
$ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C
Compiler output:
$ gcc -O1 -ftree-pre -fnon-call-exceptions testcase.C
testcase.C: In function 'void foo()':
testcase.C:21:1: error: BB 3 can not throw but has an EH edge
testcase.C:21:1: internal compiler error: verify_flow_info
--- Comment #1 from zsojka at seznam dot cz 2010-08-18 01:45 ---
Created an attachment (id=21510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21510&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45316
--- Comment #17 from vapier at gentoo dot org 2010-08-18 03:23 ---
thanks for the shorter test case. could you explain why a 64bit load is used
though ? if you're looking for the address of something, and you're not going
through a pointer to that location, why isnt it a normal lea wit
--- Comment #18 from hjl dot tools at gmail dot com 2010-08-18 03:29
---
If you believe it is a gcc bug, please provide a small run-time
testcase which can be linked with any /usr/lib64/libc.a compiled
from glibc 2.12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:31 ---
It is caused by revision 144044:
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00210.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-18 03:36 ---
It is caused by revision 161655:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #19 from vapier at gentoo dot org 2010-08-18 03:39 ---
as we stated, you wont hit the bug with vanilla gcc + vanilla glibc. we also
arent absolutely stating "this is a gcc bug". our dissection of the problem
lead us from cryptsetup to glibc to what seems like a gcc miscompi
1 - 100 of 105 matches
Mail list logo