--- Comment #2 from daney at gcc dot gnu dot org 2008-09-20 07:25 ---
Created an attachment (id=16367)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16367&action=view)
Proposed patch.
This patch seems like it may work. I will bootstrap/test it.
--
daney at gcc dot gnu dot org
--- Comment #4 from dominiq at lps dot ens dot fr 2008-09-20 07:32 ---
With the patch in comment #3, I get
FAIL: gfortran.dg/entry_1.f90 -O0 (test for excess errors)
...
FAIL: gfortran.dg/entry_1.f90 -Os (test for excess errors)
The failure is:
/opt/gcc/_gcc_clean/gcc/testsuite/gf
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-20 08:22 ---
No, I didn't mean to ask you to try to work around it, I asked you to
investigate why omp_get_num_procs returns 1 instead of 8. The gcc 4.3 vs. 4.4
difference only affects omp_get_max_threads, not omp_get_num_procs, s
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-20 08:43
---
Subject: Bug 37585
Author: ebotcazou
Date: Sat Sep 20 08:41:55 2008
New Revision: 140511
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140511
Log:
PR ada/37585
* gcc-interface/utils.c (cr
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-09-20 08:49
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 09:07 ---
It is not possible to fix this in GCC today. But we can of course output
the debug information for decls and types from the frontends ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 09:10 ---
This is the usual trade-off of doing warnings from the frontends...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from sherpya at netfarm dot it 2008-09-20 09:43 ---
adding -fno-tree-ch avoid crashing in mencoder, so I filled the bug on this,
but it can be a side effect of something else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
--- Comment #5 from dominiq at lps dot ens dot fr 2008-09-20 10:09 ---
I just noticed that the patch in
http://gcc.gnu.org/ml/fortran/2008-09/msg00342.html has an additional test in
gcc/fortran/resolve.c:
+ && sym->ns == gfc_current_ns
This may fix the failure I have repo
--- Comment #6 from burnus at gcc dot gnu dot org 2008-09-20 11:32 ---
> I just noticed that the patch in
> http://gcc.gnu.org/ml/fortran/2008-09/msg00342.html has an additional test in
> gcc/fortran/resolve.c:
> + && sym->ns == gfc_current_ns
> This may fix the failure I h
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-20 11:52 ---
After coming back to this bug, I believe the problem is that gfc_conv_expr
takes care of finding out string lengths' for things like TRIM(x) which don't
have a cl->length, but gfc_conv_expr_descriptor which is called e
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:00
---
No feedback.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:02
---
Is this still present?
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-09-20 14:05
---
This is a corner case anyway.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:15 ---
This is not a regression as it never worked. -std=c++0x is new in GCC 4.3.
Failing since 4.3.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-09-20 14:25
---
This PR is still very weird. For the curious here are the numbers, now
with numbers from trunk included:
4.3 -O: 0.4s
4.3 -O -fstrict-aliasing: 59s
4.4 -O: 1m3s
4.4 -O -fstrict-aliasing: 0.4s
4.4 -O2: 0.3s
4.4 -O
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-09-20 14:27
---
Created an attachment (id=16368)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16368&action=view)
unincluded testcase
Unincluded testcase attached.
I'll leave this at P3 so some brave soul might eventually
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-20 14:29 ---
m68k-linux-gnu is neither primary nor secondary target.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-20 14:31 ---
This is not really spu specific. The patch is ok to backport to the branch
if you can get SPEC results for one primary target (ask HJ or Luis).
--
rguenth at gcc dot gnu dot org changed:
What|Rem
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 14:35 ---
I agree with Jakub. Joseph - are you ok with closing this as invalid?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-09-20 14:41
---
The question remains if this is invalid or valid code.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:49 ---
ui32 and ui32a are identical (they are identical in middle-end terms), but
ui32 * and ui32a * would not be identical. Sounds weird, but the way
may_alias is designed make it so. A 32bit target is required to trigge
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 14:51 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
On Linux/ia32 and Linux/x86-64, this patch
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01176.html
caused
FAIL: gcc.target/i386/asm-3.c execution test
on ira-merge branch.
--
Summary: [ira-merge] FAIL: gcc.target/i386/asm-3.c execution test
Product: gcc
Versi
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-09-20 15:06
---
Trunk does very unfunny things to this testcase as well. -fno-tree-reassoc
recovers the register allocation problems.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from hjl at gcc dot gnu dot org 2008-09-20 15:08 ---
Subject: Bug 37571
Author: hjl
Date: Sat Sep 20 15:07:46 2008
New Revision: 140514
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140514
Log:
2008-09-20 H.J. Lu <[EMAIL PROTECTED]>
PR target/37571
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-09-20 15:09
---
Please open a new report for the SSA update problem. Back to NEW for this
PR, fixed on the trunk. *-*-mingw* is not in the list of primary or secondary
platforms, so P4.
--
rguenth at gcc dot gnu dot org chan
--- Comment #6 from hjl dot tools at gmail dot com 2008-09-20 15:10 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 15:12 ---
CCing ARM maintainers so they can confirm the bug and look at its relation
to PR35964.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 15:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #5 from jdecs at mssblue dot net 2008-09-20 15:19 ---
(In reply to comment #3)
> Could you try a more recent GCC version
I am reasonably convinced that the changes Thomas made were for a known
compiler bug, using the GPS installed gnatmake to get around it. I am going to
clo
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-20 15:20 ---
4.1 ICEs after the same error 4.2 rejects the code with, 4.3 ICEs again
after the error. 4.4 doesn't error but ICEs in build_base_path, at
cp/class.c:272.
Waiting to have someone confirm the validity of the testcas
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-20 15:23 ---
Confirmed anyway. Time for a IVOPTs meta-bug ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20 15:26 ---
What happens if you remove this piece of code? I suspect we merely need
to keep the function declaration to emit proper debug information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36959
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-09-20 15:29
---
Proposed solution:
I will add another component to the st_parameter_dt union and call it q. It
will be identical to the existing component p accept with the added IOparms at
the top. In the 4.4 library we will
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-20 15:22 ---
This might be a cost issue in the ppc backend (and so target, not
rtl-optimization).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-09-20 15:41
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-09-20 15:41
---
Subject: Bug 37236
Author: rguenth
Date: Sat Sep 20 15:40:15 2008
New Revision: 140515
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140515
Log:
2008-09-20 Richard Guenther <[EMAIL PROTECTED]>
with Interfaces; use Interfaces;
package A is
Var : unsigned_8;
for Var'Address use ...
pragma Volatile (Var);
end A;
with Interfaces; use Interfaces;
with A;
procedure B is
renamed : Unsigned_8 renames A.Var;
begin
renamed := renamed or 16#01#; -- 'renamed' is kept in a register
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-20 16:37 ---
Revert revision 140504 fixes this regression.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-20
17:04 ---
Subject: Re: [4.4 Regression] gcc/libgcc2.c:404: internal compiler error:
Floating point exception
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140504
> Log:
> 2008-09-19 Vladimir Makarov <[E
$ uname -a
CYGWIN_NT-5.1 MCKELVEY-XP 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
$ g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /cygdrive/f/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --disable-win32-registry
--enable-languages=c,c++
Thread model
--- Comment #19 from brian at dessent dot net 2008-09-20 17:32 ---
Subject: Re: [4.2/4.3 Regression] VRP causes stack
overflow while building libgcj
> PR, fixed on the trunk. *-*-mingw* is not in the list of primary or secondary
> platforms, so P4.
As of 4.3 both MinGW and Cygwin a
--- Comment #3 from ajrobb at bigfoot dot com 2008-09-20 17:32 ---
Created an attachment (id=16369)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16369&action=view)
proposed 32-bit API calls for 64-bit constant divison
I have attached a sample assembler code for a API calls for th
--- Comment #1 from brian at dessent dot net 2008-09-20 17:40 ---
Subject: Re: New: Bootstrap Failure with Undefined
References
This is a dup of pr37528 which has a patch waiting to be applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37600
--- Comment #4 from burnus at gcc dot gnu dot org 2008-09-20 17:49 ---
> I marked this as regression, but it is not a true regression as it was before
> only rejected because bound-specs where not allowed at all in earlier
> gfortran versions.
Well, as testing shows, it still does not w
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-09-20 17:51
---
Oops.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P4
--- Comment #5 from tdragon at tdragon dot net 2008-09-20 17:57 ---
Any news or thoughts on this bug? (*Ping*)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
Sent from my iPhone
On Sep 20, 2008, at 8:26 AM, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-20
15:26 ---
What happens if you remove this piece of code? I suspect we merely
need
to keep the function
--- Comment #2 from pinskia at gmail dot com 2008-09-20 18:36 ---
Subject: Re: [4.2/4.3/4.4 Regression] C++ front-end causing a static inline
function to be emitted
Sent from my iPhone
On Sep 20, 2008, at 8:26 AM, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED]
> wrote:
>
>
>
--- Comment #11 from hjl dot tools at gmail dot com 2008-09-20 18:44
---
(In reply to comment #10)
> Subject: Re: [4.4 Regression] gcc/libgcc2.c:404: internal compiler error:
> Floating point exception
>
> > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140504
> > Log:
> > 200
$ ../gcc-4.4-20080919/configure --prefix=/usr --enable-threads --enable-shared
--enable-languages=c,c++,ada --host=x86_64-unknown-linux-gnu --with-system-zlib
--with-x --enable-java-awt=gtk --enable-targets=x86_64-unknown-linux-gnu
--with-arch=athlon64 --with-tune=athlon64 --with-cpu=athlon64
--dis
--- Comment #1 from gcc at spatium dot org 2008-09-20 18:57 ---
(In reply to comment #0)
current gcc ver.: 4.3.1
--
gcc at spatium dot org changed:
What|Removed |Added
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2008-09-20 19:16
---
Subject: Bug 33642
Author: ebotcazou
Date: Sat Sep 20 19:15:19 2008
New Revision: 140516
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140516
Log:
PR rtl-optimization/33642
* gcc.c-tortu
The following procedure generates an access to A because of its renaming as B,
even though no explicit access is made to A or B. I think this violates the
second sentence of C.6(20).
with Interfaces; use Interfaces;
with System.Storage_Elements; use System.Storage_Elements;
procedure
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
-
O1 -w -c -o pr36141.o
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr
36141.c(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr36141.c: In function
'ff
i_prep_closure_loc':
/test/gn
--- Comment #1 from sam at gcc dot gnu dot org 2008-09-20 20:08 ---
Rolf,
could you include the problematic assembler code? On i686-pc-linux-gnu, it
looks like it generates the expected code except for the bogus extra access
that I submitted as a separate bug in PR ada/37602:
_ada_b:
The following code generates suboptimal code on i686-pc-linux-gnu:
with Interfaces; use Interfaces;
with System.Storage_Elements;
package A is
Var : unsigned_8;
for Var'Address use System.Storage_Elements.To_Address (1000);
pragma Volatile (Var);
end A;
with A;
with Interfaces; use Interf
--- Comment #4 from joel at gcc dot gnu dot org 2008-09-20 21:24 ---
According to http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01683.html this
problem is gone. We are back down to 10 failures. Thanks.
Are there any remaining on that report, you want me to give you a back trace
on
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-09-20 21:40
---
> According to http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01683.html this
> problem is gone. We are back down to 10 failures.
OK, that's good news.
> Are there any remaining on that report, you want me to
--- Comment #3 from mmitchel at gcc dot gnu dot org 2008-09-20 21:59
---
I suspect that things have been improved so that this code is no longer
required. My expectation is that in the past we only emitted the static when
we emitted the function body, so the code made sense. But, now,
--- Comment #1 from danglin at gcc dot gnu dot org 2008-09-20 22:26 ---
This test started to fail when it was moved in r140340
from gcc.c-torture to gcc.c-torture/compile.
It doesn't fail with 4.2.4, but does with 4.3.2.
--
danglin at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Summary|boostrap failure due to |[4.4 Regression
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-20 22:48 ---
*** This bug has been marked as a duplicate of 37528 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-20 22:48 ---
*** Bug 37600 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-20 22:51 ---
Set in insn 6 is invariant (0), cost 0, depends on
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-20 22:54 ---
The original insn:
(insn 6 5 7 3 t.c:6 (set (reg:SI 3 3)
(reg/f:SI 122)) 325 {*movsi_internal1} (expr_list:REG_EQUAL (plus:SI
(reg/f:SI 113 sfp)
(const_int 8 [0x8]))
(nil)))
--
http:/
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-20 23:32 ---
(In reply to comment #4)
> This might be a cost issue in the ppc backend (and so target, not
> rtl-optimization).
GCSE is pulling out the invariant.
Before GCSE we had:
(insn 20 5 6 3 t.c:6 (set (reg/f:SI 121)
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-20 23:35 ---
GCSE in 4.1.1 did not move this for some reason ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-09-21 00:20 ---
After changing fwprop.c to do the prop if it was used only once,
loop-invariant.c pulls it out again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #2 from danglin at gcc dot gnu dot org 2008-09-21 00:23 ---
'x' is not a legitimate constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37603
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-09-21 00:26
---
Now in gain_for_invariant, size_cost is zero, even though we have a hard
register so we know it will have an extra move.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-21 00:32 ---
While looking a different bug dealing with invariant motion, I noticed that
estimate_reg_pressure_cost does not take into account the mode of the new
register. This seems like a big issue. Also init_set_costs alway
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-09-21 00:45
---
Here is another testcase which shows the issue:
int f(int b);
float g(int a)
{
while (f(a + 1));
while (f(a));
}
--- CUT ---
This increases the need for another volatile register and in fact increases
register
--- Comment #4 from ajrobb at bigfoot dot com 2008-09-21 02:39 ---
Created an attachment (id=16370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16370&action=view)
proposed 32-bit API calls for 64-bit constant divison
The original attachment did not handle shift greater than 31.
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-09-21 04:15
---
Experimental patch submitted to list for comment.
http://gcc.gnu.org/ml/fortran/2008-09/msg00353.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
79 matches
Mail list logo
