--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-16 07:06 ---
> I believe that there are related PRs that I have to find.
pr40472 comment #21 for SPREAD:
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *, size(Z
--- Comment #2 from zsojka at seznam dot cz 2010-09-16 07:20 ---
(In reply to comment #0)
> Tested revisions:
> r164228 - crash
> r163636 - crash
> r161659 - crash
typo, r161659 doesn't crash (thus it's a 4.6 regression)
4.5 r163761 compiles fine as well
--
zsojka at seznam dot cz
--- Comment #10 from mh+gcc at glandium dot org 2010-09-16 07:43 ---
(In reply to comment #9)
> Created an attachment (id=21806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21806&action=view) [edit]
> testcase
>
> Here you go. This passes at -O0 but fails at -O2. Note that the t
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 08:13 ---
Broken by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164135
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-16 08:27 ---
Seems ipa_modify_call_arguments creates incorrect MEM_REF here.
base is correctly ADDR_EXPR of a, with int * type for the ADDR_EXPR, but
offset has int ** type instead of int *. At RTL level this results in alias
set
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-16 08:50 ---
> (I have not regtested this yet.)
The (second) patch in comment #2 fixes the pr without regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45674
--- Comment #10 from rguenther at suse dot de 2010-09-16 08:50 ---
Subject: Re: Missed devirtualization
On Wed, 15 Sep 2010, hubicka at ucw dot cz wrote:
> --- Comment #9 from hubicka at ucw dot cz 2010-09-15 22:39 ---
> Subject: Re: Missed devirtualization
>
> > We fold a
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-16 08:55 ---
--- ipa-prop.c.jj 2010-09-14 15:24:45.0 +0200
+++ ipa-prop.c 2010-09-16 10:47:14.0 +0200
@@ -2185,7 +2185,8 @@ ipa_modify_call_arguments (struct cgraph
if (TREE_CODE (base) == ADDR_EXPR
&& DE
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 09:30 ---
With seeing .clone in fn names I suppose this is ipa-cp or ipa-sra.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 09:35 ---
Subject: Bug 45686
Author: jakub
Date: Thu Sep 16 09:35:02 2010
New Revision: 164330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164330
Log:
PR bootstrap/45686
* fold-const.c (fold_checksum_
--- Comment #9 from paul dot richard dot thomas at gmail dot com
2010-09-16 09:43 ---
Subject: Re: [4.3/4.4/4.5/4.6 Regression] ICE in
gfc_conv_array_initializer, at fortran/trans-array.c:4208
Thanks! Paul
On Thu, Sep 16, 2010 at 9:06 AM, dominiq at lps dot ens dot fr
wrote:
>
>
>
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-16 10:17 ---
DECL_ALIGN of d is set to 128 (but appearantly it isn't ensured it'll end up
that way). DECL_ALIGN is adjusted here:
Old value = 32
New value = 128
expand_one_stack_var_at (decl=0x75ae90a0, offset=-16)
at /
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-16 10:18 ---
Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view)
patch to fix "half STRICT_ALIGNMENT" targets memcpy folding
Might need this patch to fix as well. i?86 / x86_6
> HP-UX system header files may use version level functioning for some system
> calls.
This is a very amusing (what I assume to be) typo in the documentation of
function-level versioning.
Not sure this is the right bug tracker but this is one that I know...
--
Summary: Typo in __a
--- Comment #1 from dascandy at gmail dot com 2010-09-16 10:23 ---
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
The link where the typo is to be found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-16 10:40 ---
Re: #c4, shouldn't there be srcvar = NULL_TREE; somewhere for the
STRICT_ALIGNMENT non-aligned case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
While playing with modifications of PR4581, I tried
module m
implicit none
type t
integer :: i
end type t
type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /)
type(t), dimension(2), parameter :: d = cshift ( a1, 1 )
end module m
and got
pr45081_red.f90:7.43:
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 10:42 ---
pasto!-(
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Summary|CSHIFT an
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 10:50 ---
Missing some else indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-09-16 11:06
---
Subject: Bug 45623
Author: rguenth
Date: Thu Sep 16 11:06:25 2010
New Revision: 164333
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164333
Log:
2010-09-16 Richard Guenther
PR tree-optimizatio
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-09-16 11:07
---
Fixed for trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 ---
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the functions are not properly simplified and thus not constant.
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyword
--- Comment #11 from laurent at guerby dot net 2010-09-16 11:49 ---
With --with-arch=armv5te --with-tune=xscale I get the comparison failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-16 11:57 ---
For the ix86/x86_64 alignment issue, I believe the problem here is that
max_align = MAX (crtl->max_used_stack_slot_alignment,
PREFERRED_STACK_BOUNDARY);
is fine for !SUPPORTS_STACK_ALIGNMEN
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 12:09 ---
PR 45679 also reproduce during -O3 build. I am testing patch for it now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 ---
(In reply to comment #3)
> Thanks for the quick fix!
Well, it was *your* fix, so *I* should thank *you* :)
Anyway, I think the patch in comment #2 qualifies as obvious, and has no
regressions, as noted by Dominique.
--- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25
---
Hmm, so do you have any idea where folding should be added for this particular
case?
It always seemed to me that it would make sense to add verifier that all
statements are folded (locally, not by looking at SSA g
--- Comment #12 from rguenther at suse dot de 2010-09-16 12:31 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, hubicka at gcc dot gnu dot org wrote:
> --- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25
> ---
> Hmm, so do you have any idea wher
--- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 ---
Subject: Re: Missed devirtualization
> I'm lost in this PR - for what testcase what statement needs folding
> (and what pending patches do I need to apply to see that)?
PR is tracking missed optimization in the testcase in
--- Comment #14 from rguenther at suse dot de 2010-09-16 12:51 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, hubicka at ucw dot cz wrote:
> --- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 ---
> Subject: Re: Missed devirtualization
>
> > I'm lost
--- Comment #8 from hjl dot tools at gmail dot com 2010-09-16 13:02 ---
This also failed:
---
typedef float V __attribute__ ((vector_size (16)));
V g;
float d[4] = { 4, 3, 2, 1 };
int
main ()
{
V e;
__builtin_memcpy (&e, &d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g
--- Comment #20 from dominiq at lps dot ens dot fr 2010-09-16 13:03 ---
The test in comment #0 now gives (with/without -std=g95)
pr25104.f90:3.5:
CASE(MAXLOC(K,1))
1
Error: transformational intrinsic 'maxloc' at (1) is not permitted in an
initialization expression
for 4.4.4, 4.5.
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-16 13:05 ---
If __builtin_memcpy generates instructions which
require bigger alignment than alignments of
source or destination, it should increase the
alignment of source or destination.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-16 13:09 ---
MAXLOC and MINLOC are also missing (see pr25104).
> They are not, as there, afaik, are no simplifiers yet.
>
> Hence, with your patch they will be accepted, but you'd end up with wrong code
> at the end, as the funct
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-16 13:10
---
When __builtin_memcpy increases the alignment of source
or destination, it should update needed stack alignment if
source or destination is on stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-16 13:13 ---
Subject: Bug 45674
Author: janus
Date: Thu Sep 16 13:12:59 2010
New Revision: 164338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164338
Log:
2010-09-16 Janus Weil
PR fortran/45674
* inte
--- Comment #7 from janus at gcc dot gnu dot org 2010-09-16 13:14 ---
Fixed with r164338. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-16 13:14 ---
(1) The patch in comment #7 fixes this pr without regression.
(2) If I replace
type(t), dimension(1), parameter :: a1 = (/ t(1) /)
type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1 /) )
wi
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-16 13:21
---
This code:
if (TREE_CODE (srcvar) == ADDR_EXPR
&& var_decl_component_p (TREE_OPERAND (srcvar, 0))
&& tree_int_cst_equal (TYPE_SIZE_UNIT (srctype), len)
&& (!STRICT_ALIGNMENT
--- Comment #12 from hjl dot tools at gmail dot com 2010-09-16 13:32
---
(In reply to comment #4)
> Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view) [edit]
> patch to fix "half STRICT_ALIGNMENT" targets memcpy folding
>
> Might nee
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-16 13:39
---
(In reply to comment #12)
> (In reply to comment #4)
> > Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view) [edit]
> > patch to fix "half STRICT_ALIGNMENT" targe
--- Comment #12 from bernds at gcc dot gnu dot org 2010-09-16 13:50 ---
(In reply to comment #6)
> So stage1 chooses adds but stage2 and stage3 choose lsls for << of the lower
> half of a long long. Since the behaviour of a stageN xgcc depends on both the
> gcc source code and the compi
--- Comment #14 from jakub at gcc dot gnu dot org 2010-09-16 13:54 ---
The reason why cfgexpand does increase the alignment is that it believes that
the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is
true on all targets but i?86/x86-64, which apparently somet
--- Comment #15 from hjl dot tools at gmail dot com 2010-09-16 13:54
---
Created an attachment (id=21810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21810&action=view)
A patch
This patch adds HARD_ALIGNMENT_MODE_P and works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #16 from hjl dot tools at gmail dot com 2010-09-16 13:59
---
(In reply to comment #13)
> With that patch the assignment generated from memcpy doesn't need more
> that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
> decl to 128 so expand uses aligned instructio
hi,
on the recent 4.5 branch i have a problems with dwarf4 and pretty printers.
here's steps to reproduce:
$ make
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.cpp -gdwarf-3 -g2 -o t-dw3
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.
--- Comment #1 from pluto at agmk dot net 2010-09-16 14:01 ---
Created an attachment (id=21811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21811&action=view)
source, makefile and precompiled binaries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
--- Comment #10 from pluto at agmk dot net 2010-09-16 14:04 ---
(In reply to comment #9)
> Are you sure you haven't modified your GCC sources?
i'm testing gcc-4.5 from svn branch, with gdb-7.2 and binutils-2.20.51.0.11.
filled as PR45690.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #17 from jakub at gcc dot gnu dot org 2010-09-16 14:08 ---
That's true. But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code. If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY ev
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-16 14:13
---
(In reply to comment #16)
> (In reply to comment #13)
>
> > With that patch the assignment generated from memcpy doesn't need more
> > that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
> > decl to 1
--- Comment #19 from hjl dot tools at gmail dot com 2010-09-16 14:17
---
(In reply to comment #17)
> That's true. But many expanders can make use of DECL_ALIGN information, e.g.
> to choose faster code. If cfgexpand keeps doing what it does now, namely
> bumping DECL_ALIGN of variable
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-09-16 14:22
---
The patch in comment #4 makes memcpy folding not lie about alignment.
cfgexpand still lies about alignment though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #21 from hjl dot tools at gmail dot com 2010-09-16 14:30
---
(In reply to comment #20)
> The patch in comment #4 makes memcpy folding not lie about alignment.
X86 only cares about alignment for vector modes.
Can we combine 2 patches into one?
> cfgexpand still lies about a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||wrong-code
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-09-16 14:55
---
Like
Index: gimplify.c
===
--- gimplify.c (revision 164333)
+++ gimplify.c (working copy)
@@ -2477,10 +2477,13 @@ gimplify_call_expr (tree *expr_p,
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
---
(In reply to comment #15)
> Like
>
> Index: gimplify.c
> ===
> --- gimplify.c (revision 164333)
> +++ gimplify.c (working copy)
> @@ -2477,10 +2477
--- Comment #17 from rguenther at suse dot de 2010-09-16 16:06 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, jamborm at gcc dot gnu dot org wrote:
>
>
> --- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
> ---
> (In reply to comment #15)
>
--- Comment #3 from ro at gcc dot gnu dot org 2010-09-16 16:37 ---
Subject: Bug 44763
Author: ro
Date: Thu Sep 16 16:37:01 2010
New Revision: 164341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164341
Log:
Record PR middle-end/44763 in ChangeLog.
Modified:
trunk/gcc/Chang
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-16 16:43 ---
Fixed for 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-09-16 16:54
---
(In reply to comment #12)
> I think it's likely there really is a miscompilation. I've not been able to
> get very far trying to set up a native compiler to run on qemu, so it would
> help if you could try to nar
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-09-16 16:56 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
That's true. Inter
After upgrading to gcc 4.5.0 from 3.3.4, some of my floating point code fails.
Searched for and could not find a matching bug. It boils down to this very
simple example:
#include
#define MY_PI 3.14159265358979323846
int main()
{
double z = MY_PI;
puts(z == MY_PI ? "==" : "!=");
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 17:02 ---
pr323?
As a general rule: never compare floating points for equality, use
abs(a-b)http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
I think this is cove
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-16 17:08
---
As an even more general rule, remember to always specify your target: in this
case, for example, I can't reproduce at all the behavior on x86_64 -m64, only
with -m32.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 ---
*** This bug has been marked as a duplicate of 323 ***
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08
---
*** Bug 45691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double. The assignment of the constant to a double var or expl
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-16 17:15
---
Thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
--- Comment #4 from spop at gcc dot gnu dot org 2010-09-16 17:19 ---
Subject: Bug 45680
Author: spop
Date: Thu Sep 16 17:19:25 2010
New Revision: 164345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164345
Log:
Fix PR45680.
2010-09-16 Reza Yazdani
PR bootstrap/4568
--- Comment #5 from spop at gcc dot gnu dot org 2010-09-16 17:21 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-16 17:36 ---
Hmm, the problem is that foo is virtual self recursive function.
We inline it and then indirect inlining decide that it can devirtualize the
self recursive call since it knows the operand has proper type.
At that tim
--- Comment #6 from ian at macky dot net 2010-09-16 17:44 ---
Subject: Re: Floating point comparison failure
Thanks everyone. I usually do fuzzy floating-point comparison, except in
certain special circumstances. I will switch to using double constants;
I'm trying for a code that is
--- Comment #11 from dherring at tentpost dot com 2010-09-16 18:54 ---
FWIW, the example given in the C++ draft spec, section 9.5, fails to compile in
g++, even under version 4.5 with the -std=c++0x flag. (This example has been
there for a few years.)
Coupled with requirements such as
Since the test objc/execute/exceptions/throw-nil.m has been introduced at
revision 164024, it has failed on *-apple-darwin* with -m32, see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00816.html
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00835.html
--
Summary: FAIL: objc/ex
Between 20100607 and 20100624, all Tru64 UNIX V5.1B EH tests started to fail,
e.g.
FAIL: g++.old-deja/g++.mike/eh33.C execution test
This testcase segfaults like this:
Program received signal SIGSEGV, Segmentation fault.
__cxa_call_unexpected (exc_obj_in=0x70)
at /vol/gcc/src/hg/trunk/local/
Hi,
(i first reported this to mingw32-w64's bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3067541&group_id=202880&atid=983354
and was forwarded here)
The attached fortran program aborts() (a host associated variable
changes value from host to hostee without asking) using
gfortran -O
--- Comment #1 from jpr at csc dot fi 2010-09-16 19:31 ---
Created an attachment (id=21812)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812&action=view)
failing fortran code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
--- Comment #2 from pluto at agmk dot net 2010-09-16 21:02 ---
ha, my gcc was built with: export CXXFLAGS="-O2"; ./configure
--disable-shared..."
and this CXXFLAGS afaics affects libstdc++.a debuginfo level.
with CXXFLAGS="-O2 -g2" the python pretty printer works fine.
testcase compiled
--- Comment #26 from burnus at gcc dot gnu dot org 2010-09-16 21:30 ---
Subject: Bug 43665
Author: burnus
Date: Thu Sep 16 21:30:05 2010
New Revision: 164348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164348
Log:
2010-09-16 Tobias Burnus
PR fortran/43665
$ebx is left uninitialized for not-equal comparison.
Compilation flags: -O1
it passes = exit code 0 = with -O0
it fails = exit code 1 = with -O1
PASS: gcc (GCC) 4.4.5 20100916 (prerelease)
FAIL: gcc (GCC) 4.5.2 20100916 (prerelease)
PASS: gcc (GCC) 4.6.0 20100916 (experimental)
FAIL: gcc-4.5.1-3
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 21:57 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163555
change, so will look into it tomorrow.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21560&action=view
doesn't break it, only the version that tries
--- Comment #8 from t7 at gmail dot com 2010-09-16 21:58 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
This is very odd, becaus
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, GC, ice-on-valid-code
Summary|Dangling reference ab
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-16 22:00 ---
GC issues normally don't show at different times depending on the layout of
memory and such. Sometimes it depends on env variables being slightly
different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #10 from t7 at gmail dot com 2010-09-16 22:03 ---
Program received signal SIGSEGV, Segmentation fault.
gt_ggc_mx_cpp_macro (x_p=) at gtype-desc.c:2078
2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE
(((*x).params[i0]))) : NULL;
(gdb) bt
#0 gt_ggc
--- Comment #11 from t7 at gmail dot com 2010-09-16 22:06 ---
But too bad this file 'gtype-desc.c' is automatically generated at build time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #12 from jakub at gcc dot gnu dot org 2010-09-16 22:28 ---
Can you try compiling it with
--param ggc-min-expand=0 --param ggc-min-heapsize=0
? Perhaps you'll trigger it then more reliably...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #13 from t7 at gmail dot com 2010-09-16 22:33 ---
(In reply to comment #12)
> Can you try compiling it with
> --param ggc-min-expand=0 --param ggc-min-heapsize=0
> ? Perhaps you'll trigger it then more reliably...
>
Without it:
GGC heuristics: --param ggc-min-expand=30
--- Comment #49 from LpSolit at netscape dot net 2010-09-16 22:51 ---
(In reply to comment #48)
> The current bugzilla has
> extra separating lines with the column names. The new installation does not.
Yeah, it is so by design. Not something I'm going to reimplement.
Note that we fina
--- Comment #3 from ekuznetsov at divxcorp dot com 2010-09-16 23:08 ---
Created an attachment (id=21813)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21813&action=view)
Output of gcc -v -O3 gcc-bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
Using gcc 4.6.0 20100915 trunk revision 164317
Using the preprocessor on following piece:
--8<--
error_identifiers: \
kErr_AlreadyWaitingForGDB("Already waiting for a GDB to connect")
--8<--
gcc -E gives me:
--8<--
# 1 "test-preprocess.c"
# 1 ""
# 1 ""
# 1 "test-preprocess.c"
error-iden
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
typedef unsigned char uint8_t;
void f(uint8_t __restrict__ foo[]) {
// no warnings/errors
}
void f2(unsigned char __restrict__ foo[]) {
// doesn't compile::
// test.cc:6: error: __restrict__ qualifiers cannot be applied to unsigned
char
}
The two functi
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 ---
C preprocessor is not a generic preprocessor. The continuation character is
removed so the correct line number is used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from John dot Tytgat at aaug dot net 2010-09-17 00:04
---
I don't understand why the continuation character should be removed. For the C
parser that character is not special (only for the C preprocessor it is), nor
it confuses its line number accountancy. Or am I mistake
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 ---
(In reply to comment #2)
> I don't understand why the continuation character should be removed. For the C
> parser that character is not special (only for the C preprocessor it is), nor
> it confuses its line number
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 00:27 ---
Hmm, so actually it is really difference in gold.
System gold on evans is
GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.
while one I use is
GNU gold (GNU Binutils 2.20.51.20100706) 1.9
yo
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-09-17 00:28 ---
Gold shipped with SLES:
GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.
is known to have problems leading to PR45194
The following version: GNU gold (GNU Binutils 2.20.51.20100706) 1.9
wor
1 - 100 of 109 matches
Mail list logo
