--- Comment #34 from jv244 at cam dot ac dot uk 2008-12-20 08:58 ---
BTW, should I split this PR in 4 sub PRs, and make them block this one?
1) inline heuristics (4.3/4.4 Regression)
2) IRA mem explosion (4.4 Regression)
3) rename registers issue (?)
4) may_alias issue (?)
This makes
--- Comment #35 from steven at gcc dot gnu dot org 2008-12-20 09:54 ---
Re comment #34: Good idea, but add:
5) quadratic behaviour in find_temp_slot_from_address.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-20 09:56 ---
Fixing all targets is beyond my hacking skills.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
This is split off from PR38474 for clarity. Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
as
gfortran-4.3 -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
-march=native -funroll-loops testcase.f90
shows that about 13 hours are needed in renam
This is split off from PR38474 for clarity. Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
as
gfortran -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
-march=native -funroll-loops -fno-rename-registers testcase.f90
requires ~9.3Gb of RAM with
This is split off from PR38474 for clarity. Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
as
gfortran-4.3 -ffree-line-length-512 -g -ffree-form -ftime-report -c -O0
testcase.f90
requires about 20min in inline heuristics, estimating the stack frame size
This is split off from PR38474 for clarity. Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
as
gfortran-4.3 -ffree-line-length-512 -g -ffree-form -ftime-report -c -O3
-march=native -funroll-loops -fno-rename-registers testcase.f90
shows that a slow routi
--- Comment #2 from goeran at uddeborg dot se 2008-12-20 11:26 ---
That's true. Simply including the "is" in the symstd_msg, so the entire
message within the parenthesis would be translated as a unit, would be a
significant improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
This is split off from PR38474 for clarity, see steven's comment #35 in that
PR.
Compiling the testcase of that PR
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=16873)
should be illuminating
--
Summary: quadratic behaviour in find_temp_slot_from_address.
Product: gcc
--- Comment #36 from jv244 at cam dot ac dot uk 2008-12-20 11:30 ---
I've added
PR38582 : rename registers
PR38583 : ira
PR38584 : inline heuristic
PR38585 : compute_may_aliases
PR38586 : find_temp_slot_from_address
and turned this one in a meta bug.
--
jv244 at cam dot ac dot uk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38583
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-20 11:32 ---
affects both 4.3 and 4.4
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone
--- Comment #7 from laurent at guerby dot net 2008-12-20 12:21 ---
../trunk/configure --prefix=/n/50/guerby/install-trunk-142808
--enable-languages=c,c++ --enable-__cxa_atexit --disable-nls
--enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2
--build=arm-linux-gnueabi --host=arm-lin
--- Comment #13 from dominiq at lps dot ens dot fr 2008-12-20 13:01 ---
The patch in comment #12 fixes the pr without causing the regressions reported
in comments #8 and #9.
Compiling gcc/testsuite/gfortran.dg/char_length_7.f90 gives an ICE:
gimplification failed:
2
constant 2>
/opt/gc
--- Comment #14 from dominiq at lps dot ens dot fr 2008-12-20 14:27 ---
Regtested with -m32 and -m64 without other regression that
gcc/testsuite/gfortran.dg/char_length_7.f90. The offending line is:
! This was another bug, uncovered when the PR was fixed.
if (any(ccopy(z//mz(:)(i:j))
GNATLS 4.4.0 20081209 (experimental) [trunk revision 142610]
idecode.c:6591: assertion failed - current_cpu >= 0 && current_cpu < nr_cpus
It may be after the new year before I can investigate further. I have
a test sweep of 20081219 running now on gcc12 and once it gets past the powerpc
I will t
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
--- Comment #1 from steven at gcc dot gnu dot org 2008-12-20 15:50 ---
Probably 4.5 material (alias improvement branch).
You could try --param max-aliased-vops=0 as a work-around.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-12-20 18:34
---
Created an attachment (id=16950)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16950&action=view)
Revised patch
This is latest version of the patch. Please test.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-20 18:47 ---
Subject: Bug 36921
Author: jakub
Date: Sat Dec 20 18:46:12 2008
New Revision: 142849
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142849
Log:
PR c++/36921
* c-common.c (warn_about_parenthese
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-20 18:47 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-20 18:46 ---
This sounds more likely an overflow issue. Does -fno-strict-overflow make this
work?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-20 18:53 ---
(In reply to comment #4)
> Yes. Though you have to be careful not to create false positives for
>
> float f;
> struct X { int i; };
>
> struct X *p = (struct X *)&f;
> float *q = (float *)&p->i;
> return *q;
Actu
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-20 18:58 ---
(In reply to comment #5)
> Actually that is an aliasing violation still as you still accessing *p, yes it
> looks like it is not an access because of the address but you are still
> accessing *p really.
Oh and we do
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-12-20 21:35
---
OK well, thanks for trying. I'm glad you have a workaround,
even if it's not the one I thought. (Perhaps it was another
TRULY_NOOP_TRUNCATION combine.c fix. ISTR there were a few.)
Anyway, the problem is fixed
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2008-12-20
22:22 ---
Oddly, it appears that we see the failure of...
Running target unix/-m64
FAIL: PR16923 run
when gcc trunk is built with...
Platform: i686-apple-darwin9
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-12-20 22:33
---
Subject: Bug 37610
Author: ebotcazou
Date: Sat Dec 20 22:32:30 2008
New Revision: 142850
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142850
Log:
PR target/37610
* configure.ac (gcc_cv_
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-21 00:33 ---
Created an attachment (id=16951)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16951&action=view)
Avoid expensive inline heuristics at O0, and speed up add_alias_set_conflicts
This problem is always going to be
Hi:
use gcc4.1.2 on x86_64/linux, for example:
main()
{
long long int a;
double b;
a=4607182418800017408;
b=*(double *)&a;
printf("%f\n",b);
}
if using -O0/-O1 optimization, the result is 1.00;
but if using -O2/-O3 optimization,the result is 0.00.
i have try to close -fno-
Hi:
another bug,for example:
1.f:
subroutine aaa(a,nla,nlo)
include "1.h"
nlo=nlo-1
end
1.h:
interface
subroutine aaa(a1,nla1,nlo1)
end
end interface
i use gfortran(gcc 4.1.2) on x86_64/linux with default optimization -O2.but
compiling it give me an error
--- Comment #136 from pinskia at gcc dot gnu dot org 2008-12-21 01:58
---
*** Bug 38588 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-21 01:58 ---
No this is working as designed. GCC does warn about this case.
t.c:6: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Now in 4.4.0 and above, the same result will happen at -O1 and -O2
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-21 02:01 ---
The code compiles (well dies with an appropriate error) with
GNU Fortran (GCC) 4.2.5 20080702 (prerelease)
GNU Fortran (GCC) 4.3.3 20081120 (prerelease)
GNU Fortran (GCC) 4.4.0 20081213 (experimental) [trunk revision 1
uages=c,c++ --no-create --no-recursion : (reconfigured)
../configure --program-prefix=current- --prefix=/home/regehr
--enable-languages=c,c++ --no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20081220 (experimental) (GCC)
--
Summary: ice: verify_gimple failed
--- Comment #2 from joel at gcc dot gnu dot org 2008-12-21 02:15 ---
(In reply to comment #1)
> This sounds more likely an overflow issue. Does -fno-strict-overflow make
> this
> work?
>
No. "-O2 -fno-strict-overflow" did not work.
I also tried with -O1 and it did not work.
With -O0
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-12-21 05:28
---
This little patch eliminates the misalignment of output characters with -m32
and gets rid of a many many valgrind errors.
@@ -628,7 +637,7 @@ output_float_FMT_G_ ## x (st_parameter_d
\
while (low <= high)\
--- Comment #16 from sergeid at il dot ibm dot com 2008-12-21 07:44 ---
(In reply to comment #15)
> Re. comment #14: Yes, I suppose so. Why do you want to remove gcse-las from
> mainline. Not that I'm against it -- ideally RTL gcse.c would not work on
> memory at all anymore -- but I w
42 matches
Mail list logo
