--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-09 06:00 ---
Alias analysis can handle a-b now and we also fold during forwprop * a-b
into a-b so it might be a good idea to have this fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23401
--- Comment #5 from ubizjak at gmail dot com 2007-07-09 06:01 ---
(In reply to comment #4)
Confirmed, still regression on 4.2 branch.
Actually, already fixed on 4.2.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 06:08 ---
Related to PR 32685.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 06:17 ---
This has been fixed for 4.3.0:
vspltisw v0,2
stvx v0,0,r2
(insn 10 21 29 t34.c:8 (set (reg:V4SF 77 v0 [125])
(const_vector:V4SF [
(const_double:SF
Reading signed bitfield value when it needs to be extended to larger type (for
example assigning 24-bit value to int) results in zero extending instead of
sign extending when compiled with g++ using optimizations (-O1 or higher).
Compiling the same code with gcc or disabling optimizations makes
--- Comment #2 from irar at il dot ibm dot com 2007-07-09 06:22 ---
I guess it's an if-cvt problem - nothing gets vectorized (and I also disabled
the vectorizer to be sure), and if-cvt is applied on function aa_renderpalette
(where it ICEs later).
Ira
--
irar at il dot ibm dot com
When two separate Dynamic Shared Objects (DSO's) are using the same static
object with the same name and each of them keeps a local copy of that object.
When the application gets loaded that objects constructor is called twice for
the same instance and the destructor is also called twice when the
--- Comment #1 from ranc at mobixell dot com 2007-07-09 07:07 ---
Created an attachment (id=13874)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13874action=view)
gzipped tar ball of a sample code
The is the sample code problem, execute from bash the compile.bash script:
.
--- Comment #2 from ranc at mobixell dot com 2007-07-09 07:08 ---
Attached is a gzipped tag ball with a sample problem.
just execute from bash the compile.bash script and execute ./main .
(I use RHEL 4.0)
[EMAIL PROTECTED] test]$ g++ --version
g++ (GCC) 3.4.5 20051201 (Red Hat
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 07:12 ---
This is not a bug in GCC, you are violating the One Definition Rule which does
not need any diagnostic.
Actually there are two violations, first the class Common are different between
the TUs.
Second you have two
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 07:17 ---
Works on the trunk correctly.
Related to PR 31136.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 07:35 ---
Actually the RTL issue was fixed up by subreg2 pass.
So closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 07:40 ---
Fixed at -O2 but not at -O1 and the code looks worse there too (I think
because we disable tail call optimization at -O1).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Hi,
the following snippet
program gfcbug67
implicit none
type mytype
integer, pointer :: i(:) = NULL ()
end type mytype
type(mytype) :: t
print *, size (transfer (1, t% i))
end program gfcbug67
fails to compile with:
gfcbug67.f90:9.17:
print *, size (transfer (1, t% i))
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 08:03 ---
This was all fixed in 4.3.0 by a couple of patches, I forget if it was
backported to 4.2.x or not.
Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-09 08:06
---
Ok, I guess I blew looking at this for a year. Too busy with work really :).
Anyways maybe next weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-07-09 08:15 ---
Note: The program fails with
call sub(c+f())
where c is a parameter and dimensions of c and f are (2,2). If one has
dimension(2) it works.
Working with 2007-05-08-r124539, failing with
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:19 ---
Here is a patch for the C front-end:
Index: c-typeck.c
===
--- c-typeck.c (revision 126424)
+++ c-typeck.c (working copy)
@@ -7881,7 +7898,9 @@
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 08:24 ---
And one for the C++ front-end:
Index: typeck.c
===
--- typeck.c(revision 126424)
+++ typeck.c(working copy)
@@ -3213,7 +3213,9 @@
case
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:31 ---
Patch (which needs testing):
Index: c-typeck.c
===
--- c-typeck.c (revision 126424)
+++ c-typeck.c (working copy)
@@ -2825,7 +2825,9 @@
break;
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-09 08:34 ---
This should be warned by -Wsequence-points.
It is kinda of hard to know if the two function calls will be invoked and
modify the global state.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12411
--- Comment #3 from pcarlini at suse dot de 2007-07-09 08:43 ---
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 headers.
Please double check in this light, thanks.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:50 ---
I have a patch for this when I get back in August.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 08:51 ---
This is still true as of today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:00 ---
Mine, patch (which needs full testing):
Index: config/rs6000/rs6000-c.c
===
--- config/rs6000/rs6000-c.c(revision 126424)
+++
gcc version 4.2.1 20070628
make profiledbootstrap
...
Configuring in i686-pc-linux-gnu/boehm-gc
...
checking for i686-pc-linux-gnu-strip... strip
updating cache ./config.cache
/bin/sh: /root/downloads/gcc-4_2-branch/boehm-gc/ltconfig: No such file or
directory
configure: error: libtool configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:03 ---
Still happens today:
t3.cc:1: internal compiler error: in add_const_value_attribute, at
dwarf2out.c:10119
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 09:10 ---
From docs:
RESULT = TRANSFER(SOURCE, MOLD[, SIZE])
The result has the same type as MOLD, with the bit level representation of
SOURCE. If SIZE is present, the result is a one-dimensional array of length
SIZE. If
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-07-09 09:15
---
Here is a new testcase which shows the problem on the trunk on powerpc-darwin:
struct s
{
int i1:1;
int i2:1;
};
void f(struct s *x, struct s *y) { *x = *y; }
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-09 09:18 ---
Confirmed, this is now on the trunk.
http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00395.html
FAIL: gcc.dg/vect/vect-103.c scan-tree-dump-times vectorized 1 loops 1
FAIL: gcc.dg/vect/vect-103.c
Testcase:
float
quantum_real(float _Complex a)
{
float *p = (float *) a;
return p[0];
}
float
quantum_imag(float _Complex a)
{
float *p = (float *) a;
return p[1];
}
--- CUT -
Even though the above are optimized at the RTL level, it would be nice if we
could get them optimized at
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:34 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 09:38 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 09:50 ---
It does:
function2:
.LFB3:
callfunction1
movsbl %al,%eax
ret
because this is what the C ABI specifies. Now, the stack adjustments are
indeed superfluous. And we fail to tailcall as
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-09 09:54 ---
So I just applied it and now we get
function1:
.LFB2:
movl$10, %eax
ret
function2:
.LFB3:
movqpfunc(%rip), %r11
jmp *%r11
for the indirect call. Fixed.
--
rguenth
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-09 10:00 ---
It builds a TRUTH_AND_EXPR with second operand NULL_TREE ... in
#1 0x008a3d96 in find_phi_replacement_condition (loop=0x2ac838a04320,
bb=0x2ac8389a7480, cond=0x7fff72b2f308, bsi=0x7fff72b2f2f0)
at
--- Comment #4 from ubizjak at gmail dot com 2007-07-09 10:15 ---
(In reply to comment #3)
where first_edge-aux is NULL.
Looking into it.
Reduced testcase is:
--cut here--
int aa_renderpalette (int p)
{
int y = 42;
int i;
for (i = 0; i 256; i++)
{
if (y 255)
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-09 10:18 ---
Emit a warning if an unused parameter is found (-Wunused/-Wall), currently
regtesting:
Index: trans-decl.c
===
--- trans-decl.c(revision
--- Comment #5 from ubizjak at gmail dot com 2007-07-09 10:23 ---
It's a copy'n'pasto. Attached patch fixes the failure:
Index: tree-if-conv.c
===
--- tree-if-conv.c (revision 126478)
+++ tree-if-conv.c (working
--- Comment #2 from jwakely dot gcc at gmail dot com 2007-07-09 10:30
---
I'm seeing the same with this configuration:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: $SRCS/gcc/gcc-4.1.1/configure --prefix=$DEST/gcc/4.1.1-64bit
--with-gnu-as
--- Comment #3 from jwakely dot gcc at gmail dot com 2007-07-09 10:35
---
In reply to comment #2:
actually, the sparc64-sun-solaris2.8 problem could be slightly different and I
can't confirm it now
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32415
--- Comment #6 from aph at gcc dot gnu dot org 2007-07-09 10:36 ---
_ZN4java4lang12PosixProcess9queueLockE is defined in the assembly source:
.globl _ZN4java4lang12PosixProcess9queueLockE
.bss
.align 4
.type _ZN4java4lang12PosixProcess9queueLockE, @object
The attached testcase just produces warning or errors (depending on gcc
version) for func1, func3 and func5:
testwarning.c:5: error: static declaration of func1 follows non-static
declaration
testwarning.c:3: error: previous declaration of func1 was here
testwarning.c:25: error: static
--- Comment #2 from patchapp at dberlin dot org 2007-07-09 12:10 ---
Subject: Bug number PR31129
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-07/msg00776.html
--
Hi,
Compiling following testcase for h8sx target with optimization (-O1
onwards), gives ICE (internal compiler error) . The testcase works fine
for other H8 targets.
// Start Of Testcase
===
#include stdlib.h
typedef union
{
--- Comment #1 from sirl at gcc dot gnu dot org 2007-07-09 12:15 ---
Since attaching files doesn't seem to work right now, here a copy'n'paste:
extern int func1 (int);
static int func1 (int);
static int func1 (int in)
{
return in;
}
static int func2 (int);
extern int func2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-09 12:16 ---
I thought we already decided the other way around should not error or warn.
From gcc.dg/local1.c which is testing this exactly:
C90 6.1.2.2 [as corrected by TC1], C99 6.2.2:
For an identifier
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-09 12:16 ---
*** Bug 32692 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pcarlini at suse dot de 2007-07-09 12:35 ---
Paolo agreed in private email to work on it (many thanks again!)
--
pcarlini at suse dot de changed:
What|Removed |Added
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c = 0)
{
if (x (WordS64) 0x7FFFll - c)
return 6;
}
else if (x
--- Comment #4 from aribrei at arcor dot de 2007-07-09 12:39 ---
I should note that I do NOT want to see this bug fixed. I would prefer to hear
that you won't fix it at all. So I can exploit this behavior as there is no
standards-compliant way of achieving the same results.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-09 12:46 ---
which target? I cannot reproduce this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c = 0)
{
if (x (WordS64) 0x7FFFll - c)
return 6;
}
else if (x
typedef signed long long int WordS64;
typedef unsigned long long int Word64;
int
foo (Word64 *p)
{
while (1)
{
WordS64 c = 0x1llu;
WordS64 x = *p;
if (c = 0)
{
if (x (WordS64) 0x7FFFll - c)
return 6;
}
else if (x
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-09 12:52 ---
x86_64-linux.
Rebuilding gcc 4.2 with --enable-checking yields a verify_stmt failure already
after ccp, which changes
WordS64D.1870 xD.1876;
long long intD.5 D.1879;
...
D.1879_7 = 9223372036854775807 -
--- Comment #3 from jakub at gcc dot gnu dot org 2007-07-09 12:53 ---
*** Bug 32695 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-09 12:53 ---
Oops, sorry.
*** This bug has been marked as a duplicate of 32694 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-09 12:54 ---
Oops, sorry.
*** This bug has been marked as a duplicate of 32694 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-09 12:54 ---
*** Bug 32696 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-09 12:56
---
Related: PR31447 - set intent(out) arguments to uninitialized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
--- 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
--- 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=gccview=revrev=126482
Log:
PR tree-optimization/32681
* tree-if-conv.c
--- 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=gccview=revrev=126483
Log:
PR tree-optimization/32681
* tree-if-conv.c
--- 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
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
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 since
--- 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=gccview=revrev=126484
Log:
PR tree-optimization/32681
* tree-if-conv.c
--- 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 #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 #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 #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
--- 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=13875action=view)
patch
With the proposed patch mainline generates again
foo:
pushl %ebp
movl%esp, %ebp
--- 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
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
--- Comment #2 from sorenj at us dot ibm dot com 2007-07-09 13:55 ---
Please refer to
https://sourceforge.net/tracker/?func=detailatid=101645aid=1560993group_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
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 #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
--- 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.
--
--- 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 counts
--- 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 #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 #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.
--
For the code
program main
character (len=1) :: word
word = dog
print*,word =,word
end program main
compiled with
U:\vrao\fortrangfortran -v xbug.f90
Driving: gfortran -v xbug.f90 -lgfortranbegin -lgfortran
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure
--- 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=gccview=revrev=126486
Log:
gcc/fortran:
2007-07-09 Daniel Franke [EMAIL PROTECTED]
--- 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 #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
--- 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 #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
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
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-mingw32
--- 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)
--- 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=gccview=revrev=126487
Log:
2007-07-09 Paolo Bonzini [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=126488
Log:
2007-07-09 Paolo Bonzini [EMAIL PROTECTED]
PR
--- 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
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 #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.
--
1 - 100 of 159 matches
Mail list logo
