--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 07:46 ---
Paul, I CC you as you are our generic-resolution expert.
* * *
gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
print the following:
E
S, S
E
E, E ! you expect an S, S here
Looking
--- Comment #2 from jpr at csc dot fi 2009-06-15 08:28 ---
(In reply to comment #1)
Paul, I CC you as you are our generic-resolution expert.
* * *
gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
print the following:
E
S, S
E
E, E ! you
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 08:52 ---
(In reply to comment #2)
COmplete code for the test case including the module iso_varying_string
Works with: gfortran 4.3.3, ifort 11, sunf95, NAG f95 5.1 (w/o flush
statements)
Fails (abort) with gfortran
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-15 09:05 ---
I have applied the following patch on revision 148472
diff -up libffi/testsuite/libffi.call/err_bad_abi.c
/opt/gcc/gcc-4.5-work/libffi/testsuite/libffi.call/err_bad_abi.c
---
--- Comment #9 from jamborm at gcc dot gnu dot org 2009-06-15 09:07 ---
Created an attachment (id=18001)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18001action=view)
Fix
This was quite a serious oversight on my part, I wonder how it went
for so long unnoticed. I am about to
--- Comment #5 from aph at gcc dot gnu dot org 2009-06-15 09:07 ---
That probably is my fault. However, I can't do anything about it until I see
the testsuite log file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
--- Comment #6 from aph at gcc dot gnu dot org 2009-06-15 09:08 ---
Re http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00929.html:
That was answered on Fri, 12 Jun by Kaz Kojima.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-15 09:09 ---
Created an attachment (id=18002)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18002action=view)
Fix
OK, the statement is fine except that it is not gimple ;-). Fixed
with this patch, I will submit it if
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-15 09:19 ---
That probably is my fault. However, I can't do anything about it until I see
the testsuite log file.
The log file looks like:
...
Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-15 09:19
---
(In reply to comment #0)
I can't use template A Bint::a = something; form (which would help)
because I have only empty ctor (like in the case of map).
I'm not sure what you mean but this works fine:
template
--- Comment #8 from dominiq at lps dot ens dot fr 2009-06-15 09:24 ---
That was answered on Fri, 12 Jun by Kaz Kojima.
Not exactly, it answered about some future goal of the tests, but without any
name of platform(s) on which they work. My implicit question is does it make
any sense
--- Comment #9 from aph at gcc dot gnu dot org 2009-06-15 09:29 ---
I need to know why it's crashing. Usually there's some sort of error message.
If there's not, there's no choice but to debug.
This Darwin problem is clearly not the same bug as 40385, so it needs a new
Bugzilla
See comment #4 of pr40385:
=== libffi Summary for unix ===
# of expected passes1594
# of expected failures 10
# of unsupported tests 15
Running target unix/-m64
FAIL: libffi.call/closure_fn0.c -O0 -W -Wall execution test
...
FAIL:
--- Comment #10 from dominiq at lps dot ens dot fr 2009-06-15 09:42 ---
This Darwin problem is clearly not the same bug as 40385, so it needs a new
Bugzilla entry.
This is now pr40444.
I expect that a patch to xfail err_bad_abi.c on *-*-* would be approved.
Probably
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-15 09:55
---
extern C int printf(const char*, ...);
struct A
{
A() : value(1) { printf(A::A %d\n, value); }
int value;
};
templateclass T
struct B
{
static A a;
};
templateclass T A BT::a = A();
--- Comment #12 from irar at il dot ibm dot com 2009-06-15 09:58 ---
(In reply to comment #9)
The patch in comment #8 fixes the failures reported in comment #7. I now see
(powerpc-apple-darwin9 with -m64):
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect Alignment of access
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 ---
Subject: Bug 40439
Author: rguenth
Date: Mon Jun 15 10:05:29 2009
New Revision: 148486
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148486
Log:
2009-06-15 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-15 10:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-15 10:10 ---
ping 4.3.4...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087
--- Comment #13 from eres at il dot ibm dot com 2009-06-15 10:41 ---
Created an attachment (id=18003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18003action=view)
Patch to fix error in vect-42.c
Ira, thanks for the suggestion!
I deleted an extra space, so now the syntax is {!
--- Comment #3 from joseph at codesourcery dot com 2009-06-15 10:57 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
This may be true for standard headers, but system directories don't contain
only standard
--- Comment #16 from mrsam at courier-mta dot com 2009-06-15 11:13 ---
After staring at the code for a while, I'm leaning towards thinking that this
change does not really change the application ABI, so the soname bump is not
needed.
As far as I can tell, there are no public members of
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-15 11:24 ---
gfortran 4.1 to 4.5, NAG f95 5.1, g95, ifort 11, openf95, Sun Studio 12 all
print the following:
Correction, ifort 9.1 to 11.1 all print S, S - sorry for missing it. But the
other compilers listed above indeed
--- Comment #17 from paolo dot carlini at oracle dot com 2009-06-15 11:36
---
Maybe it's because I didn't really look carefully at the patch: aren't you
adding a new data member to the class? Changing either size or layout of a type
specified in the C++ standard definitely changes the
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-15 12:06
---
8.3.5p5? is that reference right?
and I assume you mean line 10, not line 14.
The pair(pair) constructor is not in the WP. Commenting it out causes the
pair(pairU,V) constructor to be used, which fails to
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-15 12:16 ---
Note: syntax_get_rule_ptr is defined as:
function syntax_get_rule_ptr (syntax, key) result (rule)
type(syntax_rule_t), pointer :: rule
type(syntax_t), intent(in), target :: syntax
type(string_t),
--- Comment #14 from dominiq at lps dot ens dot fr 2009-06-15 12:36 ---
(In reply to comment #13)
if that still does not fix the problem I will try to add more braces...
I tried several variants that were not working. The following patch works,
though I have no idea if it is right:
--- Comment #15 from dominiq at lps dot ens dot fr 2009-06-15 12:46 ---
With the patch in comment #14, on i686-apple-darwin9 I get:
=== gcc tests ===
Schedule of variations:
unix
unix/-m64
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as
--- Comment #5 from joseph at codesourcery dot com 2009-06-15 13:06 ---
Subject: Re: Option -I and POSIX conformance (c99 utility)
On Mon, 15 Jun 2009, vincent at vinc17 dot org wrote:
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-15 13:09 ---
Juergen: Thanks for the report, but it is not a regression - it might not crash
with 4.3 (or your 4.4) but I think that's just by chance.
Paul, I think also this bug touches code for which you have the expertise.
Compiling the single line program
void f() { __builtin_unreachable(); }
works fine with gcc, but triggers an ICE when compiled with g++
unreachable.c:1:37: internal compiler error: in remove_insn, at emit-rtl.c:3796
I'm using SVN revision 148487.
--
Summary: g++ void f() {
--- Comment #4 from pault at gcc dot gnu dot org 2009-06-15 13:21 ---
(In reply to comment #1)
Paul, I CC you as you are our generic-resolution expert.
Well, gosh golly, that's a mantle that I did not seek:-)
Note that my account at the CC address is no longer valid - I'll fix that.
--- Comment #16 from eres at il dot ibm dot com 2009-06-15 13:32 ---
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable} {!vect_hw_misalign} } } } } } */
+/* { dg-final {
#include emmintrin.h
#include complex
#include cstdlib
int
main ()
{
union { __m128d vec; double val[2]; } u;
std::complexdouble c = std::complexdouble(0, 1);
u.vec = _mm_load_pd ((double*)c);
if (u.val[0] != 0 || u.val[1] != 1)
abort ();
}
ICEs with -O1 and above in g++ 4.4 and
It's currently possible to build gcc in two ways.
1) Compiler and install mpfr and use switches to indicate the location of their
instalation
--with-mpfr=/somedirector --
2) Put directories mpfr and gmp under the source of gcc.
What I propose is to allow a couple of extra switches
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|g++ void f() {|[4.5 Regression] g++ void
--- Comment #15 from mikpe at it dot uu dot se 2009-06-15 14:24 ---
(In reply to comment #14)
ping 4.3.4...
The PR40087 fix depends on changes from the PR39455 fix. Both of them are 4.3
regressions, and I've used both fixes in my 4.3 tree for a while now without
issues.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-15 14:35 ---
Caused by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=134947
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40446
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 14:55 ---
(In reply to comment #1)
Caused by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=134947
In this case, exposed as VIEW_CONVERT_EXPR was not widely used before so there
will be some bugs that we did not hit until
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 14:59 ---
You can use soft links inside the source directory to say where the source
directories are located. Is that good enough?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-15 14:59 ---
Why is this a regression? Do we support _builtin_unreachable() in 4.4?
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 15:00 ---
(In reply to comment #1)
Why is this a regression? Do we support _builtin_unreachable() in 4.4?
Well it is a regression as it compiled before and did not do what the user
expected though.
--
pinskia at gcc dot
--- Comment #97 from bonzini at gnu dot org 2009-06-15 15:14 ---
Brad, could you try to time compiler.i with and without -ftime-report to see
how much of the tree stmt walking timevar is just accounting overhead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #1 from aph at gcc dot gnu dot org 2009-06-15 15:47 ---
Adding Andreas Tobler; perhaps he knows.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rwild at gcc dot gnu dot org 2009-06-15 16:11 ---
Would it help to work around this issue by collecting the objects in one or
more
convenience archives and linking those (plus at least one plain object)
together
to form libgfortran.la? The intermediate partially
--- Comment #98 from lucier at math dot purdue dot edu 2009-06-15 16:11
---
I don't quite understand how you would like me to configure and run the test.
First, I've applied your patches to speed up computing DF to my tree; do you
want them included in the test, or should I use a
--- Comment #99 from paolo dot bonzini at gmail dot com 2009-06-15 16:20
---
Subject: Re: [4.3/4.4/4.5 Regression] 30% performance
slowdown in floating-point code caused by r118475
First, I've applied your patches to speed up computing DF to my tree; do you
want them included in
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-15 16:53 ---
GCC already outputs the version of GMP/MPFR:
GNU C (GCC) version 4.5.0 20090519 (experimental) [trunk revision 147718]
(i386-apple-darwin8.11.1)
compiled by GNU C version 4.5.0 20090519 (experimental) [trunk
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-15 16:56
---
I assume this is only in your experimental version. I can see that is an
improvement. I still think the switch would be useful, but it does reduce the
need for it somewhat.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-15 17:08 ---
Subject: Bug 40426
Author: jakub
Date: Mon Jun 15 17:08:02 2009
New Revision: 148497
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148497
Log:
PR testsuite/40426
* lib/gcc-dg.exp
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-15 17:19
---
Older versions show the information too:
$ echo | gcc -v -x c -c - 21 | fgrep -B1 GMP
GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.3, MPFR version 2.3.1.
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-06-15 17:20 ---
Has been true since:
r124822 | ghazi | 2007-05-17 19:04:02 -0700 (Thu, 17 May 2007) | 3 lines
* toplev.c (print_version): Output GMP/MPFR version info.
--
Dear GUN team,
I came across the following error when I try to compile gcc4.04:
/usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 17:57 ---
You need to install the 32bit userland.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Dear GUN team,
I came across the following error when I try to compile gcc4.04:
/usr/bin/ld: skipping incompatible /usr/lib64//libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64//libc.a when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib64/libc.so when
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 ---
*** This bug has been marked as a duplicate of 40448 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-15 18:00 ---
*** Bug 40449 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40448
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:17
---
Without any more information, there's nothing we can do. I tried to reproduce
with a simple testcase, but I can't.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #3 from ksong at lbl dot gov 2009-06-15 18:21 ---
(In reply to comment #1)
You need to install the 32bit userland.
Thanks for your response. I am not familiar with 32 bit userland. Can you give
me more instructions, or links that I can learn more about it?
Thanks.
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:32
---
This is not darwin-specific, I also see it happening on x86_64-linux.
And what's more, the output changes between -m32 and -m64.
$ cat u.f90
integer(8), parameter :: l = z'5fe6eb3be000'
integer, parameter
The following program gives a segfault at runtime:
MODULE m
ABSTRACT INTERFACE
SUBROUTINE sub()
END SUBROUTINE sub
END INTERFACE
CONTAINS
SUBROUTINE passf(f)
PROCEDURE(sub), POINTER:: f
CALL callf(f)
END SUBROUTINE passf
SUBROUTINE callf(f)
PROCEDURE(sub), POINTER :: f
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-15 18:44 ---
(In reply to comment #3)
This is not darwin-specific, I also see it happening on x86_64-linux.
And what's more, the output changes between -m32 and -m64.
The code is invalid Fortran, so gfortran is not required
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:45
---
I'm not sure it's still present: if I look into the 10.3.9 and the 10.4u
headers, I see:
#ifdef __cplusplus
Class super_class;
#else
Class class;
#endif
The 10.5 header is very different, but
--- Comment #3 from gni at gecko dot de 2009-06-15 19:36 ---
Subject: gcc 4.4.0 error at postreload.c:396
(In reply to comment #2)
Could be a duplicate of one of PR30064, PR34439, PR37053.
I compiled the provided testcases as stated in the appropriate PR
with the following result:
--- Comment #102 from lucier at math dot purdue dot edu 2009-06-15 19:57
---
Subject: Re: [4.3/4.4/4.5 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Mon, 2009-06-15 at 16:20 +, paolo dot bonzini at gmail dot com
wrote:
Yes, and the output of
--- Comment #103 from lucier at math dot purdue dot edu 2009-06-15 20:21
---
Regarding comment #101 ...
With
heine:~/programs/gcc/objdirs/gsc-fft-tests/gambc-v4_1_2
/pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with:
--- Comment #3 from geir at cray dot com 2009-06-15 20:47 ---
For another point of reference, I see this problem in our GCC 4.3.1 build; but
the problem did not occur in our gcc 4.3.0 and 4.3.2 versions. I assume this
was an error on our part.
$ diff
The following program is rejected with:
f = sin
1
Error: Interfaces don't match in procedure pointer assignment at (1)
However, if one removes the module m; contains it is accepted
module m
contains
function f()
intrinsic :: sin
procedure(sin), pointer :: f
f = sin
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-15 21:10 ---
Post script: With your current patch, the error message is:
Error: Interface mismatch in procedure pointer assignment at (1): 'sin' has the
wrong number of arguments
--
Follow up to PR 37746 / PR 40383. I believe the following program is valid due
to the storage association/argument association. However, with -fcheck=bounds
one gets:
At line 5 of file aa.f90
Fortran runtime error: Actual string length is shorter than the declared one
for dummy argument 'a' (2/4)
--- Comment #18 from mrsam at courier-mta dot com 2009-06-15 21:53 ---
Yes, the patch does add a new data member to the class. I see that this would
fall under item #8 under prohibited changes, although, as I said, AFAIK it
won't actually break binary compatibility with existing
--- Comment #19 from paolo dot carlini at oracle dot com 2009-06-15 22:06
---
I think we are definitely going to wait for the next ABI, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #20 from paolo dot carlini at oracle dot com 2009-06-15 22:18
---
One last clarification, maybe necessary because not spelled out (yet) in the
docs: really, when we say *ABI* we mean it in a very wide sense, also including
linking together objects built with different
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-15 22:40 ---
Also for OPTIONAL a suitable error message would be useful. For finding a
specific interface, the OPTIONAL attribute could be ignored similarly to
INTENT; however, one needs to be careful as for ambiguity checks and
Follow up to PR 36947/PR 40039. I think there was no PR yet, if not - mark as
duplicate. See also PR 40276.
I think some other checks should still be added, e.g.
a) PUREness check (see example below); passing/assigning
a pure to a non-pure dummy/proc-pointer is OK; doing vice versa
is
--- Comment #14 from dje at gcc dot gnu dot org 2009-06-15 23:06 ---
This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE
finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the
REG_NOTE on the move itself share RTL.
I suspect we need to
--- Comment #21 from peturrun at gmail dot com 2009-06-15 23:10 ---
Isn't it possible to add more data to messages without breaking the ABI by
changing the type of one of the existing members?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
--- Comment #22 from paolo dot carlini at oracle dot com 2009-06-15 23:14
---
A patch would help understanding what you exactly mean, at the moment, I'm
skeptical.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
Hi,
I notice that PNGCrush compiled with GCC 4.4.0 (release) is about 20% slower
compared to GCC 3.4.0 build. (Amiga 68...@50mhz).
CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s
PNGCrush test.png out.png
Here are the results:
GCC 3.4.0 build:
CPU time used = 267.340
--- Comment #4 from hp at gcc dot gnu dot org 2009-06-16 02:28 ---
Mee too! I mean, seen for cris-elf too!
BTW, isn't it odd that for recent regressions, the committer's testing never
seem to have shown the regressions seen by every other target after commit?
1/2 ;)
(Definitely _not_
--- Comment #5 from hp at gcc dot gnu dot org 2009-06-16 02:36 ---
To add something useful, I should have mentioned that they were ok for 148440,
regressed for 148444 for cris-elf, so that leaves only commit's from Aldy and
Steven B., IIUC.
--
--- Comment #23 from mrsam at courier-mta dot com 2009-06-16 03:51 ---
Created an attachment (id=18004)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18004action=view)
Revised patch
Well, this is approximately what I have in mind. Aside from the formatting
style, which I can clean
--- Comment #13 from cnstar9988 at gmail dot com 2009-06-16 03:54 ---
ping 4.3.4...
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
CC|
--- Comment #14 from cnstar9988 at gmail dot com 2009-06-16 03:56 ---
ping 4.3.4...
The PR40087 fix depends on changes from the this fix, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39455
--- Comment #6 from hjl dot tools at gmail dot com 2009-06-16 04:30 ---
All regressions are caused by revision 148442, including
gcc.dg/func-ptr-conv-1.c. You may need to enable checking
to see it.
--
hjl dot tools at gmail dot com changed:
What|Removed
As of commit r148408, http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00388.html, gcc
trunk does not bootstrap on cygwin using configure like this:
../gcc/configure --enable-threads=posix --enable-libgcj
--disable-sjlj-exceptions --with-system-zlib --enable-nls --enable-static
--enable-shared
90 matches
Mail list logo
