--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-07-07 06:22
---
We have addressed this in previous bug reports. Any unit "can be" accessed as
formatted or unformatted if one chooses to do so, this is why we answer yes.
In other words, it is "allowed"
This should not be conf
bash-3.2$ cat /tmp/foo.f
SUBROUTINE DIMOID(DEN,RLMO,SSQU,STRI,ATMU,IATM,IWHI,MAPT,INAT,
* IATB,L1,L2,M1,M2,NATS,NOSI,NCAT,NSWE)
C
IMPLICIT DOUBLE PRECISION(A-H,O-Z)
C
DIMENSION RLMO(L1,L1),SSQU(L1,L1),STRI(L2),ATMU(NATS),DEN(M2)
DIMENSION IATM(NATS,M1),IWHI(M1+NATS),
--- Comment #8 from rob1weld at aol dot com 2007-07-07 04:05 ---
I searched the last 30 reports using
http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&version=4.3.0&chfieldfrom=2007-07-06&chfieldto=2007-07-07&chfieldvalue=&cmdtype=doit&order=Bug+Number
to find the best place to put th
--- Comment #21 from dberlin at gcc dot gnu dot org 2007-07-07 03:25
---
Subject: Bug 23488
Author: dberlin
Date: Sat Jul 7 03:25:29 2007
New Revision: 126434
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126434
Log:
2007-07-06 Daniel Berlin <[EMAIL PROTECTED]>
Fix
--- Comment #2 from rob1weld at aol dot com 2007-07-07 03:10 ---
There is a whole list of these optimizations at:
http://graphics.stanford.edu/~seander/bithacks.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32648
--- Comment #1 from rob1weld at aol dot com 2007-07-07 03:03 ---
This is a duplicate of 32004 - That is fixed and so is this.
--
rob1weld at aol dot com changed:
What|Removed |Added
--
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-07 02:55 ---
Richard,
Thanks for the bug report. Your code compiles with
gcc version 4.2.0 20070501
gcc version 4.3.0 20070704 <-- This is a recent trunk.
You can get recent binaries on the gfortran wiki. Note,
I'm marking t
Consider the following functions:
typedef unsigned long long int u64;
void foo(u64* d, u64 const* s, u64 k) {
*d = ((__uint128_t) *s*k) >> 64;
}
void foo(u64* d, u64 const* s, u64 k, u64 m) {
*d = ((__uint128_t) (*s&m)*k) >> 64;
}
void foo2(u64* d, u64 const* s, u64 k) {
foo(d, s, k)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu
|
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|mmitchel at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 02:02
---
Subject: Bug 32245
Author: mmitchel
Date: Sat Jul 7 02:02:37 2007
New Revision: 126433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126433
Log:
PR c++/32245
* init.c (build_zero_init): A
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-07 02:02
---
Subject: Bug 31992
Author: mmitchel
Date: Sat Jul 7 02:02:37 2007
New Revision: 126433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126433
Log:
PR c++/32245
* init.c (build_zero_init): A
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-07-07 02:02
---
Subject: Bug 32251
Author: mmitchel
Date: Sat Jul 7 02:02:37 2007
New Revision: 126433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126433
Log:
PR c++/32245
* init.c (build_zero_init): A
--- Comment #3 from aribrei at arcor dot de 2007-07-07 01:46 ---
I don't have a copy of the standard at all, unfortunately, but I was referred
to [12.3.2/1 p.6]. If I understood correctly, the problem being that implicit
conversions shall not take place for the class or a base class of t
--- Comment #6 from zackw at panix dot com 2007-07-07 00:20 ---
Created an attachment (id=13861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13861&action=view)
and smaller still
I can't believe I didn't think of these reductions three hours ago...
--
zackw at panix dot com c
--- Comment #5 from zackw at panix dot com 2007-07-07 00:15 ---
Created an attachment (id=13860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13860&action=view)
Even smaller test case
--
zackw at panix dot com changed:
What|Removed |Added
--
--- Comment #4 from zackw at panix dot com 2007-07-07 00:07 ---
Adding DJ to cc: list, confirming.
--
zackw at panix dot com changed:
What|Removed |Added
--- Comment #3 from zackw at panix dot com 2007-07-07 00:06 ---
Created an attachment (id=13859)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13859&action=view)
Minimized test case
Here's a minimal test case (from my duplicate report of this, #32659). I
analyzed it a bit there -
--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 ---
*** Bug 32659 has been marked as a duplicate of this bug. ***
--
zackw at panix dot com changed:
What|Removed |Added
---
--- Comment #2 from zackw at panix dot com 2007-07-07 00:05 ---
*** This bug has been marked as a duplicate of 32656 ***
--
zackw at panix dot com changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-07 00:00 ---
And why do you think it is not?
I don't have access to my copy of the standard but I think this is valid thing
to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
Compiling the following with "g++ -msse3 -O3":
#include
int foo(__m128i* val) {
return __builtin_ia32_vec_ext_v4si(*val, 1);
}
int bar(__m128i* val) {
union vs {
__m128i *_v;
int* _s;
} v = {val};
return v._s[1];
}
yields the following assembler output. Ideally, both functions wo
--- Comment #1 from scovich at gmail dot com 2007-07-06 23:11 ---
Oops.. forgot to include the error message
g++ -Wall -msse3 -O3 -S union-bug.C
union-bug.C: In function long int foo(long long int __vector__):
union-bug.C:4: error: unrecognizable insn:
(insn 12 7 13 0 (set (reg:DI 61)
Attempting to compile the following function causes an ICE:
#include
long foo(__m128i val)
return __builtin_ia32_vec_ext_v2di(val, 1)
}
Changing the call to any of the following compiles just fine:
__builtin_ia32_vec_ext_v2di(val, 0)
__builtin_ia32_vec_ext_v4si(val, 1)
__builtin_ia32_vec_ext
--- Comment #1 from zackw at panix dot com 2007-07-06 22:12 ---
Created an attachment (id=13858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13858&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32659
The attached test case produces this RTL sequence after lreg, when compiled at
-O2 -mcpu=m32cm:
(insn 12 11 13 2 ba-bug.ii:24 (set (reg:DI 26 [ p.2 ])
(mem/s:DI (reg/f:PSI 31) [3 S8 A8])) 176 {movdi_splittable}
(expr_list:R
EG_DEAD (reg/f:PSI 31)
(nil)))
(insn 13 12 14 2 ba-bug.ii
--- Comment #1 from aribrei at arcor dot de 2007-07-06 21:44 ---
Created an attachment (id=13857)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13857&action=view)
File that compiles unexpectedly, without warnings (no #includes)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32
xyz::operator xyz &() gets called implicitly. I'm told that it shouldn't.
Is this intended behaviour and will it stay?
$ LC_ALL=C gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.3-20070608/configure
--prefix=/opt/unstable/gcc-4.3-20070608 --enable-languages
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c |target
http:
/bin/sh ./libtool --tag=GCJ --mode=compile /usr/src/rpm/BUILD/gcc-build/gcc/gcj
-B/usr/src/rpm/BUILD/gcc-build/pentium4-east-linux/libjava/
-B/usr/src/rpm/BUILD/gcc-build/gcc/ -fclasspath=
-fbootclasspath=../../../gcc-4.3.0-20070706/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated
--- Comment #1 from rask at sygehus dot dk 2007-07-06 20:50 ---
Created an attachment (id=13856)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13856&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
I get this failure building libstdc++:
/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/m32cm/libstdc++-v3/include/ext/bitmap_allocator.h:
In member function 'void
__gnu_cxx::bitmap_allocator<_Tp>::_M_deallocate_single_object(_Tp*) [with _Tp =
wchar_t]':
/home/rask/build/gcc-m32c-unknown-elf/
--- Comment #1 from rge21 at pas dot rochester dot edu 2007-07-06 20:25
---
Created an attachment (id=13855)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13855&action=view)
Minimum test case
This is the file test.f90 I copied into the bug report
--
http://gcc.gnu.org/bugzil
I have a PURE subroutine which requires a PURE functions as arguments. When I
attempt to compile the code, gfortran says:
$ gfortran -c test.f90
In file test.f90:6
PURE SUBROUTINE Demo( dydx )
1
Error: Argument 'dydx' of pure subroutine 'demo' at (1) must have its I
--- Comment #9 from zackw at panix dot com 2007-07-06 17:59 ---
Ian Taylor and I found a simpler patch that does not use langhooks, and also
has the virtue of working. ;-) Committed as rev 126424.
--
zackw at panix dot com changed:
What|Removed |A
--- Comment #8 from zackw at panix dot com 2007-07-06 17:58 ---
Subject: Bug 32441
Author: zack
Date: Fri Jul 6 17:57:58 2007
New Revision: 126424
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126424
Log:
2007-07-06 Ian Lance Taylor <[EMAIL PROTECTED]>
Zack Weinb
Bootstrapping the current 4.2 branch on alpha-dec-osf5.1b with GCC 3.4 as
the bootstrap compiler, I get a comparison failure in exp_aggr.o:
Comparing stages 2 and 3
Bootstrap comparison failure!
./ada/exp_aggr.o differs
make[2]: *** [compare] Error 1
There's only a minimal difference in the debu
It seems that in r126296, tree-ssa-pre is using much more memory compiling
libjava/interperter.cc than it did in r126044. I had to kill it after it was
thrashing for more than 24 hours on my 128MB build machine.
Configured thusly:../gcc/configure --with-arch=mips32 --with-float=soft
--disable-jav
Even with the fix for PR libgcj/32651 (which sets libgcj_interpreter=no),
libgcj doesn't build on IRIX 6.5 (or any other platform) because several
types and classes from java-interp.h are used even with INTERPRETER
undefined. This is a regression from 4.1 and 4.2 and can easily be
reproduced with
On both the 4.2 branch and mainline, libjava fails to build on
mips-sgi-irix6.5:
* sysdeps_dir isn't set in configure.host, so the generic locks.h is used
which just errors out
* libgcj_interpreter is set to yes in the general mips-* clause in
configure.host, but this cannot work for IRIX 6
--- Comment #2 from jconner at gcc dot gnu dot org 2007-07-06 16:57 ---
Subject: Bug 32603
Author: jconner
Date: Fri Jul 6 16:57:19 2007
New Revision: 126422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126422
Log:
2007-07-06 Josh Conner <[EMAIL PROTECTED]>
PR midd
--- Comment #2 from jconner at gcc dot gnu dot org 2007-07-06 16:57 ---
Subject: Bug 32602
Author: jconner
Date: Fri Jul 6 16:57:19 2007
New Revision: 126422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126422
Log:
2007-07-06 Josh Conner <[EMAIL PROTECTED]>
PR midd
--- Comment #11 from pcarlini at suse dot de 2007-07-06 16:33 ---
Ok, thanks. Let's ask Paolo's opinion here too (as a build system maintainer),
in particular about the final part of Comment #6...
--
pcarlini at suse dot de changed:
What|Removed |A
According to Mark Mitchell, strchr(p,'\0') is more efficient than
p+strlen(p).
#include
void * f (char *p) { return p + strlen (p); }
void * g (char *p) { return strchr (p, '\0'); }
g:
xorl%esi, %esi
jmp __rawmemchr
f:
pushq %rbx
movq%rdi, %rbx
--
schwab at suse dot de changed:
What|Removed |Added
AssignedTo|schwab at suse dot de |unassigned at gcc dot gnu
||dot
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-06 15:45
---
This is also a missed optimization ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from matz at gcc dot gnu dot org 2007-07-06 15:42 ---
This helps (the loop already tries to copy the content byte wise, but uses
the wrong modes for that), but someone knowledgeable in that bitfield business
should look at it. In particular it might happen that extract_bi
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|000
--- Comment #27 from bonzini at gnu dot org 2007-07-06 15:13 ---
fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #26 from bonzini at gnu dot org 2007-07-06 15:13 ---
Subject: Bug 32004
Author: bonzini
Date: Fri Jul 6 15:12:55 2007
New Revision: 126419
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126419
Log:
2007-07-06 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--- Comment #25 from bonzini at gnu dot org 2007-07-06 15:10 ---
Subject: Bug 32004
Author: bonzini
Date: Fri Jul 6 15:10:10 2007
New Revision: 126418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126418
Log:
2007-07-06 Paolo Bonzini <[EMAIL PROTECTED]>
PR middle-en
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-07-06 15:06 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00583.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32641
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-06 15:06 ---
hammer branch is bad as well. Code works with -m32.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-06 14:58 ---
We use store_field() to a bitpos of 80 with a bitsize of 48 to a mem:BLK target
which in turn calls store_expr on an adjusted mem which calls
temp = expand_expr_real (exp, tmp_target, GET_MODE (target),
--- Comment #134 from jv244 at cam dot ac dot uk 2007-07-06 14:52 ---
(In reply to comment #133)
> I've made a first try to an automatic nightly tester of CP2K (thanks Joost for
> the input files provided), I'll post full details when I'm sure it's working
> OK.
that's great...
--
--- Comment #3 from pluto at agmk dot net 2007-07-06 14:29 ---
(In reply to comment #2)
> 4.3.0 20070703 fails to.
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00562.html
this patch fixes gcc from trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32508
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-06 14:05 ---
The following testcase exposes the problem in Initialize()
struct STRUCT_6_BYTES
{
unsigned char slot[sizeof(unsigned short)];
unsigned char page[sizeof(unsigned int)];
};
struct SQLU_DICT_INFO_0
{
void *
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-06 13:54 ---
The tree IL looks sane.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Co
--- Comment #10 from hp at gcc dot gnu dot org 2007-07-06 13:52 ---
In reply to comment #9: Yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32499
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2007-07-06 13:50 ---
I think this is invalid.
The normative words are, from 9.6.1.11
"The scalar-default-char-variable in the FORMATTED= specifier is
assigned the value YES if FORMATTED is included in the set of allo
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-06 13:44 ---
Even if this IR is created at expansion time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32441
--- Comment #1 from Vladislav dot Mikhailikov at paradox-neo dot uz
2007-07-06 13:16 ---
(In reply to comment #0)
> I have configured gcc like this:
>
> /n/08/rask/src/gcc/configure --target=arm-unknown-elf --disable-multilib
> --disable-nls --disable-gdb --with-newlib --enable-sim
>
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-06 12:54 ---
Confirmed. This needs VRP of bits. The IL we generate is currently
bool b3;
bool b5;
int D.2483;
int D.2482;
int D.2481;
:
D.2481_2 = a_1(D) & 32;
b5_3 = D.2481_2 != 0;
D.2482_4 = a_1(D) & 8;
b3
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-06 12:53 ---
*** This bug has been marked as a duplicate of 32644 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-06 12:53 ---
*** Bug 32649 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32644
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-07-06 12:52 ---
Joost, thanks for reporting!
Closing as fixed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
When I compile the program listed below with the latest snapshot version of
gfortran, I get the message "Error: Unclassifiable statement at (1)". I believe
this bug was introduced by a recent fix.
PROGRAM f
CHARACTER*1, c
END PROGRAM f
--
Summary: "CHARACTER*1, c" produces "Unclassif
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-07-06 12:37 ---
Subject: Bug 32633
Author: dfranke
Date: Fri Jul 6 12:37:22 2007
New Revision: 126413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126413
Log:
gcc/fortran:
2007-05-06 Daniel Franke <[EMAIL PROTECTED]>
> cat b5-xor-b3.cc
bool f1(int a)
{
bool b5 = a & 0x20;
bool b3 = a & 0x08;
return b5 ^ b3;
}
bool f2(int a)
{
return (a ^ (a << 2)) & 0x20;
}
> g++ -O3 -c b5-xor-b3.cc
> objdump -d b5-xor-b3.o
b5-xor-b3.o: file format elf64-x86-64
Disassembly of section .text
This testcase fails with a spill failure for class AREG:
void f(int a)
{
register int reg asm ("eax") = 0;
a /= 1000;
asm volatile ("nop" : "+r"(reg), "+r"(a));
}
--
Summary: spill failures with hard-register variable
Product: gcc
Version: 4.3.0
--- Comment #133 from fxcoudert at gcc dot gnu dot org 2007-07-06 12:18
---
I've made a first try to an automatic nightly tester of CP2K (thanks Joost for
the input files provided), I'll post full details when I'm sure it's working
OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
rmatted=answer,iostat=ier)
if (ier /= 0) stop 'Eh?'
print*,'is_formatted = ',answer
end program fred
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Compiled code as "gfo
--- Comment #24 from bonzini at gnu dot org 2007-07-06 12:18 ---
Also, the testcase from comment #21 is not a regression: if we do the inlining
manually, it fails in 3.3 too. The failing testcase is:
void f(int a)
{
register int reg asm ("eax") = 0;
a /= 1000;
asm volatile ("nop"
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-06 12:17
---
Lee has submitted a new version of his patch, taking into account that testcase
(and adding it to the testsuite). Thus, closing the bug.
--
fxcoudert at gcc dot gnu dot org changed:
What|Remove
--- Comment #23 from bonzini at gnu dot org 2007-07-06 12:08 ---
In particular, this one could be rewritten to
inline void g(int b)
{
register int reg = 0;
asm volatile ("nop" : "+a"(reg), "+r"(b));
}
void f(int a)
{
a /= 1000;
g(a);
}
but the one in PR21291 could not.
--
--- Comment #9 from pcarlini at suse dot de 2007-07-06 12:06 ---
Thanks for the patch. Care of adding a ChangeLog entry and posting it to
gcc-patches for public review? Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
--- Comment #9 from pcarlini at suse dot de 2007-07-06 12:05 ---
Thanks Hans-Peter for the (partial) patch. Therefore, I understand now the
issue isn't a libstdc++ proper issue anymore? Someone should play with the
toplevel configure.ac?
--
pcarlini at suse dot de changed:
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-06 11:53 ---
gcc version 4.3.0 20070627 (experimental)
$> gfortran-svn -g -Wall pr32644.f90
pr32644.f90:2.14:
CHARACTER*1, c
1
Warning: Unused variable c declared at (1)
gcc version 4.3.0 20070705 (experimental)
$
When I compile the program listed below with the latest snapshot version of
gfortran, I get the message "Error: Unclassifiable statement at (1)". I believe
this bug was introduced by a recent fix.
PROGRAM f
CHARACTER*1, c
END PROGRAM f
--
Summary: "CHARACTER*1, c" produces "Unclassif
--- Comment #2 from patchapp at dberlin dot org 2007-07-06 11:20 ---
Subject: Bug number PR32634
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/msg00561.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #34 from ubizjak at gmail dot com 2007-07-06 11:16 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #33 from uros at gcc dot gnu dot org 2007-07-06 10:54 ---
Subject: Bug 32450
Author: uros
Date: Fri Jul 6 10:54:03 2007
New Revision: 126411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126411
Log:
PR rtl-optimization/32450
* function.c (thread_pro
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-06 09:54 ---
The issue is we are folding 0*n into 0 but not marking it as being non
constant, we could use the infrastructure provided by the patch for PR 32643
and set folding_initializer correctly while folding of the array siz
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-06 09:52
---
I think for the 0*x case, we need the infrastructure provided by PR 32643 and
then set folding_initializer when we are inside an enum.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #32 from uros at gcc dot gnu dot org 2007-07-06 09:50 ---
Subject: Bug 32450
Author: uros
Date: Fri Jul 6 09:49:52 2007
New Revision: 126407
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126407
Log:
PR rtl-optimization/32450
* function.c (thread_pro
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-06 09:43 ---
This quick hack fixes the problem for both testcases (the fold-const part is
the only part required to fix the second testcase);
Index: fold-const.c
===
--- Comment #31 from ubizjak at gmail dot com 2007-07-06 09:24 ---
Author: uros
Date: Fri Jul 6 08:53:15 2007
New Revision: 126403
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126403
Log:
PR rtl_optimization/32450
* function.c (thread_prologue_and_epilogue_insn
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-06 09:07 ---
Note this was found while trying to fix PR 32628.
The diagnostic issue is at least a regression from 4.0.1. Well and the accepts
invalid (without -pedantic-errors for the first testcase).
The second testcase was
testcase, compile with -pedantic-errors (we don't reject it overwise in 4.3):
unsigned char p;
unsigned char p1 = p & 512;
- cut ---
We get:
overflow-warn-5.c:7: warning: overflow in implicit constant conversion
overflow-warn-5.c:7: error: overflow in constant expression
Now there
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-06 08:45 ---
To implement PR32239, integer exponention was changed recently:
2007-07-01 Janne Blomqvist <[EMAIL PROTECTED]>
PR fortran/32239
* trans-expr.c (gfc_conv_power_op): Use builtin_powi for
rea
There seems to be a problem either with the doc or with GCC in this case,
I am not sure that has ever worked neither.
[EMAIL PROTECTED] ~]$ cat tmp.c
/* info gcc -> Extended Asm
If you know how large the accessed memory is, you can add it
as input or output but if this is not known, you should ad
--- Comment #17 from aoliva at gcc dot gnu dot org 2007-07-06 08:38 ---
Subject: Bug 23551
Author: aoliva
Date: Fri Jul 6 08:38:40 2007
New Revision: 126402
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126402
Log:
PR debug/23551
* tree-ssa-copyrename.c (copy_rename_partition_
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-06 08:23 ---
closing as magically fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Stat
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-06 08:23 ---
closing as magically fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Stat
--- Comment #9 from rob1weld at aol dot com 2007-07-06 08:13 ---
Also occurs in 4.2 and 4.3
Discussed here:
http://lists.boost.org/Archives/boost/2002/03/27238.php
http://lists.boost.org/Archives/boost/2002/03/27274.php
Seems to end with this:
http://lists.boost.org/Archives/boost/2002
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-07-06 07:02 ---
I'm working on a patch
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
Assigned
97 matches
Mail list logo
