--- Comment #19 from rguenth at gcc dot gnu dot org 2006-11-15 07:40
---
Bootstrapping / regtesting a backported patch (to 4.1) is fine on ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29797
--- Comment #20 from jakub at gcc dot gnu dot org 2006-11-15 07:37 ---
Looking at i386 backend, also (const (plus (unspec (something)) (const_int)))
is special (a whole bunch of routines rely on the unspec being surrounded
by CONST, optionally with a PLUS in there).
Not sure if make_tree
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-11-15 07:29 ---
fold_convert cannot handle casts between aggregates (what would that be
anyway...), but only scalars (including pointers). But it also has an early
out
in case of the types are equal already, so in this case it is "
--- Comment #2 from raj dot khem at gmail dot com 2006-11-15 06:17 ---
Yeah it worked fine when configured --target=i686-*-linux-gnu but not with
--target=i586-*-linux-gnu --with-cpu=i586
--
raj dot khem at gmail dot com changed:
What|Removed |A
--- Comment #3 from brooks at gcc dot gnu dot org 2006-11-15 06:05 ---
It turns out that we can't set -fpreprocessed to "Undocumented", as it is
shared with other front ends. However, it is documented in the GCC manual in
the preprocessor section, and thus falls outside the "options spe
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-15 05:58 ---
This works just fine in 4.2.0 20061112 plus valgrind says nothing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
The following example (reduced from openssl) causes GCC 4.2 to ICE when -O2 is
used it works ok with -O1. It does not ICE with GCC 4.1 as well with 3.4.6
gcc -c -O2 xxx.c
xxx.c: In function 'foo':
xxx.c:8: warning: function called through a non-compatible type
xxx.c:8: note: if this code is reach
--- Comment #6 from bdavis at gcc dot gnu dot org 2006-11-15 05:10 ---
Subject: Bug 28974
Author: bdavis
Date: Wed Nov 15 05:10:22 2006
New Revision: 118844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118844
Log:
2006-11-15 Bud Davis <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-15 04:48 ---
Note, I am not going to close this bug just yet because this testcase produces
some weird -O2 timing results for 4.2.0:
tree operand scan : 11.29 (27%) usr 0.51 (22%) sys 13.09 (25%) wall
9015 kB ( 4%) gg
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-15 04:46 ---
In 4.2.0 on i686-linux-gnu this is much better:
parser: 1.99 (31%) usr 0.28 (28%) sys 2.42 (25%) wall
43674 kB (49%) ggc
name lookup : 0.48 ( 7%) usr 0.37 (37%) sys 1.51 (16%
--- Comment #4 from brooks at gcc dot gnu dot org 2006-11-15 04:02 ---
Fixed, as per above commits.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from brooks at gcc dot gnu dot org 2006-11-15 04:00 ---
Subject: Bug 29702
Author: brooks
Date: Wed Nov 15 04:00:35 2006
New Revision: 118843
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118843
Log:
PR fortran/29702
* fortran/error.c (show_loci): Move column-off
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-11-15 03:55
---
Subject: Re: DWARF: Not all inline concrete instances are being generated
> OK, so I'll have to find another way of using the DWARF info to see if a
> inline
> routine, such as __task_rq_lock was used at all in
OK, so I'll have to find another way of using the DWARF info to see if a inline
routine, such as __task_rq_lock was used at all in the build or was just
included in the DWARF info but not referenced anywhere, have to dig more into
the available information...
BTW, if, in these cases, DW_TAG_subro
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-11-15 03:52 ---
Fixed
--
dberlin at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from brooks at gcc dot gnu dot org 2006-11-15 03:44 ---
Subject: Bug 29702
Author: brooks
Date: Wed Nov 15 03:44:18 2006
New Revision: 118840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118840
Log:
PR fortran/29702
* fortran/error.c (show_loci): Move column-off
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-15 02:50 ---
Seems to me, you should not be using a target that defines
TARGET_THREAD_SSP_OFFSET for -ffreestanding mode. Also IIRC the x86_64 Linux
has a different TLS base register which fixes this issue there.
--
http://
--- Comment #1 from danglin at gcc dot gnu dot org 2006-11-15 02:41 ---
(gdb) r ../../gcc/gcc/config/pa/pa.md > tmp-condmd.c
Starting program: /test/gnu/gcc/objdir/gcc/build/genconditions
../../gcc/gcc/config/pa/pa.md > tmp-condmd.c
Program received signal SIGSEGV, Segmentation fault.
0
/test/gnu/gcc/objdir/./prev-gcc/xgcc -B/test/gnu/gcc/objdir/./prev-gcc/
-B/opt/g
nu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-
strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H
-DG
ENERATOR_FILE -I. -Ibuild -I../../gcc/gcc -I../../gcc/gc
--- Comment #4 from bangerth at dealii dot org 2006-11-15 02:09 ---
(In reply to comment #3)
> 14.3.2/1 says that "a constant expression that evaluates to a null member
> pointer value" is allowed as a non-type template argument, with an explicit
> reference to 4.11, which explains how t
--- Comment #19 from jason at redhat dot com 2006-11-15 02:07 ---
Subject: Re: [4.1 regression] ICE in extract_insn, at recog.c:2084
OK, now I've really reverted the patch. Silly svn resolved...
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #2 from bangerth at dealii dot org 2006-11-15 01:59 ---
Confirmed.
> (Note that in the actual code, Doh was boost::mutex::scoped_lock.
> And I fear that using boost::mutex::scoped_lock like this is becoming
> a widespread idiom.)
Ugh, this isn't an easy to read idiom...
W
--- Comment #1 from bangerth at dealii dot org 2006-11-15 01:53 ---
There's two problems here: first, you are missing a template<>
in front of your definition. Second, you can't initialize
static variables with
type class::variable();
since this is ambiguous to declaring a function o
--- Comment #26 from ppluzhnikov at charter dot net 2006-11-15 01:22
---
(In reply to comment 25)
Confirmed: using newer glibc:
GNU C Library development release version 2.3.5, by Roland McGrath et al.
and having rebuilt gcc-4.3-20061104 on it, I do not see violations on
make-3.81
Co
A - template static member class
B - template class containing A
C - class inheriting from specialized class B
Class C is to inherit a static member appropriate for its class.
The last line is intended as definition of this static member.
template class A
{
public:
A() {}
virtual
--- Comment #1 from samuel dot thibault at ens-lyon dot org 2006-11-15
01:16 ---
Created an attachment (id=12622)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12622&action=view)
braindead patch
Just a small braindead patch, not tested at all, just adds testing flag_hosted.
--
Hi,
On some architectures, when given -fstack-protector (which is the default on
ubuntu), gcc generates a TLS reference for the stack guard. For instance, on
linux x86 with a fairly recent version of glibc:
echo 'void f (void) { volatile char a[8]; a[3]; }' | gcc -S -x c -O2
-fstack-protector - -
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-15 00:39 ---
I have a start to this patch and it works nicely, I just have to finish up
marking which builtins should be pure and which should be const and which are
neither.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-11-15 00:38
---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from kargl at gcc dot gnu dot org 2006-11-15 00:18 ---
The trivial workaround is to assign MAXVAL(X) to an integer.
SUBROUTINE T(X)
INTEGER, INTENT(IN) :: X(:)
INTEGER Y, Z
z = maxval(x)
CALL A(z,Y)
END SUBROUTINE T
I need to look at the standard with
--- Comment #1 from enok at lysator dot liu dot se 2006-11-14 23:14 ---
Created an attachment (id=12621)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12621&action=view)
Small testcase that triggers the compiler bug
gfortran4 -c tst.f90
In file tst.f90:22
CALL A(MAXVAL(X),Y)
Different INTENT parameters on the first argument of overloaded subroutines
confuse the argument matching mechanism and a compiler error is generated for
code that is correct. See attached testcase.
The problem breaks my code and I see no workaround. I hope somebody can fix it
before the release.
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-14 22:55 ---
Janis can you do a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-14 22:51 ---
Not a bug as explained by Neil.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from neil at daikokuya dot co dot uk 2006-11-14 22:49
---
Subject: Re: New: Concatenation operator ## doesn't work with this: / ## /
michael dot bishop at gdcanada dot com wrote:-
> I am trying to use the macro concatenation operator to make a "conditional
> comment"
Exchange Service from Paypal to e-gold, from StormPay to e-gold, from
Moneybookers to e-gold
SERVICE FEES:
PayPal to E-Gold: 5% - 10%
StormPay to E-Gold: 5% - 10%
Moneybookers to E-Gold: 4%-7%
PayExchange.net
www.PayExchange.net
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:48 ---
It gets better and better...
module gfcbug45
implicit none
contains
subroutine foo
integer :: i
real:: a
real, parameter :: eps(1) = (/ 1 /)
i = 1
a = mysum (eps(i:i) * eps)
end subrouti
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 21:33 ---
I you use
( Doh ( x ) ), ++ x;
it works. (EDG accepts the code unmodified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-14 21:24 ---
>
> If the "implicit none" or the "module ... end module" is removed, the ICE goes
> away. Probably worth running using a non-optimized front-end under valgrind.
>
or replacing a = sum (eps(i:i) * eps)
by
a = sum (e
--- Comment #18 from debian-gcc at lists dot debian dot org 2006-11-14
21:09 ---
(In reply to comment #16)
> I've reverted my patch on the
> 4.1 branch, as it seems to be too risky there.
afaics the patch is not yet reverted.
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-14 21:08 ---
The remark in #3 that the bug clears if the order of the procedures is reversed
is a giveaway:
Index: gcc/fortran/trans-types.c
===
*** gcc/fortran/trans
--- Comment #3 from jens dot maurer at gmx dot net 2006-11-14 20:24 ---
I agree with Wolfgang's interpretation of the standard, but can't see why it
renders my original code invalid.
14.3.2/1 says that "a constant expression that evaluates to a null member
pointer value" is allowed as a
To whom it may concern,
I am trying to use the macro concatenation operator to make a "conditional
comment". I want a symbol that I can sprinkle throught my C code that will be
replaced either be a C++ style // comment, or it will be replaced with nothing.
This is useful for turning on and off d
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-11-14 19:45
---
> Please apply this patch to 4.2 and the trunk. I've reverted my patch on the
> 4.1 branch, as it seems to be too risky there.
Have you really done so?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #6 from bonzini at gnu dot org 2006-11-14 18:56 ---
Created an attachment (id=12620)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12620&action=view)
updated patch
Right, you need this additional hunk (I didn't include the regenerated
configure, you have to run autoco
--- Comment #2 from patchapp at dberlin dot org 2006-11-14 18:41 ---
Subject: Bug number pr24783
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/2006-11/msg00966.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #14 from bangerth at math dot tamu dot edu 2006-11-14 18:37
---
Subject: Re: Specialization of inner template using outer template argument
doesn't work
> It is not a regression as far as I can tell.
True. However it does produce wrong code.
W.
--
http://gcc.gnu.org
--- Comment #16 from jason at gcc dot gnu dot org 2006-11-14 18:21 ---
(In reply to comment #15)
> patch
Please apply this patch to 4.2 and the trunk. I've reverted my patch on the
4.1 branch, as it seems to be too risky there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29825
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-11-14 18:12 ---
Subject: Bug 27755
Author: dberlin
Date: Tue Nov 14 18:12:20 2006
New Revision: 118821
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118821
Log:
2006-11-14 Daniel Berlin <[EMAIL PROTECTED]>
Fix P
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
gfortran writes:
read(1,'(Q,A)',iostat=i) n,line(:n)
1
Warning: Unexpected element in format string at (1)
And if there is a long comment it may even look like:
XLINE
1
Warning: Unexpected element in format string at (1)
Expected:
read(1,'(Q,A)',
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-14 17:54
---
(In reply to comment #12)
> Raising severity, some more people in CC. This at least seems to be an often
> reported problem.
It is not a regression as far as I can tell.
--
pinskia at gcc dot gnu dot org chan
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-14 17:50 ---
fpchg should also be enabled in sh.md for TARGET_SH4_300
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29349
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-11-14 17:46
---
Raising severity, some more people in CC. This at least seems to be an often
reported problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:44
---
Yes:
gcc41-g/gcc> ./cc1plus -quiet t.C -O3
t.C: In function 'int f()':
t.C:6: internal compiler error: in copy_to_mode_reg, at explow.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-11-14 17:42
---
It's true that the number of created calls is 2^N, but unfortunately the number
of created temporaries grows super-exponential:
--param max-inline-recursive-depth-auto grep 'struct X' t.C.t24.fixupcfg
| wc
--- Comment #11 from zjasz at yahoo dot com 2006-11-14 17:40 ---
(In reply to comment #6)
> Work postponed to GCC 4.1. This bug is tricky to fix.
What is the status of this bug? Will be resolved in the next release?
For us is critical because a whole framework is built up on this.:,,,(
--- Comment #14 from mmitchel at gcc dot gnu dot org 2006-11-14 17:30
---
I cannot getting this to fail with current GCC 4.1.2 sources. Can others still
reproduce this problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-11-14 17:25
---
The following simpler test case is sufficient to show the same behavior:
struct X{};
void f(X& x)
{
f(x);
f(x);
}
Also, it is indeed true that --param max-inline-recursive-depth-auto=3 makes
this compile inst
--- Comment #10 from acme at mandriva dot com 2006-11-14 17:19 ---
(In reply to comment #9)
>
> I'm quite aware of what GCC outputs here :)
>
> However, past the initial declarations, we don't output debug
> information about what the state of the IR is at random points in the
> compil
--- Comment #5 from burnus at gcc dot gnu dot org 2006-11-14 17:16 ---
> Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden
>
> My limited german knowledge seems to indicate that it's OK, but I'm not sure.
Looks ok.
> Could you try the attached patch on a few case
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15
---
Fixed in 4.1 by the patch for PR 29106.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from mmitchel at gcc dot gnu dot org 2006-11-14 17:15
---
Subject: Bug 29106
Author: mmitchel
Date: Tue Nov 14 17:15:08 2006
New Revision: 118819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118819
Log:
PR c++/29106
* g++.dg/init/self1.C: New t
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-11-14 17:14
---
Created an attachment (id=12619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12619&action=view)
patch
This one passes a C bootstrap & regtest on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-11-14 17:14
---
Subject: Bug 29106
Author: mmitchel
Date: Tue Nov 14 17:13:57 2006
New Revision: 118818
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118818
Log:
PR c++/29106
* g++.dg/init/self1.C: New t
--- Comment #5 from Jean-pierre dot vial at wanadoo dot fr 2006-11-14
17:11 ---
(In reply to comment #0)
> when building ada on linux (x86-64)
> building ada fails because the makefile looks for gnatbuild in
> mydir/gcc-4.2-20061107/prev-gcc
> instead of
> mydir/gcc-4.2-20061107/host-x8
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-14 16:30 ---
*** This bug has been marked as a duplicate of 14032 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-11-14 16:44
---
What about:
de.f90:4:
use foo, only : bar
1
Fehler: Bei (1) referenziertes Symbol »bar« nicht im Modul »foo« gefunden
My limited german knowledge seems to indicate that it's OK, but I'm not sure.
More cases where g++ apparently doesn't take
enough context into account when deciding that
something can be (and thus is) a declaration.
Compiled the following (legal) program using "g++ -c"
---
struct Doh
{
Doh( int ) {}
} ;
int x = 0 ;
int
f()
{
Doh
--- Comment #4 from thaytan at noraisin dot net 2006-11-14 16:09 ---
It's using -mtune=generic:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --l
--- Comment #5 from tla at thrane dot com 2006-11-14 16:28 ---
(In reply to comment #4)
> What's the status of this patch?
The bug is also present in arm-elf-gcc version 4.1.0
However, adding the -fno-omit-frame-pointer parameter, make
the compiler emit the correct code in the mentioned
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-11-14 15:56 ---
For SUSE 4.1.2 I get prefetcht0 generated. So this is an Ubuntu bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #5 from wolfgang dot roemer at gmx dot net 2006-11-14 15:35
---
[EMAIL PROTECTED] wrote:
"Usually the problem will get caught as soon as you try to invoke a method, but
if it's something like a guard object, without methods, then it can be a
problem."
At least in this case
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-14 15:35 ---
Subject: Bug 29657
Author: burnus
Date: Tue Nov 14 15:35:36 2006
New Revision: 118812
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118812
Log:
fortran/
2006-11-14 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #6 from Raimund dot Merkert at baesystems dot com 2006-11-14
15:52 ---
It does not seem to warn about unused functions. I also tried the following
test case where 4.0.0 (solaris) does not warn even about foo ( I guess because
it's referenced in Y's constructor?)
gcc -Wunu
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-11-14 16:34
---
(In reply to comment #13)
> > While that can help in this case, I think letting make_tree/expand_expr
> > combo
> > create invalid RTL is very dangerous (and, at least from i386 backend POV,
> > some of the PIC UN
--- Comment #2 from jakub at gcc dot gnu dot org 2006-11-14 14:28 ---
Forgot to mention, the problem is reproduceable also on gcc-4_1-branch
and gcc-4_2-branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-11-14 16:30
---
*** Bug 29830 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-14 16:29 ---
Please file a bug with Ubuntu instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
Actual version string from gcc: 4.1.2 20060928 (prerelease) (Ubuntu
4.1.1-13ubuntu5)
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
gfortran.fortran-torture/execute/scalarize.f90 is miscompiled at least
on x86_64-linux with -O2 -ftree-loop-linear (other miscompiled fortran
tests with -ftree-loop-linear are forall_1.f90 and der_type.f90).
The only linear transformed loop in scalarize.f90 is the
b(:, 5:1:-1) = a
one (i.e.
int8 S
Have built gcc with "--prefix=/usr/local/gcc-4.1.1".
When "/usr/local/gcc-4.1.1" is moved and symlinked to "/stranger/gcc-4.1.1",
the include path order changes, so that fixed system headers are searched
before local headers.
In non-symlink case, where the searched include path is correct, I can
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-14 15:54 ---
What does adding '-v' to the compile command say? It seems Ubuntu is using a
default -march that enables 3dnow (k8 or opteron maybe) - it should use x86_64
instead.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from zjasz at yahoo dot com 2006-11-14 15:02 ---
(In reply to comment #1)
> this is a dup of PR29767
Sorry for duplication, I haven't checked again after I posted to the gcc-help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-14 14:17 ---
Confirmed.
Tobias,
What criterion are you chosing for the missing F2003 features? The reason that
I ask is that it is not clear to me when you stop; eg. should we have a PR for
polymorphism or for sub-modules? Mayb
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-14 12:42 ---
You need to provide a preprocessed testcase, specify what gcc version you use
and what flags to compile.
arm-linux-g++: Internal error: Killed (program cc1plus)
this means the kernel (or you) killed the compiler, i
--- Comment #25 from fche at redhat dot com 2006-11-14 12:19 ---
(In reply to comment #24)
> Might the problem be that I am compiling on an "old" glibc?
That is possible. Try MUDFLAP_OPTIONS="-trace-calls -verbose-trace".
If you have access to a modern glibc, you could compare traces f
--- Comment #1 from pluto at agmk dot net 2006-11-14 12:53 ---
this is a dup of PR29767
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29830
Hi,
I haven't found any related bug in the known bugs database.
Also I posted this problem to several forums to be shore that this code doesn't
violate the C++ standard. ~60% replies that this should work. Moreover two
other compilers can compile without any problem:
The simplified code:
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-11-14 11:48
---
> While that can help in this case, I think letting make_tree/expand_expr combo
> create invalid RTL is very dangerous (and, at least from i386 backend POV,
> some of the PIC UNSPECs not surrounded by CONST are i
--- Comment #1 from Denis dot Excoffier at airbus dot com 2006-11-14 11:39
---
To be connected to Bug 29825.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
--- Comment #4 from bonzini at gnu dot org 2006-11-14 12:23 ---
Created an attachment (id=12616)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12616&action=view)
patch to fix the bug
Please try this.
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #7 from burnus at gcc dot gnu dot org 2006-11-14 15:49 ---
Fixed in trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #1 from jakub at gcc dot gnu dot org 2006-11-14 14:27 ---
lambda_loopnest_to_gcc_loopnest interchanges the loops and we get:
:;
lletmp.77_46 = 0;
lletmp.77_38 = lletmp.77_46 + 5;
lnivtmp.75_21 = lnivtmp.75_9 + 1;
lnivtmp.75_12 = lnivtmp.75_9 + 1;
if (lletmp.77_38 <=
--- Comment #1 from thaytan at noraisin dot net 2006-11-14 14:26 ---
Created an attachment (id=12617)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12617&action=view)
simple test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29833
--- Comment #3 from jpvial at nerim dot net 2006-11-14 11:10 ---
Subject: Re: wrong directory in makefile for ada and libada
when building the src directory
bonzini at gnu dot org wrote:
> --- Comment #2 from bonzini at gnu dot org 2006-11-14 08:26 ---
> it is supported, it i
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-11-14 11:11
---
The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with
the same error.
At least (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] ) is not a valid PIC address (it's only one
in 64bit mode).
while working in a project in C++. I tried to use a forward declaration of a
class. Class is unders some name space. There I got the error message like
below.
arm-linux-g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructio
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-14 10:16 ---
A long overdue patch for this will be submitted in the next 24hours.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 131 matches
Mail list logo
