--- Comment #7 from burnus at gcc dot gnu dot org 2008-08-26 06:11 ---
Some initial patch: http://gcc.gnu.org/ml/fortran/2008-08/msg00238.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
--- Comment #12 from manu at gcc dot gnu dot org 2008-08-26 07:58 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01913.html
Please test that it fixes the ICE in i686-pc-cygwin. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37217
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-26 09:06 ---
Created an attachment (id=16147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16147action=view)
gcc41-pr36449.patch
4.1 patch which doesn't kill the optimization altogether, but instead fixes it.
--
--- Comment #8 from manu at gcc dot gnu dot org 2008-08-26 11:13 ---
(In reply to comment #7)
The goal for warnings should be to use an attribute on the specific class or
function in question, not on a per-file basis.
Care to elaborate? I don't understand what you mean here.
If the condition of the loop is tested within the loop with == or !=, it may be
beneficial to peel off the final iteration of the loop by changing the
condition to .
This happens in the attached benchmark's heapsort function where
while ((maxIdx += maxIdx) = last) {
if (maxIdx !=
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:36 ---
Created an attachment (id=16148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16148action=view)
benchmark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239
In the attached code, changing
if (numbers[maxIdx] numbers[maxIdx + 1]) maxIdx++;
to
maxIdx += numbers[maxIdx] numbers[maxIdx + 1];
gives a 10% performance speedup at -O3.
--
Summary: missed if-conversion opportunity
Product: gcc
Version:
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:39 ---
Created an attachment (id=16149)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16149action=view)
benchmark
this is a modified version of the PR37239 testcase, with the optimization
requested there performed manually.
On Darwin, we have the following since at least revision 136913 (revision
136903 seems the most likely candidate, the others being 136899, 136905, and
136912):
FAIL: g++.dg/abi/key2.C scan-assembler .globl __ZTI1fn\\t.weak_definition
__ZTI1fn\\t.section __DATA,__const_coal,coalesced
The
In the attached code, the if-conversion opportunity in PR37240 does not benefit
a Pentium 4. However, there is another optimization possible on both systems,
namely changing
while ((maxIdx += maxIdx) last) {
if (numbers[maxIdx] numbers[maxIdx + 1]) maxIdx++;
if (tmp =
--- Comment #1 from bonzini at gnu dot org 2008-08-26 11:55 ---
Created an attachment (id=16150)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16150action=view)
benchmark
same as the attachment to 37240
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242
--- Comment #55 from dominiq at lps dot ens dot fr 2008-08-26 11:57 ---
FeaPR-creep is strictly frowned upon: open a new PR.
This now pr37241.
With the patch in comment #54 all the failures reported in comment #40 are gone
without regressions
(currently regtesting gfortran).
Thanks
--- Comment #2 from bonzini at gnu dot org 2008-08-26 12:02 ---
This is missed because this:
maxIdx.1_15 = (unsigned int) maxIdx_59;
D.1923_20 = maxIdx.1_15 + 1;
D.1924_21 = D.1923_20 * 4;
D.1925_22 = numbers_9(D) + D.1924_21;
and this:
maxIdx_24 = maxIdx_59 + 1;
--- Comment #2 from bje at au1 dot ibm dot com 2008-08-26 12:29 ---
Subject: Re: [4.4 Regression] vector context sensitive
keyword vs macros
Partial fix, which fixes the testcase from this PR, but still other cases
in the made up testcase fail and I don't know if they are
--- Comment #4 from cnstar9988 at gmail dot com 2008-08-26 13:38 ---
gcc 4.3.2 20080826 failed.
#include stdio.h
unsigned int g_24;
unsigned int g_37 = 1;
unsigned char g_225;
int main (void)
{
int l_289;
for (l_289 = 1; l_289 5; l_289 += 1
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
On Linux/x86-64, revision 139590 caused the following
--- Comment #1 from hjl dot tools at gmail dot com 2008-08-26 15:07 ---
Those are Linux/ia32 only regressions:
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
Some of the headers are not created? This is the first bits the fails:
---
make[2]: Entering directory
`/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3'
...
make[3]: Entering directory
`/home/htl10/tmp-build/obj-dir/alphaev68-dec-osf5.1a/libstdc++-v3'
Making all in
Initially reported as a GDB bug:
http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-traildatabase=gdbpr=2512
but changing the compiler to GCC 4.2 eliminates the problem, so this is a GCC
bug. Bug description reproduced here for convenience:
Steps to reproduce:
1) Save the attached file
--- Comment #1 from ludovic at ludovic-brenta dot org 2008-08-26 17:43
---
Created an attachment (id=16151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16151action=view)
Source file that reproduces the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-26 17:45 ---
Some of the headers are not created?
What tar did you use? Because the filename for this file goes past the limit
of a POSIX tar, GNU tar is required to untar the GCC now.
--
pinskia at gcc dot gnu dot org
--- Comment #2 from ludovic at ludovic-brenta dot org 2008-08-26 17:49
---
Note that 4.1.2 fails in a different way than 4.3.1 and trunk.
--
ludovic at ludovic-brenta dot org changed:
What|Removed |Added
--- Comment #2 from htl10 at users dot sourceforge dot net 2008-08-26
18:04 ---
Oh dear, sorry about the noise - Looking at my own error message about the
missing files and where they are, I found that it is the vendor tar which is
broken - it truncates file path names to 100
--- Comment #3 from htl10 at users dot sourceforge dot net 2008-08-26
18:06 ---
Yes, mid-air collision - I realised the problem as soon as I looked at my own
bug report and looked at the directory again.
Still, the POSIX tar vs GNU tar issue could be spelt out a bit :-(.
(spent a few
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-26 18:10 ---
Can somebody update the platform-specific notes please:
http://gcc.gnu.org/install/specific.html ?
Still, the POSIX tar vs GNU tar issue could be spelt out a bit :-(.
(spent a few days on this...)
It is
--- Comment #5 from htl10 at users dot sourceforge dot net 2008-08-26
18:19 ---
(In reply to comment #4)
From that link:
GNU tar version 1.14 (or later)
Necessary (only on some platforms) to untar the source code. Many systems' tar
programs will also work, only try GNU tar if you
--- Comment #2 from hjl dot tools at gmail dot com 2008-08-26 18:22 ---
These are regressions on Linux/ia64:
+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90 -O0 execution test
+FAIL: gfortran.dg/list_read_8.f90 -O1 execution test
+FAIL:
--- Comment #61 from janis at gcc dot gnu dot org 2008-08-26 18:28 ---
I've got a huge patch now that modifies 359 tests to use the correct one of
dg-error, dg-warning, or dg-message, and splits combined checks into multiple
checks. In the tests I've modified I've also added some of
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-08-26 19:03 ---
Subject: Bug 37219
Author: pinskia
Date: Tue Aug 26 19:02:05 2008
New Revision: 139605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139605
Log:
2008-08-26 Andrew Pinski [EMAIL PROTECTED]
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.2 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
--- Comment #3 from hjl dot tools at gmail dot com 2008-08-26 20:03 ---
On Linux/ia32, it also miscompiled 416.gamess in SPEC CPU 2006.
with -O2 -msse2 -mfpmath=sse -ffast-math.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2008-08-26 20:09 ---
We got
Running 416.gamess ref base lnx32-gcc default
416.gamess: copy #0 non-zero return code (rc=0, signal=11)
416.gamess: copy #0 non-zero return code (rc=0, signal=11)
416.gamess: copy #0 non-zero return
The diff adds support for dl_iterate_phdr from FreeBSD 7.0 libc, and also uses
--as-needed when linking to libgcc_s.
The main spec source is the FreeBSD spec from their cvs.
The extras for dl_iterate_phdr adapted (they set -D__GLIBC__=3 on the
cmdline/Makefile) on the code/config.
This is only
--- Comment #1 from the_paya at gentoo dot org 2008-08-26 20:28 ---
Created an attachment (id=16152)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16152action=view)
patch against gcc-4.3.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-08-26 20:39 ---
Patches go to [EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
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 2008-08-26 20:46 ---
I think this is a dup of bug 30521.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37240
--- Comment #5 from tehila at il dot ibm dot com 2008-08-26 20:47 ---
(In reply to comment #3)
The meaning here is to the second
for (j = 0; j 4; j++)
loop.
It's loop #4 in cunrolli pass.
cunrolli doesn't recognize # of iterations = 4.
I think it doesn't recognize it starts
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-26 21:16 ---
This could be due to array indexing lowered to POINTER_PLUS_EXPR.
Array indexing is never lowered using POINTER_PLUS_EXPR, only for pointers it
is. Though it looks like
we are doing the math in unsigned in one
when calling a function with an function call address as argument, the address
is passed incremented by 1. it may work some times, but often crashes.
It can be verified in the dumpfile (.dm), the error is also present in hex
file.
the function call is netif_add (see below) argument
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from the_paya at gentoo dot org 2008-08-26 21:43 ---
My bad, sent.
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01988.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37246
--- Comment #5 from hjl dot tools at gmail dot com 2008-08-26 22:24 ---
Linux/x86-64 only regressions are
+FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL:
In short, when passing a bitfield as parameter, each bit is converted to bytes
before being tested instead of a simple mask and test.
Is there a way to disable bit to bytes conversion by a compilation switch,
I have never seen that producing better code up to now?
$ cat tmp2.c
struct
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-26 22:50 ---
BIT_FIELD_REF was removed because it caused wrong code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hjl dot tools at gmail dot com 2008-08-27 00:05 ---
On Linux/Intel64, I got
Running 434.zeusmp ref base lnx32e-gcc default
434.zeusmp: copy #0 non-zero return code (rc=0, signal=11)
with -O2 -ffast-math.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
This bug is related to bug 2707. I think the following code should generate a
warning:
int64_t i = 9223372036854775807ll;
int32_t j = i;
It does not generate any warnings with gcc-4.2.1 -Wall -Wextra.
--
Summary: gcc does not warn on trucate of int64_t to int32_t
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-27 02:34 ---
try -Wconversion, which works like what you want it to work in 4.3 and above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37249
Since at least 4.0, some or all of the following functions are no longer
available in GCC, yet they're still in the documentation. See also comments in
bug #20049. Could someone please remove references to them?
__builtin_ia32_loadaps
__builtin_ia32_loadddup
__builtin_ia32_loadsss
--- Comment #5 from astrange at ithinksw dot com 2008-08-27 04:27 ---
Fixed.
--
astrange at ithinksw dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from astrange at ithinksw dot com 2008-08-27 04:28 ---
Fixed.
--
astrange at ithinksw dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from astrange at ithinksw dot com 2008-08-27 04:28 ---
Fixed.
--
astrange at ithinksw dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from bonzini at gnu dot org 2008-08-27 04:40 ---
*** This bug has been marked as a duplicate of 30521 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2008-08-27 04:40 ---
*** Bug 37240 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2008-08-27 04:40 ---
see PR37240 for another testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
--- Comment #3 from astrange at ithinksw dot com 2008-08-27 04:41 ---
Now it is.
--
astrange at ithinksw dot com changed:
What|Removed |Added
Summary|IRA
59 matches
Mail list logo
