Ian Lance Taylor wrote:
Consider code along these lines:
struct s { int len; char* p; };
inline char
bar (struct s *sp, int n)
{
if (n 0)
abort ();
if (n sp-len)
abort ();
return sp-p[n];
}
void
foo (struct s *sp, int n)
{
int len = sp-len;
int i;
int
I'm not at all impressed with the recent series of flex releases, since it
started using m4 internally and passing user code through m4.
(cf. bison, which unlike
flex pays proper attention to assuring that arbitrary valid parsers are
not mangled by m4).
Fully agreed. The recent releases
Dear GCC Developers,
I am working on a target backend for the DLX architecture and I have a
question concerning the layout of the stack frame.
Here is a simple test C-program:
---snip---
int main(void)
{
int a = 1;
int b = 2;
int c = a + b;
return c;
}
---snap---
Markus Franke wrote:
Please let me know whether I missunderstood something completely. If
this behaviour is correct what can I do to change it to the other way
around. Which macro variable do I have to change?
There is no legitimate reason to care about the order of variables
in the local
Hi,
In the old references there is a function build that is used for
building tree nodes. Using this function one can build a conditional
expression as follows:
build(EQ_EXPR, integet_type_node, left, rith);
which is left == right
But, as I noticed this function build is not maintained (used)
Robert Dewar writes:
Markus Franke wrote:
Please let me know whether I missunderstood something completely. If
this behaviour is correct what can I do to change it to the other way
around. Which macro variable do I have to change?
There is no legitimate reason to care about the
On 1/23/07, Ferad Zyulkyarov [EMAIL PROTECTED] wrote:
But, as I noticed this function build is not maintained (used) by
gcc any more. Instead build, what else may I use to create a
conditional expression node?
Look for buildN where N is a small integer ;-)
I think you want build2 for EQ_EXPR.
Well, you are right. The code looks good and works also. But I have some
kind of a reference implementation which is based on GCC 2.7.2.3. In
this version the local variables are allocated the other way around, the
way in which I expected. Obviously, the order of allocation has changed
till now
This is a typical example of removing an if branch because signed
overflow is undefined. This kind of code is common enough.
I could not have made my point any better myself.
And you think that somehow defining it (which the definition people
seem to favor would be to make it wrapping)
Daniel Berlin wrote:
And you think that somehow defining it (which the definition people
seem to favor would be to make it wrapping) ameliorates any of these
concerns?
Yes, absolutely. There is a difference between well-defined and
understood semantics on one hand, and undefined and probably
Andreas Bogk [EMAIL PROTECTED] writes:
Making it defined and wrapping doesn't help at all. It just means you
write different checks, not less of them.
You have just seen somebody who can be considered an expert in matters
of writing C sofware come up with a check that looks correct, but
Mike Stump wrote:
On Jan 11, 2007, at 10:47 PM, Joe Buck wrote:
The description of WORKSFORME sounds closest: we don't know how to
reproduce the bug. Should that be used?
No, not generally.
Of the states we have, WORKSFORME seems best to me, and I agree with Joe
that there's benefit in
* Joe Buck:
You appear to mistakenly believe that wrapping around on overflow is
a more secure option. It might be, but it usually is not. There
are many CERT security flaws involving integer overflow; the fact
that they are security bugs has nothing to do with the way gcc
generates code,
Hi,
Please consider following testcase which is a core of PR c++/28236.
typedef enum { X, Y } E;
int f( E e )
{
switch ( e )
{
case X: return -1;
case Y: return +1;
}
}
In this example g++ produces a warning:
e.cpp: In function ‘int
Ian Lance Taylor wrote:
Andreas Bogk [EMAIL PROTECTED] writes:
I think a better way to describe your argument is that the compiler
can remove a redundant test which would otherwise be part of a defense
in depth. That is true. The thing is, most people want the compiler
to remove redundant
A summary of what has been proposed so far to clean up Wextra follows.
Please, your feedback is appreciated. And reviewing patches even more
;-)
* Subscripting an array which has been declared register.
* Taking the address of a variable which has been declared register.
Proposed: new option
On 1/23/07, Paweł Sikora [EMAIL PROTECTED] wrote:
typedef enum { X, Y } E;
int f( E e )
{
switch ( e )
{
case X: return -1;
case Y: return +1;
}
+ throw runtime_error(invalid value got shoehorned into E enum)
}
In this example
On Tue, Jan 23, 2007 at 07:52:30PM +, Manuel López-Ibáñez wrote:
* A base class is not initialized in a derived class' copy constructor.
Proposed: move this warning to -Wuninitialized seems the appropriate
solution. However, I am afraid that this warning will turn out to be
too noisy and
Ferad == Ferad Zyulkyarov [EMAIL PROTECTED] writes:
Ferad build(EQ_EXPR, integet_type_node, left, rith);
Ferad which is left == right
Ferad But, as I noticed this function build is not maintained (used) by
Ferad gcc any more. Instead build, what else may I use to create a
Ferad conditional
Hi,
I've noticed that you've asked a few questions about trees on the
list. You might want to read a tutorial on trees in GCC; there are a
few kicking around out there.
Sure I would like to look at any tutorial. I found some, but most of
them were not complete :( I would appreciate if you
On 23/01/07, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, Jan 23, 2007 at 07:52:30PM +, Manuel López-Ibáñez wrote:
* A base class is not initialized in a derived class' copy constructor.
Proposed: move this warning to -Wuninitialized seems the appropriate
solution. However, I am afraid that
Vaclav Haisman wrote:
Gerald Pfeifer wrote:
[...]
openSUSE 10.2 now comes with flex 2.5.33, but FreeBSD, for example, still
is at flex 2.5.4. Just some additional data pointes...
FreeBSD has version 2.5.33 as textproc/flex port.
But that will not replace the system flex, so it will
Ian Lance Taylor wrote:
You have just seen somebody who can be considered an expert in
matters of writing C sofware come up with a check that looks
correct, but is broken under current gcc semantics. That should
make you think.
I'm not entirely unsympathetic to your arguments, but,
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
For 4.3 we have already added quite a bit of infrastructure that is all
good in paper but still needs some amount of TLC.
There was
On 1/23/07, Diego Novillo [EMAIL PROTECTED] wrote:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
Heh.
Maybe part of the problem here is that the release manager isn't very
actively
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already
crossed the 1 year barrier.
For 4.3 we have already added quite a bit of
On Wed, Jan 24, 2007 at 12:55:29AM +0100, Steven Bosscher wrote:
On 1/23/07, Diego Novillo [EMAIL PROTECTED] wrote:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
Heh.
Maybe
Yes, absolutely. There is a difference between well-defined and
understood semantics on one hand, and undefined and probably dangerous
behaviour on the other hand. It's the difference between security
audits of C software being hard and completely hopeless.
I disagree. Code written with
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
For 4.3 we have already added quite a
Wiadomość napisana w dniu 2007-01-24, o godz01:48, przez David Daney:
I missed the discussion on IRC, but neither of those front-ends are
release blockers.
I cannot speak for ADA, but I am not aware that the Java front-end
has caused any release delays recently. I am sure you will
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo [EMAIL PROTECTED] said:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but here are some thoughts:
As far as I can tell, it looks to
Oh, and teaching all of the programmers out there all the subtle nuances
of C and trying to get them to write proper code: good luck. That
simply won't happen.
If people who write security-critical code in a programming language
can't take time to learn the details of that language relevant
Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
For 4, you should probably spend some time figuring out why bugs are
being introduced into the code in the first place. Is test coverage
not good enough?
It's too good to be usable. The time required for a full test
Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
For 4, you should probably spend some time figuring out why bugs are
being introduced into the code in the first place. Is test coverage
not good enough?
The test coverage is not good for C++ while it is great
Hi,
I am working on gcc 4.0.0. I want to use gcc to intercept each call to
read, and taint the data readed in. For example:
transform
read(fd, buf, size)
to
read(fd, buf, size)
if(is_socket(fd))
taint(buf, size)
So, what is the best suitable level to do
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo [EMAIL PROTECTED] said:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but here are some thoughts:
As far as I can tell,
I know valgrind, it is an emulator ,but we are restricted not to use
an emulator. :-(
2007/1/24, Nicholas Nethercote [EMAIL PROTECTED]:
On Wed, 24 Jan 2007, [GB2312] ÎâêØ wrote:
I am working on gcc 4.0.0. I want to use gcc to intercept each call to
read, and taint the data readed in. For
On Wed, 24 Jan 2007, [GB2312] ÎâêØ wrote:
I know valgrind, it is an emulator ,but we are restricted not to use
an emulator. :-(
Well, for some definition of emulator.
Nick
GCC should treat plain char in the same fashion on all types of machines
(by default).
The ISO C standard leaves it up to the implementation whether a char
declared plain char is signed or not. This in effect creates two
alternative dialects of C.
The GNU C compiler supports both dialects; you
On Tue, 2007-01-23 at 23:19 -0600, [EMAIL PROTECTED] wrote:
GCC should treat plain char in the same fashion on all types of machines
(by default).
No, no, no. It is up to the ABI what char is.
The ISO C standard leaves it up to the implementation whether a char
declared plain char is signed
Anyway, the program is supervised...would you mind giving some advices
with the compiler-based approach, after recompilation, I could finish
this modification.
2007/1/24, Nicholas Nethercote [EMAIL PROTECTED]:
On Wed, 24 Jan 2007, [GB2312] ÎâêØ wrote:
I know valgrind, it is an emulator ,but
Marcin Dalecki wrote:
A trivial by nature change like the
top level build of libgcc took actually years to come by.
I'm not sure how much that's inherently evidence that it was
inappropriately difficult to do, though.
For example, the quite trivial change of having make pdf support for
I am working on gcc 4.0.0. I want to use gcc to intercept each call to
read, and taint the data readed in. For example:
transform
read(fd, buf, size)
to
read(fd, buf, size)
if(is_socket(fd))
taint(buf, size)
So, what is the best suitable level to do this
Wiadomość napisana w dniu 2007-01-24, o godz04:32, przez Andrew Pinski:
It's too good to be usable. The time required for a full test suite
run can be measured by days not hours.
Days, only for slow machines. For our PS3 toolchain (which is really
two sperate compilers), it takes 6 hours
Richard Kenner wrote:
Oh, and teaching all of the programmers out there all the subtle nuances
of C and trying to get them to write proper code: good luck. That
simply won't happen.
If people who write security-critical code in a programming language
can't take time to learn the details of
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 08:09
---
can't open .class, even though it exists: Too many open files
Add:
perror (can't open .class, even though it exists);
after the call to JCF_OPEN_EXACT_CASE in find_class and you get the error.
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-01-23 08:23
---
The temp zip file was being stayed opened even though it was empty. This
caused us to open too many files.
Anyways, I have a fix now:
Index: ../../gcc/java/jcf-io.c
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-01-23 08:28
---
Here is a better patch (with correct formating):
Index: ../../gcc/java/jcf-io.c
===
--- ../../gcc/java/jcf-io.c (revision 121050)
+++
--- Comment #2 from georg dot viehoever at web dot de 2007-01-23 08:30
---
Wow, that was fast.
You probably mean -fno-math-errno, or -ffast-math, which implies this. I have
verified the effect, and it works.
Thanks,
Georg
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30545
--- Comment #15 from andreast at gcc dot gnu dot org 2007-01-23 08:44
---
Hah, that's why it builds here:
Darwin wolfram.local 8.8.0 Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT
2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Power Macintosh powerpc
[wolfram:head/gcc/boehm-gc]
--- Comment #15 from Bil dot Kleb at NASA dot gov 2007-01-23 08:44 ---
I tried out the one dated 23-jan-07, but it was apparently also configured with
checks:
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --disable-checking to disable checks.
--
--- Comment #9 from patchapp at dberlin dot org 2007-01-23 08:50 ---
Subject: Bug number PR c++/17729
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-01/msg01869.html
--
Hi,
I'm not sure where to post my problem. sorry if there is a more adapted
mailing list.
After loged in with my Bugzilla account, I'm trying to add a new
Additional Comment to the bug #29845. I didn't modify any of the other
fields. I keep getting the following error message:
-
Not
gfortran -c test.f90
test.f90:8: internal compiler error: Segmentation fault
Backtrace:
0x0043c85e in mio_pointer_ref (gp=0x28) at module.c:1945
1945 p = get_pointer (*((char **) gp));
#1 0x0043ccb7 in mio_symbol_ref (symp=0x28) at module.c:2174
#2 0x0043cd39
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-23 10:34 ---
Based on the bugreport by Ignacio Fernández Galván
http://gcc.gnu.org/ml/fortran/2007-01/msg00531.html
The test case has been extracted from the Dynamo package,
http://www.pdynamo.org/Installation.html
--
On systems where possible, GCC should get knowledge about the errno location so
it can clobber the right memory location for calls only setting errno.
On glibc the errno location is obtained using a call to the __errno_location ()
library function, so the obvious thing would be to introduce
Attention: gcc-bugs@gcc.gnu.org, an email message detected as spam was sent by
you.
This notification is sent to you due to policies set by the system
administrator.
The entire message may not have reached its destination.
The spam message was reported to be: Likely spam message
Please contact
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-01-23 13:13 ---
Well, the obvious patch for the mainline is not working -- it looks like
GNATBIND is no longer fixed to use the staged ones:
/abuild/rguenther/obj/./prev-gcc/xgcc -B/abuild/rguenther/obj/./prev-gcc/
--- Comment #9 from bonzini at gnu dot org 2007-01-23 13:17 ---
Can you attach a working patch for 4.1 (for all three of GNATBIND, GNATLINK,
GNATMAKE; I prefer to err on the safe side)? Then of course we'll update it
and apply it to 4.3 first, but at least I can understand better what
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-23 13:26
---
matmul also has this problem:
$ cat a.f90
integer(kind=1) :: x(2,2), y(2,2), i
integer :: z(2,2)
print *, matmul(x,y)
!pack
!unpack
print *, maxval(x,dim=2), minval(x,dim=2)
print *, (1.2,0.2)**i
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from mueller at gcc dot gnu dot org 2007-01-23 13:33 ---
ah, no, this doesn't seem to be the same thing.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-23 13:52
---
Created an attachment (id=12937)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12937action=view)
patch for the mainline
This is a working patch for the mainline - GNATLINK is omitted. Note that the
only
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 13:57 ---
I don't get this. The enum value can be any integer apart from foo and bar.
Moreover, since it is undefined, it can be literally anything! So you need a
default: case to handle that.
In the first testcase, without a
--- Comment #4 from hjl at lucon dot org 2007-01-23 14:00 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01654.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #5 from hjl at lucon dot org 2007-01-23 14:03 ---
An updated patch is at
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01882.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #11 from bonzini at gnu dot org 2007-01-23 14:09 ---
You're right. gnattools is only built at the end of the bootstrap.
I'd prefer a slightly more conservative patch; I don't want to fix things later
if we know that the tools are needed somewhen during the build.
So,
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-23 14:13 ---
Could you provide a smaller testcase?
--
manu 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
As seen from the following log (building stage3)
/abuild/rguenther/obj/./prev-gcc/xgcc -B/abuild/rguenther/obj/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -gnatpg -gnata -g -O0
\
-I- -I. -Iada -I/space/rguenther/src/svn/trunk/gcc/ada
--- Comment #1 from bonzini at gnu dot org 2007-01-23 14:23 ---
Is this really a bug, or just an enhancement?
As far as I know, it's been like this forever (even when you used to make
gnat_lib_and_tools after make bootstrap).
--
bonzini at gnu dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-01-23 14:26 ---
It's an enhancement. Currently we do not use the finally built gnatmake, so
we'd
increase coverage if we'd do. (I just wanted to record this in a different
bug)
--
rguenth at gcc dot gnu dot org changed:
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 14:28 ---
What about a warning about __builtin_stdarg_start being deprecated? That will
be clearer than the current warning, and we can still keep backwards
compatibility (the user may use -Wno-deprecated to work-around the
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-23 14:35 ---
We already have a warning about discarding qualifiers somewhere. Perhaps we
could just add this to that one (saving us from yet another warning option).
--
manu at gcc dot gnu dot org changed:
What
--- Comment #12 from charlet at adacore dot com 2007-01-23 14:47 ---
Subject: Re: Top-level should pass GNATBIND, GNATLINK and GNATMAKE variables
down
GNATBIND = $(STAGE_PREFIX)gnatbind
GNATMAKE = gnatmake
GNATLINK = gnatlink
in both Make-lang.in and Makefile.in. (sidenote:
--- Comment #7 from igodard at pacbell dot net 2007-01-23 14:54 ---
My goof - sorry to trouble you
--
igodard at pacbell dot net changed:
What|Removed |Added
--- Comment #13 from paolo dot bonzini at lu dot unisi dot ch 2007-01-23
14:55 ---
Subject: Re: Top-level should pass GNATBIND, GNATLINK
and GNATMAKE variables down
True, they seem to be unused, but it's better to be consistent; for the same
reason I prefer to pass GNATLINK down
--- Comment #6 from pluto at agmk dot net 2007-01-23 15:02 ---
(In reply to comment #5)
I don't get this. The enum value can be any integer apart from foo and bar.
3.9.1/7, subnote. 43) says that enum isn't an integral type
but can be promoted to {signed/unsigned} int/long.
an
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-01-23 15:16
---
Confirmed. It's worth noting that the doc says the right thing:
Arguments:
PID Shall be a scalar INTEGER, with INTENT(IN)
SIGNAL Shall be a scalar INTEGER, with INTENT(IN)
STATUS (Optional) status flag
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-01-23 15:23
---
Well, I can confirm that one the reporter's code, on my i686-linux (Intel(R)
Pentium(R) III CPU family 1266MHz), whatever optimisation flags I give to
gfortran-4.3, g77-3.4.6 -O does a better job.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-01-23 15:32 ---
These issues have already been fixed as I can bootstrap now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from charlet at gcc dot gnu dot org 2007-01-23 15:44 ---
xnmake is an internal support tool used to automatically generate a file,
and gnattools should indeed only be built after a full bootstrap of the
compiler.
As for more coverage of gnatmake, this usage of gnatmake
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47 ---
which revision is that? -r121081 fails here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47
---
which revision is that? -r121081 fails here
revision 121050, and 121076.
-- Pinski
--- Comment #8 from pinskia at physics dot uc dot edu 2007-01-23 15:50
---
Subject: Re: [4.3 Regression] Gcc failed to bootstrap
--- Comment #7 from mueller at gcc dot gnu dot org 2007-01-23 15:47
---
which revision is that? -r121081 fails here
revision 121050,
--- Comment #7 from manu at gcc dot gnu dot org 2007-01-23 15:55 ---
(In reply to comment #6)
an assignment of int to enum produces an error,
so how ( in defined non-hax0r way ) enum can be any integer?
if it can be, then what's difference between enum and int?
Undefined behaviour
--- Comment #8 from manu at gcc dot gnu dot org 2007-01-23 15:57 ---
(In reply to comment #7)
* PR 12242
* PR 27975
* PR 12242
This should have been:
* PR 12242
* PR 27975
* PR 30357
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
The following small program gives an segmentation fault when compiled like
this:
extgccsrc g++ -Wall -fopenmp -O2 -I$POLDEST/ext/include -L$POLDEST/ext/lib
-otest test.cc -lblitz -lgomp -lm
test2.cc: In function int main():
test2.cc:7: internal compiler error: Segmentation fault
When removing
--- Comment #9 from hjl at lucon dot org 2007-01-23 16:00 ---
-r121081 fails here too.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from bonzini at gnu dot org 2007-01-23 16:02 ---
Is the file placed in srcdir? If not, it's *right* to generate the file on
every stage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30556
--- Comment #10 from hjl at lucon dot org 2007-01-23 16:02 ---
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01882.html
works for me with revision 121081.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-01-23 16:04
---
For one your resolve.c patch is incorrect, see PR 30549.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-01-23 16:06
---
Two, I don't see any warning from cp/parser.c at all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from charlet at gcc dot gnu dot org 2007-01-23 16:10 ---
Is the file placed in srcdir? If not, it's *right* to generate the file on
every stage.
Fair enough. Then there's nothing to fix or improve here.
Arno
--
charlet at gcc dot gnu dot org changed:
I just tried to compile Suse Linux package libnasl-2.2.6-40
with the new GNU C compiler version 4.3 snapshot 20070119.
I used compiler flag -O3. The compiler appeared to hang
for more than 30 minutes when compiling source code file regex.c.
I tried compiling the same file with the same compiler
--- Comment #1 from dcb314 at hotmail dot com 2007-01-23 16:13 ---
Created an attachment (id=12938)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12938action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-01-23 16:25 ---
This should be fixed with
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01728.html I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30559
--- Comment #5 from mueller at gcc dot gnu dot org 2007-01-23 16:26 ---
fortran seems to bootstrap now.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-23 16:27 ---
Can you attach the preprocessed source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30558
1 - 100 of 185 matches
Mail list logo
