--- Comment #7 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-04-19 09:08 ---
Subject: Re: wrong types in array transfer
burnus at gcc dot gnu dot org wrote:
> --- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44
> ---
>> Nevertheless, the acc
--- Comment #8 from pault at gcc dot gnu dot org 2007-04-19 10:37 ---
(In reply to comment #7)
I am completely trapped by the workshop that I am running and have not even
managed to do what I promised last night. Realistically, it might have to wait
until the weekend. If you can devel
void
foo (int control2, unsigned long *state, int size)
{
int i;
for(i=0; i:;
D.1989_4 = (long unsigned int) i_1;
D.1990_5 = D.1989_4 * 8;
D.1991_6 = (long unsigned int *) D.1990_5;
D.1992_8 = D.1991_6 + state_7(D);
# VUSE
D.1993_9 = *D.1992_8;
D.1994_11 = D.1993_9 >> control2_1
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-19 12:08 ---
The patch in http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01075.html makes the
testcase ICE because of the type mismatch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19
---
Subject: Bug 29841
Author: ebotcazou
Date: Thu Apr 19 12:19:16 2007
New Revision: 123970
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123970
Log:
PR rtl-optimization/29841
* cfgbuild.c
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:19
---
Subject: Bug 29841
Author: ebotcazou
Date: Thu Apr 19 12:19:39 2007
New Revision: 123971
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123971
Log:
PR rtl-optimization/29841
* cfgbuild.c
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2007-04-19 12:21
---
Should work now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: [4.1 regression]
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gc
--- Comment #1 from jakub at gcc dot gnu dot org 2007-04-19 12:40 ---
struct S
{
long int l;
void *m;
};
int
foo (struct S *x)
{
unsigned long a;
a = x->l;
if (a <= ((void *) 0))
x->m = 0;
return 0;
}
ICEs at -O2 on both x86_64-linux and ppc-linux.
--
jakub at gcc d
--- Comment #2 from jakub at gcc dot gnu dot org 2007-04-19 12:56 ---
I'd say this is a frontend bug (in all of 4.1/4.2/4.3 at least), it shouldn't
have created
unit size
align 8 symtab 0 alias set -1 precision 1 min max >
arg 0
unit size
--- Comment #8 from tprince at computer dot org 2007-04-19 14:35 ---
4.2 branch appears to have the identical problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
--- Comment #3 from jakub at gcc dot gnu dot org 2007-04-19 14:58 ---
Actually a bug in fold-const.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #10 from pault at gcc dot gnu dot org 2007-04-19 15:20 ---
(In reply to comment #5)
> For the record, the problem Richard is pointing out is in the body of the
> function Up, namely in the expression for MERGE, probably caused by TRANSFER.
Duuh! You are right about where th
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-04-19 15:55
---
It's not blocking me atm as a different patch got accepted which doesn't expose
this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
--- Comment #2 from burnus at gcc dot gnu dot org 2007-04-19 16:16 ---
Analogously for character lengths:
program test
character(len=10) :: x
call foo(x)
write(*,*) 'X=',x
contains
subroutine foo(y)
character(len=20) ::
See:
% cat gcc-bug.c
int foo(void) {
int (*bar)(int);
return bar(33);
}
% gcc -c -Wall gcc-bug.c
^ NO WARNING
% gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr
--b
indir=/usr/x86_
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 17:24 ---
Use -O1 if you want to find unitialized variables (including function
pointers):
[pinskia-laptop:gcc/objdir-noboot/gcc] pinskia% ./cc1 -quiet -W -Wall t5.c -O1
t5.c: In function 'foo':
t5.c:4: warning: 'bar' is used
--- Comment #17 from opruz at centrum dot cz 2007-04-19 17:29 ---
4.1.2 -m32 -O2
.L6:
movl8(%ebp), %ebx
movl4(%edx), %ecx
movl-4(%ebx,%eax,4), %ebx
movl%ecx, -20(%ebp)
cmpl%ecx, %ebx
movl%ebx, -16(%ebp)
jle
--- Comment #3 from eduardo dot iniesta at aquiline dot es 2007-04-19
17:39 ---
(In reply to comment #1)
Thanks...
The exact version is:
$ gcj --version
gcj (GCC) 4.3.0 20061212 (experimental)
...
> Are you sure you are using gcj 4.3?
>
> I see a SEGV with 4.1 and 4.2. But with 4.
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 17:39 ---
Fixed by:
Author: echristo
Date: Wed Apr 18 23:27:51 2007
New Revision: 123960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123960
Log:
2007-04-18 Eric Christopher <[EMAIL PROTECTED]>
* config/rs
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
The macros TEXT_SECTION_ASM_OP, DATA_SECTION_ASM_OP, SDATA_SECTION_ASM_OP,
READONLY_DATA_SECTION_ASM_OP, CTORS_SECTION_ASM_OP, DTORS_SECTION_ASM_OP,
BSS_SECTION_ASM_OP and SBSS_SECTION_ASM_OP are used by
varasm.c:init_varasm_once
to pass their value to get_unnamed_section; the result of that functi
The -mno-vrsave switch as well as the old -mvrsave=no is ignored on 64bit
target.
Testcase is an empty file.
Results with powerpc64-unknown-linux-gnu-gcc -o a.s -c b.c -maltivec
-mno-vrsave -S -fverbose-asm -m64 into:
# rs6000/powerpc options: -msdata=none
.section".toc","aw"
.se
--- Comment #1 from amylaar at gcc dot gnu dot org 2007-04-19 19:27 ---
On second thought, the implementation is simpler when NULL is not treated
specially. But then there is a slight majority of the uses in the
config directory that wants the old behaviour of get_unnamed_section,
so it
red --enable-threads --disable-nls
--disable-multilib --enable-c99 --enable-long-long --enable-sjlj-exceptions
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java --enable-libada
--enable-boehm-gc
Thread model: win32
gcc version 4.2.0 20070419 (prerelease)
I have tried to report this using the o
--- Comment #1 from arcangelpip at hotmail dot com 2007-04-19 19:51 ---
Forgot to mention, it works the same as before. If the optimisations are
removed then it will compile, but if you have -O1 -O2 or -O3 in the command
line then it will ICE.
Also, if the dllimport is removed then it wi
--- Comment #2 from arcangelpip at hotmail dot com 2007-04-19 19:55 ---
Forgot to mention 2.
-_-; memory is getting worse, I'm sure of it.
Command line used. With the executable in the path.
i686-pc-mingw32-gcc -c -O2 -o test.o test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #3 from bangerth at dealii dot org 2007-04-19 20:06 ---
Confirmed. This is a regression on at least mainline. I don't
have my set of compilers around here to verify if it is also a
regression on 4.1 and 4.2.x. It seems to work with 4.0.x.
W.
--
bangerth at dealii dot or
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:08 ---
This appears fixed since gcc 3.4.x.
--
bangerth at dealii dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
GCC target triplet
--- Comment #2 from bangerth at dealii dot org 2007-04-19 20:10 ---
Fixed since 4.0.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-19 20:15 ---
(In reply to comment #3)
> Confirmed. This is a regression on at least mainline. I don't
> have my set of compilers around here to verify if it is also a
> regression on 4.1 and 4.2.x. It seems to work with 4.0.x.
For the program
program main
implicit none
real :: xx
double precision :: yy
call random_seed()
call random_number(yy)
xx = yy ! assign double to single
print*,"yy =",yy
print*,"xx =",xx
end program main
g95 -Wall -Wextra says
In file xreal_dp.f90:7
xx = yy
1
Warning (140): Implicit conver
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 20:47 ---
(In reply to comment #1)
This does the trick but I haven't checked against the standard, nor have I
regtested.
Paul
Index: /svn/trunk/gcc/fortran/check.c
=
--- Comment #15 from tkoenig at gcc dot gnu dot org 2007-04-19 21:03
---
(In reply to comment #14)
> (In reply to comment #13)
> > The tree stuff is hard, btw. Still trying :-)
>
> Tree stuff? Do we generate inline code?
We generate inline code for rank 0 minval and minloc, i.e.
r
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-04-19 21:35 ---
(In reply to comment #2)
> Confirming. g77 does not do it right either. :)
gfortran 4.1 doesn't get this right either, so at least
this isn't a regression. Uff :-)
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 ---
*** This bug has been marked as a duplicate of 27866 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-04-19 21:45 ---
*** Bug 31637 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-19 22:42 ---
module a
end module a
use a
end
How are you going to handle this? There's no meaningful syntax checking
without also creating modules. One could maybe create the modules in a
temporary place?
--
tobi at gcc dot
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-19 22:44
---
Simply fixing the doc is also fine with me :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31612
--- Comment #1 from kkojima at gcc dot gnu dot org 2007-04-20 00:05 ---
I've confirmed that the testcase doesn't fail with 3.4 compiler
and fails with 4.0, 4.1 and 4.2. Although it doesn't fail with
the current trunk compiler, it might be simply latent. The segfault
occurs in insn_curr
[ Forwarded from http://bugs.debian.org/382153 This issue has been reported
by Margarita Manterola who also provided the testcase ]
If you compile the following testcase with -Wcast-align you get a warning
on certain architectures, including alpha, arm, hppa, ia64 and sparc.
I've verified this o
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-20 00:49 ---
I think this is really the same as PR 19495.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[ forwarded from http://bugs.debian.org/401496 The report and original
testcase came from Jonathan Stott. I further reduced it down in size. ]
I've confirmed this bug with 4.1.2 20061115 and 4.3.0 20070326.
(sid)18753:[EMAIL PROTECTED]: ~/src/t] gfortran -c c.f90
c.f90: In function âxstrcmpâ
--- Comment #1 from brooks at gcc dot gnu dot org 2007-04-20 01:52 ---
This is invalid code, since initialization expressions must be constants, and
the length of an assumed-length string argument is not a constant. Regardless,
we shouldn't be ICE'ing on it.
--
brooks at gcc dot gnu
--- Comment #11 from bdavis at gcc dot gnu dot org 2007-04-20 03:41 ---
i think not. i must have confued myself (rather easy to do!). will dig
through the source this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
--- Comment #13 from patchapp at dberlin dot org 2007-04-20 07:45 ---
Subject: Bug number PR 27740
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/2007-04/msg01253.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #14 from jb at gcc dot gnu dot org 2007-04-20 07:45 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01253.html
Also removed the dependency on PR25709 (ISO_C_BINDING), since we don't depend
on that one anymore for this functionality.
--
jb at gcc dot gnu dot
--- Comment #14 from dannysmith at users dot sourceforge dot net
2007-04-20 07:49 ---
(In reply to comment #13)
> I'm going to try again since it seems my last post was just ignored.
> The test case works fine on 4.2 but it still occurs under some circumstances.
If you provide preproce
49 matches
Mail list logo
