The following C program gives incorrect results with vanilla gcc 4.1.1 (default
./configure options except --prefix, compiled on Fedora Core 5) and specific
compile options.
#include stdio.h
char buf[8] = {1,1,1,1,1,1,1,1};
char zero=0;
int main() {
int i;
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 07:57 ---
You are violating C aliasing rules.
You are accessing a character array via something other than a character type
which is undefined. The opposite way would have been defined in that accessing
an long long array
--- Comment #107 from pinskia at gcc dot gnu dot org 2006-10-28 07:57
---
*** Bug 29626 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from vincent at vinc17 dot org 2006-10-28 09:07 ---
(In reply to comment #17)
Yes, I can reproduce the NaN. In fact, any negative value
gives a NaN.
Not any negative value, but in lngamma.c:
/* if x 0 and -2k-1 = x = -2k, then lngamma(x) = NaN */
probably
--- Comment #2 from uros at gcc dot gnu dot org 2006-10-28 09:41 ---
Subject: Bug 29377
Author: uros
Date: Sat Oct 28 09:41:41 2006
New Revision: 118102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118102
Log:
PR target/29377
* config/h8300/h8300.c
--- Comment #3 from uros at kss-loka dot si 2006-10-28 09:43 ---
Fixed on 4.3 mainline
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-28 10:03 ---
Subject: Bug 29377
Author: uros
Date: Sat Oct 28 10:03:37 2006
New Revision: 118103
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118103
Log:
PR target/29377
* config/h8300/h8300.c
--- Comment #5 from uros at kss-loka dot si 2006-10-28 10:04 ---
Fixed for 4.1.2.
--
uros at kss-loka dot si changed:
What|Removed |Added
Known to work|4.3.0
--- Comment #6 from v dot vasaitis at sms dot ed dot ac dot uk 2006-10-28
11:08 ---
OK thanks, it's quite clear now. My apologies for acting inappropriately.
Regards,
Vasilis
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29618
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-28 11:31 ---
Subject: Bug 28806
Author: rguenth
Date: Sat Oct 28 11:30:41 2006
New Revision: 118105
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118105
Log:
2006-10-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-10-28 11:06 ---
Ah, no - I didn't look at the result of this first hunt and though it was the
switch from -floop-optimize to -floop-optimize2. Sorry for the noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28970
--- Comment #19 from ghazi at gcc dot gnu dot org 2006-10-28 13:28 ---
(In reply to comment #18)
(In reply to comment #17)
Yes, I can reproduce the NaN. In fact, any negative value
gives a NaN.
Not any negative value, but in lngamma.c:
/* if x 0 and -2k-1 = x = -2k, then
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-28 13:34 ---
Probably the same for binary and hexadecimal?
io/transfer.c(formatted_transfer_scalar): case FMT_O: seems to be a good
place for adding notify_std (dtp-common, GFC_STD_GNU,...)
--
--- Comment #14 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-28 13:09 ---
Do g95 and ifort also compile the original testcase and do The Right Thing?
No. g95 has a run-time error, ifort garbage at the beginning (but no crash);
f95 and sunf95 don't compile.
gfortran:
--- Comment #20 from vincent at vinc17 dot org 2006-10-28 14:05 ---
(In reply to comment #19)
The documenation in MPFR says:
-- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
Set ROP to the value of the Gamma function on OP, and its
logarithm
--- Comment #9 from franke dot daniel at gmail dot com 2006-10-28 14:27
---
I ran into this on a x86_64 running some flavour of debian. Since I can not
alter the system setup, I have to compile svn sources with multilib disabled
(otherwise the build process stops due to various
--- Comment #21 from ghazi at gcc dot gnu dot org 2006-10-28 16:03 ---
(In reply to comment #20)
I agree. And I think that none of the MPFR developers were aware of this
problem (I didn't notice the difference when I was looking for C functions
that were missing in MPFR).
Since you
--- Comment #22 from vincent at vinc17 dot org 2006-10-28 16:58 ---
(In reply to comment #21)
Since you mentioned C functions missing in MPFR, what are your plans for the
Bessel functions? I'd like to hook up builtins j0/j1/jn/y0/y1/yn. Thanks.
They're in the TODO, but there are no
--- Comment #3 from patchapp at dberlin dot org 2006-10-28 16:39 ---
Subject: Bug number PR28484
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/msg01387.html
--
--- Comment #3 from Thomas8675309 at yahoo dot com 2006-10-28 17:57 ---
If one clicks on the list of All regressions for GCC 4.1.1 from the main
page, http://gcc.gnu.org, this bug doesn't come up. Any idea why?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-28 18:03 ---
Subject: Bug 26899
Author: rguenth
Date: Sat Oct 28 18:03:21 2006
New Revision: 118106
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118106
Log:
2006-10-28 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-28 18:04 ---
Fixed what is possible to fix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29054
$ cat partial.f90
program main
character(len=1) a(2)
open(10, form=unformatted,status=unknown)
write (10) 'a'
rewind 10
a = 'b'
read (10) a
print *,a
end program main
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/trunk/configure
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-28 18:11 ---
Uh, I forgot the actual output from the program:
$ gfortran partial.f90
$ ./a.out
ab
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-28 18:22 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-10-28 18:22
---
Now that we do all possible canonicalization we still can not figure out # of
iterations here.
I'm revisiting the proposed patch for this PR and am going to attack
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28806
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 18:26 ---
Related to PR 21952.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29617
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-28 18:44 ---
As far as I can tell this has been a pedwarning since the begining of the C++
front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 18:49 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
`main' function (the function with specific prologue/epilogue) is missing DWARF
`DW_AT_location' for its `argc' and `argv' on 32-bit targets - only if these
arguments are never unused.
affected: x86_64-redhat-linux with -m32, i386-redhat-linux
not affected: x86_64-redhat-linux (-m64)
32-bit
--- Comment #2 from burnus at gcc dot gnu dot org 2006-10-28 21:05 ---
Subject: Bug 29625
Author: burnus
Date: Sat Oct 28 21:05:42 2006
New Revision: 118111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118111
Log:
2006-10-28 Tobias Burnus [EMAIL PROTECTED]
PR
There must be something inherently evil with the code below as both, gfortran
and ifort, crash.
If either func is not array valued or not listed in the REDUCE-clause,
everything is fine.
$ cat omp.f90
PROGRAM omp
write (*,*) func(n)
CONTAINS
FUNCTION func(n)
INTEGER, INTENT(in) :: n
--- Comment #3 from burnus at gcc dot gnu dot org 2006-10-28 21:07 ---
Subject: Bug 29625
Author: burnus
Date: Sat Oct 28 21:07:19 2006
New Revision: 118112
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118112
Log:
2006-10-28 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-28 21:24 ---
Created an attachment (id=12504)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12504action=view)
preliminary patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
--- Comment #5 from burnus at gcc dot gnu dot org 2006-10-28 21:46 ---
Accept.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-28 21:43 ---
Fix checked in:
Author: burnus
Date: Sat Oct 28 21:05:42 2006
New Revision: 118111
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118111
Log:
2006-10-28 Tobias Burnus [EMAIL PROTECTED]
PR
erik:~/gcc$ cat bug.f90
program init
implicit none
integer, parameter :: a1(6) = [1, 2, 3, 4, 5, 6]
integer, parameter :: b1(3) = a1([1,2,3])
end program init
erik:~/gcc$ gfortran bug.f90
In file bug.f90:4
integer, parameter :: b1(3) = a1([1,2,3])
1
Error: Unclassifiable
--- Comment #5 from burnus at gcc dot gnu dot org 2006-10-28 21:44 ---
Mark fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2006-10-28 21:59 ---
Subject: Bug 28224
Author: burnus
Date: Sat Oct 28 21:59:20 2006
New Revision: 118113
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118113
Log:
fortran/
2006-10-28 Tobias Burnus [EMAIL PROTECTED]
--- Comment #7 from burnus at gcc dot gnu dot org 2006-10-28 21:59 ---
Fixed.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from burnus at gcc dot gnu dot org 2006-10-28 22:13 ---
Assign.
Preliminary patch at:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01387.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-10-28 22:34 ---
Ok, I have double checked that both on 4.0.3 and the active branches everything
is fine per Valgrind (3.2.1). You may want to pass -v to Valgrind and look at
the supp: lines in the output, showing the used suppressions:
--- Comment #2 from mueller at gcc dot gnu dot org 2006-10-28 22:34 ---
Subject: Bug 29033
Author: mueller
Date: Sat Oct 28 22:34:06 2006
New Revision: 118117
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118117
Log:
2006-10-29 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #3 from mueller at gcc dot gnu dot org 2006-10-28 22:41 ---
Fixed for 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-28 23:05 ---
What happens if you try -O2 -fno-loop-optimize?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-28 23:02 ---
Subject: Bug 29295
Author: pinskia
Date: Sat Oct 28 23:01:59 2006
New Revision: 118118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118118
Log:
2006-10-28 Andrew Pinski [EMAIL PROTECTED]
PR
This is extracted from gnushogi (http://bugs.debian.org/393075).
[EMAIL PROTECTED]:~% cat bug.c
const signed char nunmap[] = { 17, -1, 1 };
__attribute__((noinline))
void ff(int i) {
asm volatile();
}
__attribute__((noinline))
void f(short delta) {
short p0 = 2, s;
for (s = 0; s 2;
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-28 23:02 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from falk at debian dot org 2006-10-28 23:13 ---
(In reply to comment #1)
What happens if you try -O2 -fno-loop-optimize?
No crash then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-28 23:19 ---
No crash then.
So this is another loop.c bug. This is why it was removed, it was full of bugs
:).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mueller at gcc dot gnu dot org 2006-10-28 23:22 ---
Testing patch.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
GCC build triplet|i686-pc-linux-gnu |
GCC host
--- Comment #4 from mueller at gcc dot gnu dot org 2006-10-28 23:45 ---
testing patch
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2006-10-28 23:56 ---
Subject: Re: ICE in gfc_match_common for blank common in BLOCK DATA unit
On Sun, Oct 22, 2006 at 09:08:02PM -, aldot at gcc dot gnu dot org wrote:
Created an attachment (id=12476)
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-10-28 23:21
---
I had considered flipping the logic around on is_stream_io as you have done in
the preliminary patch. The first versions of stream_io I was leaving the
existing code completely untouched while testing out the
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-29 00:28 ---
Subject: Bug 29271
Author: pinskia
Date: Sun Oct 29 00:27:49 2006
New Revision: 118128
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118128
Log:
2006-10-28 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-10-29 00:28 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from ghazi at gcc dot gnu dot org 2006-10-29 02:02 ---
Subject: Bug 29335
Author: ghazi
Date: Sun Oct 29 02:02:10 2006
New Revision: 118129
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118129
Log:
PR middle-end/29335
* builtins.c (do_mpfr_arg2,
The following crashes g++:
struct nullptr_type {
nullptr_type ( void ) {}
template typename T
operator T* ( void ) const {
return ( 0 );
}
} const nullptr;
int main ( void ) {
0 == nullptr;
}
g++ -v:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/specs
Configured
The simplest way to explain this is with an example. When compiling the
testcase below, g++ will report an error on lines 16, but it should report an
error on lines 18. If you change just about anything about this example, it
will report the correct line number (e.g. using non-template classes
--- Comment #1 from ceckak at alumni dot washington dot edu 2006-10-29
04:51 ---
Created an attachment (id=12505)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12505action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29633
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-29 05:16
---
Should we simply avoid the ice, perhaps accepting the invalid code or do we
want to search for duplicates in the DATA statements and generate an error?
Also,
Is this valid?:
real :: a(5,5)
DATA a(1,1), a(3,1),
65 matches
Mail list logo
