Just really ! The array arr has the type void ***, the cast happens on the
first derefencing of arr. So the result remains a void **, which is for
sure a pointer. This leads to a pointer truncation,
therefore to a warning and a build failure. It is clear, that the first
element of the array
Joseph S. Myers [EMAIL PROTECTED] writes:
We should use current CVS HEAD libtool. We definitely can't use 1.5
releases without *a lot* of auditing of local changes: we've allowed local
changes into GCC's libtool on the basis that there are equivalents in CVS
HEAD (this is the policy in
Please stop top-posting.
Kai Tietz writes:
Richard Henderson [EMAIL PROTECTED]
08.03.2007 19:08
On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
In gcc the file emutls.c assumes that a long has sizeof void * in
function
emutls_destroy.
Not really. It
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
Hallo,
There is another point in libiberty, which has a problem with
integer-values and pointer sizes. This small patch should fix.
ChangeLog:
2007-03-06 Kai Tietz [EMAIL PROTECTED]
* splay-tree.h (splay_tree_key): type declared as ptrdiff_t
(splay_tree_value): Ditto
Hallo,
I detected, that ptrdiff_t is not declared in all places, therefore the
use of size_t seems to be more correct.
Regards,
i.A. Kai Tietz
jimmy wrote:
Steven Bosscher wrote:
Hi,
I found this old patch
(http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers
to pages 202-214 of Muchnick's Advanced Compiler Design and
Implementation book. That book still is not in my own compiler books
collection because of its
Dear GCC Developers,
I have a rather simple piece of a call_value instruction pattern in my
machine description:
---snip---
(define_insn call_value
[(set (match_operand 0 )
(call (match_operand:QI 1 )
(match_operand:SI 2 )))]
jal\\t%S0%(
[(set_attr type jump)
Hi,
If you like maths, a short book Scheduling and Automatic Parallelization
by Alain Darte, Yves Robert, and Frederic Vivien, not publicized as much
as the books proposed by Vladimir, provides more formal background
than what you can find in classical compiler literature.
I would also recommend
Markus Franke [EMAIL PROTECTED] writes:
What am I doing wrong? It seems so simple but I can't figure out what's
wrong with my pattern.
Run the compiler under gdb and do a backtrace to see where the ICE is
coming from.
Ian
Vladimir, you forgot a good book:
o Y.N. Srikant P.Shankar.
The Compiler Design Handbook: Optimizations and Machine Code Generation.
CRC Press 2003. Upto page 916.
Good topics:
9. Scalar Compiler Optimizations on the Static Single Assignment (SSA) Form
and the Flow Graph
by Y.N.
J.C. wrote:
Vladimir, you forgot a good book:
o Y.N. Srikant P.Shankar.
The Compiler Design Handbook: Optimizations and Machine Code
Generation.
CRC Press 2003. Upto page 916.
Thanks for reminding. I know about this book but I did not read it. It
looks very interesting but it is
It might be considered a backend issue, but in general it
is a binutils (so OP is in the wrong list!).
I beg to disagree with the in general it is a binutils issue part.
One of the posters explained why the information needed for name
decoration can't be determined at link-time (nor at
On Fri, Mar 09, 2007 at 08:36:25AM -0500, Vladimir N. Makarov wrote:
o Muchnik book is a fat one. Muchnick's book is rather encyclopedia
of optimizations and can be considered as collection of articles with
many details (sometimes too many). But some themes (like RA and
scheduling) are
On 3/9/07, Vladimir N. Makarov [EMAIL PROTECTED] wrote:
o Muchnik book is a fat one. Muchnick's book is rather encyclopedia
of optimizations and can be considered as collection of articles with
many details (sometimes too many). But some themes (like RA and
scheduling) are described not
Maxim Kuvyrkov [EMAIL PROTECTED] wrote on 04/03/2007 11:53:47:
Hi.
I want to share some of my thoughts and doings on improving / cleaning
up current GCC instruction scheduler (Haifa) - most of them are just
small obvious improvements.
I have semi-ready patches for about a half of them and
Snapshot gcc-4.3-20070309 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I have made some progress in updating libtool in the src (binutils) tree
and I have attached the various changes (but not the actual new libtool
files) to this email in case anyone wants to see what I am doing.
I am having more trouble with the GCC tree. I put the new libtool in
the toplevel
Steve Ellcey [EMAIL PROTECTED] writes:
$ aclocal
autom4te: unknown language: Autoconf-without-aclocal-m4
aclocal: autom4te failed with exit status: 1
Looks like you have an out-of-date autom4te.cache.
Andreas.
I removed autom4te.cache and reran aclocal. Same results.
Steve Ellcey
Andrew MacLeod wrote:
There are a handful I've been involved with which are labeled as
4.0/4.1/4.2/4.3 regressions which I don't see ever being fixed in 4.0
through 4.2. There is perhaps some hope for 4.3, but 4.4 is the more
likely case. They require new development work that I think is
On mingw, I get the following:
$ cat a.c
int foo(int x) { return x+1; }
$ gcc.exe -mrtd a.c -shared -o a.dll
$ nm a.dll | grep foo
100011c0 T _foo
$ cat b.c
int __stdcall foo(int x) { return x+1; }
$ gcc.exe b.c -shared -o b.dll
$ nm b.dll | grep foo
100011c0 T [EMAIL PROTECTED]
On Fri, Mar 09, 2007 at 03:58:40PM -0800, Steve Ellcey wrote:
I am having more trouble with the GCC tree. I put the new libtool in
the toplevel directory, just like I did in the binutils src tree and
then I went to the boehm-gc (and libffi) directories to try and rerun
autoconf. If I just
I get the following ICE on IA-64:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O
libnasl-capture_packet.c
libnasl-capture_packet.c: In function 'capture_next_packet':
libnasl-capture_packet.c:19: internal compiler error: in expand_expr_real_1, at
expr.c:8786
Please submit a full bug
--- Comment #1 from tbm at cyrius dot com 2007-03-09 08:30 ---
Testcase:
typedef long unsigned int size_t;
__extension__ typedef long int __time_t;
__extension__ typedef long int __suseconds_t;
typedef struct
{
}
__sigset_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
--- Comment #9 from bonzini at gnu dot org 2007-03-09 08:44 ---
Zdenek, any chance that your aliasing oracle can be used to fix these?
--
bonzini at gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|--- |4.3.0
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-03-09 08:54
---
Alias oracle could be used for this; but my patch only uses it in loop
optimizers. So some changes to make ccp use it would be necessary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
The following two functions should be equzlivant when overflow is undefined:
int f(int a, int b)
{
return a * 10 == b*10;
}
int f1(int a, int b)
{
return a==b;
}
--
Summary: a*C == b*C where C is a constant is not optimized to a
== b
Product: gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||19987
nThis||
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a/10 == b/10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a/C == b/C is not foldded to a == b with --fast-
math/floating point
Product:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||19987
nThis||
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a*10 == b*10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a*C == b*C is not foldded to a == b with --fast-
math/floating point
Product:
--- Comment #8 from Andreas dot Kowarz at tu-dresden dot de 2007-03-09
09:37 ---
It seems that the bug triggers only when returning NULL in the new operators.
Returning something different ( tested with (void *)1 ) is a workaround for the
problem. Checking for not returning NULL in the
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
$ cat a.f90
PROGRAM TEST
INTEGER :: A
OPEN(10, FORM=UNFORMATTED, RECL=1024)
A = -1
WRITE(10) A
END PROGRAM TEST
$ gfortran a.f90 ./a.out
At line 5 of file a.f90
Fortran runtime error: I/O past end of record on unformatted file
$ pgf90 a.f90 ./a.out xxd fort.10
The macro ASM_OUTPUT_ALIGN_WITH_NOP on sparc contains an explicit filler on the
align statement. This is given as a word representing the NOP. The GNU
assembler only uses the last byte of the filler. This generates wrong code. The
original SUN assembler needs this word to insert NOPs instead of
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-09 10:06
---
This one hurts. Nevertheless, it's probably too late for 4.2.0...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ubizjak at gmail dot com 2007-03-09 10:22 ---
This problem is fixed in 4.3.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-09 10:32 ---
It looks like a no-op change. For reference:
--- ChangeLog (revision 121301)
+++ ChangeLog (revision 121302)
@@ -1,3 +1,41 @@
+2007-01-28 Daniel Berlin [EMAIL PROTECTED]
+
+ * tree.h (struct
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:33 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:35 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from baldrick at free dot fr 2007-03-09 10:41 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
Sure, it's just that overloading V_C_E like this feels somehow wrong to me.
Why? It's not overloading. V_C_E of an expression E of type X to
type Y means
--- Comment #8 from tbm at cyrius dot com 2007-03-09 10:52 ---
I definitely think this should be an error, not a warning. I only saw this
problem by luck. I'm compiling the entire Debian archive (ie 7000 packages)
on IA64 with GCC 4.3 and I cannot look at every log file (especially
This testcase:
double t (double a, double b)
{
return fmod (a, b);
}
generates wrong code when compiled with -O2 -funroll-all-loops
(-ffast-math -fomit-frame-pointer is used here only for clarity):
:
fldl4(%esp)
fldl12(%esp)
fxch%st(1)
.L2:
--- Comment #2 from tbm at cyrius dot com 2007-03-09 11:11 ---
I've confirmed that this doesn't happen with 4.2.0 20070309.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-03-09 11:11
---
Well, the only problem with V_C_E is that if you assert on the range of the
base type like
if (V_C_E X'Base (y) 5)
abort();
that you still want VRP to infer that V_C_E X'Base (y) is = 5 after this
check
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2007-03-09 11:19
---
All the mess would be way easier if the FE would not expose the subtypes to
the middle-end...
I personally agree, but there is no clear consensus among the Ada maintainers.
--
--- Comment #9 from tbm at cyrius dot com 2007-03-09 11:21 ---
This warning is really frequent. I can find 2200 warnings that mention const
and same canonical type node for different types. Some don't mention
const;
I'll look at them and file separate bugs.
--
--- Comment #10 from ubizjak at gmail dot com 2007-03-09 11:22 ---
(In reply to comment #8)
Anyway, are there any other warning messages like this one? If so, I can
search my log files.
Yes, the one reported in PR middle-end/30666.
--
--- Comment #5 from v dot lesk at ic dot ac dot uk 2007-03-09 11:28 ---
Can anyone suggest a workaround?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
--- Comment #32 from baldrick at free dot fr 2007-03-09 11:34 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
Well, the only problem with V_C_E is that if you assert on the range of the
base type like
if (V_C_E X'Base (y) 5)
abort();
that you still want VRP to
--- Comment #33 from baldrick at free dot fr 2007-03-09 11:50 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
My suggested use of a builtin would allow multiple redundant validity checks
to be safely eliminated, because the builtin would be a pure function.
This is presumably
--- Comment #2 from joseph at codesourcery dot com 2007-03-09 12:06 ---
Subject: Re: New: a*C == b*C where C is a constant
is not optimized to a == b
On Fri, 9 Mar 2007, pinskia at gcc dot gnu dot org wrote:
The following two functions should be equzlivant when overflow is
: Segmentation fault
g++ --version
g++ (GCC) 4.3.0 20070309 (experimental)
--
Summary: ICE with -O2 -ftracer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #11 from tbm at cyrius dot com 2007-03-09 12:13 ---
Another problem is that this warning does not always occur, even when I use
the same source and options.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-09 12:29 ---
The error setting happens in io/transfer.c's write_buf:
/* Unformatted sequential. */
have_written = 0;
if (dtp-u.p.current_unit-flags.has_recl
(gfc_offset) nbytes
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 ---
Subject: Bug 30904
Author: rguenth
Date: Fri Mar 9 12:29:09 2007
New Revision: 122748
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122748
Log:
2007-03-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-03-09 12:29
---
Subject: Bug 31058
Author: rguenth
Date: Fri Mar 9 12:29:09 2007
New Revision: 122748
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122748
Log:
2007-03-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-09 12:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-09 12:30
---
The original issue is fixed. The rest belongs in a different bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from Zarathustra at gentlemansclub dot de 2007-03-09 12:35
---
(In reply to comment #5)
So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
ambiguous. I must admit that I don't know whether this is the correct
behavior.
Also the SunCC yields the
--- Comment #11 from patchapp at dberlin dot org 2007-03-09 12:40 ---
Subject: Bug number PR30643
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-03/msg00545.html
--
warning: same canonical type node for different types - with long int
% /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 icu-dtfmtsym.ii
dtfmtsym.cpp: In member function 'void
icu_3_6::DateFormatSymbols::setMonths(const icu_3_6::UnicodeStr
ing*, int32_t, icu_3_6::DateFormatSymbols::DtContextType,
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:46 ---
Created an attachment (id=13176)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13176action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
warning: same canonical type node for different types - anonymous
% /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 dosbox-sdl_mapper.ii
sdl_mapper.cpp: In function 'void CreateBindGroups()':
sdl_mapper.cpp:1554: warning: same canonical type node for different types
CBindList [(long int)anonymous] and
--- Comment #12 from tbm at cyrius dot com 2007-03-09 12:49 ---
PR31103 - same canonical type node for different types with long int
PR31104 - same canonical type node for different types with anonymous
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:50 ---
Created an attachment (id=13177)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13177action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-09 12:55 ---
I was checking where bytes_left is set:
open.c: u-bytes_left = 0;
This is the default setting in new_unit (/* Open an unused unit. */)
It is also set to 0 in file_pos.c (two places).
In list_read.c's next_char
--- Comment #2 from tbm at cyrius dot com 2007-03-09 13:06 ---
Created an attachment (id=13178)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13178action=view)
testcase
I should mention that this warning doesn't show up all the time, but it'll
eventually show when you try long
--- Comment #2 from droessle at us dot ibm dot com 2007-03-09 13:25 ---
Thanks for the direction. I will take the issue up at RH.
--
droessle at us dot ibm dot com changed:
What|Removed |Added
/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/xgcc
-B/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/
-B/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin/ -c
-O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes
1) fesetexcept(FE_EXCEPT_ALL) sets the control fpu control word to 0x342, so
that the denormal operand exeption is masked, by definition all exceptions are
supposed to be enabled so it should be using 0x340.
2) If I establish a signal handler for FPEs the fpu is being reset to its
default state
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:58 ---
These are all not compiler issues but glibc and/or kernel issues.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
13:59 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
You may well respond that you are only supposed to forget
information you deduced from the range of the type, not information
you worked out by
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:59 ---
Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=122746
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 14:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from mtrudel at gmx dot ch 2007-03-09 14:05 ---
I close this bug as WONTFIX because there's no active cygwin maintainer for
libjava. So, if it's not fixed already, it probably won't be fixed anyway.
I just once tested it for fun :-)
--
mtrudel at gmx dot ch changed:
--- Comment #2 from mtrudel at gmx dot ch 2007-03-09 14:12 ---
Thanks. But actually I also tried to start a discussion why such compilation
errors can happen:
This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
Is it possible that some flags trigger the
--- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
14:18 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
All the mess would be way easier if the FE would not expose the subtypes to
the middle-end...
I don't see how giving *additional* information could
--- Comment #36 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09
14:29 ---
Subject: Re: [4.3 regression] ACATS cxh1001 fails
I don't think this is a very serious problem. My understanding is
that the checks can be divided into two classes: normal checks and
validity
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.3 Regression] same |[4.3 Regression] same
|canonical type node for
--target-help shows compiler, assembler and linker options together, without
saying which is which. It can confuse users (see PR31073 for example).
Example: on i686-pc-linux-gnu, with mainline:
$ gcc --target-help | tail -n 35
-mtune= Schedule code for given CPU
-muclibc
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-09 15:23
---
(In reply to comment #6)
when typing gfortran --target-help those options are all listed as compiler
options.
We all agree it's a bug: compiler, assembler and linker options are listed
there indifferently. I
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 15:23 ---
I think gas should be fixed instead of the driver.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-09 15:30 ---
(In reply to comment #3)
I close this bug as WONTFIX because there's no active cygwin maintainer for
libjava. So, if it's not fixed already, it probably won't be fixed anyway.
I just once tested it for fun :-)
The ACATS failure occurs with gcc-4.2-20070307 bootstrapped from
gcc-4.2-20061226.
I was not able to build any 4.0 or 4.1 Ada compiler on MinGW, so this is a
regression against gcc-3.4.
,.,. C35507M ACATS 2.5 07-03-09 15:15:52
C35507M CHECK THAT THE ATTRIBUTES 'POS' AND 'VAL' YIELD THE
--- Comment #13 from mueller at gcc dot gnu dot org 2007-03-09 16:16
---
Subject: Bug 17946
Author: mueller
Date: Fri Mar 9 16:16:35 2007
New Revision: 122751
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122751
Log:
2007-03-09 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #14 from mueller at gcc dot gnu dot org 2007-03-09 16:17
---
Fixed for 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
gcc 3.3 is working fine in Interix (Services for Unix under Windows) on other
Windows XP machines that I use (both laptop and desktop)
A new installation of SFU35SEL_EN.exe (SFU/Interix) on a new IBM ThinkPad
laptop with Centrino Duo procesor does not seem to allow compilation of any
program (I
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-09 17:05
---
Created an attachment (id=13179)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13179action=view)
from SVN revision: 122728
Commandline used to create libgcc2.i:
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-09 17:05 ---
This is not that much of a blocker, really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-09 17:08 ---
In fact this is an enhancement and really there just needs a new win32 option
for this feature.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl at lucon dot org 2007-03-09 17:11 ---
Gcc 4.3 revision 122738 has the same issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-09 17:14 ---
Of course I could be completely wrong. But if I'm right, there would be an
easy
way to prevent such build breaks...
People make mistakes, this was just one of them.
--
--- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 ---
Created an attachment (id=13180)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180action=view)
A breakdown testcase
xxx.f90 is the problem. -fdump-tree-all shows that revision 121302
generates very different alias
1 - 100 of 195 matches
Mail list logo
