A full bootstrap took 12h 38' on my machine (1.8Ghz G5) minus probably ~1h
diverted for
other tasks. Although I did not measured accurately this time before, it could
be my
fastest one. Most of the improvement from my original post comes from
gnu/javax/swing/text/html/parser/HTML_401F.deps, for
+++ Ian Lance Taylor [06/07/07 09:16 -0700]:
shorten_branches should work correctly--you shouldn't need to do
anything special. My only guess is that there is something wrong with
the way you are reordering the blocks. For example, perhaps you are
simply reordering the CFG without reordering
On Oct 29, 2007 10:49 AM, Dorit Nuzman [EMAIL PROTECTED] wrote:
I wonder if it's versioning-for-aliasing (run-time dependence testing) that
was responsible for a lot of the new vectorizable loops
It is then possible that the code size noticeably increased. Toon
could you provide more data on
Richard Guenther writes:
On 10/26/07, Andrew MacLeod [EMAIL PROTECTED] wrote:
Note that we are building what-becomes-openSUSE 11.0 with current trunk
in parallel to 4.2 at the moment, switching to 4.3 is in the next weeks
(unless I get pushed back again ;)).
It would be excellent
Most of the improvement from my original post comes from
gnu/javax/swing/text/html/parser/HTML_401F.deps, for which the compile time
went from over 100 minutes to below 10 (twice due to multilib). For all the
other pieces of code the saving (if any) was clearly well below a factor 2.
Does
Ian Lance Taylor wrote:
It appears that the draft C++0x memory model prohibits speculative
stores.
Therefore I now think we should aim toward prohibiting them
unconditionally.
I agree, or perhaps unless the user specifies a flag like
-fthread-unsafe-opts or something.
That memory model is
Snapshot gcc-4.2-20071031 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071031/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
- --with-mpfr=/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/install
- --with-local-prefix=/appl/shared/gnu/HP-UX/hppa2.0w-hp-hpux11.00
Thread model: posix
gcc version 4.3.0 20071031 (experimental) (GCC)
But using this as bootstrap compiler for itself results in the following error
in stage 1:
gcc -g
--- Comment #8 from hailijuan at gmail dot com 2007-10-31 07:18 ---
Subject: Re: gfortran: incorrect output for array of dynamic bounds
running a.out compiled with -fbounds-check and then get following message:
micro# ./a.out
Fortran runtime error: Array reference out of bounds for
--- Comment #9 from hailijuan at gmail dot com 2007-10-31 07:20 ---
invalid testcase.
--
hailijuan at gmail dot com changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-10-31 07:24
---
Fixed on mainline.
Probably by the patch for PR31993 and PR32252.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-10-31 07:56 ---
Subject: Bug 19531
Author: chrbr
Date: Wed Oct 31 07:55:46 2007
New Revision: 129792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129792
Log:
fix PR c++/19531: NRV is performed on volatile temporary
Added:
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-10-31 08:01 ---
fixed check_return_expr
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-31 08:23
---
Subject: Bug 33948
Author: rsandifo
Date: Wed Oct 31 08:23:30 2007
New Revision: 129794
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129794
Log:
gcc/
PR target/33948
* config/mips/mips.c
--- Comment #4 from rsandifo at gcc dot gnu dot org 2007-10-31 08:23
---
Fixed on mainline.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-31 09:20 ---
Apart from the issue regarding that the last two errors should be notes this
is really impossible to fix if -Wfatal-errors should continue to work as
designed. That is, the only way would be to annotate all
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-31 09:13
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 09:47 ---
Uh, the VEC_* stuff used there looks like a mess. It's not clear who allocates
and what the size should be. For example vect_get_vec_defs_for_stmt_copy
doesn't allocate the VECs which is exactly what causes the
--- Comment #15 from burnus at gcc dot gnu dot org 2007-10-31 09:59 ---
Subject: Bug 33897
Author: burnus
Date: Wed Oct 31 09:59:16 2007
New Revision: 129795
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129795
Log:
2007-10-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #16 from burnus at gcc dot gnu dot org 2007-10-31 09:59 ---
FIXED on the trunk (= 4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-31 10:25 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from ubizjak at gmail dot com 2007-10-31 10:31 ---
Smaller testcase:
--cut here--
void
blockmove_NtoN_blend_noremap32 (const unsigned int *srcdata, int srcwidth,
int srcheight, int srcmodulo,
unsigned int
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-31 10:37 ---
typedef unsigned int UINT32;
void blockmove_NtoN_blend_noremap32 ( const UINT32 *srcdata,int srcwidth,int
srcheight,int srcmodulo, UINT32 *dstdata,int dstmodulo, int srcshift) {
UINT32 *end;
while (srcheight) {
--- Comment #5 from irar at il dot ibm dot com 2007-10-31 10:57 ---
The problem here is that more than one vector stmts are used to vectorize (SLP)
this loop, while only one vector operand is created in case of vector shift
with scalar argument.
I am preparing a patch.
Thanks,
Ira
--- Comment #19 from dominiq at lps dot ens dot fr 2007-10-31 11:11 ---
Minimal quick and dirty patch (including Tobias' one) that fixes the composite
relational operators:
--- /opt/gcc/_gcc-clean/gcc/fortran/module.c2007-10-28 21:01:20.0
+0100
+++
--- Comment #6 from irar at il dot ibm dot com 2007-10-31 11:22 ---
(In reply to comment #2)
Uh, the VEC_* stuff used there looks like a mess. It's not clear who
allocates
and what the size should be.
I'll take a look and fix if necessary.
For example
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-10-31 12:09 ---
I can duplicate this locally. Here's a smaller test case:
templatetypename T
struct uncvref
{
typedef T type;
};
templatetypename... Args
struct args
{
static const int size = sizeof...(Args);
};
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-10-31 12:23 ---
This tiny patch should fix the problem. We weren't digging into TYPENAME_TYPEs
deep enough to find all of the parameter packs. The patch fixes both the
original test case and the reduced one. However, I can't test
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-31 12:24 ---
Another, similar testcase. ICEs at -O and above with
Unable to coalesce ssa_names 23 and 15 which are marked as MUST COALESCE.
SR.8_23(ab) and SR.8_15(ab)
t.ii: In function 'int main(int, char**)':
t.ii:36:
gfortran rejects the following:
function bug(i) result(c)
integer, pointer :: i
character(len=merge(1,2, associated(p)) :: c
end function bug
Error: Inquiry function 'associated' at (1) is not permitted in an
initialization expression
However according to 7.1.6.2 of ISO/IEC1539-1 there is
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-31 12:31 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-31 12:33 ---
Subject: Bug 33779
Author: rguenth
Date: Wed Oct 31 12:33:05 2007
New Revision: 129796
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129796
Log:
2007-10-31 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-31 12:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from irar at il dot ibm dot com 2007-10-31 12:57 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 129627)
+++ tree-vect-transform.c
--- Comment #1 from anlauf at gmx dot de 2007-10-31 12:59 ---
(In reply to comment #0)
[...]
(and indeed no other compiler I have access to has complained about this.)
As a side note: xlf 9.1 says this is a F2003 feature and not a F95 feature.
--
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-31 13:07
---
The memory is temporarily needed now by solve_graph(), because the graph has
48902 nodes. On the mainline we have only 3 constraints while for 4.2 we have
thousands:
ANYTHING = ANYTHING
READONLY = ANYTHING
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-31 13:09 ---
The c#4 testcase fails even on x86_64-linux, with
-m64 -Os -fno-omit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-31 13:17 ---
The test case is bogus (missing closing parenthesis and p is not a pointer). I
hope the following is valid:
! { dg-do compile }
function bug(i) result(c)
integer, pointer :: i
character(len=merge(1,2,
--- Comment #8 from bonzini at gnu dot org 2007-10-31 13:21 ---
Reopening and marking as enhancement.
A patch like this should work:
Index: sparseset.c
===
--- sparseset.c (revision 129768)
+++ sparseset.c (working copy)
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-31 13:33 ---
(7) A specification inquiry where each designator or function argument is
(a) a restricted expression or
(b) a variable whose properties inquired about are not
(i) dependent on the upper bound of the last
--- Comment #20 from burnus at gcc dot gnu dot org 2007-10-31 13:35 ---
Alternative patch (bootstraps/regtests).
I'm not sure how soon I can submit it.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-31 13:41 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from spop at gcc dot gnu dot org 2007-10-31 13:53 ---
Subject: Bug 32377
Author: spop
Date: Wed Oct 31 13:53:03 2007
New Revision: 129797
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129797
Log:
2007-10-31 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #19 from spop at gcc dot gnu dot org 2007-10-31 13:53 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from tow21 at cam dot ac dot uk 2007-10-31 13:58 ---
(Sorry for mis-typed example, I can't cut paste from the VM I'm working in
into my web-browser. Your corrected version is what I meant to type)
Well I'm going from the F95 standard (which is the only one I have to
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-31 14:04
---
(In reply to comment #20)
Alternative patch (bootstraps/regtests).
I think it's better to go that way: apparently, care has been taken until now
to keep module files alphanumeric, let's keep it that way.
If
--- Comment #16 from dberlin at gcc dot gnu dot org 2007-10-31 14:22
---
Subject: Re: [4.2 Regression] memory hog in solve_graph
On 31 Oct 2007 13:07:57 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #15 from rguenth at gcc dot gnu dot org
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-10-31 14:27
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Oct 31 14:26:57 2007
New Revision: 129798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129798
Log:
2007-10-31 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #8 from tromey at gcc dot gnu dot org 2007-10-31 14:50 ---
Subject: Bug 30786
Author: tromey
Date: Wed Oct 31 14:50:13 2007
New Revision: 129800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129800
Log:
gcc/testsuite
PR preprocessor/30786:
*
Starting with r129030 tramp3d-v4 segfaults on startup if compiled statically
with -fopenmp. This can be reproduced with the preprocessed testcase from
http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.ii.gz (x86_64) and compiling
with -fopenmp -static (optimization does not change the effect).
--- Comment #11 from jakub at gcc dot gnu dot org 2007-10-31 14:47 ---
Created an attachment (id=14449)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14449action=view)
gcc43-pr31507.patch
That's IMHO wrong, you are changing the meaning of constraint.
This patch is what I'll
--- Comment #10 from rask at gcc dot gnu dot org 2007-10-31 14:44 ---
Oops, I'm sorry about stealing your bug, Jakub. I didn't see you had taken it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-31 14:53 ---
gdb doesn't like static code too much but the following is a backtrace of the
crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x88d8a0 (LWP 8358)]
0x in ?? ()
(gdb)
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-31 14:37 ---
Created an attachment (id=14448)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14448action=view)
patch for testing
This seems to be a simple mismatch between what push_operand() accepts and what
matches the ''
g++ -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc4.2.0
Thread model: posix
gcc version 4.2.0
using the following compilation flags:
g++ -Wall -Werror -ansi -pedantic -Wno-long-long -pipe -fmessage-length=0
-funit-at-a-time
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-10-31 14:31
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Oct 31 14:30:48 2007
New Revision: 129799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129799
Log:
2007-10-31 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #1 from eran dot nissenhaus at mobileye dot com 2007-10-31
14:34 ---
Created an attachment (id=14447)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14447action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33958
Error also occurs in g++4.3 in 20071026 snapshot. In that snapshot,
the ice occurred on line 6651 which is a gcc_assert preceded by comment:
/* We should never instantiate a nested class before its enclosing
class; we need to look up the nested class by name before we can
instantiate
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 14:59 ---
Which is
static inline int
__gthread_cond_broadcast (__gthread_cond_t *cond)
{
return __gthrw_(pthread_cond_broadcast) (cond);
}
It looks like pthread_cond_broadcast is not correctly bound, as the disassembly
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-31 15:00 ---
That's IMHO wrong, you are changing the meaning of constraint.
Yes, I see what you mean, they ('' and '') are defined independently of stack
direction. They should however accept PRE_MODIFY and POST_MODIFY.
--
--- Comment #22 from burnus at gcc dot gnu dot org 2007-10-31 15:10 ---
Subject: Bug 33941
Author: burnus
Date: Wed Oct 31 15:10:12 2007
New Revision: 129801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=129801
Log:
2007-10-31 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #23 from burnus at gcc dot gnu dot org 2007-10-31 15:11 ---
Alternative patch (bootstraps/regtests).
I think it's better to go that way: apparently, care has been taken until now
to keep module files alphanumeric, let's keep it that way.
If your patch regetests fine,
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-31 15:23 ---
The complete statically linked __cxa_guard_release looks like:
005528d0 __cxa_guard_release:
5528d0: 53 push %rbx
5528d1: 48 89 fbmov%rdi,%rbx
--- Comment #1 from cppljevans at suddenlink dot net 2007-10-31 15:09
---
I was unable to create attachment; so, here's the source (no #includes).
-- cut here --
//Purpose:
// Reproduce, with simplified code, the error:
/*
main.cpp:1675: instantiated from here
main.cpp:1277:
--- Comment #13 from jakub at gcc dot gnu dot org 2007-10-31 15:08 ---
See md.texi:
@cindex @samp{} in constraint
@item @samp{}
A memory operand with autodecrement addressing (either predecrement or
postdecrement) is allowed.
And that's for a reason, post_modify here adjusts it by
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 15:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 15:46 ---
Works for me. Try a newer 4.2.x release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33958
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-31 15:48 ---
What happens if you force libpthreads to be all linked in?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from andreast at gcc dot gnu dot org 2007-10-31 15:58
---
Started a test build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-31 15:58 ---
dwarf2out.c needs to handle DECL_BY_REFERENCE PARM_DECLs (and perhaps also
RESULT_DECLs).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from andrew dot stubbs at st dot com 2007-10-31 16:15
---
This bug appears to be no longer present in GCC 4.2.1.
--
andrew dot stubbs at st dot com changed:
What|Removed |Added
--- Comment #20 from jakub at gcc dot gnu dot org 2007-10-31 16:31 ---
What I'd try instead is something like:
--- tree-data-ref.c.jj112007-10-28 19:34:10.0 +0100
+++ tree-data-ref.c 2007-10-31 16:22:21.0 +0100
@@ -629,7 +629,7 @@ dr_analyze_innermost (struct
The attached simple sample application crashes if it is with g++ 4.3 at -O1 or
higher.
To make things even odder, it works as expected when built with g++ 4.3 at -O1
or higher with -DDONTCRASH, even though the #ifdef DONTCRASH codepath is never
actually run.
The problem is reproducable on both
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-31 16:52 ---
But should we really print it? What if this while_stmt contains
say megabyte of source? Wouldn't be better to just print
could not convert expression at [locus] to bool?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-31 16:53 ---
This is the new pass by Matz which is causing the issue. So we have a
conditional write which writes to a read only memory.
Though the warning:
vt.cc: In function 'int main(int, char**)':
t.cc:21: warning:
--- Comment #1 from bero at arklinux dot org 2007-10-31 16:44 ---
Created an attachment (id=14450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14450action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33961
--- Comment #3 from bero at arklinux dot org 2007-10-31 17:00 ---
That conversion warning is only in the simplified test case, the original code
it's extracted from (khtml) doesn't pass a string constant (it passes html code
retrieved from a web server) and crashes the same way.
There
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-31 17:03 ---
Reduced testcase:
void decode(char *d, int len);
void decode(char *d, int len) {
int i = len - 1;
while(i = 0) {
d[i];
if(d[i] == 0)
d[i]='
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|rtl-optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-31 17:07 ---
So what we have is a conditional store but a non conditional read. So the
store can trap but the read does not. Really using a const_cast does nothing
to change the fact you are passing a readonly memory to
--- Comment #6 from tromey at gcc dot gnu dot org 2007-10-31 17:37 ---
This patch makes gcc enter an infinite loop rather than ICEing.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from maksim at kde dot org 2007-10-31 17:45 ---
The usage scenario of the method pretty much precludes it from being used in a
way where read-only memory would have to be written, except if someone does
something silly with the API. Essentially it is called either with
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-31 17:46 ---
(In reply to comment #2)
Works for me. Try a newer 4.2.x release.
I wonder if the fix for PR25413 fixed this problem - it went into 4.2 on July
25th, just shortly after 4.2.1 was released :-( but should be in 4.2.2
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-10-31 17:39 ---
It does not reproduce for me on i686-linux, either. Do you pass any special
flags to configure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #4 from dj at redhat dot com 2007-10-31 18:03 ---
Subject: Re: iv folding fails with pointer iterations
Oops, sorry, I have a local patch. Apparently I'm trying to support
pointer math the same size as pointers (pointers are 24 bits) as an
option for the future, which
--- Comment #4 from dje at gcc dot gnu dot org 2007-10-31 18:20 ---
If the nm found only is a wrapper passing through the arguments, the -B
-X32_64, should not cause an error.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-31 18:20 ---
I think the middle-end internal sizetype needs to be at least the same size
as pointer types, otherwise you _will_ definitely see wrong-code in some
circumstances.
--
--- Comment #7 from bero at arklinux dot org 2007-10-31 17:54 ---
To clarify, the problem in this usage scenario occurs because the test case
crashes even though the code path that writes to the read-only memory is never
actually run (there is no \0 in the string).
if(d[i] == 0) {
--- Comment #5 from dougkwan at google dot com 2007-10-31 18:00 ---
Subject: Re: New: [4.3 Regression] r129030 breaks -fopenmp -static compile of
tramp3d-v4
I'm looking at that.
-Doug
31 Oct 2007 14:52:04 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED]:
Starting with
--- Comment #4 from bero at arklinux dot org 2007-10-31 18:36 ---
Unfortunately I don't remember what I was trying to compile, but I was trying
to compile some open source code I had downloaded. It was running javac on a
huge list of files, one of which was empty (probably to be
--- Comment #6 from dj at redhat dot com 2007-10-31 18:36 ---
Subject: Re: iv folding fails with pointer iterations
Hmmm... pointers are PSImode (24 bits) with --mcpu=m32c. How do you
make sizetype that size? The chip doesn't have enough 24 bit math
opcodes to do all the things gcc
--- Comment #3 from tromey at gcc dot gnu dot org 2007-10-31 18:26 ---
Confirmed.
I would not mind giving an error for this. We don't necessarily have
to be compatible with javac here.
I wonder, though, whether this is used in a configure script or something
like this. How did the
--- Comment #3 from cppljevans at suddenlink dot net 2007-10-31 18:49
---
When that following main is used instead of the one posted earlier,
the error no longer occurs.
-- cut here --
int
main(void)
{
typedef gram_treevars gt;
gt::productions prods;
#define INST_SEQ
--- Comment #1 from pthaugen at gcc dot gnu dot org 2007-10-31 19:05
---
Looks like the -fpic/PIC/pie/PIE issue was fixed on mainline with the following
patch.
2007-09-04 Daniel Jacobowitz [EMAIL PROTECTED]
* config/rs6000/rs6000.c (rs6000_stack_info): Allocate space for
--- Comment #7 from tromey at gcc dot gnu dot org 2007-10-31 19:12 ---
I'm testing a revised patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
-languages=c,c++ --enable-long-long --enable-checking
--with-gmp=/home/tmp/u/rjpeters/gmp-4.2.1-install
--with-mpfr=/home/tmp/u/rjpeters/mpfr-2.2.1-install
Thread model: posix
gcc version 4.3.0 20071031 (experimental) [trunk revision 129804] (GCC)
$ cat bug.C
template class T struct A;
template
--- Comment #3 from pcarlini at suse dot de 2007-10-31 19:23 ---
Good point, Jakub. If you have a patch ready to post, please go ahead, don't be
afraid to reassing. Otherwise, will work along the lines you are suggesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-31 19:25 ---
This is valid code and cselim really has to be changed not to introduce writes
to possibly shared or read-only variables that are otherwise never written
into.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33961
1 - 100 of 133 matches
Mail list logo
