--- Comment #22 from pault at gcc dot gnu dot org 2005-12-07 06:20 ---
Subject: Bug 15809
Author: pault
Date: Wed Dec 7 06:20:21 2005
New Revision: 108150
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108150
Log:
2005-12-07 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #9 from pault at gcc dot gnu dot org 2005-12-07 06:06 ---
(In reply to comment #8)
> Showstopper.
>
What is the status on this one?
Paul T
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24793
--- Comment #12 from amodra at bigpond dot net dot au 2005-12-07 05:50
---
pr25212 has a more complete fix that I propose applying to the 4.1 branch.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-12-07 05:16
---
I have found the offending code. I am working on the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-12-07 04:34
---
Closing as invalid based on the resolution of the Defect report making this
code invalid and should be rejected as GCC does.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-07 04:14 ---
This is only an if conversion failure now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-12-07 04:13 ---
Fixed in 4.2.0 by:
2005-11-24 Paolo Bonzini <[EMAIL PROTECTED]>
* gcse.c (hash_scan_set): Look through REG_EQUAL or REG_EQUIV notes
also when doing PRE, rather than only for global CPROP.
--
pi
--- Comment #13 from ghazi at gcc dot gnu dot org 2005-12-07 03:54 ---
(In reply to comment #12)
> Subject: Re: builtin *printf handlers are confused by -fexec-charset
> "ghazi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> | Backporting this fix to 3.4 requires also backporting
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-07 03:23 ---
I should note that the first testcase in comment #0 in the bug is fixed but not
the second, non reduced one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-07 03:12 ---
Once fold does (a&b)!=0?a|b:a to a and PR 25290 is fixed then this will be
caught at the tree level. There are most likely others like this too.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
PHI-OPT could be rewritten so that it uses fold_ternary (type, COND_EXPR, cond,
op1, op2) and that it could remove code which is already done in fold_ternary.
A patch like
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00153.html
will work but it needs to be reworked for the changes which made it in
--- Comment #8 from billingd at gcc dot gnu dot org 2005-12-07 01:08
---
I can confirm this works for me on trunk.
--
billingd at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2005-12-07 00:38 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #3 from tromey at gcc dot gnu dot org 2005-12-07 00:35 ---
Subject: Bug 25283
Author: tromey
Date: Wed Dec 7 00:35:06 2005
New Revision: 108145
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108145
Log:
PR java/25283:
* parse.y (patch_new_array_init)
--- Comment #2 from tromey at gcc dot gnu dot org 2005-12-07 00:34 ---
Subject: Bug 25283
Author: tromey
Date: Wed Dec 7 00:34:36 2005
New Revision: 108144
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108144
Log:
PR java/25283:
* parse.y (patch_new_array_init)
--- Comment #1 from tromey at gcc dot gnu dot org 2005-12-07 00:32 ---
Subject: Bug 25283
Author: tromey
Date: Wed Dec 7 00:31:58 2005
New Revision: 108143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108143
Log:
PR java/25283:
* parse.y (patch_new_array_init)
--- Comment #3 from bkoz at gcc dot gnu dot org 2005-12-07 00:16 ---
I still want this.
Someday...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
--- Comment #4 from danglin at gcc dot gnu dot org 2005-12-07 00:16 ---
Mine.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 23:56 ---
Confirmed, very much related to PR 19774.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-06 23:55 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-06 23:43 ---
So the 3.3 was a regression so closing as fixed for 3.4.0 as 3.3.x is no longer
being maintained.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
malo /tmp $ cat a.f
integer*1 abyte
integer*8 n
n = huge(0_4)
n = 256 * n
print *, n
open(10,file="foo",recl=1,form='unformatted',access='direct')
write(10,rec=n) abyte
close(10)
end
malo /tmp $ ifort a.f && ./a.out
549755813632
malo /
--- Comment #2 from albertm at uphs dot upenn dot edu 2005-12-06 22:52
---
Subject: Re: gfortran ignores explicit return type for
fun ctions
Thank you very much. My apologies. I don't understand Fortran as
well as I should.
Sincerely,
Mike Albert
On Tue, 6 Dec 2005, tkoenig at
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-12-06 22:37
---
*** Bug 25280 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 22:37 ---
*** This bug has been marked as a duplicate of 19266 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pcarlini at suse dot de 2005-12-06 22:36 ---
Ouch! Luckily seems not too difficult to fix, consistently with other similar
situations in the library. Thanks for your report.
--
pcarlini at suse dot de changed:
What|Removed |Adde
--- Comment #5 from dpatel at apple dot com 2005-12-06 22:23 ---
Created an attachment (id=10430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10430&action=view)
zem's patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19523
--- Comment #4 from listor1 dot rombobeorn at comhem dot se 2005-12-06
22:21 ---
Subject: Re: Discriminant is left uninitialized.
laurent at guerby dot net wrote:
> The problem is that you are using "Unbounded_String" in your record, and
> this brings in lots of dope information for F
--- Comment #2 from dpatel at apple dot com 2005-12-06 22:19 ---
This is already fixed.
--
dpatel at apple dot com changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-12-06 22:14 ---
(In reply to comment #0)
> PROGRAM BUG
> external real function Mfunc
This declares an external symbol called
"realfunctionmfunc" (fixed form), which is
probably not what you intended.
If you replace t
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-06 21:58 ---
(In reply to comment #4)
> So, no, the code is not worse, but much better. I hope this
> workaround will continue to work in future versions.
You are wrong in general since this is a conditional indirect jump. Sin
--- Comment #4 from anton at mips dot complang dot tuwien dot ac dot at
2005-12-06 21:46 ---
Subject: Re: pessimization of goto * ("computed goto")
pinskia at gcc dot gnu dot org wrote:
> __asm__(""); makes stuff worse.
I just applied the following patch to engine1.i:
--- engine1.i
--- Comment #22 from tkoenig at gcc dot gnu dot org 2005-12-06 21:45
---
Added new patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
U
--- Comment #2 from lennox at cs dot columbia dot edu 2005-12-06 21:31
---
Created an attachment (id=10427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10427&action=view)
Custom debug allocator, based on libstdc++'s malloc_allocator.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from lennox at cs dot columbia dot edu 2005-12-06 21:30
---
Created an attachment (id=10426)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10426&action=view)
C source file, constructing a list with a custom debug allocator.
--
http://gcc.gnu.org/bugzilla/show_b
According to section 23.2.2.3 [lib.list.modifiers] of the C++ specification,
for all the insert member functions of std::list, "If an exception is thrown
there are no effects."
However, this doesn't appear to be the case for libstdc++. It's possible for
an exception to be thrown out of an insert
--- Comment #1 from pcarlini at suse dot de 2005-12-06 21:09 ---
(In reply to comment #0)
> The failure in bug 25168 appeared between the same pair of revisions; I don't
> know if they are related.
At least, both testcases replace operator new...
--
http://gcc.gnu.org/bugzilla/show
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 21:09 ---
Ignore the:
.L3:
mtctr %r30
bctr
Part
and "beqctr %cr7,.L3" should have been "beqctr %cr7"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25287
Code:
int f(void *a, int b)
{
if (b ==1) goto *a;
g();
if (b ==2) goto *a;
g();
return 1
}
This is very minor but I thought it would be cool if GCC could do something
like:
.f:
mflr %r0
cmpwi %cr7,%r4,1
std %r30,-16(%r1)
std %r31,-8(%r1)
mr %r30,%r
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-06 20:57 ---
Since there is no conditional indirect jumps on x86 this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #21 from pluto at agmk dot net 2005-12-06 20:55 ---
ok, I hope this ppc-elf-linux fix for pr20218-x86-32_64.patch is correct.
with this both testcases work.
diff -uNrp a/gcc/config/rs6000/linux.h b/gcc/config/rs6000/linux.h
--- a/gcc/config/rs6000/linux.h2005-11-30 11:15
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 20:46 ---
__asm__(""); makes stuff worse.
Anyways it looks like the code in GCC only deals with non conditional jumps
(unless I am missing something).
Is there a conditional jump of an indirect jump for x86/x86_64?
--
ht
--- Comment #23 from rakdver at gcc dot gnu dot org 2005-12-06 20:33
---
Patch: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00454.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-06 20:20 ---
Reopening since this was only fixed for 4.2.0 and not also for 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
FAIL: ext/pool_allocator/allocate_chunk.cc execution test
appeared on mainline between 20051117 and 20051118 (revisions 107115 and
107161) on hppa2.0w-hp-hpux11.11 and still appears present on mainline and 4.1
branch. This test previously passed.
The failure in bug 25168 appeared between the same
--- Comment #1 from anton at mips dot complang dot tuwien dot ac dot at
2005-12-06 20:00 ---
Created an attachment (id=10425)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10425&action=view)
test case input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25285
This is the gcc-4.0 reincarnation of PR 15242. Since about gcc-3.2 or
so gcc tends to compile "goto *" into direct jumps to a shared
indirect jump. Gcc-4.0 tries to undo this in a later stage, but
apparently it is not completely successful:
This is a fragment from the engine1.i file I will
attac
--- Comment #7 from aldyh at gcc dot gnu dot org 2005-12-06 19:48 ---
Fixed.
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01175.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from gnassre at earthlink dot net 2005-12-06 19:45 ---
(In reply to comment #1)
> The C standard says that if a function is not declared (prototyped) then
> implicately it returns the type of int.
>
ok thanks, that makes sense =)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #6 from aldyh at gcc dot gnu dot org 2005-12-06 19:45 ---
Subject: Bug 24138
Author: aldyh
Date: Tue Dec 6 19:45:00 2005
New Revision: 108126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108126
Log:
PR C++/24138
* tree.c (integer_all_onesp): Always
--- Comment #4 from gnassre at earthlink dot net 2005-12-06 19:41 ---
Created an attachment (id=10424)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10424&action=view)
main() function definition file from gcc --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #3 from gnassre at earthlink dot net 2005-12-06 19:41 ---
Created an attachment (id=10423)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10423&action=view)
testo() function definition file from gcc --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #2 from gnassre at earthlink dot net 2005-12-06 19:40 ---
Created an attachment (id=10422)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10422&action=view)
output of gcc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25284
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 19:40 ---
The C standard says that if a function is not declared (prototyped) then
implicately it returns the type of int.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from eedelman at gcc dot gnu dot org 2005-12-06 19:38
---
(In reply to comment #6)
> Working on a patch.
Posted a pacth here: http://gcc.gnu.org/ml/fortran/2005-12/msg00116.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197
inside main(), a call is made to function testo() which simply returns a
double(1415.149). The correct double value is returned only if main.c has
#include , which is where testo() is declared.
I've compiled two versions of this program, with and without the include line,
withinclude.a.out and wi
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-12-06 19:27
---
*** Bug 25278 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-06 19:27 ---
The reason why removing one enum works is because the size of the RGB will be
one instead of two so that the specialized version of SwapEndianness::swap can
be used. There is nothing magical here with respect with t
--- Comment #20 from pluto at agmk dot net 2005-12-06 19:26 ---
Created an attachment (id=10421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10421&action=view)
patch for current 4.1 branch.
I would love to see a ppc-linux part for this patch.
--
http://gcc.gnu.org/bugzilla/
gcj generates an invalid signature for the anonymous constructor
in this test case:
public class t {
public t(char[][] args) { }
public Object m() {
return new t(new char[][] { "hi".toCharArray(),
"bob".toCharArray(),
"and jo
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 18:51 ---
(In reply to comment #2)
I may accept that g++ is right to reject this code. I cannot convince myself
from reading the standard but I'm not a langage lawyer. I think that this is a
major flaw in
--- Comment #22 from bergner at vnet dot ibm dot com 2005-12-06 18:47
---
...and I can verify that the patch fixes the reduced test case. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
cause
> the default class for SwapEndianness does not contain any swap method.
>
> This has been tested with gcc version 4.2.0 20051206 (experimental).
>
> Note also that things slightly improved since
> gcc version 4.2.0 20051124 (experimental)
> which failed also if the e
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 18:39 ---
*** Bug 25282 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25281
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 18:39 ---
*** This bug has been marked as a duplicate of 25281 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Request fix for Bug #23150 |[3.4/4.0 only] Request fix
|(aka Bug #24675) in gcc
Hello,
A bug #24675 was logged on Nov 4th for gcc 3.2.1 (arm arch). After
several emails communication by helpful people, it was determined that
the issue is similar to bug #23150 and is still there for:
gcc 3.2.1,
gcc 3.3.3, gcc 3.3.6, gcc 3.4.4
gcc 4.0.1 and gcc 4.0.2
It was tested and
Hello,
A bug #24675 was logged on Nov 4th for gcc 3.2.1 (arm arch). After
several emails communication by helpful people, it was determined that
the issue is similar to bug #23150 and is still there for:
gcc 3.2.1,
gcc 3.3.3, gcc 3.3.6, gcc 3.4.4
gcc 4.0.1 and gcc 4.0.2
It was tested and
--- Comment #21 from olh at suse dot de 2005-12-06 18:11 ---
Created an attachment (id=10420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10420&action=view)
pr25248.patch
This patch fixes it for me.
Let me attach it in a readable form.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #7 from janis at gcc dot gnu dot org 2005-12-06 18:04 ---
Subject: Bug 25247
Author: janis
Date: Tue Dec 6 18:04:00 2005
New Revision: 108124
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108124
Log:
PR testsuite/25247
* lib/target-supports-dg.exp (
--- Comment #6 from eedelman at gcc dot gnu dot org 2005-12-06 18:03
---
Working on a patch.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-06 17:59 ---
This is a glibc bug. round is not prototype any where when looking at the
preprocessed source for the file but is when adding -std=c99.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
#include
int foo(double x)
{
return round(x);
}
causes
$ gcc -c t.c
t.c: In function 'foo':
t.c:5: warning: incompatible implicit declaration of built-in function 'round'
the transformation of round to lround here done in convert_to_integer is
likely the cause for this. Compiling with -std=
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 17:48 ---
No, GCC is correct to reject this code. What is happening is that the
overloaded set for the ChangeEndianness in the second ChangeEndianness is only
the first and the second so there is no way to consider the third
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2005-12-06 17:39 ---
Created an attachment (id=10419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10419&action=view)
The code describing the regression.
Simplify compile with g++
--
http://gcc.gnu.org/
from ChangeEndianness(T* begin,const T* end) so that the generic
version ChangeEndianness(T& t) is called instead generating and error because
the default class for SwapEndianness does not contain any swap method.
This has been tested with gcc version 4.2.0 20051206 (experimental).
Note also tha
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-12-06 17:32
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-12-06 17:31
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #3 from reichelt at gcc dot gnu dot org 2005-12-06 17:30
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #87 from pluto at agmk dot net 2005-12-06 17:05 ---
current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-06 16:04 ---
This is not fully a regression as this was on purpose change until emms was
emmitted correctly. Anyways this is very much related to PR 22076 and PR 14552
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #20 from rakdver at gcc dot gnu dot org 2005-12-06 15:43
---
This patch should fix the problem:
Index: tree-scalar-evolution.c
===
*** tree-scalar-evolution.c (revision 108078)
--- tree-scalar-evolution.c
--- Comment #3 from roger at eyesopen dot com 2005-12-06 15:43 ---
Fixed. I've checked all other uses of TREE_OVERFLOW in cp/decl.c and c-decl.c
to confirm that the C front-end isn't affected by a similar issue there.
Sorry for any inconvenience.
--
roger at eyesopen dot com changed
--- Comment #14 from roger at eyesopen dot com 2005-12-06 15:39 ---
Fixed for gcc v4.2
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW
--- Comment #19 from rakdver at gcc dot gnu dot org 2005-12-06 15:28
---
Seems like some problem in iv analysis:
ssa name pstart_17
type long unsigned int
base (long unsigned int) (unsigned int) D.1301_7 + (long unsigned int)
(unsigned int) pstart_10
step (long unsigned int) step
--- Comment #1 from pluto at agmk dot net 2005-12-06 15:02 ---
(In reply to comment #0)
> $ gcc tmp.c -S -O2 -mmmx
fix: -S -O2 -mmmx -fomit-frame-pointer -mregparm=3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25277
#include
__v8qi foo(const __v8qi x, const __v8qi y){return x+y;}
__v8qi bar(const __v8qi x, const __v8qi y){return __builtin_ia32_paddb(x,y);}
$ gcc tmp.c -S -O2 -mmmx
3.3.6 produces the same code for foo() and bar():
foo:movq4(%esp), %mm0
paddb 12(%esp), %mm0
movq
Last known to work with: "Mon Dec 5 12:27:13 UTC 2005 (revision 108052M)".
First known to fail with: "Mon Dec 5 22:19:13 UTC 2005 (revision 108077M)".
Running /home/hp/combined/combined/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-weakref-1.c execution test
With the message in the .log
--- Comment #2 from jakub at gcc dot gnu dot org 2005-12-06 14:48 ---
Yeah, making separate
(define_insn "*di3_and_31"
[(set (match_operand:DI 0 "register_operand" "=d")
(SHIFT:DI (match_operand:DI 1 "register_operand" "0")
(and:SI (match_operand:SI 2 "shift_c
--- Comment #1 from krebbel at gcc dot gnu dot org 2005-12-06 14:33 ---
Shorter testcase:
long long
foo (long long x, int y)
{
return x << ((y + 1) & 63);
}
The count operand of a shift instruction is a somewhat weird
thing on S/390. It is basically an address accepting the sum of
an
--- Comment #18 from olh at suse dot de 2005-12-06 14:26 ---
Adding -fno-ivopts to CFLAGS for hash_utils_64.o fixes it for me.
Tested with gcc-4_1-branch r108104 and current binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #2 from sayle at gcc dot gnu dot org 2005-12-06 14:00 ---
Subject: Bug 25263
Author: sayle
Date: Tue Dec 6 14:00:09 2005
New Revision: 108119
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108119
Log:
PR c++/25263
* decl.c (compute_array_index_type)
--- Comment #17 from rguenth at gcc dot gnu dot org 2005-12-06 13:59
---
IVOPTs truncates pstartD.1866_10 down to int, which is wrong:
htab_bolt_mapping (pstartD.1866, cntD.1867)
{
unsigned intD.3 D.1959;
long unsigned intD.4 D.1960;
long unsigned intD.4 ivtmp.50D.1954;
unsigne
--- Comment #16 from rguenth at gcc dot gnu dot org 2005-12-06 13:48
---
Confirmed. -fno-ivopts fixes it.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dir at lanl dot gov 2005-12-06 13:47 ---
If you look at the output from format 2030, you will see that that comma at the
end of the "44h e n d..." statement is printed, but the comma is the 45th
character after the 44h . Like wise the '/' after the 8 is printed inspit
--- Comment #15 from rguenth at gcc dot gnu dot org 2005-12-06 13:43
---
So, CCing zdenek. Btw., checking -floop-optimize2 may also be worth trying
(setting up a rpoper chroot now).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from bergner at vnet dot ibm dot com 2005-12-06 13:40
---
sizeof(unsigned long) and sizeof(unsigned long long) are both 8 bytes on ppc64.
Olaf, -O1 isn't a workaround, it's the minimum optimization level that still
shows the bug. Trying some -fno-* options, using -fno-
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-12-06 13:39
---
hmhm, maybe I'm in a ppc32 chroot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25248
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-12-06 13:37
---
Note that in the reduced testcase we have
pr25248.c: In function ?htab_bolt_mapping?:
pr25248.c:15: warning: integer constant is too large for ?unsigned long? type
pr25248.c: In function ?main?:
pr25248.c:24: warn
1 - 100 of 119 matches
Mail list logo
