--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-26 08:14 ---
Thanks Steve :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-07-26 07:50 ---
It might be, can you attach the preprocessed source? Which you can find by
adding -save-temps and it will be either end in .i or .ii. The difference in
glibc versions could be cause different warnings to show up
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-07-26 08:41
---
Created an attachment (id=13985)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13985action=view)
Result on avr target from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #11 from cnstar9988 at gmail dot com 2007-07-26 08:13 ---
Created an attachment (id=13981)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13981action=view)
(64bit)gcc -m32 -O3 -Wall test.c -save-temps
(64bit)gcc -m32 -O3 -Wall test.c -save-temps
In this platform, it's
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-07-26 08:10
---
This is a bug in glibc version you are using, the warning is comming from the
expansion of a #define. Looking at the expanded version, I see that glibc is
violating C aliasing rules anyways so the code might not
--- Comment #2 from j at uriah dot heep dot sax dot de 2007-07-26 08:39
---
Created an attachment (id=13983)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13983action=view)
Result on i386 target from GCC 3.4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #7 from burnus at gcc dot gnu dot org 2007-07-26 09:49 ---
Patch looks OK and regtests on x86-64.
That's strange - for me, it breaks ret_pointer_2.f90, at the statement print
*,
x(3) because the elements in the data transfer are incorrectly referenced.
In the
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-26 10:01
---
Well, honestly not. Still other frontends do not do return type promotion
themselves, so the backend is responsible for doing this. Do you have any
suggestion on what target to look at to verify this?
--
--- Comment #2 from tehila at il dot ibm dot com 2007-07-26 10:46 ---
(In reply to comment #2)
Just want a clarification:
I see you're compiling on PPU (since you're using -maltivec).
Does this problematic also on SPU? Does SPU has this LHS hazard?
Another question:
lwz r0,-20(r1)
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-26 10:33 ---
Maybe related to PR32891.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rask at gcc dot gnu dot org 2007-07-26 09:33 ---
Reopening since this was only partially fixed.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from j at uriah dot heep dot sax dot de 2007-07-26 08:40
---
Created an attachment (id=13984)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13984action=view)
Result on i386 arch from GCC 4.1.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32901
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 ---
Subject: Bug 32843
Author: rguenth
Date: Thu Jul 26 09:13:58 2007
New Revision: 126950
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126950
Log:
2007-07-26 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #12 from cnstar9988 at gmail dot com 2007-07-26 08:20 ---
I want the warning.
but why the warning is glibc's bug?
because memset(x,19,0), is buggy code.
I need the warning.
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-26 09:20 ---
(In reply to comment #5)
This fixes the PR but is not regtested:
Patch looks OK and regtests on x86-64.
That's strange - for me, it breaks ret_pointer_2.f90, at the statement print *,
x(3) because the elements in
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2007-07-26
09:23 ---
Fixed by:
http://gcc.gnu.org/viewcvs?view=revrevision=126942
r126942 | ian | 2007-07-26 04:27:34 +0400 (Thu, 26 Jul 2007) | 7 lines
* combine.c (combine_max_regno): Remove. Remove all uses.
--- Comment #7 from cnstar9988 at gmail dot com 2007-07-26 07:45 ---
test.c:14: warning: statement with no effect
So I think it is gcc warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
--- Comment #4 from pluto at agmk dot net 2007-07-26 10:53 ---
(In reply to comment #3)
Maybe related to PR32891.
sip-qt problems == PR30052
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32900
--- Comment #5 from drs at nrao dot edu 2007-07-26 14:48 ---
I have exactly the same problem with gcc 4.2.1 on a powerpc osx system:
oz:~/bug root# gcc -DMONOLITH -I. -fPIC -fno-common -DOPENSSL_PIC -DZLIB
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DB_ENDIAN -c
-o
There is a typo in libjava/classpath/gnu/java/security/util/Base64.java's
decode function.
public static byte[] decode(final byte[] src, final int off, final int len)
{... }
The following loop ends up throwing an exception on correct input.
A continue line is missing, as shown below.
When the
--- Comment #8 from belyshev at depni dot sinp dot msu dot ru 2007-07-26
19:48 ---
Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus
java) with patch from comment #6 on alphaev56-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32522
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-26 19:52 ---
Created an attachment (id=13987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13987action=view)
testcase
Whoops - I have boot headers installed!? Try again.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 ---
Ah, woops, many apologises. Too long since I've looked at list::size, I forgot
which way around libstdc++ differed from the rest of the world :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 20:21 ---
Created an attachment (id=13988)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13988action=view)
preprocessed testcase (trunk)
Note preprocessed source is incompatible wrt different gcc versions and so
useless
The frontend creates a tree gfc_c_int_type_node in multiple places, to
represent integers the same size as C int. This is unnecessary, as the same
thing is found in the tree integer_type_node defined by the middle-end.
Assigning this to myself.
--
Summary: Replace
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-07-26 22:16 ---
Currently fighting namelists ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dmixm at marine dot febras dot ru 2007-07-27 01:24
---
Yes, results are:
avr-gcc-3.3.6: O0 -- 75, O1,O2,O3,Os -- 79
avr-gcc-4.2.1: O0 -- 109, O1,O2,O3,Os -- 79
The mistake is corrected? It is possible to tell and so as now
application of keys of optimization
--- Comment #6 from scovich at gmail dot com 2007-07-26 22:51 ---
I've observed several more pieces of code where this bug comes up, and it
always seems to be a case of (a) the compiler duplicating a register to
preserve the value after a 2-operand insn can clobbers the original, then
--- Comment #9 from falk at debian dot org 2007-07-26 22:49 ---
(In reply to comment #8)
Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus
java) with patch from comment #6 on alphaev56-unknown-linux-gnu.
So, are you going to post the patch to gcc-patches?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
|
--
chris at bubblescope dot net changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
lexicographical_compare is used to implement operator and friends on all
containers. The code is not optimised for random_access iterators, where we can
find which list is the longest before starting and save one comparison every
loop.
Replace the following line:
for (; __first1 != __last1
--- Comment #1 from pault at gcc dot gnu dot org 2007-07-26 19:27 ---
(In reply to comment #0)
The problem looks similar to PR31205 in so far that gfortran did the
Tobias,
This PR is caused by the patch for pr31205. If you reference x1 in set, for
example by another print, it works
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-26 18:22 ---
Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
Also, it requires boost :)
On 7/26/07, Daniel Berlin [EMAIL PROTECTED] wrote:
Preprocessed source please.
I don't make installed
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #4 from sje at cup dot hp dot com 2007-07-26 17:19 ---
Fix is checked in.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #21 from zadeck at naturalbridge dot com 2007-07-26 17:35
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
Seongbae Park (???, ???) wrote:
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch extends the fix in
program test_gfortran
implicit none
!test case 1, similar to PR26074
integer, parameter :: len = 1
integer, parameter :: arr(max(len,1)) = (/1/)
!test case 2
character(len=*), dimension (1), parameter :: specStr =
--- Comment #11 from sje at cup dot hp dot com 2007-07-26 16:44 ---
Sorry, I missed the fact that it was a regression. I will test the 4.2 branch
and then backport it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--- Comment #9 from sje at cup dot hp dot com 2007-07-26 16:30 ---
The fix for this was approved and checked into mainline.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2007-07-26 15:02
---
Unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-26 13:57 ---
(In reply to comment #12)
I want the warning.
but why the warning is glibc's bug?
Andrew already tried to explain. It is a side-effect of a bug in glibc.
because memset(x,19,0), is buggy code.
I need the
--- Comment #19 from zadeck at naturalbridge dot com 2007-07-26 11:51
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
This patch extends the fix in
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
to handle the case of clobbers inside conditional calls.
This
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-26 09:58 ---
Confirmed. This is caused by
2007-04-17 Mark Mitchell [EMAIL PROTECTED]
PR c++/31513
* call.c (convert_for_arg_passing): Convert bitfields to their
declared types.
which causes us to
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-26 09:14 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 07:42 ---
can gernerate warning on gcc-4.2.1 on x86
What is the warning? Because I am not seeing it.
It might be that glibc is doing the warning. Can you paste the warning you are
getting?
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mmitchel at gcc dot gnu dot
|dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-26 21:19 ---
PR 32596 is the ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-26 20:02 ---
This is fixed by:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 126885)
+++ gcc/fortran/trans-decl.c(working copy)
--- Comment #1 from pcarlini at suse dot de 2007-07-26 19:35 ---
Well, in our current, C++03, implementation, definitely list::size is O(N). The
issue is thorny, as you know well. For C++0x, Howard has a proposal related to
the additional splice overload, I'm not sure which is the
This is picked up from http://gcc.gnu.org/ml/gcc/2007-07/msg00681.html ,
apologises if it has already been dealt with.
Both std::string and std::list do not compare lengths before comparing elements
in operator==. In std::string this increases the chances of quitting early and
produces a small
--- Comment #2 from dberlin at gcc dot gnu dot org 2007-07-26 18:21 ---
Subject: Re: [4.2 Regression] PRE goes crazy on YQPkgTechnicalDetailsView.cpp
Preprocessed source please.
I don't make installed versions of the compiler to play with :)
On 25 Jul 2007 11:46:35 -, rguenth at
--- Comment #22 from seongbae dot park at gmail dot com 2007-07-26 17:56
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Seongbae Park (???, ???) wrote:
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This
F95, 5.4 Namelist Statement, 1st Constraint:
A namelist-group-object shall not be [...] a pointer, a variable of a type
that has an ultimate component that is a pointer [...].
This code is accepted by gfortran-20070725:
TYPE :: tt
INTEGER, POINTER :: x
END TYPE
TYPE(tt) :: t
NAMELIST /nl2/ t
--- Comment #14 from pinskia at gmail dot com 2007-07-26 16:51 ---
Subject: Re: warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think that is a sensible feature request, am I missing something Andrew?
memset
--- Comment #10 from pluto at agmk dot net 2007-07-26 16:37 ---
(In reply to comment #9)
The fix for this was approved and checked into mainline.
resolved/fixed? what about 4.2 branch? it's a regression.
--
pluto at agmk dot net changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-26 16:19 ---
Note that this is fixed in Classpath and gcj 4.3.
As I recall, Casey (? I think) consolidated all the Base64
implementations into a single good one.
--
tromey at gcc dot gnu dot org changed:
What
Hi,
I know, wenn man uses strcmp(const char* s1, const char* s2), Null pointer
values for s1 and s2
are treated the same as pointers to empty strings.
But I can only get SegFault in my application, because s1 or s2 sometimes
may be NULL.
I am using g++ version 3.4.3 20041212 (Red Hat
--- Comment #7 from dje at gcc dot gnu dot org 2007-07-26 12:53 ---
v0 (and v10 are scratch registers and not saved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
I found the following program on my disc; it might well belong to some PR, but
I could not find it anywhere in bugzilla.
I think the program is valid; due to the default initializer, it should print
2 (as it does with g95, NAG f95, ifort, openf95), but gfortran prints 4.
The problem looks similar
--- Comment #42 from debian-gcc at lists dot debian dot org 2007-07-26
11:20 ---
*** Bug 32900 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
The error message of using sizeof() as aktual argument to a default-kind
integer is not very clear.
One should state in the manual not only that an INTEGER is returned (which
implies default kind), but also that depending on the system the integer could
be of non-default kind.
When defining a bitfield constant where multiple bitfields have initializing
values, this constant is moved into .data in GCC 4.1. GCC 3.x could realize
it can be written and assigned as a single integer number. GCC 4.x only
realizes this situation as long as a single bitfield is initialized.
--- Comment #9 from jakub at gcc dot gnu dot org 2007-07-26 09:25 ---
But the change was in generic code, are you very sure you haven't changed ABI
on any of the targets?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
--- Comment #1 from j at uriah dot heep dot sax dot de 2007-07-26 08:38
---
Created an attachment (id=13982)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13982action=view)
Test file
Test case. Compile with -Os -S, and optionally -DONLY_ONE_BITFIELD
to see the difference.
--
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-07-26 06:57
---
case FL_UNKNOWN:
+ if (sym-attr.access == ACCESS_PUBLIC)
+ break;
if (gfc_add_flavor (sym-attr, FL_VARIABLE,
sym-name, NULL) == FAILURE)
return MATCH_ERROR;
--- Comment #12 from leo at marco dot de 2007-07-26 06:33 ---
Subject: Re: [4.2 Regression] building a crosscompiler
for arm-elf fails because of an error in cirrus.md
pbrook at gcc dot gnu dot org wrote:
--- Comment #11 from pbrook at gcc dot gnu dot org 2007-07-25 15:47
--- Comment #43 from dberlin at gcc dot gnu dot org 2007-07-26 18:03
---
On my current branch, which i will commit soon, i have
tree PTA : 14.56 ( 1%) usr 0.57 ( 1%) sys 16.98 ( 1%) wall
26372 kB ( 2%) ggc
tree alias analysis : 577.90 (26%) usr 8.72 ( 8%) sys
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-07-26 17:39 ---
Confirmed.
PR26974 has:
integer, parameter :: len = 1
integer :: arr(max(len,1)) = (/1/)
Above testcase contains:
integer, parameter :: len = 1
integer, parameter :: arr(max(len,1)) = (/1/)
--
dfranke
--- Comment #20 from seongbae dot park at gmail dot com 2007-07-26 17:27
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch extends the fix in
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
to
--- Comment #6 from rakdver at gcc dot gnu dot org 2007-07-26 12:09 ---
rs6000_conditional_register_usage ();
memset (reg_class_size, 0, 84);
gets compiled to
vxorv0,v0,v0
...
bl 0x104f0c68 rs6000_conditional_register_usage
...
stvxv0,r0,r9
addir9,r11,32
stw
--- Comment #5 from debian-gcc at lists dot debian dot org 2007-07-26
11:20 ---
*** This bug has been marked as a duplicate of 30052 ***
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
The operator== of hashtable.h (also used in ext/hash_map.h) is broken. Even if
the two hash tables being compared have the same key/value pairs, if the number
of *buckets* is different, the == operator returns false. Looking at the code
for the ==operator (line 698 of hashtable.h in the trunk of
--- Comment #3 from sje at gcc dot gnu dot org 2007-07-26 17:11 ---
Subject: Bug 32087
Author: sje
Date: Thu Jul 26 17:11:24 2007
New Revision: 126959
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126959
Log:
PR tree-optimization/32087
* tree-ssa-loop-manip.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-26 17:02 ---
(In reply to comment #2)
(In reply to comment #2)
Just want a clarification:
I see you're compiling on PPU (since you're using -maltivec).
Does this problematic also on SPU?
No because extraction from a vector
--- Comment #15 from manu at gcc dot gnu dot org 2007-07-26 16:58 ---
(In reply to comment #14)
Subject: Re: warning for memset with zero size
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think that is a sensible feature request, am I
On 26 Jul 2007 13:57:41 -, manu at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
I think that is a sensible feature request, am I missing something Andrew?
memset with a zero size is valid code.
Thanks,
Andrew Pinski
--- Comment #9 from cnstar9988 at gmail dot com 2007-07-26 08:02 ---
Created an attachment (id=13980)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13980action=view)
file
gcc -m32 -O3 -Wall test.c -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32887
--- Comment #15 from patchapp at dberlin dot org 2007-07-27 05:47 ---
Subject: Bug number PR32760
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/msg01960.html
--
--- Comment #17 from dominiq at lps dot ens dot fr 2007-07-27 05:56 ---
Subject: Re: [4.3 regression] HUGE(1.0d0) is written a
+Infinity on Darwin8
Maybe you could try to delete the conditional defines that redefine isfinite
so
that the native calls are used and see if the
81 matches
Mail list logo
