--- Comment #2 from astrange at ithinksw dot com 2010-08-29 06:39 ---
Still happens with the new combine work (not that I really expected it to
change).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44474
--- Comment #16 from jv244 at cam dot ac dot uk 2010-08-29 06:38 ---
adjust summary according to the last timings
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
---
--- Comment #15 from jv244 at cam dot ac dot uk 2010-08-29 05:31 ---
Similar times (a bit faster) with release checking:
Execution times (seconds)
garbage collection: 1.17 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall
0 kB ( 0%) ggc
callgraph construction: 0.04 ( 0%) usr
--- Comment #14 from pinskia at gcc dot gnu dot org 2010-08-29 05:23
---
(In reply to comment #12)
> >Extra diagnostic checks enabled; compiler may run slowly.
>
> Make sure you configure the trunk with --enable-checking=release to get the
> same timing results as what a release would
--- Comment #13 from jv244 at cam dot ac dot uk 2010-08-29 05:20 ---
(In reply to comment #12)
> >Extra diagnostic checks enabled; compiler may run slowly.
>
> Make sure you configure the trunk with --enable-checking=release to get the
> same timing results as what a release would be.
>
--- Comment #12 from pinskia at gcc dot gnu dot org 2010-08-29 05:13
---
>Extra diagnostic checks enabled; compiler may run slowly.
Make sure you configure the trunk with --enable-checking=release to get the
same timing results as what a release would be.
--
pinskia at gcc dot gnu
--- Comment #11 from jv244 at cam dot ac dot uk 2010-08-29 05:09 ---
After David's patch (thanks!), the testcase requires 240s, that's still a 5x
slowdown. I paste the new timing profile below, and reopen the bug. There is no
obvious candidate for the slowdown.
> gfortran -c -ftime-repo
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-29 00:55 ---
The sequencing rules have changed in C++0x, but G++ doesn't implement them yet
AFAIK, and I'm not sure if the new rules affect this example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-28
23:59 ---
I believe this was fixed by r159979...
2010-05-28 Iain Sandoe
* config.gcc (*-*-darwin*): Adjust t-make fragments for Darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44309
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-28 23:48 ---
(In reply to comment #6)
> Thank you. Don't know about C, but this is C++ in which operators are
> function.
Builtin operators are not functions.
See e.g. footnote 12 on 1.9p18 in C++ 2003 which makes it clear that b
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #6 from igodard at pacbell dot net 2010-08-28 17:49 ---
Thank you. Don't know about C, but this is C++ in which operators are function.
BTW, even in C the standard goes to some lengths in places to make things that
look like functions but have odd semantics be defined as macr
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-28 17:42 ---
Ouch!
We need some sort of lazy evaluation.
Like (pseudo-code)
bool scalar_ever_evaluated = false;
whatever_type scalar_value;
while(1)
{
/* loop handling stuff */
if (scalar_ever_evaluated)
{
--- Comment #9 from hariharans at picochip dot com 2010-08-28 17:17 ---
Fixed on mainline.
--
hariharans at picochip dot com changed:
What|Removed |Added
Stat
--- Comment #8 from hariharans at picochip dot com 2010-08-28 16:15 ---
Created an attachment (id=21585)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21585&action=view)
Patch to fix the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299
--- Comment #7 from hariharans at picochip dot com 2010-08-28 16:14 ---
picochip is a vliw processor and reorder_var_tracking_notes tries to move debug
instructions from middle of vliw instructions out. There was a bug in that
which resulted in this problem.
--
http://gcc.gnu.org/b
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-28 15:40 ---
The error message is generated in
gfc_conv_array_ref
it's called via gfc_trans_where_3 -> gfc_conv_loop_setup ->
gfc_add_loop_ss_code -> gfc_conv_variable
Thus, the condition (mask) ends up at
gfc_add_ss_to_loop
--- Comment #4 from chxanders at gmail dot com 2010-08-28 15:03 ---
Same problem on 64 bits, but it is one of the -O1 optimisations that does it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45306
--- Comment #30 from redi at gcc dot gnu dot org 2010-08-28 14:42 ---
Can we change the summary to mention references? It looks to me as though it's
talking about the address-of operator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #2 from schaub-johannes at web dot de 2010-08-28 14:39 ---
(In reply to comment #1)
> (In reply to comment #0)
> > Fails to compile, but should work:
> >
> > struct A {
> > char x[4];
> > A():x("bug") { }
> > };
> >
> > Error i get is:
> >
> > "main.cpp:3: error: ar
--- Comment #29 from redi at gcc dot gnu dot org 2010-08-28 14:39 ---
that's why EDG only gives a "remark" not a warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #9 from ubizjak at gmail dot com 2010-08-28 14:34 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from uros at gcc dot gnu dot org 2010-08-28 14:27 ---
Subject: Bug 41484
Author: uros
Date: Sat Aug 28 14:27:33 2010
New Revision: 163614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163614
Log:
PR target/41484
* config/i386/sse.md (sse4_1_extend
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-28 14:05 ---
(In reply to comment #4)
> It works though when explicitly specifying the size of z to allocate:
>
> logical, allocatable :: z(:)
> allocate ( z(3), source = [ .true., .false., .true. ] )
Congratulation - you have
--- Comment #7 from uros at gcc dot gnu dot org 2010-08-28 14:02 ---
Subject: Bug 41484
Author: uros
Date: Sat Aug 28 14:02:18 2010
New Revision: 163613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163613
Log:
PR target/41484
* config/i386/sse.md (sse4_1_extend
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-08-28 13:58
---
The same fix is needed on the 4.5 branch.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from rakdver at gcc dot gnu dot org 2010-08-28 13:39
---
Created an attachment (id=21584)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21584&action=view)
a new version of the patch
There were some problems with the previous patch (that could only manifest for
som
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 12:49 ---
Here's the fix:
Index: match.c
===
--- match.c (revision 163612)
+++ match.c (working copy)
@@ -4532,6 +4532,7 @@ gfc_match_select_type (void)
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 12:18 ---
Reduced test case:
module d_base_mat_mod
implicit none
type :: d_base_sparse_mat
contains
procedure, pass(a) :: mv_to_coo => d_base_mv_to_coo
end type d_base_sparse_mat
interface
subroutine
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-28 11:55 ---
It works though when explicitly specifying the size of z to allocate:
logical, allocatable :: z(:)
allocate ( z(3), source = [ .true., .false., .true. ] )
print *, z
end
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 11:51 ---
The following variant segfaults as well (same backtrace):
logical, allocatable :: z(:)
logical, dimension(1:3) :: src = (/ .true., .false., .true. /)
allocate ( z, source = src)
print *, z
end
--
http://gcc.gnu.o
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 11:46 ---
valgrind says:
==29743== Invalid read of size 4
==29743==at 0x52B37DB: __gmpz_set (in /usr/lib/libgmp.so.3.5.2)
==29743==by 0x532C37: conformable_arrays (resolve.c:6525)
==29743==by 0x533175: resolve_alloc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45436
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-28 11:40 ---
Note that internally there is no such thing as an operator|= for fundamental
types, but things are treated like in C. If you were in C,
sz.b |= f (&sz, &sz, &sz, 3);
there is no sequence point before |= as it's n
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-28 11:34 ---
Confirmed. One does not even need allocatable components for this. The
following also fails:
logical, allocatable :: z(:)
allocate ( z, source = [ .true., .false., .true.]) ! <<< ICE(segfault)
print *, z
end
--
ja
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywor
The following segfaults with the current trunk, a 20100701 trunk, and a 4.5.1
build.
type t
integer :: x
real :: y(5)
logical, allocatable :: z(:)
end type t
type(t) :: mt
mt%x = 1
mt%y = [1,2,3,4,5]
allocate ( mt%z, source = [ .true., .false., .true.]) ! <<< ICE(segfault)
print *, mt%x
p
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 11:15 ---
Created an attachment (id=21583)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21583&action=view)
test case
The code compiles cleanly with XLF.
If I switch the commented lines in the CLASS DEFAULT clause, it c
With trunk at r163595, I get an error message which is totally bogus:
=
[sfili...@localhost bug21]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.
--- Comment #12 from rguenther at suse dot de 2010-08-28 11:09 ---
Subject: Re: Number of iteration analysis
bogus
On Sat, 28 Aug 2010, rakdver at gcc dot gnu dot org wrote:
> --- Comment #11 from rakdver at gcc dot gnu dot org 2010-08-28 10:38
> ---
> Does the patch fix yo
--- Comment #11 from rakdver at gcc dot gnu dot org 2010-08-28 10:38
---
Does the patch fix your problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- Comment #10 from rakdver at gcc dot gnu dot org 2010-08-28 10:37
---
Created an attachment (id=21582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21582&action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- Comment #2 from dominiq at lps dot ens dot fr 2010-08-28 10:29 ---
Confirmed as a regression appearing between revisions 158215 and 158921, the
seg fault is:
Reason: KERN_INVALID_ADDRESS at address: 0x0048
gfc_conv_procedure_call (se=0x7fff5fbfd6b0, sym=0x141921b10, arg=
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-28 10:02 ---
This is invalid.
See OpenMP 3.0, 2.9.4.1, COPYIN restrictions on page 102, lines 17-18:
An array with the ALLOCATABLE attribute must be in the allocated state. Each
thread's copy of that array must be allocated w
--- Comment #1 from sfilippone at uniroma2 dot it 2010-08-28 09:04 ---
Created an attachment (id=21581)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21581&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
Hello,
Trying to debug another issue, I have found this ICE, trunk at r163595
[sfili...@localhost bug22]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured w
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-08-28 07:35
---
Subject: Bug 45436
Author: fxcoudert
Date: Sat Aug 28 07:35:10 2010
New Revision: 163611
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163611
Log:
PR fortran/45436
* trans-types.c (gfc_in
--- Comment #1 from domob at gcc dot gnu dot org 2010-08-28 07:26 ---
I agree, this is also something I thought about in the past. And to be
complete, we could also just do the other way round?
--
domob at gcc dot gnu dot org changed:
What|Removed
49 matches
Mail list logo
