Ian Lance Taylor wrote:
Sanjiv Kumar Gupta [EMAIL PROTECTED] writes:
I am using gcc 3.3.1 release as my port, and looks
like I have hit a problem with greg.
You neglected to mention what target you are using.
Ian, the port is for a 32-bit RISC and not complete yet,
hence still not
On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
Daniel Berlin [EMAIL PROTECTED] wrote on 30/05/2005 06:41:54:
On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
Michael Veksler [EMAIL PROTECTED] wrote:
3. Nontrivial search of GCC Bugzilla are, sometimes,
On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
Daniel Berlin [EMAIL PROTECTED] wrote on 30/05/2005 06:41:54:
On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
Michael Veksler [EMAIL PROTECTED] wrote:
3. Nontrivial search of GCC Bugzilla are, sometimes,
in gcc-3.4.1
rtl can be generated when parsing the source program,
for example,
stmt:
compstmt
{ stmt_count++; $$ = $1; }
| expr ';'
{ stmt_count++;
$$ = c_expand_expr_stmt ($1); }
while in c_expand_body, rtl can also be generated .
what are they
On 2005-05-30 00:31:44 -0400, Daniel Berlin wrote:
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809]
Compiling the code there with icc gives us:
[EMAIL PROTECTED]:~ icc icca.c
icca.c(7): warning #1572: floating-point equality and inequality
comparisons are unreliable
assert(a == x);
On 2005-05-29 23:59:39 -0400, Daniel Berlin wrote:
On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
If more than 50 people report it, independently, as a bug then it
sure is a bug.
Which is why it's still open!
It isn't (it was marked as INVALID).
The problem with 323 isn't
On 2005-05-29 13:22:55 +0300, Michael Veksler wrote:
Two examples come in mind:
1. Non conformance of x86 to the standard FP due to
its extra precision.
Wrong. The IEEE-754 standard allows extended precision.
This includes different results between -O2 and -O0 even with
On 2005-05-29 01:33:43 -0600, Roger Sayle wrote:
I apologise for coming into this argument late. I'll admit that I
haven't even caught up on the entire thread, but an interesting
relevant article that may or may not have already been mentioned is:
On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
If more than 50 people report it, independently, as a bug then it
sure is a bug. You might argue whether technically it is a bug, but
from user's perspective it is a bug (and you have over 50 duplicates
as an evidence). As such it has to be
On 2005-05-29 19:22:57 +0200, Marc Espie wrote:
In article [EMAIL PROTECTED] you write:
http://csdl.computer.org/dl/mags/co/2005/05/r5091.pdf
An Open Question to Developers of Numerical Software, by
W. Kahan and D. Zuras
Doesn't look publically accessible from my machine...
Hmm...
[EMAIL PROTECTED] (William Beebe) wrote on 29.05.05 in [EMAIL PROTECTED]:
On 29 May 2005 11:37:00 +0200, Kai Henningsen [EMAIL PROTECTED]
wrote: [EMAIL PROTECTED] (Scott Robert Ladd) wrote on 28.05.05
in In my experience, people don't file Bugzilla reports because it feels
impersonal
Hi,
I'm using gcc long long type for my calculator. I have to check
integer overflow. I'm using sign compare to check overflow, but it
doesn't work for 10^16 * 10^4 :
1 * 1
Here you have my code to check overflow :
long long produit = a * b; // a,b: long long
bool ok;
* Georg Bauhaus [EMAIL PROTECTED] [050529 20:53]:
By real circle I mean a thing that is not obfuscated by the useful
but strange ways in which things are redefined by mathematicians;
cf. Halmos for some humor.
Sorry, but sin and cos are mathematical functions. If you want to invent
some
Hi all,
I've had an idea for additional checking that gcc could do
to help programmers - check that functions declared as
pure or reentrant are actually pure/reentrant. It appears
that the most obvious checking can be done relatively easily.
I know that there are other methods to check these
MfG Kai
OK, then let me explain it to you. The problem with the GCC Bugzilla
reporting system is that it's a system that only other developers can
tolerate, let alone love.
You probably feel this way about all Bugzilla's then, since they are all
the same except for the really large ones.
On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
Giovanni Bajo wrote on 29/05/2005 13:54:39:
Vincent Lefevre [EMAIL PROTECTED] wrote:
Perhaps because GCC developers think that GCC isn't buggy when the
processor doesn't do the job for them? (I'm thinking of bug 323.)
On 5/29/05, Russ Allbery [EMAIL PROTECTED] wrote:
Setting aside for the moment that GCC is a software package *targetted* at
developers, and hence the above is not necessarily a serious problem, I
agree that the Bugzilla interface isn't exactly my favorite UI. However,
I haven't figured out
R Hill [EMAIL PROTECTED] writes:
Joe Buck wrote:
[The request to create a login] also helps assure that the bug
filer is a real person. If Bugzilla provided an anonymous way to
file Bugzilla reports, we'd probably have spammers filling the bug
database with ads for penis enlargement.
On Sun, May 29, 2005 at 05:52:11PM -0400, Scott Robert Ladd wrote:
(I expect Gabriel dos Rios to respond with something pithy here; please
don't disappoint me!)
Funny, I don't expect any message from that signature.
Gabriel dos Reis, on the other hand, may have something to say...
Marc Espie wrote:
Heck, I can plot trajectories on a sphere that do not follow great circles,
and that extend over 360 degrees in longitude. I don't see why I should be
restricted from doing that.
Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
are not equal to
Marc Espie wrote:
Heck, I can plot trajectories on a sphere that do not follow great circles,
and that extend over 360 degrees in longitude. I don't see why I should be
restricted from doing that.
Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
are not equal to
On Mon, May 30, 2005 at 11:03:24AM -0600, Jeffrey A Law wrote:
In this case I'd replace the .* with _5 and see if it matches
properly. If it does, then I'd tighten the wildcard.
Something like p_[0-9]*
Excellent, that worked. I wonder why is dejagnu so fussy about
patterns.
Thanks.
Marc Espie wrote:
Funny, I don't expect any message from that signature.
Gabriel dos Reis, on the other hand, may have something to say...
A regrettable mistake, brought on by spending too many years in
Spanish-speaking areas, where rio is river.
..Scott
On Sun, 29 May 2005, Steven Bosscher wrote:
I don't understand what lines 2728 to 2741 are for. Could someone give
an example of when we can have a then_bb that has no successors, but
still ends in something that satisfies simplejump_p()? What kind of
strange indirect jump would that be?
Bernhard R. Link wrote:
Breaking things like sin(-x) or sin(x+y) will definitly hurt people,
because it is natural to expect this to work.
Where in the name of [insert diety here] did I *ever* say I wanted to
break anything?
Just because something breaks *your* application doesn't mean I
Bernhard R. Link wrote:
Sorry, but sin and cos are mathematical functions.
The mathematical functions sin and cos are mathematical
functions in mathematics but almost never in GCC's world,
almost never in the mathematical sense:
They can almost never be computed by programs translated using
* Georg Bauhaus [EMAIL PROTECTED] [050530 19:34]:
Programmers write calls to functions named sin and cos for
reaons of getting a result that is near what the mathematical
model (involving the same names sin and cos) would suggest.
Question is, how and when should GCC enable a programmer to
William Beebe [EMAIL PROTECTED] writes:
Then I would like you to review and contrast GCC Bugzilla
(http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's
(https://bugzilla.mozilla.org) and Redhat's
(https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit
more organized
Bernhard R. Link wrote:
naming any range smaller than some [-50pi,100pi] valid could
really make me crazy...
No one is asking for sine to be restricted in this way.
Some are asking for the freedom to request this or that
kind of sine computation to be generated, because they know
that for
Hello,
we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitted at all.
The problem appears to be this piece of code in
On May 30, 2005, at 2:59 PM, Ulrich Weigand wrote:
Hello,
we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitted at
--- Daniel Berlin wrote:
Let's take a duplicate of 323, 21809
Compiling the code there with icc gives us:
[EMAIL PROTECTED]:~ icc icca.c
icca.c(7): warning #1572: floating-point equality
and inequality
comparisons are unreliable
assert(a == x);
^
./[EMAIL PROTECTED]:~
How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE? Is it possible to
get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
VIEW_CONVERT_EXPR?
If this is impossible, the Ada front end should probably stop setting
these fields because it assumes that it can use values outside that
range:
How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE? Is it possible to
get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
VIEW_CONVERT_EXPR?
I don't really understand either question. Also, as to the second,
keep in mind their role in array indexes.
If this is impossible,
Haren Visavadia wrote:
--- Robert Dewar wrote:
I would expect the seem behaviour for both cases.
why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed tricky.
test-case.c cause an assertion failure with
Andrew Pinski wrote:
You can reproduce it using:
static int i;
int main(void)
{
i += 3;
i *= 5;
return 0;
}
and readelf and looking for the DW_TAG_variable tag.
Yes; in fact 'main' is even superfluous. Just compile
int var;
with -S -O2 -g on gcc 3.4 and 4.0 and look at
--- Robert Dewar wrote:
Haren Visavadia wrote:
--- Robert Dewar wrote:
I would expect the seem behaviour for both cases.
why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed tricky.
Why are extra
Vincent Lefevre wrote:
On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
If more than 50 people report it, independently, as a bug then it
sure is a bug. You might argue whether technically it is a bug, but
from user's perspective it is a bug (and you have over 50 duplicates
as an
* Diego Novillo:
http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html
Current mainline does not optimize array range checks away (even with
-ftree-vrp), but I'm not sure if this is just a missed optimization
opportunity as far as the optimizers are concerned, or
On Mon, May 30, 2005 at 10:13:19PM +0200, Ulrich Weigand wrote:
Andrew Pinski wrote:
You can reproduce it using:
static int i;
int main(void)
{
i += 3;
i *= 5;
return 0;
}
and readelf and looking for the DW_TAG_variable tag.
Yes; in fact 'main' is even
On Mon, May 30, 2005 at 11:17:34PM +0200, Florian Weimer wrote:
* Steve Kargl:
I need to add a configure test to determine if MAP_NOSYNC is
present.
What about #ifdef MAP_NOSYNC in the code? Or do you invoke mmap
directly from Fortran?
There are sometimes too many TREEs (pun intended
Kai Henningsen wrote:
The entire GCC website (of which GCC
Bugzilla is a part) could be the poster child for why developers
should never be allowed to design user interfaces, especially web user
interfaces. I'm sure I'll get flamed for wanting style over substance
or about the proliferation of
Next try documentation, installation. Talks about compiling again.
Finally, at download, binaries I find what I want. Seeing as I suspect
that is the link most people want when they first visit, it should
perhaps be a little more obvious, and in the main body near the top?
Your scenario
Daniel Berlin wrote:
On Sun, 2005-05-29 at 16:37 +1200, Ross Smith wrote:
On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
Is perhaps some kind of anonymous account needed (as in Slashdot's
case) to encourage these users to fill bugreports?
I think this is probably the real showstopper.
Haren Visavadia wrote:
--- Robert Dewar wrote:
Haren Visavadia wrote:
--- Robert Dewar wrote:
I would expect the seem behaviour for both cases.
why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed
Toon Moene wrote:
But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here.
It's not off-topic. In fact, Jim Wilson argued this point
R Hill [EMAIL PROTECTED] writes:
I just wanted to speak up and say that the idea of alarm bells going off
when people see a request for an email address from bugzilla is probably
one of the sillier things I've read this week. Anyone lucid enough to
be reporting a bug to an open source
Russ Allbery wrote:
It's not the request for the e-mail address. It's that it's phrased as a
login screen and a button to create an account. I know that I definitely
pause and consider before I create an account at a web site. There are
many on-line newspapers that I refuse to read articles
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
06:10 ---
Subject: Bug 21761
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 06:10:06
Modified files:
gcc: ChangeLog
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-05-30
06:13 ---
Should work now, but please verify.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:38 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-30 07:38:36
Modified files:
libgfortran: ChangeLog
libgfortran/io :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-30
07:42 ---
Subject: Bug 20179
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-30 07:42:38
Modified files:
libgfortran:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-30
07:45 ---
Patch for first part of the problem applied. Keeping open according to comments
#8 to #11.
--
What|Removed |Added
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
07:50 ---
This program builds just fine:
$ cat conftest.c
main () {
/* Are we little or big endian? From HarbisonSteele. */
union
{
long l;
char c[sizeof (long)];
} u;
u.l = 1;
exit
When I use a ftime function in a multhithread program, sometime it will stop
and
all thread that use this function will wait for a mutex lock. The information
from
GDB are following:-
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/64/libnsl.so.1...done.
--- Additional Comments From oliverst at online dot de 2005-05-30 07:56
---
Filed a bug report on the MinGW project page:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21810
gcc -D__KERNEL__ -I/usr/src/linux-2.4.30/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe
-mpreferred-stack-boundary=2 -march=athlon-nostdinc -iwithprefix include
-DKBUILD_BASENAME=floppy -c -o floppy.o floppy.c
gcc: Internal
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/tools/pkg/gcc/4.0.0 --enable-
languages=c,c++ --disable-threads
Thread model: single
gcc version 4.0.0
$ touch a.c
$ gcc -E a.c
# 1 a.c
# 1 built-in
# 1 command line
# 1 a.c
$ gcc -E -g
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:00 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
09:35 ---
In the 64-bit case, again none of BYTE_ORDER, BIG_ENDIAN or LITTLE_ENDIAN are
defined. As far as I can understand, the configure script stops there and
doesn't run additional tests as in the 32-bit case.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:38 ---
checking whether byte ordering is bigendian... cross-compiling...
unknown
checking to probe for byte ordering... guessing bigendian ...
unknown
configure: error: unknown endianess - sorry
gmake[1]: ***
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
09:40 ---
I think you should give it another try.
rm -r sparc-sun-solaris2.8/libffi
rm -r sparc-sun-solaris2.8/sparcv9/libffi
gmake all-target-libffi
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782
--- Additional Comments From giovannibajo at libero dot it 2005-05-30
10:34 ---
As explained in the URL printed by GCC, we need the preprocessed source. Also
notice that 3.3.6 is out and the 3.3 branch is now unsupported. You may want to
switch to a newer GCC.
--
What
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
10:38 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-30
10:51 ---
I'm beginning to see what happens here. It's arising from many small errors in
the library code (bad handling of bytes_left and active fields).
I will probably come up with a nice patch in the next few
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
11:13 ---
This has to be the command line.
All I did was copying/pasting from the config.log file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21782
--
What|Removed |Added
Component|other |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21812
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:25 ---
Not a GCC bug, please report this to your libc provider (most likely glibc).
--
What|Removed |Added
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|critical
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:34 ---
This is expected behaviour as you need the current directory for debugging.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
11:36 ---
The correct URL for the bug at mingw is:
https://sourceforge.net/tracker/index.php?
func=detailaid=1211187group_id=2435atid=102435
--
What|Removed |Added
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
11:39 ---
I tried anyway:
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From joerg dot richter at pdv-fs dot de 2005-05-30
11:41 ---
Well, but I want all generated objects to be the same between our developers.
This makes an extremly good cache hit rate with ccache. We arranged with it
that we don't have the current/source
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
12:22 ---
$ /export/Plocal/GCC-3.3.6/gcc/xgcc -B/export/Plocal/GCC-3.3.6/gcc/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/bin/
-B/usr/local/gcc-3.3.6/sparc-sun-solaris2.8/lib/ -isystem
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:43 ---
We're heading in the wrong direction.
I don't see how '-v' can help. The problem is just that LD_LIBRARY_PATH contains
/usr/local/lib which contains a link to the 32-bit libgcc_s.so.1 library of gcc
4.
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:44 ---
(In reply to comment #20)
$ env ldd conftest
Instead it should read:
env LD_LIBRARY_PATH=/export/Plocal/GCC-3.3.6/gcc/sparcv9 ldd conftest
I don't know what went wrong while copying/pasting.
--
gfortran4 -c /home/oskeno/src/edge/solver/basic/tst.f90
In file /home/oskeno/src/edge/solver/basic/tst.f90:2
TYPE TTYPE
1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
--
Summary: gfortran rejects simple, valid code
Product: gcc
--- Additional Comments From papadopo at shfj dot cea dot fr 2005-05-30
12:59 ---
See:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/Makefile.am#rev1.40
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/Makefile.in#rev1.51
These changes must somehow be related to my problems with gcc
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:00 ---
Created an attachment (id=8991)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8991action=view)
Testcase with valid code that fails to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21816
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
13:01 ---
We're heading in the wrong direction.
I don't see how '-v' can help. The problem is just that LD_LIBRARY_PATH
contains
/usr/local/lib which contains a link to the 32-bit libgcc_s.so.1 library of
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:02 ---
(From update of attachment 8991)
MODULE TSTMOD
TYPE TTYPE
INTEGER, POINTER :: P =NULL()
END TYPE TTYPE
TYPE(TTYPE), POINTER :: TP
END MODULE TSTMOD
--
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:04
---
These failures should have been fixed after this:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02756.html
With the fix above I no longer see these testcase failures on powerpc-apple-
darwin, but the ICEs
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:05 ---
Created an attachment (id=8992)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8992action=view)
Corrected testcase
Please forget the previous attachment (feel free to remove it if possible) ...
_This_
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
13:08 ---
*** Bug 21816 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
13:08 ---
*** This bug has been marked as a duplicate of 16606 ***
--
What|Removed |Added
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 13:10
---
Confirmed, this is most likely the same as PR 21653.
Indeed looks related, but a patch that fixed PR21653 did not fix this PR. I
also checked if the follow-on fix - http://gcc.gnu.org/ml/gcc-patches/2005-
--- Additional Comments From enok at lysator dot liu dot se 2005-05-30
13:27 ---
If CHARACTER is replaced by INTEGER the result is the same. Thus, it is not
CHARACTER type pointers that causes the problem.
(In reply to comment #6)
*** Bug 21816 has been marked as a duplicate of this
giraff:~/edu/exjobb/src/mkexpl /scratch/dva00mkn/gcc-4.0/bin/gcc bug.c -O -c
bug.c: In function 'foo':
bug.c:4: internal compiler error: in for_each_index, at tree-ssa-loop-im.c:200
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:09 ---
Confirmed, also happens on i686-pc-linux-gnu.
Also this looks like a latent bug on the mainline.
--
What|Removed |Added
Steps to reproduce:
1. Compile they attached testcase with gcj -C DoubleClickJList.java
Expected results:
1. DoubleClickJList.class is created and no errors are shown.
Actual results:
$ /home/lindi/installdir-2005-05-22/gcc/bin/gcj -C DoubleClickJList.java
DoubleClickJList.java:3: error: Methods
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:20 ---
Confirmed, this is just namespace spilling in the library.
--
What|Removed |Added
i*86-*-gnu* not enabled in configure.ac, which makes configure fail if you try
to compile libffii on GNU.
--
Summary: i*86-*-gnu* not enabled in configure.ac
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Consider the following program:
program kl
integer i,j,k
integer, parameter :: m = 1000, n = 387
real x(m,n)
x = 1.e0
inquire(iolength=k) (x(i,1), i=1, m)
open(unit=1, file='foo.dat', access='direct', recl=k)
do j = 1, n
write(1,rec=j) (x(i,j), i=1, n)
end do
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-30
14:33 ---
Nope, I am wrong, this is a front-end bug:
copper:~cat t/JList.java
package t;
public class JList
{
void init(){}
}
copper:~cat DoubleClickJList.java
import t.JList;
public class DoubleClickJList extends
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:33 ---
Alan, am I mistaken or did you document on the 3.4 branch something that is only
in 4.x? AFAICS PR bootstrap/14992 has been solved differently on that branch:
PR bootstrap/14992
*
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-30 14:33
---
Created an attachment (id=8994)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8994action=view)
patch to fix problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21820
--- Additional Comments From dorit at il dot ibm dot com 2005-05-30 14:35
---
I can't reproduce this ICE with mainline snapshot from today. (I was able to
reproduce it a few days ago, but not anymore).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21819
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-30
14:40 ---
Aaah... You mean adding '-v' to 'xgcc', not to 'conftest' itself. My wrong.
Yup, sorry for being too vague.
Please find the output of the following command attached.
The problem stems from -lgcc
Please do not use MAXPATHLEN, it is a arbitrary limit, and is not
defined on GNU. Currently this makes libjava (gcc 4.0.0) unbuildable on GNU
since [gcc]/libjava/gnu/java/nio/channels/natFileChannelImpl.cc assumes that
MAXPATHLEN is defined. Please do not use these kind of limits in GNU
1 - 100 of 213 matches
Mail list logo
