--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 08:56 ---
This works for me on the trunk with -march=i486
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35676
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-24 08:59 ---
This is most likely a dup of bug 33009.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35675
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 09:30 ---
I am testing this patch on powerpc-darwin right now and should be able to
submit it tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31558
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-03-24 09:09
---
My patch does not work as we now don't warn for +f(); which is wrong. I am no
longer going to work on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-24 09:01 ---
(In reply to comment #5)
I am no longer working on this.
I am about to post a patch for this, I found the patch on my machine after all
this time :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29197
For the record, I see an intermitent failure (3 out of 44 tests) of
libgomp.fortran/crayptr2.f90 on i686-apple-darwin9:
rev. 132129: FAIL: libgomp.fortran/crayptr2.f90 -O2 execution test
rev. 133270: FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
--- Comment #5 from eric dot weddington at atmel dot com 2008-03-24 14:46
---
The patch in bug #33009 does indeed fix the problem that I'm seeing. Closing
bug as duplicate of #33009.
*** This bug has been marked as a duplicate of 33009 ***
--
eric dot weddington at atmel dot com
--- Comment #17 from eric dot weddington at atmel dot com 2008-03-24 14:46
---
*** Bug 35675 has been marked as a duplicate of this bug. ***
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-03-24 15:09
---
Subject: Bug 22371
Author: rguenth
Date: Mon Mar 24 15:08:52 2008
New Revision: 133479
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133479
Log:
2008-03-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-03-24 15:10
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-03-24 15:10
---
Really.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 16:08 ---
Ok, on i686-linux-gnu, I can reproduce this failure.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Consider:
templatetypename T, T struct A;
templatetypename struct B;
templatetemplatetypename T, T class U struct BUchar, 'h' {};
BAchar,'h' x;
// internal compiler error: in dependent_type_p, at cp/pt.c:15539
Comeau 4.3.9 and GCC 4.1.2 accept the code.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 16:10 ---
Does the code size difference goes away when you compare w/o -ftree-vectorize ?
It might be the case we are no vectorizing more which means we have peeled
more loops and such.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-24 16:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2008-03-24 16:23 ---
I can't reproduce this on Alpha Linux with Debian 4.2.3-2. On that system, long
double is 16 bytes. What's the length on your system? Also, can you try 4.3?
--
falk at debian dot org changed:
What
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-24 16:34
---
I think the code is violating alignment requirements of the C/C++ standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
--- Comment #2 from kmccarty at debian dot org 2008-03-24 16:47 ---
(In reply to comment #1)
Does it work with gcc 4.2?
Yes, it does, at least with this version:
(sid)[EMAIL PROTECTED]:~$ gfortran-4.2 -v
Using built-in specs.
Target: ia64-linux-gnu
Configured with: ../src/configure
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-03-24 16:48
---
I tend to agree with Andrew here. If you go through a packed union the failure
vanishes:
union U {
unsigned u;
}__attribute__((packed));
int main()
{
char buf[256];
char *dest;
int i;
dest = buf[2];
--- Comment #13 from edwintorok at gmail dot com 2008-03-24 17:00 ---
(In reply to comment #11)
I think the code is violating alignment requirements of the C/C++ standard.
First a real bug here is that -Wstrict-aliasing doesn't warn of this situation.
Do you agree?
Unaligned
--- Comment #10 from carlos at codesourcery dot com 2008-03-24 17:25
---
Greg,
I've gone through your DIY instructions. Very well done. Using the sysroot
infrastructure is definitely the way forward for you. Looking at your existing
DIY instructions you probably want to:
1. Create a
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-24 17:32 ---
Possibly a scheduling issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from w6ws at earthlink dot net 2008-03-24 17:47 ---
Subject: Re: Invalid-accepted - public entity with private
type should be diagnosed
pault at gcc dot gnu dot org wrote:
This is permitted in F2003 so you have to apply the F95 standard to extract
the
message out
/configure --disable-nls --disable-c-mbchar --disable-shared
--prefix=/emc/ucode/Linux-2x-i686/gcc3x/v4.3.0-2.18-2008-03-15
--target=i686-emc-elf --enable-languages=c++ --disable-multilib --with-gnu-as
--with-gnu-ld --with-gmp=/home/blah/gmp --with-mpfr=/home/blah/mpfr
--with-newlib
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-03-24 18:43
---
OK, I now can reproduce it. Here's a reduced testcase:
module TransferBug
type ByteType
integer(kind=1) :: singleByte
end type
type(ByteType) :: BytesPrototype(1)
contains
function StringToBytes(v)
program main
print *, foo()
contains
function foo()
integer foo(size(transfer(x, [1])))
real x
end function
end program
gives: a.f90:2: internal compiler error: Segmentation fault
gfortran 4.1.2 20070626 (Red Hat 4.1.2-14) says:
In file a.f90:5
integer foo(size(transfer(x,
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-24 19:02 ---
This was indeed fixed by PR 34529:
.L3:
stvx 0,0,9
stvx 0,9,0
addi 9,9,32
bdnz .L3
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-24 19:12 ---
Subject: Bug 33295
Author: pault
Date: Mon Mar 24 19:11:24 2008
New Revision: 133488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133488
Log:
2008-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #4 from pault at gcc dot gnu dot org 2008-03-24 19:12 ---
Subject: Bug 34813
Author: pault
Date: Mon Mar 24 19:11:24 2008
New Revision: 133488
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133488
Log:
2008-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #14 from victork at gcc dot gnu dot org 2008-03-24 19:14
---
I tend to agree with Andrew here. If you go through a packed union the
failure
vanishes:
So, IMHO this bug is invalid.
The fact that failure vanishes is not a good argument here. The failure
vanishes simply
The following program prints out the wrong results when an
array with vector valued subscript is used in an expression
as the FROM argument and also used as the TO argument.
The array case gives different results from a similar
scalar DO loop.
If a different array is used in the FROM argument,
--- Comment #1 from brian at dessent dot net 2008-03-24 19:54 ---
Subject: Re: New: Cannot build cross compiler for
i686-pc-linux-gnu: configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES
yakov at emc dot com wrote:
--target=i686-emc-elf --enable-languages=c++
--- Comment #5 from d at domob dot eu 2008-03-24 20:01 ---
Created an attachment (id=15370)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15370action=view)
Partly fixed patch
This patch fixes the problem described above with respect to correct detection
of seen_ts and adds some
When I try the following test program, a value is stored into
the first element of the complex array, even though the array
section is zero sized. It fails with variables for the
section subscripts and works if I use explicit constants
for the subscripts.
Dick Hendrickson
--- Comment #2 from yakov at emc dot com 2008-03-24 20:29 ---
Subject: Re: Cannot build cross compiler for i686-pc-linux-gnu:
configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
Brian,
first, thank you very much for such a quick response.
Actually, this target is
--- Comment #1 from dick dot hendrickson at gmail dot com 2008-03-24 20:35
---
Some similar assignment statements that work correctly
ZCA(NF1:NF10:MF1) = ZDA(NF1:NF10:MF1)
XCA(NF10:NF5:NF2) = XDA(NF4:NF9:MF2)
where the NF* variables have the value * and the
MF* variables
The following program gives the wrong value for the UBOUND
function on a zero sized array. It looks correct for constant
section subscripts, but incorrect for run-time expressions.
The related functions, LBOUND, SHAPE, and SIZE are correct.
Dick Hendrickson
C:\g_experiments\gfortrangfortran
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-24 21:11 ---
Subject: Bug 33295
Author: pault
Date: Mon Mar 24 21:10:36 2008
New Revision: 133490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133490
Log:
2008-03-24 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-24 21:11 ---
Subject: Bug 34813
Author: pault
Date: Mon Mar 24 21:10:36 2008
New Revision: 133490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133490
Log:
2008-03-24 Paul Thomas [EMAIL PROTECTED]
PR
Very simple function returns value of vector-item instead of the correct value.
Code compiles without any problem. Running it returns incorrect value.
Tried it with Intel and Microsoft compilers, both return the correct value.
Code (since I do not see a method to attach anything here...):
--- Comment #1 from lmdv_gnu at mandata dot nl 2008-03-24 21:14 ---
Created an attachment (id=15371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15371action=view)
preprocessed file of the program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-24 21:16 ---
next[0] = addNode();
This will invoke undefined behavior as the order of execution of the lhs and
rhs of the assignment expression is unspecified. So a compiler can invoke
either next[0] first or addNode()
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-24 21:28 ---
CCing Jason as he was the one who did the attribute delaying patches for 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmdv_gnu at mandata dot nl 2008-03-24 21:29 ---
Does this mean that it is correct that no assigment takes place?
Even though the returned value is an integer that has nothing to do with the
vector?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-24 21:34 ---
It means that the vector is probably re-allocated and the value stored into
dead memory. Using valgrind should uncover that fact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-24 21:35 ---
(In reply to comment #3)
Does this mean that it is correct that no assigment takes place?
So what is happening is that next[0] returns a reference and that reference
goes invalid when next.push_back(-1) gets
--- Comment #6 from lmdv_gnu at mandata dot nl 2008-03-24 21:38 ---
ok, I understand. Thanks for your help!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35686
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from t dot artem at mailcity dot com 2008-03-24 22:24
---
I'll check this out very soon - at least on Wine sources. Recompiling KDE isn't
a task I'm very found of.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
make[3]: Entering directory `/test/gnu/gcc/objdir/gcc/ada/tools'
../../gnatmake -c -I../rts -I. -I/test/gnu/gcc/gcc/gcc/ada gnatchop
--GCC=../..
/xgcc -B../../ -g -O2 -mdisable-indexing -gnatpg -gnata
../../xgcc -c -I./ -I../rts -I. -I/test/gnu/gcc/gcc/gcc/ada -B../../ -g -O2
-mdi
--- Comment #3 from t dot artem at mailcity dot com 2008-03-24 23:01
---
counting all .so and .a files in lib/wine directory:
Without -ftree-vectorize:
GCC 4.2.3: 46,884,566 bytes in 305 files
GCC 4.3.0: 47,375,178 bytes in 305 files
With -ftree-vectorize:
GCC 4.2.3: 46,889,486
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-03-24 23:06
---
Subject: Bug 26222
Author: pinskia
Date: Mon Mar 24 23:05:31 2008
New Revision: 133493
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133493
Log:
2008-03-24 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-24 23:18 ---
Error also occurs on linux.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
GCC
/* { dg-require-visibility } */
/* { dg-options -fvisibility=hidden } */
/* { dg-final { scan-hidden __ZN1s6vectorI1AEC1Ev } } */
/* { dg-final { scan-hidden __ZN1s3fooI1AEEvT_ } } */
/* Radar 5813435 */
namespace s __attribute__((visibility(default))) {
template class T
class vector {
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-25 00:42 ---
This patch will align DFP to its natural boundary.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 1917)
+++
The pdftk package fails to compile under gcc 4.3.1 from the gcc 4.3 branch due
the error...
/sw/lib/gcc4.3/bin/g++ pdftk.cc -I../java_libs -O3 -DPATH_DELIM=0x2f
-DASK_ABOUT_WARNINGS=false -fdollars-in-identifiers -DPDFTK_VER=\1.41\ -c
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-03-25
00:57 ---
This regression doesn't exist in gcc 4.2.3 on i686-apple-darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-25 01:03 ---
I don't think this is a GCC bug at all. libstdc++ can use exceptions freely
really since it is C++ code. Since there is no way to combine C++ and Java
exceptions in one TU, we reject the code. Now there is
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-03-25
01:05 ---
Created an attachment (id=15372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15372action=view)
compressed preprocessed source file for pdftk.cc
File generated with...
/sw/lib/gcc4.3/bin/g++
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-25 01:08 ---
Basically it is wrong that pdftk is using C++ I/O here really but instead java
I/O.
Anyways this is the correct error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-03-25
01:12 ---
So it is meaningless now to attempt to set
#pragma GCC java_exceptions
in c++ code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35689
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-03-25 01:15 ---
(In reply to comment #5)
So it is meaningless now to attempt to set
#pragma GCC java_exceptions
in c++ code?
This is C++ code but it is CNI code also so setting that is ok.
-- Pinski
--
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-03-25 02:53
---
Un-assigning myself. I can see valgrind errors but have been unable to isolate
the problem.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-03-25 03:42
---
All of these testcases work correctly now on the trunk (except for an extra
store for the one in comment #11 but that is PR 30271).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-03-25
04:05 ---
I've started over using the 4.3.0 release source files instead of svn and still
have the same problem.
After more checking I've narrowed this down to stage 2 ld-new, collect2 and the
xgcc from stage 1.
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-25 04:23 ---
2005-12-22 Richard Guenther [EMAIL PROTECTED]
* tree.c (tree_fold_gcd): Use build_int_cst where appropriate.
* tree-ssa-loop-ivcanon.c (create_canonical_iv): Likewise.
* varasm.c
While looking into PR 35429, I noticed this small missed optimization.
If we have:
typedef unsigned int1;
int foo(int z0, int1 z1)
{
return z0 != 0 || z1 != 0;
}
int foo1(int z0, int1 z1)
{
return z0 == 0 z1 == 0;
}
--- CUT ---
Both of those should optimize as int is the same size as
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-25 04:34 ---
Here is the patch which I am testing:
Index: fold-const.c
===
--- fold-const.c(revision 133503)
+++ fold-const.c(working copy)
@@
--- Comment #9 from pault at gcc dot gnu dot org 2008-03-25 05:34 ---
Fixed on trumk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-25 05:34 ---
Fixed on trumk and 4.3.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-25 05:42 ---
Not only did the TODO disappear but the problem SEEMs to have done so too. The
last attempt at a fix was pretty all embracing and has ensured that the
scalarizer is always getting a string expression to work with.
73 matches
Mail list logo
