--- Comment #3 from ubizjak at gmail dot com 2007-07-10 06:46 ---
(In reply to comment #1)
> "X" constraint means anything matches. Now why we are ICEing is a bit weird
We hit:
/* We have patterns that allow zero sets of memory, for instance.
In 64-bit mode, we should p
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-10 06:37
---
*** Bug 32709 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-10 06:37 ---
*** This bug has been marked as a duplicate of 20520 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-10 06:23 ---
I think this is indeed no bug. I contacted NAG f95 and if they found something
in the standard which we overlooked, I will reopen this PR.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-07-10 05:59
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-10 05:37
---
Subject: Bug 32702
Author: jvdelisle
Date: Tue Jul 10 05:37:29 2007
New Revision: 126510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126510
Log:
2007-07-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from pault at gcc dot gnu dot org 2007-07-10 05:15 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-10 05:13 ---
Fixed on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-10 05:12 ---
Fixed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-10 05:11 ---
Subject: Bug 32689
Author: pault
Date: Tue Jul 10 05:11:00 2007
New Revision: 126509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509
Log:
2007-07-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-10 05:11 ---
Subject: Bug 32634
Author: pault
Date: Tue Jul 10 05:11:00 2007
New Revision: 126509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509
Log:
2007-07-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-10 05:11 ---
Subject: Bug 32157
Author: pault
Date: Tue Jul 10 05:11:00 2007
New Revision: 126509
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126509
Log:
2007-07-10 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from rob1weld at aol dot com 2007-07-10 04:55 ---
>--- Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] ---
>Note that in 4.3 the header dependencies have been streamlined and it's well
>possible that some projects around are failing to include required head
--- Comment #6 from rob1weld at aol dot com 2007-07-10 04:31 ---
>Comment #5 From Paolo Carlini 2007-07-09 21:19 [reply] ---
>The last issue simply doesn't make sense.
On page http://gcc.gnu.org/bugs.html#need it says:
"the preprocessed file (*.i*) that triggers the bug, generated
--- Comment #1 from pedro dot lamarao at mndfck dot org 2007-07-10 01:33
---
Just to note I'm aware of the bug.
I'll take a look at it soon but unfortunately not too soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32676
--- Comment #4 from kkojima at gcc dot gnu dot org 2007-07-10 01:02 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-07-10 01:01 ---
Subject: Bug 32664
Author: kkojima
Date: Tue Jul 10 01:01:11 2007
New Revision: 126507
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126507
Log:
PR rtl-optimization/32664
* mode-switching.c
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-10 00:39
---
Got it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-10
00:04 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
> The problem that i have is it the argument pointer does not have a fixed
> value.
--- Comment #2 from scovich at gmail dot com 2007-07-09 23:27 ---
(In reply to comment #1)
> "X" constraint means anything matches. Now why we are ICEing is a bit weird.
I started using it because "g" doesn't seem to allow xmm references.
Fortunately, "xm" seems to have the desired eff
--- Comment #11 from appfault at hotmail dot com 2007-07-09 23:21 ---
I've been unable to reproduce any issues in 3.4.6, even with tests that do not
rely on the empty string. I suspect there is something more specific that was
fixed somewhere between 3.3.x and 3.4.6.
It doesn't seem ap
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 22:59 ---
"X" constraint means anything matches. Now why we are ICEing is a bit weird.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32711
Compiling the following functions with gcc-4.{1,2,3} results in an ICE.
gcc-3.4.4 does not ICE:
#include
static inline
__m128i my_asm(__m128i a, __m128i b) {
__m128i result;
asm("pshufb\t%1,%0" : "=x"(result) : "X"(b), "0"(a));
return result;
}
__m128i foo(__m128i src) {
return my_asm(
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-09 22:42 ---
Oh dear - that's right. I feel a temporary coming on!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-07-09 22:40 ---
(In reply to comment #2)
Whilst I agree that this is a regession, it is so because an underlying bug is
exposed - in other words, r124541 is perfectly correct.
The following also fails:
program matrix
implicit none
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-07-09 22:35 ---
Fixed on trunk. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-07-09 22:35 ---
Subject: Bug 32336
Author: tkoenig
Date: Mon Jul 9 22:34:43 2007
New Revision: 126498
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126498
Log:
2007-07-09 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-09 22:34 ---
If one moves "subroutine name()" before "readinput", valgrind shows no
problems. (And no ICE occurs with 4.2 and 4.1.)
This occures for dt->namelist->name, which is "name" (len 4)
==18422==at 0x4A3FB2: build_dt (
--- Comment #18 from zadeck at naturalbridge dot com 2007-07-09 22:28
---
Subject: Re: [4.3 Regression] checking for suffix of
object files... configure: error: cannot compute suffix of f object files:
cannot compile
dave at hiauly1 dot hia dot nrc dot ca wrote:
> --- Comment #1
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-09 22:03
---
With the initial testcase:
module foo_mod
implicit none
contains
subroutine print_sub(fmt_acf,iu,labels)
character (len=*), intent(in), optional :: fmt_acf
integer , intent(in), optional :: iu
character
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-09
22:01 ---
Subject: Re: [4.3 Regression] checking for suffix of object files...
configure: error: cannot compute suffix of f obje
> --- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 ---
> Looking
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-07-09 22:01
---
Subject: Bug 29459
Author: fxcoudert
Date: Mon Jul 9 22:00:52 2007
New Revision: 126496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126496
Log:
PR fortran/29459
* trans-array.c (gfc_tr
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-09 21:57 ---
Works for me with 4.3.0; I can reproduce the ICE with 4.2 and 4.1.
valgrind with 4.3.0 shows:
==18422== Invalid read of size 8
==18422==at 0x4A3FB2: build_dt (trans-io.c:1592)
==18422==by 0x47819E: gfc_trans_
program samename
contains
subroutine readInput
implicit none
integer:: a,b,c
NAMELIST /name/ a,b,c
read(5,nml=name)
end subroutine readInput
subroutine name()
end subroutine name
end program
this code fails with the following error (gfortran 4.3 and 4.1.3):
samena
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-09 21:33 ---
(In reply to comment #1)
How wierd and wonderful - whilst it is a regression, it is only just; given the
timing of gfc_array_transfer and gfc_simplify_transfer, the latter undid the
former by only a few months or so:)
--- Comment #5 from pcarlini at suse dot de 2007-07-09 21:19 ---
(In reply to comment #4)
> >Comment #2 From Andrew Pinski 2007-07-09 02:53 [reply] ---
> >No include for or .
>
> Andrew, I'm not an expert at C++ but I did my best to attempt to make a couple
> of reduced testcases
NAG f95 does:
Error: foo.f90, line 45: ALLOCATABLE array NCOSET used but never ALLOCATEd
gfortran does not detect this. Testcase, see PR 31683.
--
Summary: Diagnose: ALLOCATABLE array used but never ALLOCATEd
Product: gcc
Version: 4.3.0
Status: UNCON
Consider the following functions (compiled with "g++-4.1.2 -msse3 -O3"):
#include
__m128i int2vector(int i) { return _mm_cvtsi32_si128(i); }
int vector2int(__m128i i) { return _mm_cvtsi128_32(i); }
__m128i long2vector(long long i) { return _mm_cvtsi64x_si128(i); }
long long vector2long(__m128i) {
--- Comment #16 from bonzini at gnu dot org 2007-07-09 21:04 ---
Looking out of the box, why can't we add it always, the same as we do with the
frame and stack pointer?? I wonder if the fixed/variable thing is a red
herring.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
--- Comment #4 from rob1weld at aol dot com 2007-07-09 21:01 ---
>Comment #2 From Andrew Pinski 2007-07-09 02:53 [reply] ---
>No include for or .
Andrew, I'm not an expert at C++ but I did my best to attempt to make a couple
of reduced testcases where I felt I was able. BOTH those
--- Comment #1 from rob1weld at aol dot com 2007-07-09 20:27 ---
A few hours later and it failed for want of ltcf-c.sh and ltcf-cxx.sh. I ran
gcc_update again and that fixed the configure / makefile problem of not copying
those files over.
There is still the annoyance of the build re-st
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-09 19:42 ---
Subject: Bug 32698
Author: rguenth
Date: Mon Jul 9 19:41:54 2007
New Revision: 126494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126494
Log:
2007-07-09 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #4 from geoffk at gcc dot gnu dot org 2007-07-09 19:34 ---
'external linkage' is not the same thing as 'the declaration contains the
keyword "extern"'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32692
--- Comment #18 from aoliva at gcc dot gnu dot org 2007-07-09 19:24 ---
Subject: Bug 23551
Author: aoliva
Date: Mon Jul 9 19:24:23 2007
New Revision: 126492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126492
Log:
Revert:
2007-07-06 Alexandre Oliva <[EMAIL PROTECTED]>
PR de
--- Comment #16 from uros at gcc dot gnu dot org 2007-07-09 19:22 ---
Subject: Bug 27855
Author: uros
Date: Mon Jul 9 19:22:03 2007
New Revision: 126491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126491
Log:
PR target/27855
* doc/extend.texi: Add ftree-reass
--- Comment #2 from jaydub66 at gmail dot com 2007-07-09 19:17 ---
I checked it: The ICE is really introduced by rev. 124541.
> r124541 | pault | 2007-05-08 13:58:25 +0200 (Tue, 08 May 2007) | 18 lines
> PR 29397, PR 29400
> * decl.c (add_init_expr_to_sym): Expand a scal
--- Comment #1 from vivekrao4 at yahoo dot com 2007-07-09 19:05 ---
Gfortran also does not warn about the simpler code
program xtrim_array
! check if compiler catches character array constructor with elements of
different sizes
implicit none
character (len=4) :: xx(2)
xx = ["boy","girl"
For the following invalid code
program xtrim_array
implicit none
character (len=4) :: xx(2)
xx = [trim("boy "),trim("girl")] ! invalid -- elements have different lengths
print*,"xx = '" // xx(1) // "' '" // xx(2) // "'"
end program xtrim_array
compiling and running with gfortran gives
gfortran
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||4.3.0
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||19276
nThis||
Keyw
--- Comment #1 from langton at gcc dot gnu dot org 2007-07-09 18:32 ---
Confirmed. The segfault occurs on trans-array.c:1380 because e->ts->cl is
null.
--
langton at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from hp at gcc dot gnu dot org 2007-07-09 18:30 ---
>From revision 126479 (in the range 126472..126429), the bug is again hidden.
There's a libstdc++-v3/include/bits/stl_algo.h tweak in that range that
apparently sufficiently changed the code.
--
http://gcc.gnu.org/b
--- Comment #15 from ubizjak at gmail dot com 2007-07-09 18:16 ---
New timings on x86_64 core2 (from [1])
The tests were performed on core2 in 64bit mode, using '-DREPS=1 -O3 -msse3
-march=core2 -ffast-math' flags, with and without newly introduced
-fno-tree-reassoc flag.
The resul
GCJ -M is producing an empty dependency list vis:
package frysk4742;
class Referee
{
static int i;
int j;
Referee() {
j = i++;
}
}
package frysk4742;
class Referer {
static public void main(String[] args) {
new Referee();
}
}
gcj -M frysk4742/Referer.java
a
> c97205b
> c97305a c97305b c97305c c97305d c974002 c974003 c974008 c974009 c974010
> c974011
> cc1207b cc3019c cd92001 ce2103a ce2201l ce2202a ce3815a cxh1001
>
> nearly all of them are of the form
>
> +===GNAT BUG DETECTED===
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-09 18:11 ---
Subject: Re: [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
Uh, this assert was removed, so i don't know how it could still trigger ;)
On 9 Jul 2007 17:36:22 -, ebotcazou at gcc dot gnu dot
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 18:10 ---
I asked for it, seems to be me who is going to document it :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:52 ---
I can fix this...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned a
--- Comment #7 from ro at techfak dot uni-bielefeld dot de 2007-07-09
17:48 ---
Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
aph at gcc dot gnu dot org writes:
> So, the question is why the linker is complaining that "a GOT relative
> relocation must refere
--- Comment #8 from zippel at gcc dot gnu dot org 2007-07-09 17:42 ---
(In reply to comment #7)
> On the backend side we have the fwprop pass which is supposed to do
> addressing mode selection and the backend which is supposed to provide
> accurate costs for them.
Let's take your propo
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-09 17:36
---
Confirmed on platforms where the Ada compiler bootstraps at all. :-)
I plan to look at them once I've found something plausible for PR 32589.
--
ebotcazou at gcc dot gnu dot org changed:
What|
--- Comment #1 from pcarlini at suse dot de 2007-07-09 17:07 ---
Cannot be reproduced anymore. If people want me to add the testcase to be safe,
just let me know.
--
pcarlini at suse dot de changed:
What|Removed |Added
-
==+
| 4.3.0 20070709 (experimental) (x86_64-unknown-linux-gnu) GCC error: |
| in set_ssa_val_to, at tree-ssa-sccvn.c:1022 |
| Error detected around ae2113b.adb:33 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html
--- Comment #15 from bonzini at gnu dot org 2007-07-09 16:31 ---
Note that this:
> Before the dataflow merge, the argument pointer was always included
> in "Registers live at start".
... was because uninitialized registers always showed up as live at start
before DF merge.
--
http
PR 31400 added -static-libgfortran, but a documentation is missing.
(One should probably also update
http://gcc.gnu.org/wiki/GFortranGettingStarted)
--
Summary: -static-libgfortran is undocumented
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #32 from bonzini at gnu dot org 2007-07-09 15:38 ---
additional fix committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|REOPE
--- Comment #31 from bonzini at gnu dot org 2007-07-09 15:38 ---
Subject: Bug 32004
Author: bonzini
Date: Mon Jul 9 15:37:56 2007
New Revision: 126488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126488
Log:
2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--- Comment #30 from bonzini at gnu dot org 2007-07-09 15:37 ---
Subject: Bug 32004
Author: bonzini
Date: Mon Jul 9 15:37:32 2007
New Revision: 126487
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126487
Log:
2007-07-09 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--- Comment #7 from rguenther at suse dot de 2007-07-09 15:37 ---
Subject: Re: [4.3 regression] inefficient
pointer expression
On Mon, 9 Jul 2007, zippel at gcc dot gnu dot org wrote:
> (In reply to comment #5)
> > as you suggest creates worse assembly (look at the extra shift)
> >
For the program
program array_char
implicit none
character (len=1) :: x
x = "a"
print*,[trim(x)]
end program array_char
compiling on Windows XP with
gfortran -v xconcat.f90
produces an ICE:
Driving: gfortran -v xconcat.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw3
--- Comment #6 from zippel at gcc dot gnu dot org 2007-07-09 15:27 ---
(In reply to comment #5)
> as you suggest creates worse assembly (look at the extra shift)
>
> foo:
> pushl %ebp
> movl%esp, %ebp
> movl12(%ebp), %ecx
> movl8(%ebp), %edx
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 15:08 ---
Confirmed. Presumely a buffer overflow in the library.
If len==8192, valgrind does not report any errors.
If len > 8192:
===30988== Invalid write of size 1
==30988==at 0x4022D8E: memcpy (mc_replace_strmem.c:40
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 15:00 ---
Closing again. This time, I mean it.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-09 15:00 ---
Note that we don't hoist the i*4 or the addition to p to help addressing mode
selection which likes to see the "whole" address.
Of course it shouldn't matter in which form we see the addresses and the same
code shou
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-09 14:58 ---
Fixed in trunk. Not a regression, no backport. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-09 14:57 ---
Subject: Bug 31129
Author: dfranke
Date: Mon Jul 9 14:56:49 2007
New Revision: 126486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126486
Log:
gcc/fortran:
2007-07-09 Daniel Franke <[EMAIL PROTECTED]>
For the code
program main
character (len=1) :: word
word = "dog"
print*,"word =",word
end program main
compiled with
U:\vrao\fortran>gfortran -v xbug.f90
Driving: gfortran -v xbug.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure
--- Comment #4 from zippel at gcc dot gnu dot org 2007-07-09 14:40 ---
IMHO something like this should be generated:
p2 = p + (i * 4);
return (*(p2 + 4) + *(p2 + 8) + *(p2 + 12));
Right now not even the (i*4) expression is removed from the last instruction
anymore.
--
http://gcc.g
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 ---
*** This bug has been marked as a duplicate of 32157 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-09 14:25 ---
*** Bug 32699 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32157
--- Comment #15 from sebpop at gmail dot com 2007-07-09 14:19 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
> I was going to submit the attached patch, but now the analysis fails with
> "affine-affine test failed: missing iteration coun
--- Comment #3 from Dries dot Decock at excentis dot com 2007-07-09 14:07
---
Thanks for the reply.
I will use the -fno-strict-aliasing for now, and hope that the SWIG maintainers
will fix this problem in the near future.
Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from Dries dot Decock at excentis dot com 2007-07-09 14:06
---
Sorry, dup
--
Dries dot Decock at excentis dot com changed:
What|Removed |Added
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **
--- Comment #2 from sorenj at us dot ibm dot com 2007-07-09 13:55 ---
Please refer to
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1560993&group_id=1645
Long story short - as it stands today: C++ standards team won't change the spec
to allow type punning, gcc team won't
When I compile the program listed below I get the message:
al1.f90:4.17:
SUBROUTINE len(i)
1
al1.f90:2.4:
i = len(" ")
2
Error: Global name 'len' at (1) is already being used as a FUNCTION at (2)
For what it's worth:
1. g95, Compaq, and Lahey Fortran do not consider it an erro
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 13:42 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-09 13:41 ---
Created an attachment (id=13875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13875&action=view)
patch
With the proposed patch mainline generates again
foo:
pushl %ebp
movl%esp, %ebp
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 13:39 ---
With 2.95, 3.3.6 and 3.4.6 I get (for 32bit):
foo:
pushl %ebp
movl %esp,%ebp
movl 8(%ebp),%edx
movl 12(%ebp),%eax
movl %ebp,%esp
popl %ebp
movl 8(%edx,%eax,4),
--- Comment #9 from ubizjak at gmail dot com 2007-07-09 13:36 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #117 from schwab at suse dot de 2007-07-09 13:35 ---
*** Bug 32697 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
---
--- Comment #1 from schwab at suse dot de 2007-07-09 13:35 ---
Report this to the SWIG maintainers. This is violating the C/C++ aliasing
rules.
*** This bug has been marked as a duplicate of 21920 ***
--
schwab at suse dot de changed:
What|Removed
--- Comment #8 from uros at gcc dot gnu dot org 2007-07-09 13:32 ---
Subject: Bug 32681
Author: uros
Date: Mon Jul 9 13:31:46 2007
New Revision: 126484
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126484
Log:
PR tree-optimization/32681
* tree-if-conv.c (find_p
Taking this example:
int foo(int *p, unsigned int i)
{
return p[i + 1] + p[i + 2] + p[i + 3];
}
produces inefficient code. The problem already starts at tree level, where for
"p[i+1]" an expression like *(p + (i + 1) * 4)) is generated, which is not a
common pointer expression.
Also sinc
Hi,
I'm using SWIG to combine Java and C++ code. At some point, SWIG generates a
method like this :
1SWIGEXPORT jlong JNICALL Java_com_excentis_products_X_XUpcast(JNIEnv *jenv,
jclass jcls, jlong jarg1) {
jlong baseptr = 0;
(void)jenv;
(void)jcls;
*(Flow **)&baseptr = *(TcpFlow **
--- Comment #3 from sirl at gcc dot gnu dot org 2007-07-09 13:15 ---
Sorry, apparently I forgot to search 'All' bugs instead of just the 'Open' ones
yesterday.
One question though, how does the func6() part of the testcase relate to all
this? For this one there is no 'extern' specifier
--- Comment #7 from uros at gcc dot gnu dot org 2007-07-09 13:11 ---
Subject: Bug 32681
Author: uros
Date: Mon Jul 9 13:11:22 2007
New Revision: 126483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126483
Log:
PR tree-optimization/32681
* tree-if-conv.c (find_p
--- Comment #6 from uros at gcc dot gnu dot org 2007-07-09 13:00 ---
Subject: Bug 32681
Author: uros
Date: Mon Jul 9 13:00:19 2007
New Revision: 126482
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126482
Log:
PR tree-optimization/32681
* tree-if-conv.c (find_p
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 12:56 ---
Related: PR28004 - "Warn if intent(out) dummy variable is used before being
defined"
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 156 matches
Mail list logo
