--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:08
---
Fixed in current version. FI: this was ACT bug E103-008.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from baldrick at gcc dot gnu dot org 2006-12-01 08:31
---
None of the examples provided in this bug report generate
an overlapping memcpy with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:38
---
Does not occur with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 08:43
---
Does not happen with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 09:07
---
While this doesn't happen with GNAT-GPL 2006 or GNAT Pro 5.05w (20060118),
that's not surprising because they are compiled with --disable-checking.
Here are the details of the compiler for which I get this ICE:
Please find below ada code that compiles and executes on 2 machines with
different gcc versions
Machine1 has gcc 3.3.3 and compiles and executes correctly
Machine2 has gcc 4.1.1 and compiles without warnings. It executes but produces
the wrong result. As you can see the code zeroes SL(1) and
See also: http://gcc.gnu.org/ml/fortran/2006-12/msg0.html
Tim Prince's analysis why ifort needs 8.77s and gfortran 12.16s for one
program:
My copy of gfortran makes separate scalar calls to sin and cos, where ifort
makes a vector sincos call. 2 seconds to be gained there
In the Fortran
--- Comment #1 from ubizjak at gmail dot com 2006-12-01 10:14 ---
Depends on PR tree_optimization/17687. I guess it is a time to finally resolve
that one...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2006-12-01 10:57 ---
Not only that; the glibc sincos, for example, would not gain anything. ifort
gains because it basically computes the sine and cosine using two halves of an
XMM register.
Richard had a really gross ;-) patch to do this.
--- Comment #3 from bonzini at gnu dot org 2006-12-01 11:04 ---
We need multiple steps here to solve this bug and 17687:
1) change sincos (x, s, c) to
sincos (x, t1, t2);
s = t1;
c = t2;
Don't know the best place to do this.
2) alternatively, change sincos (x, s, c)
--- Comment #5 from pedro dot lamarao at mndfck dot org 2006-12-01 11:37
---
Ah, just as I thought, but I was too sleepy to find about that function on my
own.
Must someone present this to gcc-patches or will you do it yourself?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30033
--- Comment #3 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 ---
*** This bug has been marked as a duplicate of 29867 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 ---
*** Bug 30008 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-01 12:17 ---
I wonder whether this is bug is not identically to PR 21466 sqrt() function
not vectorized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
--- Comment #14 from pluto at agmk dot net 2006-12-01 12:24 ---
no backport to 4.1/4.2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-01 12:25 ---
I wonder whether this is bug is not identically to
PR 21466 sqrt()function not vectorized
I mean for the Fortran test case:
gastest.f90:8: note: LOOP VECTORIZED.
gastest.f90:9: note: LOOP VECTORIZED.
--- Comment #10 from pault at gcc dot gnu dot org 2006-12-01 13:16 ---
Created an attachment (id=12722)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12722action=view)
This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV
Joost,
I am not sure that I see how the test
Use of long long constants produces incorrect code when cross compiling for the
hppa target on a 64 bit host
$ hppa--linux-gcc -v
Using built-in specs.
Target: hppa--linux
Configured with: /home/nick/gnu/gcc/configure --target=hppa--linux
--prefix=/home/nick/gnu/path --enable-languages=c :
--- Comment #1 from skrll at netbsd dot org 2006-12-01 13:40 ---
Created an attachment (id=12723)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12723action=view)
reduced test case from netbsd src/sys/kern/kern_uuid.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
--- Comment #13 from hjl at gcc dot gnu dot org 2006-12-01 14:49 ---
Subject: Bug 29921
Author: hjl
Date: Fri Dec 1 14:49:15 2006
New Revision: 119401
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119401
Log:
2006-12-01 Zdenek Dvorak [EMAIL PROTECTED]
PR
--- Comment #14 from hjl at lucon dot org 2006-12-01 14:51 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|ASSIGNED
On Core 2 Duo, I got
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gcc -mtune=native -S x.i -v
...
/usr/gcc-4.2/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -fpreprocessed x.i
-mtune=nocona -quiet -dumpbase x.i -auxbase x -version -o x.s
...
On Core Duo, I got
[EMAIL PROTECTED] tmp]$
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 15:24
---
The uninitialized bytes are normal: the Unit_Type structure is 16 bytes long:
type Unit_Type is
record
Position : Natural := 19;
String_Value : String (1..9) := (others =
When bootstrapping GCC trunk on Solaris 10 x86, sse3-movddup.c gives an ICE.
However, this test shouldn't even be running since I don't think my CPU has
sse3.
dev-zero:{bretta}$ isainfo -v
64-bit amd64 applications
sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
--- Comment #5 from paolo at gcc dot gnu dot org 2006-12-01 15:55 ---
Subject: Bug 29066
Author: paolo
Date: Fri Dec 1 15:55:11 2006
New Revision: 119403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119403
Log:
2006-12-01 Ryan Mansfield [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-01 16:00 ---
My gross patch will still work ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-01 16:03 ---
Btw, the gross patch is attached to PR17687.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-01 16:04
---
Not a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-12-01 16:37
---
Subject: Bug 29433
Author: rguenth
Date: Fri Dec 1 16:37:38 2006
New Revision: 119404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119404
Log:
2006-12-01 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-12-01 16:38
---
Improved for the case of building with -g, which should now be as bad as with
plain -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #11 from burnus at gcc dot gnu dot org 2006-12-01 17:20 ---
Created an attachment (id=12724)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724action=view)
test case for interface bl_copy
(In reply to comment #10)
This patch fixes the testcase of #6 and regtests on
g++ --save-temps -W -Wall bug.cc
bug.cc: In function `void p(T)':
bug.cc:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-01 17:25 ---
Created an attachment (id=12725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12725action=view)
The file g++ asked me to attach.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-01 18:04 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-01 18:05 ---
(In reply to comment #5)
Btw, the gross patch is attached to PR17687.
If you mean attachment (id=12055; patch using cexp) then note that it no longer
applies cleanly:
2 out of 5 hunks FAILED -- saving rejects to
--- Comment #6 from pinskia at gmail dot com 2006-12-01 18:19 ---
Subject: Re: ICE on valid with --std=c++0x (static_assert)
On Fri, 2006-12-01 at 11:37 +, pedro dot lamarao at mndfck dot org
wrote:
Must someone present this to gcc-patches or will you do it yourself?
I am going
--- Comment #15 from elizabeth dot l dot yip at boeing dot com 2006-12-01
20:24 ---
One of my colleaques said my test code in Bug 30025 works on his MAC OS X
system at home. He has an older version of gfortran. Here is what he wrote:
It worked using gfortran on my OS X system.
--- Comment #9 from ubizjak at gmail dot com 2006-12-01 20:54 ---
(In reply to comment #8)
I wonder whether this is bug is not identically to
PR 21466 sqrt()function not vectorized
Have you tried patch at
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01819.html?
The VLA - normal
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01
21:01 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 MRO
No problem. If the compiler is not being miscompiled, I will be able to
look at it
--- Comment #32 from tkoenig at gcc dot gnu dot org 2006-12-01 21:04
---
Subject: Bug 29568
Author: tkoenig
Date: Fri Dec 1 21:04:38 2006
New Revision: 119412
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119412
Log:
2006-12-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #33 from tkoenig at gcc dot gnu dot org 2006-12-01 21:18
---
Fixed on trunk.
I'll be waiting for some time for any regressions before
backporting to 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
when a coder writes (erroneously) such a code:
char *m_strrtrim(char *s) __attribute__((nonull(1));
char *m_strrtrim(char *s)
{
int len = s ? strlen(s) : 0;
while (len 1 isspace((unsigned char)s[len - 1]))
len--;
return s + len;
}
Then gcc uses the
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:28
---
Subject: Bug 30021
Author: reichelt
Date: Fri Dec 1 21:28:35 2006
New Revision: 119415
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119415
Log:
PR c++/30021
* c-common.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 21:29
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:35
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 21:35:25 2006
New Revision: 119416
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119416
Log:
PR c++/30022
* typeck.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-01 22:01 ---
nonnull attribute to the function says the function's argument is non null at
the time we enter the function so assuming that is correct.
Also this is documented this way:
nonnull (arg-index, ...)
The nonnull
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-01 22:06 ---
Fixed on the branch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01
22:22 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 MRO
DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by
a check on def_insn.
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 22:27
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:27:03 2006
New Revision: 119418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119418
Log:
PR c++/30022
* typeck.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-12-01 22:29
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:29:13 2006
New Revision: 119419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119419
Log:
PR c++/30022
* typeck.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-12-01 22:32
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:32:00 2006
New Revision: 119420
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119420
Log:
PR c++/30022
* typeck.c
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-12-01 22:33
---
Fixed on mainline, 4.2 branch, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from madcoder at debian dot org 2006-12-01 22:45 ---
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-01 22:49 ---
(In reply to comment #2)
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo'
--- Comment #4 from manu at gcc dot gnu dot org 2006-12-01 23:36 ---
I am working in a patch but don't expect it too soon. Yet, I am quite advanced,
that is why I am accepting it. If this is not the proper way to do it, please
let me know.
--
manu at gcc dot gnu dot org changed:
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
--- Comment #6 from dfranke at gcc dot gnu dot org 2006-12-02 00:12 ---
Fixed on trunk, closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2006-12-02 02:15 ---
Subject: Bug number PR c++/28284
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/2006-12/msg00064.html
--
--with-mpfr=/tmp/gcc-inst --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20061201 (experimental)
--
Summary: ICE in tsubst, at cp/pt.c:7359
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority
--- Comment #1 from pcc03 at doc dot ic dot ac dot uk 2006-12-02 02:47
---
Created an attachment (id=12727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12727action=view)
minimal test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30044
--- Comment #4 from zackw at panix dot com 2006-12-02 05:19 ---
Andrew, please don't close enhancement requests WONTFIX because you think
they're too hard to implement. There is no harm in leaving them open in case
someone decides that it's not too hard and they're going to code it.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-02 05:52 ---
The main issue I have emitting a warning here is that it will produce a bunch
of false positives for an example:
static int f(int *a)
{
if (a)
return *a;
return -1;
}
int g(int *a, int c)
While thinking about PR 30043 a little, I also looked into the code for VRP and
noticed if we had the CHAIN decl while checking for nonnull we could crash so I
wrote a testcase that crashes with -O2 -fno-inline:
int f(int *a)
{
int __attribute__((nonnull(1))) g(int *b)
{
int **c = a;
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2 4.2.0 4.3.0
Known to work|
--- Comment #6 from zackw at panix dot com 2006-12-02 06:00 ---
Subject: Re: __attribute__((nonull(...))) and silent optimizations
Well, it's just like 'may be used uninitialized' false positives,
isn't it? The warning shouldn't issue from the VRP pass, we should
have some kind of
--- Comment #7 from zackw at panix dot com 2006-12-02 06:04 ---
Subject: Re: __attribute__((nonull(...))) and silent optimizations
Also: my main concern here is not the technical details of the feature
but my dislike for your tendency to blow off bug reports that you
think are bogus
The following crashes g++-4.1.1:
template typename T
void boom ( T a ) {
T tmp = a;
}
template typename T
void null_op ( void ) {}
typedef void(F)( void );
int main ( void ) {
F f = null_opint;
boom( f );
}
gcc /added/pkg/gcc-4.1.1/usr/bin/g++ -v
Using built-in specs.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:27 ---
This testcase should be testing on your machine. GCC should not ICE on this
testcase anyways.
Also when it runs the if statement:
/* Run SSE3 test only if host has SSE3 support. */
if ((cpu_facilities
The following code prints an incorrect return value from F.
#include iostream
#include vector
int F()
{
std::vectorchar buffer; // this can be any container
std::cout std::endl;
return 12345;
std::cout std::endl;
}
int main()
{
std::cout F()
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-02 07:35 ---
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
And this works for me with 4.1.0 20051026 and 4.1.2 20061125
Oh this is a dup of 29435.
*** This bug has been marked as a duplicate of 29435 ***
--
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-12-02 07:35
---
*** Bug 30042 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 2006-12-02 07:39 ---
Confirmed, not a regression, goes back to at least 2.95.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:42 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-02 07:56 ---
I don't run into this failure when building libgfortran for spu-elf.
Can you provide the preprocessed temp?
Also by the way newlib for most targets don't have enough of POSIX to be able
to run the libgfortran
76 matches
Mail list logo
