Ian Lance Taylor wrote:
Sounds like a bug.
May I code a patch on this?
Yes, please.
One way to fix this would be to convert those directories to use
automake, but it would be fine to just add config.cache to the list in
the distclean targets in {intl,fixincludes}/Makefile.in.
Ian
1. Introduce a new BB bit flag and set it for the header BB of a loop that
has no data dependencies. This approach already works, but only if the old
loop optimizer (pass_loop_optimize) is disabled (otherwise the bit doesn't
survive).
Which will happen in 4.2.
One potential problem is that
David Daney writes:
Tom Tromey wrote:
I'm finally ready to do another classpath import,
Do you plan on another classpath import before the 4.1 release?
This is an interesting question. Potentially, a classpath import can
have a hugely destabilizing effect. However, IMO each Classpath
Hello,
As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html
I would like to improve SMS by passing data dependencies information
computed in tree-level to rtl-level SMS. Currently data-dependency graph
built for use by SMS has an edge for every two data references (i.e. it's
Original Message
From: Tom Tromey
Sent: 21 September 2005 20:31
I'm finally ready to do another classpath import, and near the last
minute I realized that the import may temporarily break the build, due
to an unfortunate interaction between the classpath Makefile and the
way cvs
Hi,
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include math.h
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
The begining of the .s file is
rad2deg:
addisp, sp, -16
stw fp, 8(sp)
mov
Hi all,
first of all, sorry for possible double post, I just didn't get any
answers from gcc-help-mailing list.
I'm trying to compile OpenSSH 0.9.8 with gcc 3.4.3 (64-bit) on a HP-UX.11i
and collect2 utility is doing something odd (as far as I can tell). It is
linking libgcc twice (I guess
Hello [EMAIL PROTECTED]
sgserv# srcdir/config.guess
i386-unknown-freebsd5.3
sgserv# /usr/local/bin/gcc -v
Using built-in specs.
Target: i386-unknown-freebsd5.3
Configured with: ../srcdir/configure --with-arch=athlon-4 --with-tune=athlon-4
Thread model: posix
gcc version 4.0.1
The following
The builtins table is initialized with a separate .def file, but it
boils down to initializers this:
{ code, __builtin_name, C2_INT,
{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
This way I only have to write the type in one place, I only create the
function types I
Thanks for the reply, but I did not get the answer to my question.
My question is:
In the below mentioned program
#include stdio.h
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(enum aa),sizeof(b),sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
Dave == Dave Korn [EMAIL PROTECTED] writes:
I'm finally ready to do another classpath import, and near the last
minute I realized that the import may temporarily break the build, due
to an unfortunate interaction between the classpath Makefile and the
way cvs import works. FWIW I'd prefer
Original Message
From: [EMAIL PROTECTED]
Sent: 22 September 2005 15:25
Dave == Dave Korn [EMAIL PROTECTED] writes:
I'm finally ready to do another classpath import, and near the last
minute I realized that the import may temporarily break the build, due
to an unfortunate interaction
David == David Daney [EMAIL PROTECTED] writes:
I'm finally ready to do another classpath import,
David Do you plan on another classpath import before the 4.1 release?
I think it depends a lot on timing; the sooner 4.1 ships the less
inclined I would be to do another import. I want to see 4.1
Daniel Berlin [EMAIL PROTECTED] writes:
The builtins table is initialized with a separate .def file, but it
boils down to initializers this:
{ code, __builtin_name, C2_INT,
{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
This way I only have to write the type in
Gaurav Gautam, Noida wrote:-
#include stdio.h
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(enum aa),sizeof(b),sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
)
The output is
size = 1 1 1
value= 0 127 128
when gcc (GCC)
Hi Gaurav,
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are correct.
(Neither output is compliant to the standard, of course, as -fshort-enums is
a deviation from the standard.)
Sincerely,
--Eljay
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Thu, Sep 22, 2005 at 10:34:19AM -0500, John Love-Jensen wrote:
Hi Gaurav,
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are correct.
(Neither output is compliant to the standard, of course, as
Original Message
From: John Love-Jensen
Sent: 22 September 2005 16:34
Hi Gaurav,
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are correct.
No, the standard is entirely unambiguous:
John Love-Jensen [EMAIL PROTECTED] writes:
| Hi Gaurav,
|
| Please confirm which of the two outputs is correct and why is there a
| difference in the output of two versions of compiler?
|
| Both outputs are correct.
|
| (Neither output is compliant to the standard, of course, as -fshort-enums
Hi Dave, Daniel, and Gaurav,
For C99, I stand corrected.
For C89 or C++98, I think my statement is applicable. (But until I
double-check by reading those standards, take that with a grain of salt.)
For all three, having enum be an int (signed or unsigned) is legit of
course.
For all three,
Hi Gaby, Dave, Daniel, and Gaurav,
This is incorrect and misleading.
I concur. I retract my previous statement, and direct
seekers-of-clarification to the previous posts that answered this issue. My
apologies for my confusion.
Sincerely,
--Eljay
John Love-Jensen [EMAIL PROTECTED] writes:
| Hi Dave, Daniel, and Gaurav,
|
| For C99, I stand corrected.
|
| For C89 or C++98, I think my statement is applicable.
No, for C++98 your statement is even more incorrect because
enumerators (the constants) are NOT of type int -- and that has been
Dave Korn wrote:
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are correct.
No, the standard is entirely unambiguous:
of course, but the behavior of a compiler with a special implementation
Mark Mitchell wrote:
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
From an RTEMS perspective, 4.0.2RC2 with no patches appeared to
be at least as good as 4.0.1 w/RTEMS patches. I spotted no
new issues. I built a native C, C++, and Ada
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave What version of CVS are you using, and does it speak the -X
Dave option (new in 1.12.x)?
Thanks! I didn't know that this was added; this addresses one of the
biggest problems I've had with cvs import over the years. I'll try
this out.
Tom
Gerald == Gerald Pfeifer [EMAIL PROTECTED] writes:
Gerald On Thu, 22 Sep 2005, Tom Tromey wrote:
I think it depends a lot on timing; the sooner 4.1 ships the less
inclined I would be to do another import. I want to see 4.1 ship with
a reasonably up-to-date class library, though; for one
The GCC 4.0.2 RC3 prerelease is spinning now.
Regressions on Solaris 2.6, 7, 8 and 9:
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL:
On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
of course, but the behavior of a compiler with a special implementation
dependent switch is not specified by the standard! Switches can do any
amount of violence to the standard you like, the only requirement is
that there be a
Hi Jan,
I think fixup_reorder_chain contains questionable code to cope with a
pathological case:
/* The degenerated case of conditional jump jumping to the next
instruction can happen on target having jumps with side
effects.
On Thursday 22 September 2005 19:31, Daniel Jacobowitz wrote:
On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
of course, but the behavior of a compiler with a special implementation
dependent switch is not specified by the standard! Switches can do any
amount of violence to
On 9/22/05, Mark Mitchell [EMAIL PROTECTED] wrote:
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
whoa, I get a few regressions here, compare this with
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html ...
LAST_UPDATED: Thu Sep 22
FYI:
On the web page:
http://gcc.gnu.org/mirrors.html
the link:
http://strawberry.resnet.mtu.edu/pub/gcc/
fails: The requested URL /pub/gcc/ was not found on this server
-- George Young
--
Are the gods not just? Oh no, child.
What would become of us if they were? (CSL)
Liu Haibin [EMAIL PROTECTED] writes:
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include math.h
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
The begining of the .s file is
rad2deg:
addisp,
In a given test case with 128 bit mmx intrinsics, routine
make_compound_operation (in combine.c) attempts to do a sign-extract
of the middle 64bit of the 128 bit (TImode) register. Pattern we have
is:
(lshiftrt:TI (ashift:TI (subreg:TI (reg/v:V2DI 75
[ vu16YPrediction3 ]) 0) (const_int
On Sep 22, 2005, at 4:21 PM, Fariborz Jahanian wrote:
Following patch avoids this problem. If this is OK, I will submit a
patch when fsf mainline is unfrozen.
The FSF mainline is not frozen, only the 4.0 release branch.
Thanks,
Andrew Pinski
On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote:
Telling users to supply that flag is useless. It is the default.
It's advertised as the default, but the threads I cited in my last
post suggest
The only time that it would matter is when the command line has on it a
Snapshot gcc-4.0-20050922 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050922/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050922
You'll find
Paul Eggert [EMAIL PROTECTED] writes:
Thanks, everybody, for writing about this.
The standardization process is one of consensus, and if the GCC
developers find some areas of disagreement here I think it unlikely
that the other POSIX implementers will agree with the proposed action.
Hence
Mike Stump wrote:
On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote:
Telling users to supply that flag is useless. It is the default.
It's advertised as the default, but the threads I cited in my last post
suggest
The only time that it would matter is when the
Ian Lance Taylor wrote:
Jonathan Turkanis writes:
I'm getting tired of this. You assumed I'm must have meant something
else than what I plainly asked; once I mentioned that I was writing a
book, you realized I really meant what I said.
That's pretty much it, yes.
Many years of experience
On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
Looking into it further, I've found:
From Bugzilla Bug 23628:
--- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
[reply]
Sorry, I was a bit sloppy--I didn't remove all intermediate layers
from my test
The POSIXy way to do that would be to refer to the LC_CHARSET
environment variable, but then consider
LC_CHARSET=UTF-16 c99 foo.c
where 'foo.c' is in UTF-16 and contains '#include stdio.h',
Not really a problem for a number of reasons. First, it's LC_CTYPE
you're thinking of. Second, the
On 9/22/05, Jonathan Turkanis [EMAIL PROTECTED] wrote:
M-x grep VISIBILITY tells you the answer.
What are you grepping?
Why, the source code to gcc of course.
Let's go back a bit:
Mike Stump wrote:
Jonathan Turkanis wrote:
So it seems a fair question to ask where
Hank Kester wrote:
On 9/22/05, Jonathan Turkanis wrote:
M-x grep VISIBILITY tells you the answer.
What are you grepping?
Why, the source code to gcc of course.
Let's go back a bit:
Mike Stump wrote:
If the implication is that users should grep the source code before asking
Mike Stump wrote:
On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
Looking into it further, I've found:
From Bugzilla Bug 23628:
--- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
[reply]
Sorry, I was a bit sloppy--I didn't remove all intermediate
On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote:
On Sep 22, 2005 11:25 AM, Zdenek Dvorak
[EMAIL PROTECTED] wrote:
4. Other ideas?
Preserving the information about loops throughout the
optimizations, and
just keeping this information attached at the loop description
would by
far
Mike Stump [EMAIL PROTECTED] writes:
| On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
| Looking into it further, I've found:
|
| From Bugzilla Bug 23628:
| --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
| [reply]
| Sorry, I was a bit sloppy--I
I will pull a patch together tomorrow. There is currently nothing in
the code for keeping the region stuff up to date as changes are made to
the cfg. For most changes this would not be hard, but for some it is
really hard.
Daniel Berlin wrote:
On Thu, 2005-09-22 at 18:49 -0700, Devang
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22
07:00 ---
I don't know the tree-cfg bits very well, but the patch seems wrong; you are not
committing the edge insertion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
The following testcase should issue an error in strict F95 mode:
REAL FUNCTION funct()
funct = 0.0
RETURN
!
ENTRY enter RESULT (answer)
answer = 1.0
RETURN
END FUNCTION funct
The f95 standard forbids
ENTRY enter RESULT (answer)
because Section 12.5.2.5 syntax rule R1225 says
ENTRY
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-09-22
07:09 ---
I have a patch but it only works in the -fno-trapping-math case. Given that
trapping math is much more complex, that the code quality improves for
-ftrapping-math, and that we are late in the development
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:16
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:16
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:27
---
Hey Paolo. I consider this fixed for mainline.
I don't want to port this to gcc-4_0-branch. First of all, this isn't a
regression since debug mode was introduced in 3.4 and refined in 4.0.x, but is
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-22
08:31 ---
load-pre should sink the load and fix the problem at the tree level.
GCSE does it at rtl level for both -O2 and -Os on i686, so maybe costs on
alpha are weird enough to prevent it from doing its work at
--- Additional Comments From charlet at adacore dot com 2005-09-22 08:34
---
Subject: Re: s-taprop.adb:69:06: warning: cannot depend on
Interrupt_Operations (wrong categorization)
This bug is also present on the 4.0 branch. This is a regression
from 4.0.0
Could you double check ?
--- Additional Comments From pcarlini at suse dot de 2005-09-22 08:49
---
Sure! And thanks a lot for your concise and very effective fix!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
08:49 ---
Subject: Bug 23956
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-22 08:48:33
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:50
---
in on mainline, queued for 4.0.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-22 08:58
---
This is WONTFIX for 4.0.x, but is fixed in 4.1.x and later.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
10:29 ---
Subject: Bug 23788
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-22 10:28:17
Modified files:
gcc/ada: ChangeLog s-tpinop.ads
Log
For the following program
#define _POSIX_C_SOURCE 1
#include iostream
g++ issues the following error message:
/gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../include/c++/4.1.0/cwchar:166:
error: '::vfwscanf' has not been declared
--- Additional Comments From chris at bubblescope dot net 2005-09-22 10:49
---
Ah ha, found the problem. tuple has a copy constructor for std::pair, but not
an operator=(std::pair). It
should. I'll prepare a patch. While I'm at fixing this, there are quite a lot
of functions
--- Additional Comments From a dot darovskikh at compassplus dot ru
2005-09-22 10:54 ---
The same problem stays unresolved in GCC-3.4.4
My test is:
$ cat header1.h
$ cat header2.h
#include header1.h
$ cat test.cpp
#include header1.h
#include header2.h
main()
{
}
$g++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
11:24 ---
Subject: Bug 22438
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-22 11:24:01
Modified files:
gcc: ChangeLog tree-ssa-loop-ivopts.c
Compiling a program like this with -Wall doesn't generate a warning, even
though the result very likely is not intended:
struct s {
int a;
};
struct s s = {
.a = 5,
.a = 6,
};
Can a duplicate initializers warning please be added? Thank you!
--
Summary:
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords|
--- Additional Comments From pluto at agmk dot net 2005-09-22 13:10 ---
Uros,
The mode switching patch ICEs current mainline on ix86.
gcc fbmmx.i -msse -O0,-O1 fails with different insn-errors.
[ -msse -O0 ]
fbmmx.c: In function
--- Additional Comments From pluto at agmk dot net 2005-09-22 13:15 ---
You're right, the mainline is ok. This bug is related to PR19161.
--
What|Removed |Added
--- Additional Comments From kmccarty at princeton dot edu 2005-09-22
14:17 ---
Could anyone find out whether this g77 bug applies to other 64-bit Linux
architectures as well as AMD64? I'm thinking of Alpha, Itanium, S390x, and
64-bit PowerPC and SPARC. Thanks in advance for any such
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
15:04 ---
Subject: Bug 24007
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-22 15:03:35
Modified files:
gcc: ChangeLog
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:04 ---
Confirmed, 4.0.0 have the same issue.
To reproduce this on i686-pc-linux-gnu use cc1 directly so _GNU_SOURCE is not
defined or undefine it
in the source or invoke gcc as
g++ t.cc -U_GNU_SOURCE
the C
// Barebones code to reproduce the problem:
// Interface
namespace NS
{
templatetypename T class X {};
templatetypename T XT operator*(const XT a, const XT b);
}
// Implementation
templatetypename T
NS::XToperator*(const NS::XT a,const NS::XT b)
{
return NS::XT();
}
The following simple program fails to compile on FreeBSD 5.4:
#define _POSIX_C_SOURCE 1
#include iostream
g++ issues the following error message:
/gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl
ude/c++/4.1.0/cwchar:166:
error: '::vfwscanf'
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:17 ---
the error message about ambiguous overload is correct as there are two
functions there.
operator* in the global namespace and operator* in the NS namespace.
You most likely wanted to implement operator* in
--
What|Removed |Added
Summary|[3.4,4.0,4,1 regression]|[3.4/4.0/4.1 regression]
|#define _POSIX_C_SOURCE |#define _POSIX_C_SOURCE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:20 ---
This is a target issue. The way we work around this on GNU/Linux is that we
define _GNU_SOURCE all
the time.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:25 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
The following simple program fails to compile on FreeBSD 5.4:
#define _POSIX_C_SOURCE 1
#include iostream
g++ issues the following error message:
/gcc-current/bin/../lib/gcc/i386-unknown-freebsd5.4/4.1.0/../../../../incl
ude/c++/4.1.0/cwchar:166:
error: '::vfwscanf'
--
What|Removed |Added
CC||rittle at latour dot rsch
||dot comm dot mot dot com
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:37 ---
*** This bug has been marked as a duplicate of 24012 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:37 ---
*** Bug 24013 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24012
I've written an macro for log2 calculation to calculate the exponent of
one value.
Than I cast this value to from double to int.
The 2 values double and int differs.
example:
log2(8) should be 3 but after casting to int its 2.
This bug could be
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:48 ---
This is really not a bug.
This is a dup of 323.
*** This bug has been marked as a duplicate of 323 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
15:48 ---
*** Bug 24014 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
CC||rittle at latour dot waar
||dot labs dot mot dot com
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
15:58 ---
Subject: Bug 23043
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-22 15:57:49
Modified files:
gcc:
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-22
16:06 ---
I applied this patch to the 4.0 branch.
--
What|Removed |Added
Target Milestone|4.1.0
gcc produces wrong code when optimizer (O1 O2 or O3) is used.
The c-source showing the problem is generated by the flex lexical scanner.
Applies to gcc versions 3.0.4, 3.3.5 and 3.4.4 (and maybe others not tested).
Tested on Debian/Intel platforms only.
On gcc 2.95 and multiple former versions of
--
What|Removed |Added
Severity|critical|normal
Component|c |middle-end
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
16:26 ---
Of course, we cannot guess what the issue is from your description.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24015
--- Additional Comments From buergel at limmat dot ch 2005-09-22 16:28
---
Created an attachment (id=9792)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9792action=view)
Testcase. Unpack and make reproduces the bug
Testcase requires flex (= 2.5.4) lexical scanner to be installed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-22
16:35 ---
Subject: Bug 21983
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-22 16:34:59
Modified files:
gcc/cp : ChangeLog class.c
--- Additional Comments From buergel at limmat dot ch 2005-09-22 16:39
---
How-To-Repeat:
Unpack the attached archive, cd showbug, make.
It will first compile the program, then process and display some test data.
Prerequisites:
You must have the flex lexical parser installed for this
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
16:40 ---
html_purify.l:24: warning: operation on `data' may be undefined
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
16:43 ---
(In reply to comment #4)
html_purify.l:24: warning: operation on `data' may be undefined
Does fixing that line help?
It should look like:
static void strtolower(char *data) { while (*data != '\0') { *data
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
17:04 ---
From the private email:
Hello and thanks for the quick answer! Yes it does! But: I am not getting the
warning: operation on `data' may be undefined
when using gcc 3.4.4 and -Wall.
So how could I (and
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
17:06 ---
(In reply to comment #6)
Hello and thanks for the quick answer! Yes it does! But: I am not getting the
warning: operation on `data' may be undefined
when using gcc 3.4.4 and -Wall.
Try at -O0, glibc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-22
17:07 ---
*** Bug 24015 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
1 - 100 of 156 matches
Mail list logo
