--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-16 07:10 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-16 07:11 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jakub at gcc dot gnu dot org 2007-11-16 07:06 ---
Subject: Bug 34100
Author: jakub
Date: Fri Nov 16 07:06:25 2007
New Revision: 130220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130220
Log:
PR c++/34100
* pt.c (apply_late_template_attribut
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-16 07:03 ---
Subject: Bug 30460
Author: jakub
Date: Fri Nov 16 07:02:49 2007
New Revision: 130219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130219
Log:
PR driver/30460
* gcc.c (init_spec): Don't initia
--- Comment #12 from eres at il dot ibm dot com 2007-11-16 06:48 ---
Created an attachment (id=14562)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14562&action=view)
gcda file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-16 06:23
---
program test
implicit none
call sub(1)
call sub()
contains
subroutine sub(dimmy)
integer, optional :: dimmy
logical :: lotto(4)
lotto = .false.
lotto = cshift((/.true.,.true.,.true.,.true./),1,dimm
--- Comment #8 from kuba at et dot pl 2007-11-16 01:19 ---
i've tried to understand it but i can't. Can anyone explain me..
Why does coalesce_partitions (tree-ssa-coalesce.c) fail after unsuccessful
attempt_coalesce? what is the difference if it is abnormal edge, or not?
--
http://g
Please see the following thread in IBM's CELL BE Forum for more details:
http://www-128.ibm.com/developerworks/forums/thread.jspa?threadID=182669
--
Summary: GCC for CELL processor does NOT relocate properly with
Optimization Turned on.,
Product: gcc
--- Comment #5 from hjl at lucon dot org 2007-11-16 04:52 ---
The correct patch is at
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00885.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001
--- Comment #7 from schlie at comcast dot net 2007-11-16 02:35 ---
Subject: Re: Initializing string literal data
improperly marked frame-relative?, should be readonly static const.
I believe so.
> From: manu at gcc dot gnu dot org <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-16 01:52 ---
(In reply to comment #3)
> Here's another example, which I think may represent a different case (and
> which
> I found much more surprising than the first):
> no_loop_opt2.c:5: warning: cannot optimize possibly inf
--- Comment #9 from schlie at comcast dot net 2007-11-16 02:35 ---
Subject: Re: Small targets without 64 bit long long
support are can't bootstrap GCC.
submitted, a long while ago; but honestly haven't been tracking things
lately.
> From: manu at gcc dot gnu dot org <[EMAIL PROTECTE
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-11-16 02:38 ---
(In reply to comment #2)
> Is there be any way to modify the code such that GCC would have an easier time
> seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
> __assert_fail is marked with noretur
--- Comment #5 from lloyd at randombit dot net 2007-11-16 02:00 ---
Argh, you are correct. The original code has
unsigned int n = an_input / 160;
so this could never occur there, but GCC's inability to tell that this
assignment means that n cannot be UINT_MAX (in that code) is clearl
--- Comment #3 from lloyd at randombit dot net 2007-11-16 01:49 ---
Here's another example, which I think may represent a different case (and which
I found much more surprising than the first):
$ cat no_loop_opt2.c
void g(unsigned int n)
{
unsigned int k;
for(k = 0; k <= n; +
--- Comment #6 from j at uriah dot heep dot sax dot de 2007-11-15 21:21
---
I'm not sure whether this is related or not... but from the description, it
looks so.
avr-libc contains a macro that helps the users declaring a flash-ROM string,
lacking any real support in GCC for different m
--- Comment #6 from scovich at gmail dot com 2007-11-16 01:04 ---
(In reply to comment #5)
> Subject: Re: atomic builtins not supported on i686?
>
> On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
> <[EMAIL PROTECTED]> wrote:
> > > Because the default arch for i686-linux-
--- Comment #4 from pcarlini at suse dot de 2007-11-16 00:07 ---
Yeah, the wind is changing!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
--- Comment #5 from scovich at gmail dot com 2007-11-16 01:00 ---
Subject: Re: atomic builtins not supported on i686?
On 15 Nov 2007 23:53:06 -, joseph at codesourcery dot com
<[EMAIL PROTECTED]> wrote:
> > Because the default arch for i686-linux-gnu is i386.
> Which is a stupid in
--- Comment #2 from lloyd at randombit dot net 2007-11-16 00:50 ---
Is there be any way to modify the code such that GCC would have an easier time
seeing this? I tried using 'assert(rnd_to_2 % 2 == 0)' (since glibc's
__assert_fail is marked with noreturn I thought it might help), but tha
--- Comment #3 from joseph at codesourcery dot com 2007-11-15 23:53 ---
Subject: Re: atomic builtins not supported on i686?
On Thu, 15 Nov 2007, pinskia at gcc dot gnu dot org wrote:
> Because the default arch for i686-linux-gnu is i386.
Which is a stupid inconsistency and arguably a
--- Comment #1 from steven at gcc dot gnu dot org 2007-11-15 23:31 ---
We may be able to propagate somehow that rnd_to_2 is always even. I doubt it
is worth the trouble, to be honest... Zdenek may have some thought on this.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #2 from mueller at gcc dot gnu dot org 2007-11-15 23:17 ---
reduced testcase:
class QChar
{
};
struct QString
{
QString(QChar);
};
struct QPainter
{
void drawText (int x, int y, const QString &);
};
class KHEChar:public QChar
{
public:KHEChar (QChar C);
};
void
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-15 22:19 ---
Because the default arch for i686-linux-gnu is i386.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34115
Hi
I've just built the 4.2-20071107 snapshot and got the folowing warning that I
think you will want to know about.
../../../libjava/classpath/gnu/java/security/util/Base64.java: In class
'gnu.java.security.util.Base64':
../../../libjava/classpath/gnu/java/security/util/Base64.java: In method
--- Comment #2 from pcarlini at suse dot de 2007-11-15 22:30 ---
I think this is essentially invalid. Note that now we also have the various
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros:
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
--
http://gcc.gnu.org/bugzilla/
Linking fails for the program below, with the error:
undefined reference to `___sync_val_compare_and_swap_4'
// gcc -Wall atomic.c
int main() {
int *a, b, c;
return __sync_val_compare_and_swap(a, b, c);
}
According to the atomic builtins docs (), "Not all operations are supported by
all targ
--- Comment #9 from bkoz at gcc dot gnu dot org 2007-11-15 21:54 ---
Awesome. Looks good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
--- Comment #8 from patchapp at dberlin dot org 2007-11-15 20:05 ---
Subject: Bug number PR c++/5310
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00865.html
--
http://gcc.gnu.org/bugzill
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-15 19:03 ---
Subject: Bug 23848
Author: jakub
Date: Thu Nov 15 19:02:54 2007
New Revision: 130206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130206
Log:
PR middle-end/23848
* tree-ssa-ccp.c (optimize_st
--- Comment #6 from rsandifo at gcc dot gnu dot org 2007-11-15 20:52
---
Fixed on mainline, and not appropriate for backporting.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in |[4.3 Regression] ICE in
|get_addr_dereference_opera
As far as I can see the loop in the function f() always terminates without the
loop counter overflowing, but GCC cannot tell that it does.
$ g++-4.3-20070907 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070907/configure --program-suffix=-4.3-20070907
--en
--- Comment #2 from dirtyepic at gentoo dot org 2007-11-15 20:06 ---
Created an attachment (id=14561)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14561&action=view)
access-mini.i
further reduced.
--
dirtyepic at gentoo dot org changed:
What|Removed
--- Comment #3 from simon_baldwin at yahoo dot com 2007-11-15 19:55 ---
The definition's really there in 4.2.1, absent in 4.1.1:
$ 4.2.1/g++ -S ns1.cc && c++filt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34094
--- Comment #6 from pcarlini at suse dot de 2007-11-15 18:14 ---
I'm finishing testing a complete patch.
--
pcarlini at suse dot de changed:
What|Removed |Added
A
--- Comment #1 from dirtyepic at gentoo dot org 2007-11-15 19:34 ---
Created an attachment (id=14560)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14560&action=view)
access-min.i
preprocessed source reduced by delta.
# gcc -v -O2 access-min.i
Using built-in specs.
Target: x86_64
--- Comment #6 from jakub at gcc dot gnu dot org 2007-11-15 19:37 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #8 from pcarlini at suse dot de 2007-11-15 19:07 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
while compiling xorg-server-1.4 with GCC trunk rev 130172.
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE
-DHAS_FCHOWN -DHAS_STIC
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-15 19:25 ---
For stdcall and @n decoration, see also PR 31073.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112
--- Comment #7 from paolo at gcc dot gnu dot org 2007-11-15 19:05 ---
Subject: Bug 34105
Author: paolo
Date: Thu Nov 15 19:05:17 2007
New Revision: 130207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130207
Log:
2007-11-15 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-11-15 18:53 ---
I think this is already fixed in 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from mueller at gcc dot gnu dot org 2007-11-15 18:21 ---
temp_stack.reg[i_90] is the access, compare_for_stack_reg is the function,
and i_90 has the VRP determined range [-1, 2147483646].
it shouldn't warn for that. I'll work on a patch.
--
mueller at gcc dot gnu do
32bit Windows uses a different calling convention (called procedure pops the
stack, not caller) with a symbol name _@n, where n is the number of bytes
to pop off.
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/19d77dfc75f8be58
http://gcc.gnu.org/ml/fortran/2007-11/
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 17:43 ---
This is either a bug or not. I think that if it is not mere constant folding
and it takes some effort, we should not do it. So let's decide so we can either
confirm it or close it as invalid.
--
manu at gcc dot gnu
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-11-15 17:10
---
Trivial testcase we get wrong with the current scheme:
int foo (int b, int c)
{
int x;
if (b)
return x & c;
else
return 1;
}
extern void abort (void);
int main()
{
if (foo(1, 0) != 0)
abort ();
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-15 17:40 ---
>From bug 26168:
"gcc/gcc.c has a comment at the top that's a guide to adding a command line
option. It's incomplete: it should say to add the new option to c.opt and
rebuild the compiler, and then describe how the va
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:35 ---
This patch is just a guess but it seems to fix this:
Index: gcc/gcc.c
===
--- gcc/gcc.c (revision 130174)
+++ gcc/gcc.c (working copy)
@@ -841,9 +841,
--- Comment #4 from patchapp at dberlin dot org 2007-11-15 15:10 ---
Subject: Bug number PR34079
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00851.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from mueller at gcc dot gnu dot org 2007-11-15 16:55 ---
Created an attachment (id=14559)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14559&action=view)
the preprocessed source
.ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-15 17:42 ---
Testing a patch which addresses the simple pointer va_list targets (i386,
non-v4-abi ppc{,64}, etc.).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:41 ---
*** This bug has been marked as a duplicate of 19180 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 17:41 ---
*** Bug 26168 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-11-15 16:40
---
Confirmed on x86_64-linux, where it triggers (with valgrind):
==2841== Conditional jump or move depends on uninitialised value(s)
==2841==at 0x43550B: next_char (io.c:141)
==2841==by 0x435616: next_char_n
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-11-15 17:17
---
I think this has been caused by the fix for PR29738.
Author: rakdver
Date: Thu Nov 9 00:09:43 2006
New Revision: 118602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118602
Log:
PR tree-optimizat
--- Comment #1 from manu at gcc dot gnu dot org 2007-11-15 17:16 ---
Confirmed. Probably some issue with the default specs.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
When I compile my program without optimization (-O2 or -O3), it works
normally. However when I compile the code with -O2 or -O3 (GCC version
4.1), my program output wrong data. In addition, I did not see this
problem when I used GCC 3.4.6.
Information regarding my GCC:
OS: Centos 5 (a clone
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 17:05 ---
This is confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-15 16:45 ---
Closing then.
(The link you gave is broken. A more stable link is
http://gcc.gnu.org/onlinedocs/gccint/Storage-Layout.html
)
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-15 17:03 ---
I think it is odd that if you call subr(i,0), it doesn't crash, that is &(p->a)
does not actually dereferences p. Nonetheless, I agree that the behaviour seems
inconsistent. A nice little project for someone. As they sa
this used to work a few days ago still:
--
Summary: new oveload resolution error
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assign
--- Comment #3 from manu at gcc dot gnu dot org 2007-11-15 16:39 ---
It also works in GCC 4.3.0.
If you still experience this issue, please, don't hesitate to reopen the bug.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-11-15 16:38
---
Oh, trivial error. Looking again tomorrow.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from manu at gcc dot gnu dot org 2007-11-15 16:30 ---
So, is this a bug or not? Do we know how icc resolves the ambiguity?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
SVN head does not build due to a warning that is treated as error.
gcc.build.lnx/./prev-gcc/xgcc
-B/gcc-b98ac6987827a195a1492167a9a158bf/gcc.build.lnx/./prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-protot
--- Comment #5 from manu at gcc dot gnu dot org 2007-11-15 16:19 ---
Is this still a valid bug?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
In the following code, the tail call in g() is compiled incorrectly on ARM with
-O2 or higher (and -fno-inline):
#include
struct s {
int x, y, z;
};
int f(int a, int b, int c, struct s d, int e) {
printf("%d %d %d\n", d.x, d.y, d.z);
return 0;
}
int g(int a, int b, int c, int d, st
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44
---
> That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
> constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
Is the problem somehow related to PR middle-end/33088?
--- Comment #10 from burnus at gcc dot gnu dot org 2007-11-15 15:12 ---
Subject: Bug 33917
Author: burnus
Date: Thu Nov 15 15:12:03 2007
New Revision: 130202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130202
Log:
2007-11-15 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-11-15 16:08
---
Created an attachment (id=14558)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14558&action=view)
new broken patch
Err, that was an old patch.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-11-15 16:06 ---
Created an attachment (id=14557)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14557&action=view)
broken patch
It miscompiles gengtype. I remember problems with changing likely_value in
similar ways back in t
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-11-15 16:04 ---
Which doesn't work :( Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from eres at il dot ibm dot com 2007-11-15 15:02 ---
(In reply to comment #9)
> I mean the files you generate with -fprofile-generate.
> I expect this to be fully blamable on the partitioning code, and I would like
> to work in fixing this. But you have to attach the pro
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-15 15:53 ---
I cannot reproduce this problem with any of 4.1, 4.2 or 4.3. But the issues
raised look related the CCP problem in PR34099.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-15 14:57
---
There is a good chance that if you try to build the runtime library with
malign-double that you will break it. My recommendation is don't use
-malign-double for I/O related things.
--
http://gcc.gnu.org/bugz
--- Comment #7 from rguenther at suse dot de 2007-11-15 15:51 ---
Subject: Re: [4.3 Regression] optimizer problem
On Thu, 15 Nov 2007, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-11-15 15:44
> ---
> > That is, a certain
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-15 15:40 ---
That is, a certain class of operations (like COMPLEX_EXPR) do not fulfil the
constraint that if one operand is UNDEFINED the result is UNDEFINED as well.
For example MIN_EXPR , or MAX_EXPR
are of such kind as well.
--- Comment #11 from burnus at gcc dot gnu dot org 2007-11-15 15:18 ---
FIXED on the trunk (4.3.0) [is not part of any branch].
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from manu at gcc dot gnu dot org 2007-11-15 15:39 ---
What happened to this patch?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-15 15:10 ---
See also:
http://gcc.gnu.org/ml/fortran/2007-11/msg00074.html
and for the patch:
http://gcc.gnu.org/ml/fortran/2007-11/msg00093.html
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pault at gcc dot gnu dot org 2007-11-15 15:19 ---
(In reply to comment #4)
> (In reply to comment #3)
> Bother, the patch causes some regressions (interface_[3-5].f90)...
> Paul
These were easily fixed - also nested_modules_1.f90 was not standard compliant
in this re
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-11-15 15:08 ---
This looks like this old bug that evaluate_stmt() sets results to UNDEFINED.
As
we visit
D.26933_16 = __t_14 * D.26932_15;
the result should become VARYING, but we make it UNDEFINED. Because also
likely_value ()
--- Comment #11 from eres at il dot ibm dot com 2007-11-15 15:05 ---
Created an attachment (id=14556)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14556&action=view)
File generated by -fprofile-generate
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-11-15 14:56 ---
Uhm, this goes wrong in CCP. (w/o SRA the failure doesn't trigger though)
Before CCP we have:
void multiply(NumType, NumType, unsigned int, NumType&) (a, b, ac, ab)
{
double s$_M_value$real;
double s$_M_value
--- Comment #9 from steven at gcc dot gnu dot org 2007-11-15 14:49 ---
I mean the files you generate with -fprofile-generate.
I expect this to be fully blamable on the partitioning code, and I would like
to work in fixing this. But you have to attach the profile information you
have ge
--- Comment #2 from pcarlini at suse dot de 2007-11-15 13:04 ---
Created an attachment (id=14555)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14555&action=view)
Draft patch for normal mode
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
--- Comment #8 from eres at il dot ibm dot com 2007-11-15 14:17 ---
When disabling rest_of_handle_reorder_blocks (bbro) the ICE disappears. (it
seems that it is not caused due to the partitioning - bbpart)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #18 from tom_francen at midtechcorp dot com 2007-11-15 13:46
---
Subject: Re: gcj seems not to pass the option to ld correctly
thank you wilson ... i just tried suggestion #6 ... and it WORKED!! thank you
very much!!
tjf
---
Thomas James Francen
Midwest
--- Comment #1 from pcarlini at suse dot de 2007-11-15 13:32 ---
intptr is not initialized: when i is destructed it calls delete on the owned
pointer, that is intptr, and anything can happen. Just initialize intptr to
zero or to a value returned by new.
--
pcarlini at suse dot de cha
--- Comment #4 from pcarlini at suse dot de 2007-11-15 13:09 ---
By the way, while we are talking about those QoI issues, I think it's in any
case better not including something like algorithmfwd.h in algobase.h: it's
relatively big and we are doing our best to keep algobase.h, the core
--- Comment #3 from pcarlini at suse dot de 2007-11-15 13:06 ---
Something like the attached (lightly tested) fixed the problem for normal mode,
the error becomes:
34105.cc: In function int main():
34105.cc:8: error: find is not a member of std
however, it doesn't for parallel mo
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-15 11:26 ---
-malign-double changes the ABI. You need to rebuild libgfortran with that
option.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pcarlini at suse dot de 2007-11-15 13:10 ---
I meant bits/stl_algobase.h, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34105
--- Comment #9 from patchapp at dberlin dot org 2007-11-15 12:35 ---
Subject: Bug number PR33917
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00842.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from eres at il dot ibm dot com 2007-11-15 12:29 ---
(In reply to comment #6)
> I can't reproduce this on x86*.
> Again, please attach the profile information and state the exact compiler
> revision you used to generate this profile information.
Sorry - I am working on r
--- Comment #1 from pault at gcc dot gnu dot org 2007-11-15 10:54 ---
Jens,
I cannot reproduce this bug, even with the same flags that you are using, under
Cygwin_NT and last night's build. I will check on a Linux system tonight.
I have downrated the severity because "critical" refers
I use gfortran on cygwin.
% wget
http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.3-Cygwin-i686.tar.bz2
% tar fjx gfortran-4.3-Cygwin-i686.tar.bz2 -C /
I get a segmentation fault when compiling program contains a simple write
statement.
% cat zerolabel.f95
write(*,0)
% /usr/local/gfortra
--- Comment #5 from eres at il dot ibm dot com 2007-11-15 12:04 ---
It seems that verify_flow_info complains about the following note,
which is generated in the partitioning phase:
(note 234 232 172 11 NOTE_INSN_SWITCH_TEXT_SECTIONS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-15 12:21 ---
I can't reproduce this on x86*.
Again, please attach the profile information and state the exact compiler
revision you used to generate this profile information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=340
1 - 100 of 126 matches
Mail list logo
