--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-29 06:50 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-29 06:48 ---
Confirmed, not 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-29 06:44 ---
Confirmed, we stopped ICEing sometime between 3.4.x and 4.0.0.
I am going to mark this as a regression, though I don't know if it should or
not.
The ICE has happened since at least 2.95.3.
--
pinskia at gcc dot g
--- 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),
--- 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=12505&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29633
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 fo
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 w
--- 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=gcc&view=rev&rev=118129
Log:
PR middle-end/29335
* builtins.c (do_mpfr_arg2,
--- 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 #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=gcc&view=rev&rev=118128
Log:
2006-10-28 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- 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 #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
AssignedTo|un
--- 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
AssignedTo|u
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |normal
GCC build triplet|i686-pc-linux-gnu |
GCC host t
--- 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 ov
--- 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 #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
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 <
--- 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 #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=gcc&view=rev&rev=118118
Log:
2006-10-28 Andrew Pinski <[EMAIL PROTECTED]>
PR C+
--- 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 #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
Status|A
--- 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=gcc&view=rev&rev=118117
Log:
2006-10-29 Dirk Mueller <[EMAIL PROTECTED]>
PR c++/
--- 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: i
--- 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 #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 #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=gcc&view=rev&rev=118113
Log:
fortran/
2006-10-28 Tobias Burnus <[EMAIL PROTECTED]>
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 stat
--- 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=gcc&view=rev&rev=118111
Log:
2006-10-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fortran/2
--- 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
AssignedTo|unassigned
--- 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
Status|ASSIGN
--- 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=12504&action=view)
preliminary patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29627
--- 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=gcc&view=rev&rev=118112
Log:
2006-10-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
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) ::
--- 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=gcc&view=rev&rev=118111
Log:
2006-10-28 Tobias Burnus <[EMAIL PROTECTED]>
PR fortra
`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 broke
--
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
--- 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|
--- 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:26 ---
Related to PR 21952.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29617
--
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 #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
tree-ssa-loop-niter.c:simplify_using_initial_cond
--- 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 #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
$ 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 --prefix=
--
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
--- 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
--- 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=gcc&view=rev&rev=118106
Log:
2006-10-28 Richard Guenther <[EMAIL PROTECTED]>
PR
--- 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 #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 n
--- 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
--
http://gcc.gnu.org/bugzilla/sh
--- 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 y
--- 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 errors).
--- 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 respecti
--- 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,...)
--
http://
--- 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,
--- 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 #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=gcc&view=rev&rev=118105
Log:
2006-10-28 Richard Guenther <[EMAIL PROTECTED]>
PR
--- 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 #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 #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 #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=gcc&view=rev&rev=118103
Log:
PR target/29377
* config/h8300/h8300.c (h8300_emit_
--- 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
AssignedTo|unassign
--- 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=gcc&view=rev&rev=118102
Log:
PR target/29377
* config/h8300/h8300.c (h8300_emit_
--- 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 b
--- 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 #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 (or
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
char buf[8] = {1,1,1,1,1,1,1,1};
char zero=0;
int main() {
int i;
68 matches
Mail list logo
