FYI
Bug has been already reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
-Vladimir
In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote:
One case is about multiple increments, the tree optimizer merges them and
increments the register only once, so if one only looks at the size of the
pointer value one misses them, e.g. something like this:
(set (mem (reg))
Hello,
Zuxy Meng [EMAIL PROTECTED] дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED]
I saw the patch in http://gcc.gnu.org/ml/gcc/2005-08/msg00281.html but is
it
available for other hosts, like mingw32?
I've uploaded a proposed patch for this bug
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151action=diff).
Hi,
On Mon, 5 Mar 2007, Roman Zippel wrote:
Yes, it is in general better now to split double-word length
operations before reload. It's not necessarily better to split as
early as possible, as that will essentially disable the RTL level loop
optimizations.
I was worried about that
Hi,
On Tue, 6 Mar 2007, Joern Rennecke wrote:
In http://gcc.gnu.org/ml/gcc/2007-03/msg00128.html, you wrote:
One case is about multiple increments, the tree optimizer merges them and
increments the register only once, so if one only looks at the size of the
pointer value one misses them,
On Tue, 6 Mar 2007, Roman Zippel wrote:
Reload has now to match (reg %d0) and (reg 38) above in insn 32 and after
pseudo register replacement it looks like this:
(insn 32 10 30 2 (parallel [
(set (strict_low_part (reg:SI 1 %d1 [orig:38+4 ] [38]))
(mult:SI
Roman Zippel [EMAIL PROTECTED] writes:
The new subreg lowering pass seems to generate a bit worse code on m68k
than before, let's take simple example:
FWIW
I see the opposite on i386: I have a function that strangely ran
slower with -fomit-frame-pointer than without on 4.1. With a 4.3
I was working on a a patch for PR 21596, and it seems to have triggered
a bug in fwprop on x86 in mainline.
The testcase is simple:
register int *reg __asm__(%edi);
int test () { return *--reg = 0; }
I've attached the patch for TER which changes the tree produced in
mainline from:
Hi all,
I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into head/gcc/Makefile.in but it seem quite
cluttered and I
Vladimir Sysoev [EMAIL PROTECTED] writes:
Bug has been already reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
I don't think this one could have anything to do with my VRP changes,
but I'll try to take a look later today.
Ian
Ian Lance Taylor wrote on 03/06/07 09:49:
Vladimir Sysoev [EMAIL PROTECTED] writes:
Bug has been already reported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
I don't think this one could have anything to do with my VRP changes,
but I'll try to take a look later today.
Actually,
Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to SetParam()
function.
Can You help me?
On 3/6/07, W. Ivanov [EMAIL PROTECTED] wrote:
Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to SetParam()
function.
Can You help me?
Don't take me wrong but it is most likely
On 3/6/07, Paulo J. Matos [EMAIL PROTECTED] wrote:
Hi all,
I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into
Hi,
I try from time to time to find some information related GNU's C++ STL
implemention e.g. in
http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/classstd_1_1basic__string.html
But this page (and others) are nearly unreadable because there is no way
to recognise member function declarations
Paulo J. Matos wrote:
On 3/6/07, W. Ivanov [EMAIL PROTECTED] wrote:
Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to SetParam()
function.
Can You help me?
Don't take me wrong
On 06 March 2007 16:07, Paulo J. Matos wrote:
Well, added a couple of lines to gcc/Makefile.in referring to files in
myproj. Still, although it is partly working one thing is annoying me.
It's using these flags by default:
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
Which means using C90, which means no mixed declarations and code, no
C++ comments, etc. Is there any way to compile at least, my files with
c99 constructs?
Or all gcc code should be built like this??
This is a feature. gcc can be bootstrapped using an arbitrary c90 compiler.
The warning
On 3/6/07, W. Ivanov [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote:
On 3/6/07, W. Ivanov [EMAIL PROTECTED] wrote:
Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to SetParam()
On 06/03/07, W. Ivanov [EMAIL PROTECTED] wrote:
Paulo J. Matos wrote:
On 3/6/07, W. Ivanov [EMAIL PROTECTED] wrote:
Hi, I use multiple inheritance in my project. In the child class i have
functions GetParam() and SetParam().
In the cpp-file I call GetParam() function, but I fell to
It would be really sweet if we propagated the 'di - 4' into insn 8, then
recognized that di is now the value of SI 58, and propagated di into the
compare. insn 7 would be dead and we'd get the code the PR is looking
for :-)
Unfortunately there's no hope of that because fwprop doesn't do
It appears that one of these:
r122580 | doko | 2007-03-05 15:23:18 -0800 (Mon, 05 Mar 2007) | 6 lines
2007-03-02 Mario Torre [EMAIL PROTECTED]
PR classpath/31017:
committed for Petteri RC383C2A4ty
[EMAIL
On 3/5/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
Diego Novillo wrote:
Maxim Kuvyrkov wrote on 03/05/07 02:14:
o Fix passes that invalidate tree-ssa alias export.
Yes, this should be good and shouldn't need a lot of work.
o { Fast but unsafe Gupta's aliasing patch, Unsafe tree-ssa
On 3/6/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 3/5/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
Diego Novillo wrote:
Maxim Kuvyrkov wrote on 03/05/07 02:14:
o Fix passes that invalidate tree-ssa alias export.
Yes, this should be good and shouldn't need a lot of work.
o
On Tue, 2007-03-06 at 18:18 +0100, Paolo Bonzini wrote:
It would be really sweet if we propagated the 'di - 4' into insn 8, then
recognized that di is now the value of SI 58, and propagated di into the
compare. insn 7 would be dead and we'd get the code the PR is looking
for :-)
On 3/5/07, Joe Buck [EMAIL PROTECTED] wrote:
On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote:
One of the bugzilla quips (the headlines appearing at random for each
bug list) is actually the head of gcc/reload.c (full text below).
That is really obnoxious and should be removed.
On Tue, Mar 06, 2007 at 12:50:47PM -0500, Daniel Berlin wrote:
On 3/5/07, Joe Buck [EMAIL PROTECTED] wrote:
On Sun, Mar 04, 2007 at 09:45:13AM +0100, FX Coudert wrote:
One of the bugzilla quips (the headlines appearing at random for each
bug list) is actually the head of gcc/reload.c (full
On 3/6/07, Dave Korn [EMAIL PROTECTED] wrote:
On 06 March 2007 16:07, Paulo J. Matos wrote:
Well, added a couple of lines to gcc/Makefile.in referring to files in
myproj. Still, although it is partly working one thing is annoying me.
It's using these flags by default:
-W -Wall
On 3/6/07, Paulo J. Matos [EMAIL PROTECTED] wrote:
Hi all,
I've just added a new gcc subdir : head/gcc/myproj with structures and
utilities for my ipa pass which lives in head/gcc. Now I have to tell
gcc to compile the files inside myproj. Is there a standard way to do
this? I've looked into
On 06 March 2007 18:22, Paulo J. Matos wrote:
i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory
And in fact there is no symbol-tables.o but I saw it being compiled so
I wonder where it has gone to.
Any suggestions ??
1. Always pipe the build output to a file so you
Mike Stump schrieb:
It appears that one of these:
+ '[' -s .bad_compare ']'
+ exit 1
I have a feeling sed -i isn't our friend.
fixed.
Matthias
2007-03-06 Matthias Klose [EMAIL PROTECTED]
* doc/Makefile.am(gkeytool.pod): Don't use sed -i.
* doc/Makefile.in: Regenerate.
On 3/6/07, Dave Korn [EMAIL PROTECTED] wrote:
On 06 March 2007 18:22, Paulo J. Matos wrote:
i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory
And in fact there is no symbol-tables.o but I saw it being compiled so
I wonder where it has gone to.
Any suggestions ??
1.
On 06 March 2007 20:12, Paulo J. Matos wrote:
On 3/6/07, Dave Korn [EMAIL PROTECTED] wrote:
On 06 March 2007 18:22, Paulo J. Matos wrote:
i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory
And in fact there is no symbol-tables.o but I saw it being compiled so
I wonder
On 05/03/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
After reviewing all of the traffic[1] that stemmed from my previous
status report, I've decided that, indeed, it makes sense to steam ahead
with GCC 4.2.0 based on current GCC 4.2.0
On 3/6/07, Dave Korn [EMAIL PROTECTED] wrote:
No, I advise that when adding a pass, regardless of whether the code can fit
in a single file or is large enough to need to use several separate files,
it's consistent to put all the files that implement the pass in the main 'gcc'
source directory.
Manuel López-Ibáñez wrote:
On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
After reviewing all of the traffic[1] that stemmed from my previous
status report, I've decided that, indeed, it makes sense to steam ahead
with GCC 4.2.0 based on current GCC 4.2.0 release branch.
I ask special
Hi Kenneth,
Just found your post in the gcc archive ;) - wanted to say that there have been
many projects
on the topic of optimal compiler flag selections. Actually, there are several
free and commercial
tools available for several years already: PathOpt from PathScale and ESTO from
IBM, for
Dear all,
Just wanted to announce that we are working
on the GCC Interactive Compilation Interface to enable
automatic tuning of optimization heuristic. This interface
is used in HiPEAC, MilePost, SARC and GCCC projects.
A website with latest patches, software, forums, mailing lists,
On 06/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Manuel López-Ibáñez wrote:
On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
After reviewing all of the traffic[1] that stemmed from my previous
status report, I've decided that, indeed, it makes sense to steam ahead
with GCC 4.2.0 based
On Mar 6, 2007, at 11:14 AM, Matthias Klose wrote:
Mike Stump schrieb:
I have a feeling sed -i isn't our friend.
fixed.
I can confirm that this fixed my build. I'm expected the regression
tester to follow shortly.
Thanks.
Manuel López-Ibáñez [EMAIL PROTECTED] writes:
| On 06/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
| Manuel López-Ibáñez wrote:
| On 05/03/07, Mark Mitchell [EMAIL PROTECTED] wrote:
| After reviewing all of the traffic[1] that stemmed from my previous
| status report, I've decided that,
--- Comment #3 from anlauf at gmx dot de 2007-03-06 08:20 ---
(In reply to comment #2)
The value 5008 is listed in libgfortran.h as ERROR_ENDFILE. The
-1 corresponds to ERROR_END. So, the return value of 5008 is
telling you that you are trying to (initiate a?) read beyond
the end
--- Comment #4 from anlauf at gmx dot de 2007-03-06 08:42 ---
(In reply to comment #3)
All other compilers I have checked (xlf, ifort 7.x-9.x, g95)
stay at the end of file.
I stand corrected with regard to xlf. It returns a
documented recoverable error condition.
I have to find
--- Comment #5 from rsandifo at gcc dot gnu dot org 2007-03-06 08:54
---
Subject: Bug 17114
Author: rsandifo
Date: Tue Mar 6 08:54:31 2007
New Revision: 122604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122604
Log:
gcc/
PR target/23482
PR target/17114
--- Comment #7 from rsandifo at gcc dot gnu dot org 2007-03-06 08:54
---
Subject: Bug 23482
Author: rsandifo
Date: Tue Mar 6 08:54:31 2007
New Revision: 122604
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122604
Log:
gcc/
PR target/23482
PR target/17114
--- Comment #8 from rsandifo at gcc dot gnu dot org 2007-03-06 08:57
---
Fixed in trunk. This particular form of the patch is too
invasive for 4.1 and 4.2.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rsandifo at gcc dot gnu dot org 2007-03-06 09:01
---
Subject: Bug 28181
Author: rsandifo
Date: Tue Mar 6 09:01:07 2007
New Revision: 122609
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122609
Log:
gcc/
PR target/28181
*
--- Comment #12 from rsandifo at gcc dot gnu dot org 2007-03-06 09:02
---
Now fixed in trunk. The patch may be too invasive to backport;
I'm not sure.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from vladimir dot sysoev at gmail dot com 2007-03-06 09:17
---
This issue causes cpu2006/447.dealII ICE too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31037
--- Comment #5 from anlauf at gmx dot de 2007-03-06 10:22 ---
(In reply to comment #4)
I have to find out why the code in question that lead to
the problem report does not properly recover with gfortran.
It might be an interference with BACKSPACE, as the
full code that lead me to the
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-06 10:31 ---
Fixed in 4.0.4/4.1.2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-06 10:31 ---
Err, FIXED!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-06 10:42 ---
No, this is a bug, 2nd stage name-lookup should find foo(const int) as var is
dependent on the template parameter T (14.6/8, /9).
But I bet we have a dup for this.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-06 10:50 ---
Stock 4.1.1 ICEs for me on the testcase, but 4.1.2 looks fine - can you provide
the wrong assembly you are seeing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
--- Comment #2 from zuxy dot meng at gmail dot com 2007-03-06 11:26 ---
Created an attachment (id=13151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151action=view)
Proposed patch against 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29498
--- Comment #13 from manu at gcc dot gnu dot org 2007-03-06 11:41 ---
(In reply to comment #4)
This is not really fixable.
Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html
I am really ignorant on this CCP optimisaton but I am willing to learn. I guess
that we merge
--- Comment #42 from michael dot klein at fazi dot de 2007-03-06 12:07
---
Created an attachment (id=13152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152action=view)
Testcase (generated assembly files from gcc 4.1.1)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
On powerpc, current auto-vectorizer does not vectorize loops that have
conversion from float to int statement in it.
For example, in case we have the following program:
#include stdarg.h
#define N 32
int main1 ()
{
int i;
int ib[N];
float fa[N] =
--- Comment #7 from dnovillo at gcc dot gnu dot org 2007-03-06 12:55
---
Might as well take this one too.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
preprocessed source at:
http://www.cg.tuwien.ac.at/~icicle/gcc/ActionsForPolarisationImages.mi
complete output:
.m.o: ActionsForPolarisationImages
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.2/configure --enable-languages=c,objc
--- Comment #10 from JBoncek at Hunter dot Com 2007-03-06 14:44 ---
This is just a nuisance at the end of a .c or .cpp file. It is, however, a
serious error that should always be notified at the end of an included (header)
file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--- Comment #9 from amacleod at redhat dot com 2007-03-06 15:01 ---
actually, mainline isn't working either. A closer examination shows the code
generated has an extra offset of -4 in the compare that shouldn't be there.
This patch triggers a bug in rtl's fwprop pass.
--
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-06 15:09 ---
Another one.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-06 15:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
building this testcase with -O2 -march=athlon -Wall -fprefetch-loop-arrays
gives:
warning: array subscript is above array bounds
[...]
which, according to VRP, seems to be valid.
testcase is:
=== Cut ===
struct real_value
{
unsigned int cl:2;
unsigned int decimal:1;
unsigned long
--- Comment #1 from mueller at gcc dot gnu dot org 2007-03-06 15:22 ---
after prefetch-loop-arrays run, vrp2 looks like this:
L81:;
D.1885_87 = r_4(D)-sig[i_13];
D.1886_88 = D.1885_87 + 160B;
__builtin_prefetch (D.1886_88, 1);
r_4(D)-sig[i_13] = 0;
i_8 = i_13 + 1;
i_26 =
--- Comment #43 from hjl at lucon dot org 2007-03-06 15:27 ---
(In reply to comment #42)
Created an attachment (id=13152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13152action=view) [edit]
Testcase (generated assembly files from gcc 4.1.1)
I got
bash-3.1$ readelf -S -N
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-06 15:31 ---
(In reply to comment #1)
and so on. since it definitely writes more than 5 ints, I don't see how it
should *not* overflow the array.
since the body of the loop is never entered.
--
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-03-06 15:50 ---
Subject: Bug 31020
Author: jsm28
Date: Tue Mar 6 15:50:28 2007
New Revision: 122620
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122620
Log:
fixincludes:
* mkheaders.in: Fix headers for each multilib
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2007-03-06 15:53 ---
Subject: Re: Bad IOSTAT values when readings NAMELISTs past EOF
On Tue, Mar 06, 2007 at 08:20:23AM -, anlauf at gmx dot de wrote:
--- Comment #3 from anlauf at gmx dot de 2007-03-06
--- Comment #3 from sayle at gcc dot gnu dot org 2007-03-06 16:30 ---
Subject: Bug 30744
Author: sayle
Date: Tue Mar 6 16:30:12 2007
New Revision: 122622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122622
Log:
PR middle-end/30744
* fold-const.c (fold_binary)
--- Comment #4 from roger at eyesopen dot com 2007-03-06 16:32 ---
This should now be fixed on both mainline and the 4.2 release branch.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #44 from michael dot klein at fazi dot de 2007-03-06 16:33
---
(In reply to comment #43)
It means your gcc 4.1.1 was built with a very old binutils and it doesn't
support COMDAT group
Yes, this gcc was build with binutils 2.15 from Debian Sarge.
Thanks
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-06 17:10 ---
(In reply to comment #3)
No, this is a bug, 2nd stage name-lookup should find foo(const int) as var is
dependent on the template parameter T (14.6/8, /9).
But I bet we have a dup for this.
14.6.4.2/1 says this
Gfortran does not report an error if an allocatable array is set to an array of
larger size, for example in the code below.
program xalloc_words
! shows error with nonconformant assignment of an allocatable array
! not caught by most compilers
character (len=1), allocatable :: w(:)
integer,
-- file: error_compiling_unary_minus.adb
procedure Error_Compiling_Unary_Minus (X : Float) is
No_Problem : Float := -1.0 * X;
ERROR : Float := X * -1.0; -- this is line 3
begin
null;
end Error_Compiling_Unary_Minus;
-- end of file
$ gcc -v -c error_compiling_unary_minus.adb
Using
--- Comment #22 from paolo at gcc dot gnu dot org 2007-03-06 17:43 ---
Subject: Bug 28080
Author: paolo
Date: Tue Mar 6 17:43:27 2007
New Revision: 122628
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122628
Log:
2007-03-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-06 17:52 ---
And this is actually invalid Ada, see PR 19539.
*** This bug has been marked as a duplicate of 19539 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-06 17:52 ---
*** Bug 31060 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
Compiled this program:
http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html
without -D_GLIBCXX_DEBUG the program works ok, but with -D_GLIBCXX_DEBUG I get
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/debug/vector:199:
error: attempt to subscript container
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-06 18:14 ---
I actually think this is a bug in the user code. the error message is correct
in that the code is acessing one past the end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-03-06 19:32 ---
Yes, this would be useful.
Confirmed.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|cannot write in |[4.3 Regression] cannot
--- Comment #2 from pcarlini at suse dot de 2007-03-06 20:17 ---
Yes, there isn't much to add, the whole point of debug-mode is catching this
kind of bug: in is_strike the vector rolls is subscripted at index 20.
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #3 from pcarlini at suse dot de 2007-03-06 20:37 ---
Sorry, I misread the backtrace: the problem happens in accumulate, called by
frame_score(), called by score().
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31061
--- Comment #7 from anlauf at gmx dot de 2007-03-06 21:51 ---
Created an attachment (id=13153)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13153action=view)
Revised demo
Revised demo. New namelist for this demo follows.
At some place, the input read gets garbled with gfortran,
--- Comment #8 from anlauf at gmx dot de 2007-03-06 21:52 ---
Created an attachment (id=13154)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13154action=view)
Namelist
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-03-06 21:57 ---
Subject: Bug 30950
Author: dfranke
Date: Tue Mar 6 21:57:02 2007
New Revision: 122640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122640
Log:
2007-03-06 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-06 21:57 ---
Subject: Bug 30950
Author: dfranke
Date: Tue Mar 6 21:57:09 2007
New Revision: 122641
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122641
Log:
2007-03-06 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-03-06 21:58 ---
Fixed in 4.2 and trunk.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from anlauf at gmx dot de 2007-03-06 22:00 ---
(In reply to comment #8)
In the new example, when I comment out the BACKSPACE
in position_nml for ios0 (EOF condition), the garbled
output goes away. But in the large program (where this
was extracted) this does not help;
// Illustrates some bugs related to __attribute__((warn_unused_result)).
struct Vector {
float x, y, z;
inline Vector() {}
inline Vector(float _x,float _y,float _z) : x(_x), y(_y), z(_z) {}
// BUG: Toggling the presence of a copy constructor (doesn't matter
which
--- Comment #1 from fletcherdunn at yahoo dot com 2007-03-06 22:26 ---
Created an attachment (id=13155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13155action=view)
Repro code with the proper line breaks
Line breaks got messed up when pasting into bug description.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-06 22:40 ---
// If you comment out the copy constructor, the warnings do not appear.
// Note that I produced this with the Playstation (CELL) version of GCC under
// MinGW/MSys, but I don't think this is a platform specific
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 00:05 ---
Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-03-07 00:16 ---
The change to gccspec.c was made by Franz Sirl on 2001-06-16, revision 43421.
The mail on gcc-patches is at
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01394.html. There's further
discussion at
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-07 00:26 ---
I should mention that with the GNU runtime, we want the shared libgcc for
exceptions so any patch that breaks the GNU runtime linking with the shared
libgcc should be rejected.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|50% slow down due to mem-ssa|[4.3 Regression] 50% slow
|merge
--- Comment #7 from ahs3 at fc dot hp dot com 2007-03-07 00:49 ---
Is this code snippet related to this bug, or a new one entirely?
#define LABEL(a, b) a##b##:
int main () {
LABEL(all,done)
return 0;
}
1 - 100 of 113 matches
Mail list logo
