In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in
I used the files from trunk revision 124627 and the build went fine.
I'll try to find some time to fill a PR
Dominique
I got the second one too. Italians must be good at acronyms. :-)
IMBGAA!
...BTTOWWTD!!!
PBTMAICFOTL (Probably better than me as I cannot figure out the latter).
On the other hand, it may mean that we can skip stage2 altogether, since
we had stage2 during stage1 for 4.3...
I'm
Hi,
I have added to the wiki the list of Google's SoC projects for this
year. http://gcc.gnu.org/wiki/SummerOfCode
From my experience of last year, I would recommend to create a wiki
page for your project to dump anything that could be remotely useful
and to allow people to add comments. You
On Fri, Apr 27, 2007 at 08:24:11AM -0700, Richard Henderson wrote:
On Fri, Apr 27, 2007 at 04:00:13PM +0200, Rask Ingemann Lambertsen wrote:
I don't see how emit_move_complex_push() can ever generate a push
instruction. Here's a backtrace:
emit_move_insn (gen_rtx_MEM (submode, XEXP
Hello,,
When I do gcc foo.c, behind the scenes I suppose there
are many actions, like calling 'cpp', 'gcc', 'as' and finally, 'ld'.
Is there a way to know what is going on exactly behind the
scenes of gcc ?
Like which other tools are called and with which command line
arguments ?
Thank You
On 20 May 2007 17:40, Sunzir Deepur wrote:
Hello,,
When I do gcc foo.c, behind the scenes I suppose there
are many actions, like calling 'cpp', 'gcc', 'as' and finally, 'ld'.
Is there a way to know what is going on exactly behind the
scenes of gcc ?
Like which other tools are called and
all, sorry for the misplaced (and trivial) question, won't happen again.
thank you for the nice attitude though !
sunzir.
Dominique Dhumieres wrote:
In toplevel, svn up -r 124763 Makefile.tpl Makefile.def Makefile.in
I used the files from trunk revision 124627 and the build went fine.
I'll try to find some time to fill a PR
I can confirm your hunting. Reverting the mentioned patch brings
bootstrap back on
Thanks,
You're welcome!
This is PR32009.
Cheers
Dominique
Paolo Bonzini wrote:
...BTTOWWTD!!!
PBTMAICFOTL (Probably better than me as I cannot figure out the latter).
Never mind, it was meant to be impossible to decode: But The Third
One Was Way Too Difficult :-)
Would these have to go in now or later in 4.4?
I would propose waiting for these
Bernardo Innocenti wrote:
(the next proposal is likely to cause some dissent)
What about moving 4.3 to stage 3 *now* and moving everything
else in 4.4 instead? Hopefully, it will be a matter of just
a few months. From http://gcc.gnu.org/gcc-4.3/changes.html,
it looks like it would already be
--- Comment #6 from daney at gcc dot gnu dot org 2007-05-20 07:11 ---
(In reply to comment #5)
With:
/home/tbm/scratch/gcc/configure -v --enable-languages=c,c++
--disable-werror
mipsel-linux-gnu
I get the same segfault in gcc/libstdc++-v3/src/fstream-inst.cc
Can you
--- Comment #7 from tbm at cyrius dot com 2007-05-20 08:47 ---
And finally, I can confirm that it works when I specify --disable-static.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
--- Comment #3 from pcarlini at suse dot de 2007-05-20 09:26 ---
Better fixing in mainline only, only GLIBCXX_FORCE_NEW has problems (in an
extension allocator)
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2007-05-20 09:29 ---
May I suggest recategorizing? In my experience, libstdc++ reports don't get
much attention from the compiler people...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31908
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-20 09:40 ---
Created an attachment (id=13587)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13587action=view)
Patch which fixes the problem
I think this patch is correct, the issue is two fold, one we don't consider
--- Comment #3 from jb at gcc dot gnu dot org 2007-05-20 09:46 ---
I see. With that in mind, I think the patch for PR31915 that went in as r124741
is incorrect (and I share some of the blame since I approved it). We should use
the size argument the frontend provides to the
--- Comment #4 from jb at gcc dot gnu dot org 2007-05-20 09:50 ---
(In reply to comment #3)
I see. With that in mind, I think the patch for PR31915 that went in as
r124741
is incorrect (and I share some of the blame since I approved it). We should
use
the size argument the
Using test_fpu.f90 of the Polyhedron testsuite,
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, fails since
2007-05-15 (r124736) on x86_64-unknown-linux-gnu, 2007-05-14 (r124708) was
still ok. Last tested: 2007-05-20 (r124860).
The ICE occures with:
gfortran -O3 -ftree-vectorize
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-05-20 10:03 ---
The problem disappeared meanwhile: 4.3.0 20070519 is no longer crashing :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31935
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-20 10:28 ---
There were no regressions in the vect.exp testsuite on powerpc-darwin. Plus a
quick s/x+i+1/y+i+1/ on this testcase gives the correct answer of
t.c:19: note: not vectorized: can't determine dependence between
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #8 from tbm at cyrius dot com 2007-05-20 10:44 ---
(In reply to comment #6)
(In reply to comment #5)
With:
/home/tbm/scratch/gcc/configure -v --enable-languages=c,c++
--disable-werror
mipsel-linux-gnu
I get the same segfault in
--- Comment #7 from nachms+gcc at gmail dot com 2007-05-20 10:46 ---
I just tested against:
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-05-20 10:52 ---
b = transpose(conjg(a)) works (also translated into
the library call).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
--- Comment #3 from uros at gcc dot gnu dot org 2007-05-20 10:54 ---
Subject: Bug 31585
Author: uros
Date: Sun May 20 09:54:23 2007
New Revision: 124868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124868
Log:
PR target/31585
* gcc.target/i386/sse-vect-types.c:
--- Comment #4 from ubizjak at gmail dot com 2007-05-20 10:55 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-20 11:20 ---
The out-of-ssa patch was clearly a hack to make this testcase work. But a real
fix involves ra and reload, none of which is in the list I like to work on ;)
But maybe Micha can try to see if this is related to
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-20 11:22 ---
Subject: Bug 32001
Author: dfranke
Date: Sun May 20 10:22:15 2007
New Revision: 124869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124869
Log:
gcc/fortran:
2007-05-20 Daniel Franke [EMAIL PROTECTED]
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-20 11:25 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-20 11:52 ---
As to comment #2, while we need one more register for the comparison, a and b
are available in the argument frame, so there's no reason to spill them, we
just need to reload them into one of the many free registers
Bootstrap is broken on ARM v3. I get Unable to determine architecture
from gcc/config/arm/lib1funcs.asm
--
Summary: [4.3 Regression] bootstrap broken on ARM v3
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from tbm at cyrius dot com 2007-05-20 11:52 ---
Caused by http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01850.html
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #2 from tbm at cyrius dot com 2007-05-20 11:54 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01304.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32007
g++ hangs computer for about 5 minutes, then reports internal error.
On program:
#include iostream
#include string
using namespace std;
int main()
{
cout \e[18t flush
string s;
return 0;
}
Compiled with:
g++ -c gcc_bug.cpp
He should report expected ';' error on line 9 (after flush,
--- Comment #1 from kuba dot skowron at gmail dot com 2007-05-20 12:05
---
Created an attachment (id=13588)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13588action=view)
preprocessed file triggering the bug
generated by command line:
g++ -v -save-temps gcc_bug.cpp
--
--- Comment #2 from kuba dot skowron at gmail dot com 2007-05-20 12:07
---
Created an attachment (id=13589)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13589action=view)
g++ output (with version and build options)
generated by:
g++ -v -save-temps gcc_bug.cpp
--
--- Comment #3 from pbrook at gcc dot gnu dot org 2007-05-20 12:18 ---
Subject: Bug 32007
Author: pbrook
Date: Sun May 20 11:18:27 2007
New Revision: 124871
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124871
Log:
2007-04-20 Martin Michlmayr [EMAIL PROTECTED]
PR
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-20 13:12 ---
This triggers the error ...
real :: a(3), b(2)
a = COS(b(:))
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32002
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-05-20 13:28
---
Subject: Bug 31196
Author: tkoenig
Date: Sun May 20 12:28:29 2007
New Revision: 124872
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124872
Log:
2007-05-20 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #3 from pcarlini at suse dot de 2007-05-20 13:29 ---
GCC 3.3.x isn't maintained anymore.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-05-20 13:30
---
Fixed on 4.2. Do we want to backport to 4.1?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Building gcc4-4.3.0-20070518 failed on OSX 10.3.9. Copies of
http://gcc.gnu.org/ml/gcc/2007-05/msg00483.html
Comparing the log of successful and failed builds I have found
that the failed one contains -mdynamic-no-pic which does not
appear in the previous build. According Apple's doc this
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-20 15:40
---
For some reason, the scalarization of conjg(transpose()) is messed up. The
following code:
complex :: a(1,1), b(1,1)
a = 0
b = conjg(transpose(a))
print *, b(1,1)
end
ends up as folllows:
int4
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-20 15:43
---
(In reply to comment #5)
What is more
confusing is that I can't trigger this scalarization bug with other intrinsics
10 seconds after I hit the Commit button, I thought about another testcase, and
it does also
--- Comment #25 from eweddington at cso dot atmel dot com 2007-05-20 16:22
---
Subject: RE: Implement binary constants with a 0b
prefix
--- Comment #24 from manu at gcc dot gnu dot org
2007-05-19 16:21 ---
Joerg,
any news about this? I cannot find the patch in
--- Comment #12 from kargl at gcc dot gnu dot org 2007-05-20 16:24 ---
(In reply to comment #11)
Fixed on 4.2. Do we want to backport to 4.1?
With 4.2 finally released, I think it is time to let
4.1 go. If gfortran follows the GCC development rules,
then this would need to be a
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-20 16:55
---
Actually, there are two separate build subdirectories created under the arch
directory in the objdir. So on systems like mine, two separate libraries are
built.
--
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-20 17:08
---
I think it may have to do with the order of resolving, I think pr32002 is not
picking up the shape checking because the array variables are not resolved
before functions using them are resolved. I think
--- Comment #3 from danglin at gcc dot gnu dot org 2007-05-20 17:38 ---
My last comment about this being a GC problem was wrong. Here's a
backtrace from a compiler containing debug symbols:
(gdb) bt
#0 0x40c5a274 in get_cse_reg_info (regno=66)
at ../../gcc/gcc/cse.c:847
Configured with
env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../4.2.0/configure
--build=powerpc64-apple-darwin8.8.0 --host=powerpc64-apple-darwin8.8.0
--target=powerpc64-apple-darwin8.8.0 --with-gmp=/pkgs/gmp-4.2.1-64/
--with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.2.0-64
and made with make
Is there a reason why in the GCC 4.3.0 the x86_64 on Linux is detected as an
x86_64-unknown-linux-gnu instead of an x86_64-pc-linux-gnu as it was in the
past?
--
Summary: Bad host triplet detection for x86_64 on Linux.
Product: gcc
Version: 4.3.0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-20 18:01 ---
This is a config.guess issue and not a GCC issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32011
--- Comment #2 from schwab at suse dot de 2007-05-20 18:03 ---
You must have been using a modified version of config.guess, the respective
line hasn't changed since it was added 6 years ago.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32011
--- Comment #4 from danglin at gcc dot gnu dot org 2007-05-20 18:15 ---
For reference, this is the rtl at the point of the hang:
(gdb) p debug_rtx_list (get_insns (), 30)
(note 6 0 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 3 6 4 2 pr31944.c:4 (set (reg/v/f:DI 68 [ mle ])
(reg:DI
Is there a reason why in the GCC 4.3.0 the x86_64 on Linux is detected as an
x86_64-unknown-linux-gnu instead of an x86_64-pc-linux-gnu as it was in the
past?
--
Summary: Bad host triplet detection for x86_64 on Linux.
Product: gcc
Version: 4.3.0
--- Comment #1 from schwab at suse dot de 2007-05-20 18:29 ---
*** This bug has been marked as a duplicate of 32011 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #3 from schwab at suse dot de 2007-05-20 18:29 ---
*** Bug 32012 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32011
--- Comment #4 from drab at kepler dot fjfi dot cvut dot cz 2007-05-20
18:33 ---
(In reply to comment #2)
You must have been using a modified version of config.guess, the respective
line hasn't changed since it was added 6 years ago.
Nope, I'm allways using the SVN version. No
--- Comment #2 from drab at kepler dot fjfi dot cvut dot cz 2007-05-20
18:34 ---
Sorry, this bugreport was posted by an accident.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32012
--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2007-05-20
18:40 ---
Same problem is on FC6, though. Also x86_64-unknown-linux-gnu. Just for the
record.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32011
--- Comment #5 from danglin at gcc dot gnu dot org 2007-05-20 19:02 ---
In order to prevent flush_hash_table from looping forever, the call to
invalidate (p-exp, VOIDmode) has to remove the element p. However, this
doesn't happen. It only removes the entry if lookup_for_remove finds
Irix 6.2 with pthread patches is not Unix98 compatible so libgomp must use the
posix95 locking primitives.
--
Summary: Use posix95 for libgomp on Irix 6.2
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority:
--- Comment #1 from gcc-tgc at jupiterrise dot com 2007-05-20 20:06 ---
Created an attachment (id=13590)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13590action=view)
Make libgomp choose posix95 for Irix 6.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32013
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-20 20:39
---
I have applied the remaining patches from comments #2 and #3 to my local trunk
and I am regression testing now. I will post to list with results in
preparation for committing these fixups.
--
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-05-20 21:01
---
One down, 54 wrong-code or ice-on-valid-code to go :-)
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
With the 4.3.0 20070518 snapshot (see PR32009) I have the following new
failures:
Native configuration is powerpc-apple-darwin7.9.0
=== gcc tests ===
Schedule of variations:
unix
...
Running /Users/dominiq/test/gcc-4.3-20070518/gcc/testsuite/gcc.dg/vect/vect.exp
...
FAIL:
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
CC||andreast at gcc dot gnu dot
|
--- Comment #6 from danglin at gcc dot gnu dot org 2007-05-20 21:30 ---
This problem isn't present in 3.4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #8 from manu at gcc dot gnu dot org 2007-05-20 21:31 ---
Subject: Bug 29694
Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124875
Log:
2007-05-20 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #22 from manu at gcc dot gnu dot org 2007-05-20 21:31 ---
Subject: Bug 12963
Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124875
Log:
2007-05-20 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-20 21:32 ---
Subject: Bug 11856
Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124875
Log:
2007-05-20 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #4 from manu at gcc dot gnu dot org 2007-05-20 21:31 ---
Subject: Bug 23587
Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124875
Log:
2007-05-20 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-20 21:33 ---
patches get sent to gcc-patches@, make sure you read
http://gcc.gnu.org/contribute.html also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32013
--- Comment #26 from manu at gcc dot gnu dot org 2007-05-20 21:31 ---
Subject: Bug 7651
Author: manu
Date: Sun May 20 20:29:55 2007
New Revision: 124875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124875
Log:
2007-05-20 Manuel Lopez-Ibanez [EMAIL PROTECTED]
PR
--- Comment #6 from hjl at lucon dot org 2007-05-20 21:40 ---
forwprop changes
bb 2:
alen_4 = alen_2(D) - blen_3(D);
out_5 = 0;
__asm__(:=r a_9, =r b_10, =mr blen_11, =mr out_12, =r
tmp_13:mr
d_6(D), 0 a_7(D), 1 b_8(D), 2 blen_3(D), 3 0:edx, eax);
if (alen_4 == 0)
goto bb
--- Comment #5 from manu at gcc dot gnu dot org 2007-05-20 21:42 ---
Fixed for GCC 4.3 (all warnings have been grouped under -Wtype-limits).
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-20 21:44 ---
Created an attachment (id=13591)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13591action=view)
new patch
This new patch changes one little thing dealing with how with indirect
references are handled in
--- Comment #24 from manu at gcc dot gnu dot org 2007-05-20 21:46 ---
As a workaround, the warning can be disabled with -Wno-type-limits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-20 21:50 ---
If it can use blen_11 instead of blen_3(D), it may compile. If forwprop can't
deal some asm stmts very well, it should skip those asm stmts.
It cannot use blen_11 instead of blen_3 because the asm will have
--- Comment #23 from manu at gcc dot gnu dot org 2007-05-20 21:50 ---
The diverse warnings of the type always true/false because of range of data
type have been grouped under -Wtype-limits that is enabled by -Wextra (and not
by -Wall). The warning can be disabled by using
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-20 21:51 ---
There is almost nothing that can be done on the tree level to fix up this
register allocator issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-05-20 22:09
---
Subject: Bug 31618
Author: tkoenig
Date: Sun May 20 21:07:14 2007
New Revision: 124878
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124878
Log:
2007-05-20 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-20 22:09 ---
Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-05-20 22:11
---
Now also fixed on 4.2.1 (revision 124878). Won't backport to 4.1.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-05-20 22:20 ---
(In reply to comment #7)
PS: as a minor improvement, we might want to give numeric types a more
Fortran-like name, with a patch such as the following:
...
Hi FX,
are you planning to submit that patch? It
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-20 23:03 ---
(From update of attachment 13591)
I take this back, this can cause an ICE with some code (which seems like I
should add a testcase).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-20 23:06 ---
(From update of attachment 13587)
This patch is safer and allows us to add more to build_classic_dist_vector_1.
Like when the two access functions are constants, just take the difference.
(which might be needed
../gcc/configure --prefix=/usr/local/gcc42 --enable-threads --with-arch=nocona
--with-tune=nocona --disable-bootstrap --disable-nls --with-gmp=/sw
--with-mpfr=/sw --with-system-zlib --enable-languages=c,c++,objc,obj-c++
--disable-multilib
Thread model: posix
gcc version 4.3.0 20070513
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-05-20 23:25
---
This is not a regression. Was not supported by g77. Fixed on 4.3
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #51 from jvdelisle at gcc dot gnu dot org 2007-05-20 23:50
---
Two testcases for 4.3 pass on 4.2. Fixed on 4.3. Because of the problems with
regressions on SPEC, I would rather not backport this. Closing.
Herald, if something else comes up, please file a new report.
On 20 May 2007 04:57:45 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #25 from pluto at agmk dot net 2007-05-20 05:57 ---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
--
Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
--- Comment #28 from dberlin at gcc dot gnu dot org 2007-05-20 23:52
---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
On 20 May 2007 04:57:45 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #25 from pluto at agmk dot net 2007-05-20 05:57
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-21 00:00
---
This is not a regression from previous releases. Closing.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kkojima at gcc dot gnu dot org 2007-05-21 00:14 ---
Subject: Bug 27405
Author: kkojima
Date: Sun May 20 23:13:48 2007
New Revision: 124879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124879
Log:
PR target/27405
Backport from mainline.
--- Comment #4 from patchapp at dberlin dot org 2007-05-21 00:16 ---
Subject: Bug number PR32002
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-05/msg01315.html
--
Friends... prob not worth creating an account in your bugzilla for...
default download of 4.2.0 source distribution... configure with no
options... no .y files changed... make reports:
/usr/local/dev/gcc/gcc-4.2.0/missing bison -t -o java/parse-scan.c
../../gcc-4. 2.0/gcc/java/parse-scan.y
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-21 00:23 ---
Subject: Bug 31022
Author: kkojima
Date: Sun May 20 23:22:46 2007
New Revision: 124880
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124880
Log:
PR target/31022
Backport from mainline.
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-21 00:25 ---
Subject: Bug 31480
Author: kkojima
Date: Sun May 20 23:25:03 2007
New Revision: 124881
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124881
Log:
PR target/31480
Backport from mainline.
1 - 100 of 123 matches
Mail list logo
