On Fri, Aug 27, 2010 at 4:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
In fact we might want to move switch optimization up to the tree level
(just because it's way easier to deal with there). Thus, lower switch
to a mixture of binary tree jump-tables (possibly using perfect
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to
the list.
FX
Le 28 août 2010 à 11:58, Mail Delivery Subsystem mailer-dae...@googlemail.com
a écrit :
Delivery to the following recipient failed permanently:
bur...@net-b.de
Technical details of
FX wrote:
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to
the list.
I have not seen any emails since 9:53 (CEST) at fortran@ - neither
directly nor via gcc.gnu.org/ml/fortran.
Le 28 août 2010 à 11:58, Mail Delivery Subsystemmailer-dae...@googlemail.com
a
[ Redirect to gcc. This is a dev issue. ]
On 08/27/2010 10:39 PM, Tom Browder wrote:
On Fri, Aug 27, 2010 at 09:17, Andrew Haley a...@redhat.com wrote:
However, just running download_prerequisites is, IMVHO, the only sane way
to do it.
That's the solution I used, and I got a good
On Friday 27 August 2010 06:07 AM, Paul Brook wrote:
Hi,
I wish to selectively enable specific optimizations to observe its effect
on the source. My project requires me to do this analysis. It seemed, the
-f* flags would enable me to do that. But it turns out that individual
optimizations can't
On Thursday 26 August 2010 11:02 PM, Jonathan Wakely wrote:
On 26 August 2010 12:56,sharj...@cse.iitb.ac.in wrote:
a) Is there any way to observe the effect of a particular optimization,
without the obvious option of using a lot of -fno switches.
b) And do the -f* switches serve any
I'm very sceptical about or any later version instructions when
building the gcc prerequisites. In practice this can never be certain
to work, because the upstream maintainers of these tools can change
them in ways that break gcc.
Indeed, on the SPARC we seem to have problems
On Thu, 2010-08-26 at 18:16 -0700, Jeff Saremi wrote:
I'm hoping someone here could take the time to outline what I need to do (i'm
not looking for code but if you point me to some i'd appreciate it).
I'd like to track an object from the it's created until it's destroyed (in
C++). And then
Basile,
you fully understood what I was asking. And I think I understood that I may
have to rethink what I wanted to do since the effort is seemingly out-weighing
the benefits.
thanks again.
jeff
--- On Sat, 8/28/10, Basile Starynkevitch bas...@starynkevitch.net wrote:
From: Basile
On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou ebotca...@adacore.com wrote:
I'm very sceptical about or any later version instructions when
building the gcc prerequisites. In practice this can never be certain
to work, because the upstream maintainers of these tools can change
them in ways
On Sat, Aug 28, 2010 at 12:43, NightStrike nightstr...@gmail.com wrote:
On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou ebotca...@adacore.com wrote:
I'm very sceptical about or any later version instructions when
building the gcc prerequisites. In practice this can never be certain
to work,
Snapshot gcc-4.6-20100828 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100828/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Before I submit it officially for review, I want this patch to get some
exposure while I clean up a few remaining dusty corners. To test the patch on
x86_64-linux, proceed as follows:
-- Get libquad from http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 ,
then ./configure --prefix=/foo
On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
Before I submit it officially for review, I want this patch to get some
exposure while I clean up a few remaining dusty corners. To test the patch on
x86_64-linux, proceed as follows:
-- Get libquad from
On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
Before I submit it officially for review, I want this patch to get some
exposure while I clean up a few remaining dusty corners. To test the patch
on x86_64-linux, proceed as
On Sat, Aug 28, 2010 at 05:56:57PM -0700, Steve Kargl wrote:
On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
Before I submit it officially for review, I want this patch to get some
exposure while I clean up a few remaining
--- Comment #10 from davidxl at gcc dot gnu dot org 2010-08-28 06:00
---
fixed in r163610.
--
davidxl at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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=gccview=revrev=163611
Log:
PR fortran/45436
* trans-types.c
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
--- 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=21581action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45438
--- 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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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,
--- 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=21582action=view)
proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45427
--- 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 #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 your
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
--- 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=21583action=view)
test case
The code compiles cleanly with XLF.
If I switch the commented lines in the CLASS DEFAULT clause, it
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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- 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
--
--- 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 not
--
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 #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:
--- 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
--
--- 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
--
--- 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 #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 #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=21584action=view)
a new version of the patch
There were some problems with the previous patch (that could only manifest for
some
--- 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 #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=gccview=revrev=163613
Log:
PR target/41484
* config/i386/sse.md
--- 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 #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=gccview=revrev=163614
Log:
PR target/41484
* config/i386/sse.md
--- 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 #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 #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: array used as initializer
--- 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 #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 #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 #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.
--
--- 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=21585action=view)
Patch to fix the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45299
--- 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
--- 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 #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
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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 ia...@gcc.gnu.org
* config.gcc (*-*-darwin*): Adjust t-make fragments for Darwin.
--
--- 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 #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
--- 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 #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.
The
--- 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 be.
--- 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
64 matches
Mail list logo
