--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-10-04 06:28
---
Oops. This is F2003 issue and therfore an enhancement relative to F95.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from uros at kss-loka dot si 2006-10-04 06:46 ---
I'm afraid you're missing my point.
The problem is that for 64-bit and 32-bit floating-point to integer
conversion,
x86 (32bit) target uses fistp* whereas x86_64 (64-bit) target uses cvt* WHEN
-mfpmath=387.
This
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-10-04 06:54
---
Subject: Bug 29020
Author: mmitchel
Date: Wed Oct 4 06:53:55 2006
New Revision: 117425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117425
Log:
PR c++/29020
* friend.c (do_friend):
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-10-04 06:59
---
I think this code is valid. Changing to ice-on-valid-code.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-04 07:01
---
Subject: Bug 28862
Author: pinskia
Date: Wed Oct 4 07:01:27 2006
New Revision: 117426
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117426
Log:
2006-10-03 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-04 07:01
---
Now also fixed in 4.1.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-10-04 07:03
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
building glibc-2.5 on ia64-linux-gnu, ok with current 4.1 20060929.
Matthias
gcc -save-temps iso-2022-cn-ext.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-s
trings -fmerge-all-constants -fstrict-aliasing -g -pipe -Wstrict-prototypes
-fPIC -I../include -I/home/p
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-10-04
07:52 ---
Created an attachment (id=12382)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12382action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29341
--- Comment #2 from debian-gcc at lists dot debian dot org 2006-10-04
07:58 ---
compiler version is trunk 20060922
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29341
trunk 20061003, works with 4.1 20060929, seen with glibc 2.3.6, 2.4, 2.5
gcc is configured with --with-system-libunwind
Matthias
$ gcc -nostdlib -nostartfiles -static -o
/home/packages/glibc/glibc-2.5/build-tree/ia64-libc/elf/sln
--- Comment #1 from rsandifo at gcc dot gnu dot org 2006-10-04 10:21
---
Subject: Bug 28448
Author: rsandifo
Date: Wed Oct 4 10:21:08 2006
New Revision: 117429
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117429
Log:
2006-10-02 Ryan Mansfield [EMAIL PROTECTED]
PR
See:
http://gcc.gnu.org/ml/fortran/2006-10/msg00086.html
Hi!
This patch causes compilation failure on SPEC cpu2000/facerec.
Below is the minimal reproducer:
Subroutine ReadParameters (Album)
Implicit NONE
Type GalleryP
Integer :: NoOfEntries
gcc version 4.2.0 20061004 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.2.0/f951 test.f90
-quiet -dumpbase test.f90 -mtune=generic -auxbase test -version -I
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.2.0/finclude -o
/tmp/ccL7Uf1l.s
GNU F95 version 4.2.0 20061004
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-04 14:17 ---
*** Bug 29344 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-04 14:17 ---
*** This bug has been marked as a duplicate of 29343 ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
The mode switching for floating point rounding that the i386 backend does
does not actually place mode switches, but rather the calculation of values
used for mode switches. Not only does that defeat the purpose of doing
lazy code motion of the mode switches themselves (this problem could easily
The following code produces an ambiguous warning from -Weffc++
class a {
private:
a operator||(const a);
};
[/Users/fca] g++ -Weffc++ -c effcpp01.cxx
effcpp01.cxx:3: warning: user-defined 'a a::operator||(const a)' always
evaluates both arguments
The meaning is effective c++ discourages you
--
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
--- Comment #2 from paulthomas2 at wanadoo dot fr 2006-10-04 16:33 ---
Subject: Re: (Regression) Error on valid specification
variables in same call to ALLOCATE
Steve,
I just wrote to Martin apologising and thanking him - the patch is
regtesting right now and I am all geared up to
Although my analysis of the i386 mode switching in PR 28764 was incorrect
(see PR target/29347), in my analysis in commnent #13 of PR target/28764
still stands with regard to superflous/unnecessarily repeated computation
that we do in the mode switching code, and additional optimizations that
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-10-04 16:50 ---
One way to handle this problem would be to consider every function call
and asm as requiring another mode for the mode switching value entities;
no code would be emittied to actually 'set' this mode, but the mode
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-04 16:54 ---
Subject: Bug 29343
Author: pault
Date: Wed Oct 4 16:54:19 2006
New Revision: 117435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117435
Log:
2006-10-04 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-04 16:57 ---
*** This bug has been marked as a duplicate of 27880 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-10-04 16:57
---
*** Bug 29342 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-04 17:12 ---
Subject: Bug 28952
Author: pinskia
Date: Wed Oct 4 17:12:30 2006
New Revision: 117436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117436
Log:
2006-10-04 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-04 17:12 ---
Subject: Bug 28952
Author: pinskia
Date: Wed Oct 4 17:12:30 2006
New Revision: 117436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117436
Log:
2006-10-04 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-04 17:17
---
The patch does not apply cleanly to the 4.1 branch so I am going to fix this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from kargl at gcc dot gnu dot org 2006-10-04 17:20 ---
gfortran still gets rrspacing of subnormal wrong.
troutmask:sgk[215] ./z
s = 4.4081038E-39 -- Subnormal named constant
x = 4.4081038E-39 -- Subnormal variable
rrspacing(s)=
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-10-04
17:31 ---
fixed in trunk 20061003
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #8 from debian-gcc at lists dot debian dot org 2006-10-04
17:36 ---
configuring --with-long-double-128 works. could --with-long-double-128 become
the default, if glibc-2.4 is detected?
the situation reminds me at --enable-__cxa_atexit, which is not the default,
but at
--- Comment #1 from laurent at guerby dot net 2006-10-04 17:56 ---
Confirmed on 4.0.3, 4.1.1 and 4.2.0 (20060922) on x86_64-linux.
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #5 from laurent at guerby dot net 2006-10-04 18:03 ---
Hi,
s-osinte.adss-osinte-linux.ads
This might need a bit more work, some structure size and such might not be
identical between versions. You should look at the s-osinte-linux-alpha.ads and
s-osinte-linux-hppa.ads
--- Comment #4 from pault at gcc dot gnu dot org 2006-10-04 18:49 ---
Fixed on trunk.
Thanks for your patience!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from lopezibanez at gmail dot com 2006-10-04 20:21 ---
Don't know whether it is relevant, but no ICE occurs if Werror is not used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29254
--- Comment #12 from sje at cup dot hp dot com 2006-10-04 21:08 ---
The uses of __Unwind_GetIPInfo in libstdc++ and libjava have been fixed. It
looks like the report in PR 29342 is due to the use of __Unwind_GetIPInfo in
gcc/unwind-c.c. I will create a patch for this use.
--
Compile:
#include pthread.h
// #include iostream
int main() {
pthread_mutexattr_t *attr;
pthread_mutexattr_init(attr);
return 0;
}
You get a link error.
Compile:
#include pthread.h
#include iostream
int main() {
pthread_mutexattr_t *attr;
pthread_mutexattr_init(attr);
return
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-04 21:39 ---
*** This bug has been marked as a duplicate of 4372 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-04 21:39
---
*** Bug 29350 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2006-10-04 22:03 ---
--with-long-double-128 is the default on glibc 2.4+, but only in GCC 4.2.
In vanilla GCC 4.1.x --with-long-double-128 isn't supported at all, those
changes
were added pretty late in the GCC 4.1 devel cycle and so do
--- Comment #23 from jakub at gcc dot gnu dot org 2006-10-04 22:20 ---
i(var) of course can't work with -fpic, it would only work at the expense
of text relocations, but those are not allowed on some architectures and highly
undesirable on the rest of architectures. In position
--- Comment #24 from amacleod at redhat dot com 2006-10-04 22:33 ---
The updated version of TER that will go into 4.3 during stage 1 resolves this
problem... TER no longer tracks dependencies the way it use to. It will replace
the expression, resulting in:
main ()
{
bb 2:
__asm__
The man page for nextafter and nextafterf states that they will signal
overflow and underflow if the result is not a normalized number (and I believe
they should signal inexact as well.) On an X8664 architecture with the -m64
option it does so, but with the -m32 option it does not. I reproduced
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-04 23:25 ---
This is a GCC bug how?
Anyways this is a glibc bug or just a documention bug. Note the man pages are
not part of the glibc project.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from brooks at gcc dot gnu dot org 2006-10-04 23:52 ---
Fixed (now that I have commit privs!): svn 117441.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-10-04 23:57 ---
Probably atoi() tail-calls strtol_l.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29302
Basically, g++ seems to have forgotten how to print some part of the error
message.
The errant code:
template typename T
struct s1
{
typedef T* ptr_type;
};
template typename T, template typename class U = s1
struct s2
{
typedef UT UT;
operator /*typename*/ UT::ptr_type
--
olsner at gmail dot com changed:
What|Removed |Added
Severity|normal |trivial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29352
--- Comment #16 from mrs at apple dot com 2006-10-05 00:57 ---
Our positron branch has the fix for this in it. We should dig it out and
submit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10901
1. configure options:
alfalfa:/home/zz/share/gcc.4.1/gcc-4.1.1:{1193} ./configure --prefix=
$HOME/local
2. make stage1 gcc-4.1.1
alfalfa:/home/zz/share/gcc.4.1/gcc-4.1.1:{1193} make boostrap
...
...
(stop at)
/home/zz/share/gcc.4.1/gcc-4.1.1/host-i386-redhat-linux/gcc/xgcc -
shared-libgcc
--- Comment #13 from eweddington at cso dot atmel dot com 2006-10-05 01:56
---
I had to slightly modify patch-2006-08-22-pr17621.diff from Carlos to
successfully patch against 4.1.1 (last hunk for gcc.c). It patched
successfully, but failed for the avr target in that the toolchain
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-10-05
02:03 ---
Geoff,
Can you expand on this? Assuming it is a atoi() tail-calls strtol_l
why is Darwin the only arch effected and what recourse do we have
in fixing this? I tried a brute force replacement of the
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 03:29 ---
Fixed in 4.0.0 and above. 3.4.x is no longer being updated so closing as
fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from sjc at pobox dot com 2006-10-05 03:41 ---
Submitted to glibc as failure to conform to ISO/IEC 9899:TC2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29351
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-05 03:43
---
Subject: Bug 27489
Author: pinskia
Date: Thu Oct 5 03:43:36 2006
New Revision: 117448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117448
Log:
2006-10-04 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-05 03:43 ---
Subject: Bug 27490
Author: pinskia
Date: Thu Oct 5 03:43:36 2006
New Revision: 117448
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117448
Log:
2006-10-04 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 03:45 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-10-05 03:45
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 04:31 ---
effcpp01.cxx:3: warning: user-defined 'a a::operator||(const a)' always
evaluates both arguments
I don't see why this is ambiguous. Because normally || is short ciruting in
that if the left hand side is true the
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 04:38 ---
Actually the reason why it uses cvttsd2si is two fold, first cvttsd2si does not
need to act on a SSE register which is where the argument is passed in.
In fact we use cvttsd2si for 32bit also which actually
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-05 04:39 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-05 04:45 ---
(In reply to comment #0)
This makes a difference if/when the extra precision of 387 makes difference to
the conversion - which -mfpmath=387 is supposed to prevent.
that is only done when doing lots of math so then
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-05 04:47 ---
Works with 4.1.2 20061004
so yes this is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 04:56 ---
Here is a shorter testcase which shows the problem:
class X{};
void (X:: *b)();
void (__attribute((stdcall))X:: *c)() = b;
This also can create wrong code too.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from seongbae dot park at gmail dot com 2006-10-05 05:00
---
For example:
# cat m.c
int todouble(double a, double b) {
return (int)(a+b);
}
#
With 4.1.0 i686-unknown-linux-gnu target:
# gcc -O2 m.c -S
# cat m.s
...
.type todouble, @function
todouble:
--- Comment #34 from patchapp at dberlin dot org 2006-10-05 05:00 ---
Subject: Bug number PR20541
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/2006-10/msg00231.html
--
On Thu, 2006-10-05 at 05:00 +, seongbae dot park at gmail dot com
wrote:
With 4.1.0 i686-unknown-linux-gnu target:
# gcc -O2 m.c -S
try -O2 -msse2, you get:
_Z8todoubledd:
subl$12, %esp
fldl24(%esp)
faddl 16(%esp)
fstpl (%esp)
movsd
--- Comment #7 from pinskia at physics dot uc dot edu 2006-10-05 05:05
---
Subject: Re: -mfpmath=387 doesn't use fistp for
double-to-integer conversion
On Thu, 2006-10-05 at 05:00 +, seongbae dot park at gmail dot com
wrote:
With 4.1.0 i686-unknown-linux-gnu target:
#
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-05 05:08 ---
(In reply to comment #6)
Don't know whether it is relevant, but no ICE occurs if Werror is not used.
Which is why I marked this as an error recovery bug. I really don't think this
should be a P1 either because we
--- Comment #2 from federico dot carminati at cern dot ch 2006-10-05 05:10
---
Subject: Re: Ambiguous warning with -Weffc++
First of all a user can implement the correct behaviour, evaluating
just the first member and returning if true, continuing if false.
Second, the compiler
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-05 05:11 ---
Confirmed.
3. Whether GMP/MPFR works on all the platforms/configurations that GCC
supports. Are we ready to require a GMP/MPFR port for every port of GCC?
As far as I know there is GMP port to all hosts that
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-05 05:18 ---
(In reply to comment #2)
Subject: Re: Ambiguous warning with -Weffc++
First of all a user can implement the correct behaviour, evaluating
just the first member and returning if true, continuing if false.
--- Comment #3 from daney at gcc dot gnu dot org 2006-10-05 05:42 ---
One way to fix it would be to have a reaper thread for *each* Process. Then
the reaper could do a waitpid(pid...) instead of waitpid(-1...). If one only
spawns a few processes, this would be fine. This would allow
On Thu, 2006-10-05 at 05:42 +, daney at gcc dot gnu dot org wrote:
--- Comment #3 from daney at gcc dot gnu dot org 2006-10-05 05:42 ---
One way to fix it would be to have a reaper thread for *each* Process. Then
the reaper could do a waitpid(pid...) instead of waitpid(-1...).
--- Comment #4 from pinskia at physics dot uc dot edu 2006-10-05 05:48
---
Subject: Re: add wait handling hook
On Thu, 2006-10-05 at 05:42 +, daney at gcc dot gnu dot org wrote:
--- Comment #3 from daney at gcc dot gnu dot org 2006-10-05 05:42 ---
One way to fix it
75 matches
Mail list logo
