In the attached program compiler don't use specified storage pool for
allocation of classwide type with initialization by function call inside
qualified expression.
Build:
gnatmake -gnat05 driver.adb
Reproduce:
./driver
FAIL
--
Summary: specified storage pool not used for classwide
--- Comment #1 from vgodunko at rostel dot ru 2008-01-20 08:01 ---
Created an attachment (id=14975)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14975action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34883
On Linux/Intel64, I got
FAIL: gfortran.dg/array_constructor_9.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
with revision 131671. Revision 131622 is OK.
--
Summary: [4.3 Regression] gfortran.dg/array_constructor_9.f90
Product: gcc
Version: 4.3.0
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-20 08:23 ---
Subject: Bug 34784
Author: pault
Date: Sun Jan 20 08:22:56 2008
New Revision: 131675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131675
Log:
2008-01-20 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-20 08:23 ---
Subject: Bug 34785
Author: pault
Date: Sun Jan 20 08:22:56 2008
New Revision: 131675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131675
Log:
2008-01-20 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-20 08:43 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2008-01-20 08:44 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
I see the following ICE with trunk from 2007-01-19 on x86_64:
(sid)3945:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
purelibc-socketcalls.i
socketcalls.c: In function 'recv':
socketcalls.c:120: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.c:574
Please
--- Comment #1 from tbm at cyrius dot com 2008-01-20 08:52 ---
Created an attachment (id=14976)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14976action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
--- Comment #3 from ed at catmur dot co dot uk 2008-01-20 08:56 ---
Created an attachment (id=14977)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14977action=view)
gcc-cpp-Werror-message-cpp-diagnostic.patch
Is this what you meant? Not sure whether I've got the source_location
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-01-20 09:20 ---
As this turned out to be wrong-code, adjusting
severity and setting target milestone (after the fact :-)
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34796
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-20 09:50 ---
I'll take a shot at this.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-20 09:59 ---
(In reply to comment #2)
It's a regression - and I might be guilty of it with my Bind(C) patches...
Well, if it's a regression, there's a bigger chance for it to
be fixed before 4.3 comes out :-)
--
tkoenig at
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-20 10:48 ---
This is a regression vs. g77:
$ cat foo.f
program chkdata
character*20 string(4)
data ( string(i) ,i=1,5 ) /'A', 'B', 'C', 'D', 'E' /
write(*,*) string
end
$ g77 foo.f
foo.f: In
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-20 10:52 ---
Fails also at '-O2 -funroll-loops', but not if I add
return
10 print *, i, j, k, values (last)
before
end subroutine test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-20 10:35 ---
Confirmed and it is a wierd regression: the test pass with '-O3' alone, but not
with '-O3 -funroll-loops'. In addition if I replace the line
if (values (last) .ne. j + k * k) call abort
by
if
--- Comment #3 from bero at arklinux dot org 2008-01-20 11:10 ---
The padlock code itself doesn't crash (if you add anything else near it, the
crash goes away). I suspect something gets messed up in the calling
conventions, and so far haven't been able to reproduce this in a smaller
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-20 11:31 ---
The failure comes in the first call of 'test()' at i=order, j=2. The values
tested in the k loop seems to be:
5.000 10.000 3.000 6.000 11.00
4.000 7.000
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-01-20 11:56 ---
Double checking patch, I don't see obvious mistakes. Since the patch should
only affect register allocation decisions, either we see a latent bug, or
another example of x86 extra precision causing FP program to
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-20 12:04 ---
Worked with rev. 131669, fails with 131671. Rev. 131670 seems the most likely,
added Kenneth Zadeck to the cc list.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 12:21 ---
g++: Internal error: Killed (program cc1plus)
How much memory do you have? How much swap space do you have?
Can you attach command_download.ii?
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-20 13:19 ---
The test and its variants pass on powerpc-apple-darwin9 rev. 131676.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
--- Comment #34 from olga at gcc dot gnu dot org 2008-01-20 13:28 ---
Dave, Dominique,
As I have no such execution failures on any one of machines, would you please
help me debugging the execution failures?
I am actually need the place where it fails and assembly files. The most
--- Comment #6 from zadeck at naturalbridge dot com 2008-01-20 13:53
---
I need a more info to reproduce this bug. I bootstrapped and regression tested
on x86_64-unknown-linux-gnu with suse 10.3 and using
--enable-languages=c,c++,fortran --disable-multilib before committing the
patch
--- Comment #4 from krefson at googlemail dot com 2008-01-20 13:53 ---
(In reply to comment #3)
(In reply to comment #2)
It's a regression - and I might be guilty of it with my Bind(C) patches...
Well, if it's a regression, there's a bigger chance for it to
be fixed before 4.3
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-20 13:38 ---
(In reply to comment #2)
I think that having -Wall clobber -Wstrict-overflow in this way is confusing.
This isn't reversing the setting of the option, it's changing its level.
Ian, should the above testcase
--- Comment #5 from dominiq at lps dot ens dot fr 2008-01-20 14:56 ---
I am trying to proceed backward. I have reached the following point:
Breakpoint 8, gfc_parse_file () at ../../gcc-4.3-work/gcc/fortran/parse.c:3460
3460{
(gdb) s
gfc_parse_file () at
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39 ---
I need a more info to reproduce this bug.
I have tried to give all the info I have been able to gather on my own. My
config is:
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-20 14:34 ---
I have a patch. Actually, I do not understand why it worked before.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #35 from dominiq at lps dot ens dot fr 2008-01-20 15:16 ---
Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
help.
For the code in comment #34 the assembly code is:
--- Comment #7 from j at uriah dot heep dot sax dot de 2008-01-20 15:21
---
(In reply to comment #6)
Sorry, I don't have any of those trees left. But if I ever come to
revisit those two bugs I'll make sure it fixes this bogus warning.
If you can give me some hints about where to
--- Comment #8 from ubizjak at gmail dot com 2008-01-20 15:21 ---
(In reply to comment #6)
Confirmed on x86_64-unknown-linux-gnu.
It fails only with --enable-checkgin=assert, as is the case in
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00695.html
--
--- Comment #8 from zadeck at naturalbridge dot com 2008-01-20 15:24
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-20 14:39
---
I need a more info
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-20 15:39
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30
---
you are building on
--- Comment #12 from zadeck at naturalbridge dot com 2008-01-20 15:52
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
dominiq at lps dot ens dot fr wrote:
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47
---
I have put the results
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-20 15:57
---
It happens for me on Linux/Intel64 with -m32:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00907.html
My configuration is
configure flags: --enable-clocale=gnu --with-system-zlib
--enable-decimal-float=bid
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-20 15:47 ---
I have put the results of the compilation with -da with the patch at
http://www.lps.ens.fr/~dominiq/gcc/tmp_fresh.tar.bz2
All the files will be in a directory tmp_fresh. Do you still need the same
without the
--- Comment #9 from dominiq at lps dot ens dot fr 2008-01-20 15:30 ---
you are building on a mac darwin box
Yes indeed, but the bug is also present for i686-pc-linux-gnu, see for
instance:
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00914.html
--
--- Comment #9 from zadeck at naturalbridge dot com 2008-01-20 15:29
---
olga,
even if the test case does not normally ice on your system, you be able to see
the bug if you run the test with valgrind.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34472
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
There is the issue, the testcase should be not run on your computer as it is
using SSE2. So this is a testsuite issue.
Please look at gcc.dg/vect/ how this should be done. There is a
--- Comment #4 from ubizjak at gmail dot com 2008-01-20 15:34 ---
(In reply to comment #3)
Double checking patch, I don't see obvious mistakes. Since the patch should
only affect register allocation decisions, either we see a latent bug, or
another example of x86 extra precision
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-20 15:36 ---
Created an attachment (id=14978)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14978action=view)
First draft of the patch
The patch works for the test case, but it fails for auto_char_dummy_array_1.f90
(ICE)
--- Comment #8 from manu at gcc dot gnu dot org 2008-01-20 16:06 ---
(In reply to comment #7)
(In reply to comment #6)
Sorry, I don't have any of those trees left. But if I ever come to
revisit those two bugs I'll make sure it fixes this bogus warning.
If you can give me some
--- Comment #10 from olga at gcc dot gnu dot org 2008-01-20 16:28 ---
(In reply to comment #9)
olga,
even if the test case does not normally ice on your system, you be able to see
the bug if you run the test with valgrind.
Kenny,
Thank you a lot for information. I was not aware
--- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43 ---
Oops. This one
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:42:42.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx p;
rtx
--- Comment #11 from zadeck at naturalbridge dot com 2008-01-20 16:34
---
Subject: Re: [4.3 Regression] gcc.dg/struct/wo_prof_malloc_size_var.c
doesn't work
olga at gcc dot gnu dot org wrote:
--- Comment #10 from olga at gcc dot gnu dot org 2008-01-20 16:28 ---
(In reply
--- Comment #6 from hjl dot tools at gmail dot com 2008-01-20 16:42 ---
Does this patch make any senses?
--- regmove.c.freq 2008-01-17 07:31:56.0 -0800
+++ regmove.c 2008-01-20 08:40:34.0 -0800
@@ -1695,7 +1695,7 @@ fixup_match_1 (rtx insn, rtx set, rtx sr
rtx
On compiling that code:
--- begin code ---
class Y {};
void f(Y*) { } // line 3. If comment - all ok
template typename T
void sel(T* a) { f(a); } //line 6
void f(void*) {}
int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---
Àppears error:
../main.cpp: In
--- Comment #5 from hjl dot tools at gmail dot com 2008-01-20 16:34 ---
Should we also update REG_FREQ_CALLS_CROSSED whenever REG_N_CALLS_CROSSED
is updated? In regmove.c, there are
delete_insn (q);
INC_REG_N_SETS (REGNO (src), -1);
--- Comment #36 from olga at gcc dot gnu dot org 2008-01-20 17:03 ---
(In reply to comment #35)
Note that the test gcc.dg/struct/wo_prof_mult_field_peeling.c pass for 32 and
64 bit modes on i686-apple-darwin9, so I am not sure that what follows will
help.
Sorry, I meant compiling
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-20 17:07 ---
Fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34858
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34861
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131679
Log:
2008-01-20 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34854
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131679
Log:
2008-01-20 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2008-01-20 16:59 ---
Subject: Bug 34784
Author: pault
Date: Sun Jan 20 16:58:15 2008
New Revision: 131679
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131679
Log:
2008-01-20 Paul Thomas [EMAIL PROTECTED]
PR
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34848
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34872
We are computing the correct result for test 8 of FM903.f, but one of the
Correct answers is truncated. Both are truncated in 4.2 and my last patch
gives this.
With FM903.f
gfortran:
COMPUTED=
12.34506.78 120.34 506.78 123.40 567.80
--- Comment #37 from dominiq at lps dot ens dot fr 2008-01-20 18:09 ---
(In reply to comment #36)
... And, if I understand correctly the comment #32, with 64 bits mode it does
fails with wo_prof_mult_fields_peeling.c. Please fix me if I am wrong.
Yes, you are right. I did not look
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-20 18:10
---
In the failing case, we have no stride:
Breakpoint 1, gfc_walk_subexpr (ss=0xfc2de0, expr=0x106f6b0)
at ../../gcc43/gcc/fortran/trans-array.c:5609
(gdb) p *expr-ref
snip
stride = {0x0, 0x0, 0x0,
--- Comment #14 from zadeck at naturalbridge dot com 2008-01-20 18:30
---
confirmed on my machine,
i will have my best people work on it.
kenny
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
There are several instruction patterns related to stack pointer operations.
These are not quite right:
1) popqi and poph1 patterns use post_inc codes - when in fact there are pre_inc
- this could fail if gcc ever used them outside prolog/epilog
2) Stack moves such as push/pop should be placed
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-20 19:26 ---
It fails even with gcc 4.1.2 and the same CFLAGS, and the problem is just buggy
inline assembly.
Following patch cures this for me:
--- hwfeatures.c.xx 2007-12-05 12:03:33.0 +0100
+++ hwfeatures.c
--- Comment #1 from pmarques at grupopie dot com 2008-01-20 19:39 ---
Created an attachment (id=14979)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14979action=view)
the attached patch implements the proposed change
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34889
gcc.c-torture/execute/builtins/pr23484-chk.c has on line 44:
if (snprintf (buf, l1 ? sizeof (buf) : 4, %d, l1 + 65536) != 5
|| memcmp (buf, 655\0, 8))
but on a 16 bit platform like the avr, the l1 + 65536 overflows and gives the
wrong result. Changing that to:
if (snprintf (buf,
--- Comment #6 from wvangulik at xs4all dot nl 2008-01-20 19:30 ---
Bug is still present in 4.2.2.
Some more info:
I rewrote the example to (atleast for me) little more clear example.
struct fseqp_void
{
void (*p) (void);
char *e;
};
struct fseqp_void c;
void bar (void){}
--- Comment #6 from mark at codesourcery dot com 2008-01-20 20:28 ---
Subject: Re: [4.2/4.3 Regression] bit-fields, references and
overloads
aoliva at gcc dot gnu dot org wrote:
--- Comment #5 from aoliva at gcc dot gnu dot org 2008-01-17 18:01
---
Created an attachment
--- Comment #5 from mmitchel at gcc dot gnu dot org 2008-01-20 20:13
---
This is a known bug in the Itanium C++ ABI. ARM noticed this; there variant of
the C++ ABI has the additional is_reference parameter precisely to correctly
handle this case.
I looked at this in some detail at
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-20 20:18 ---
Reduced test case:
$ cat bug-4.f
program main
write (*,'(3X A, T1, A,/)') 'aa', 'bb'
end
$ gfortran bug-4.f ./a.out
bb
$ g77 bug-4.f ./a.out
bb aa
--
tkoenig at gcc dot gnu dot org changed:
When I attempt to compile the 01/18/08 snapshot under Debian Linux 4.0 for mips
I get the following message:
/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/xgcc
-B/home/mrichmon/gcc-4.3-20080118/g95/./prev-gcc/
-B/home/mrichmon/irun/mips-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W
-Wall
--- Comment #38 from dominiq at lps dot ens dot fr 2008-01-20 20:47 ---
With patch form comments #11 and #31, the executable for
gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the
32 bit mode for -fprofile-generate, run the executable, and use -m64 for
--- Comment #2 from tbm at gcc dot gnu dot org 2008-01-20 21:21 ---
Fixed in SVN by Richard.
--
tbm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tbm at cyrius dot com 2008-01-20 21:20 ---
This was fixed in SVN today, see
http://gcc.gnu.org/ml/gcc/2008-01/msg00308.html
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 21:55 ---
GCC is correct here. Well partly. It should reject it no matter what.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-01-20 21:40 ---
(currently regtesting)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34887
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34892
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-01-20 21:39 ---
What about this one-character patch?
Index: transfer.c
===
--- transfer.c (revision 131679)
+++ transfer.c (working copy)
@@ -1308,7 +1308,7 @@
A broken diagnostic ('view_convert_expr' not supported by dump_expr)
is issued for the following testcase since GCC 4.0.2:
==
typedef float v4f __attribute__((vector_size(8)));
typedef int v4i __attribute__((vector_size(8)));
void foo()
{
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34891
The following invalid testcase triggers an ICE on mainline:
==
templateint=..., int=0 struct A {};
A0 a;
==
bug.cc:1: error: expected primary-expression before '...' token
bug.cc:3: internal
--- Comment #4 from ed at catmur dot co dot uk 2008-01-20 22:20 ---
Created an attachment (id=14980)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14980action=view)
gcc-cpp-Werror-message.patch
Also when preprocessing-only.
--
ed at catmur dot co dot uk changed:
On compiling that code:
--- begin code ---
class Y {};
void f(Y*) { } // line 3. If comment - all ok
template typename T
void sel(T* a) { f(a); } //line 6
void f(void*) {}
int main(int argc, char **argv)
{
sel((void*)0); //line 12
}
--- end code ---
Àppears error:
../main.cpp: In
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|fortran |middle-end
Target Milestone|--- |4.3.0
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-20 22:19 ---
- next_record (dtp, 0);
+ next_record (dtp, 1);
This causes a regression in x_slash_1.f . I'll dig around
some more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34887
--- Comment #15 from zadeck at naturalbridge dot com 2008-01-20 23:15
---
There appears to be an design inconsistency in the way that we have specified
the various dataflow problems with respect to the eq notes.
I hate eq notes.
In the rd patch that just went in where we trim the
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 22:30 ---
*** Bug 34893 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
--- Comment #4 from debian-gcc at lists dot debian dot org 2008-01-20
23:57 ---
seen as well with a sparc-linux-gnu compiler with -m64 (patched for a biarch
build ) with trunk 20080116
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33034
--- Comment #5 from ed at catmur dot co dot uk 2008-01-20 22:28 ---
Created an attachment (id=14981)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14981action=view)
gcc-cpp-Werror-message.patch
--
ed at catmur dot co dot uk changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 22:30 ---
*** This bug has been marked as a duplicate of 34886 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from sergstesh at yahoo dot com 2008-01-20 22:30 ---
Now that the flags are in this order: -Wall -Wstrict-overflow=5 :
a) the warnings during compilation:
[EMAIL
PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17
grep warn make.log
lpc.c:220:
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22 ---
I favor blowing away the RD patch.
Having the LR problem (and probably the LIVE problem too?) always propagate the
REG_EQ* notes as if they were real uses sounds like a terrible idea to me.
They are not real uses
--- Comment #9 from kkojima at gcc dot gnu dot org 2008-01-21 00:05 ---
Subject: Bug 34808
Author: kkojima
Date: Mon Jan 21 00:04:23 2008
New Revision: 131680
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131680
Log:
PR rtl-optimization/34808
* emit-rtl.c
--- Comment #17 from zadeck at naturalbridge dot com 2008-01-20 23:27
---
Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90
steven at gcc dot gnu dot org wrote:
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-20 23:22
---
I favor blowing away
--- Comment #10 from kkojima at gcc dot gnu dot org 2008-01-21 00:12
---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-21
00:27 ---
Subject: Re: ICE: output_operand: invalid expression
as operand on hppa
(gdb) p debug_rtx (insn)
(code_label/s 1897 4221 1898 13722 (*.LJpc=819954) [0 uses])
We are losing usage counts in
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-21 01:10 ---
*** Bug 34841 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 125 matches
Mail list logo
