Right now, pack/unpack
a) use memcpy, even if a native type is available
b) convert mask arguments of kind 1 and 2 to default
logical kind, which wastes cycles and memory
Case b) is actually true of all intrinsic functions with mask.
--
Summary: performance of pack/unpack
--- Comment #26 from tkoenig at gcc dot gnu dot org 2007-08-03 05:53
---
Subject: Bug 32770
Author: tkoenig
Date: Fri Aug 3 05:52:52 2007
New Revision: 127178
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127178
Log:
2007-08-03 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #3 from kinetik at flim dot org 2007-08-03 05:11 ---
(In reply to comment #2)
> asm ("lea %1(%2), %0"
>: "=r" (i)
>: "i" (offsetof(struct coord, y)),
> "r" (c)
>: "memory");
Bug #29357 suggests that I need to use %c1 rather than %1 here, an
--- Comment #2 from kinetik at orcon dot net dot nz 2007-08-03 04:51
---
Using a memory operand to pass the offset value is not ideal in the first
place, but I'm not sure how else I can do it. It looks like the "i" contraint
(immediate value) is what I want, but the following code:
--- Comment #1 from kinetik at orcon dot net dot nz 2007-08-03 04:48
---
Created an attachment (id=14014)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14014&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32971
The following test case fails to compile without optimization with gcc 4.3.0
(20070503 (experimental)), 4.1.2 (20070502 (Red Hat 4.1.2-12)), and 4.0.4
(20060904 (prerelease) (Debian 4.0.3-7)), but succeeds with 3.3.6 (Debian
1:3.3.6-15) and 3.4.6 (Debian 3.4.6-5). With optimization (-O and -O2), i
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-03 04:46 ---
I Know how to fix the problems with spacing and rrspacing. Patch is
forthcoming.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from kargl at gcc dot gnu dot org 2007-08-03 04:29 ---
Change severity to "normal". Yes, I know the bug is "critical"
to Wirawan, but a Fortran bug is rarely considered "critical".
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from dominiq at lps dot ens dot fr 2007-08-03 00:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> I think that we may be converging on a patch. Can you test
> the attached diff?
I have converged in the same direction (modulo the coding sty
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2007-08-03 00:04 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote:
>
> I think you need the same kind of machinery
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 23:49 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:02:55PM -, dominiq at lps dot ens dot fr wrote:
>
>
> --- Comment #8 from dominiq at lps do
--- Comment #8 from dominiq at lps dot ens dot fr 2007-08-02 23:02 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> Can you try the attached patch?
It fixes the problem for -fdefault-integer-8, but without it,
it gives on your test (and others) the infamous
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-02 23:01 ---
Are you sure that this is not a bug in the ecj version that is on the ftp site?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 22:29 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote:
>
> look to yours, but with -fdefault-integer-8, I get '1
--- Comment #5 from drow at gcc dot gnu dot org 2007-08-02 21:59 ---
Nathan Froyd checked in a patch for this.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:42 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 11:17:02PM +0200, Dominique Dhumieres wrote:
>
> look to yours, but with -fdefault-integer-8, I get '1
--- Comment #4 from dominiq at lps dot ens dot fr 2007-08-02 21:17 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
> What is the -fdump-tree-original for
without:
{
int4 D.966;
D.966 = _gfortran_selected_int_kind (&i);
_gfortran_transfe
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 21:06 ---
Subject: Re: selected_(int|real)_kind fail with -fdefault-integer-8
On Thu, Aug 02, 2007 at 10:55:45PM +0200, Dominique Dhumieres wrote:
>
> I applied your patch, but on PPC Darwin I get 10 times
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-02 20:56 ---
CONJ_EXPR< a.data[0*1+(-2)]>
The offset = -2 is generated in gfc_conv_expr_descriptor:
offset = gfc_index_zero_node;
for (n = 0; n < ndim; n++) // ndim = 2
start = info->start[dim]; // st
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 20:55 ---
Subject: Re: selected_(int|real)_kind fail with
-fdefault-integer-8
Steve,
I applied your patch, but on PPC Darwin I get 10 times 1 for int, instead of:
1
1
2
2
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 20:38 ---
Same place to ICE for bounds_check_5.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-08-02 20:32 ---
Subject: Re: Compiling equiv_7_db.f90 gives an error with -fdefault-integer-8
On Thu, Aug 02, 2007 at 08:26:44PM -, tkoenig at gcc dot gnu dot org wrote:
>
> If we use -fdefault-integer-8 on
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-08-02 20:26 ---
If we use -fdefault-integer-8 on code which includes common
or equivalences, we should also include -fdefault-real-8.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #25 from tkoenig at gcc dot gnu dot org 2007-08-02 20:19
---
One additional thought.
When we add -fdefault-integer-8 to the testsuite (finally :-)
we should also add -fdeault-real-8 as well so the sizes
of integers and reals match in common blocks.
--
http://gcc.gnu.or
--- Comment #24 from tkoenig at gcc dot gnu dot org 2007-08-02 20:08
---
Subject: Bug 32770
Author: tkoenig
Date: Thu Aug 2 20:07:54 2007
New Revision: 127168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127168
Log:
2007-08-02 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- Comment #15 from axel at freakout dot de 2007-08-02 19:55 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
>
> as you can see there is a semicolon after call_do_IRQ(void)
> and following asm st
--- Comment #14 from pluto at agmk dot net 2007-08-02 19:42 ---
yup, i see something new :)
please look at line 12137 of i8259.i:
__attribute__((regparm(0))) void call_do_IRQ(void); __asm__(...
as you can see there is a semicolon after call_do_IRQ(void)
and following asm statement isn
--- Comment #3 from zadeck at naturalbridge dot com 2007-08-02 19:19
---
Given that the rtl passes are moving to not allow illegally shared rtl, i do
not believe that the resolution of this bug has anything to do with the
dataflow port.
If this bug is to be resolved, it will be done by
--- Comment #10 from aribrei at arcor dot de 2007-08-02 18:39 ---
(In reply to comment #9)
> See also:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
>
> So it seems you should be able to play with it now.
>
Unfortunately, I have to support older GCC version (like 4.0 and 4.1
When compiling a function with parameter of a pointer to a vector constant
type, the compiler calls a recursive function and is not able to get out.
Concretely, in gcc/cp/mangle.c file, in function write_type:
if (write_CV_qualifiers_for_type (type) > 0)
/* If TYPE was CV-qualified, we ju
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:53
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2007-08-02 17:53
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:52
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from kargl at gcc dot gnu dot org 2007-08-02 17:51 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from lmillward at gcc dot gnu dot org 2007-08-02 17:51
---
Subject: Bug 30851
Author: lmillward
Date: Thu Aug 2 17:50:55 2007
New Revision: 127167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167
Log:
PR c++/30849
PR c++/30850
PR c++
--- Comment #1 from lmillward at gcc dot gnu dot org 2007-08-02 17:51
---
Subject: Bug 30849
Author: lmillward
Date: Thu Aug 2 17:50:55 2007
New Revision: 127167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167
Log:
PR c++/30849
PR c++/30850
PR c++
--- Comment #2 from lmillward at gcc dot gnu dot org 2007-08-02 17:51
---
Subject: Bug 30850
Author: lmillward
Date: Thu Aug 2 17:50:55 2007
New Revision: 127167
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127167
Log:
PR c++/30849
PR c++/30850
PR c++
--- Comment #21 from dominiq at lps dot ens dot fr 2007-08-02 17:42 ---
Created an attachment (id=14011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14011&action=view)
new gdb session with 'watch sptr'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #7 from rob1weld at aol dot com 2007-08-02 17:24 ---
Created an attachment (id=14010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14010&action=view)
Example of kernel file that causes "inlining failed" error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31886
--- Comment #6 from rob1weld at aol dot com 2007-08-02 17:18 ---
I can confirm this too. Here is the bug report I was to post - but I searched
to see if this was already reported ;) - Here are my notes:
tree-inline.c - sorry, unimplemented: inlining failed ... function body not
availabl
--- Comment #20 from tkoenig at gcc dot gnu dot org 2007-08-02 17:17
---
(In reply to comment #19)
> I have also had a look to the results of -fdump-tree-original and to the
> assembly with and without the flag, but did not see anything obvious.
This is very strange. sptr gets clobbe
--- Comment #9 from widman at gimpel dot com 2007-08-02 17:17 ---
See also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
So it seems you should be able to play with it now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32658
--- Comment #2 from dominiq at lps dot ens dot fr 2007-08-02 17:08 ---
Subject: Re: C/Fortran interoperability and
-fdefault-integer-8
> A check of this option can be inserted at various locations during
> the parsing.
Certainly, but this will give a very interesting exercise to buil
--- Comment #8 from widman at gimpel dot com 2007-08-02 17:07 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Is it possible that rvalue references will give you an alternative for the
> > desired effect? See the relevant papers linked to from here:
> >
> > http://open-std
--- Comment #3 from dominiq at lps dot ens dot fr 2007-08-02 16:37 ---
Subject: Re: Compiling equiv_7_db.f90 gives an error
with -fdefault-integer-8
> These two examples are the poster child for
> 1) Why -fdefault-integer-8 is a bad option and should only be
>used by people who ar
--- Comment #7 from aribrei at arcor dot de 2007-08-02 16:34 ---
(In reply to comment #6)
> (In reply to comment #4)
> > I should note that I do NOT want to see this bug fixed. I would prefer to
> > hear
> > that you won't "fix" it at all. So I can exploit this behavior as there is
> >
Hi Eric, Hi Richard,
We have received a bug report against the mips64vrel-elf toolchain
which is reproducible with the mainline sources. Since it (appears
to) involve MIPS code generation and I know almost nothing about
MIPS I am passing it on to you in the hopes that you might be able
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-02 16:32 ---
For my testcase (with parameter) I find the following in the original dump:
(*D.1371)[(S.4 + D.1380) * D.1384 + D.1387] = CONJ_EXPR <(*(complex4[0:] *)
parm.1.data)[S.4 * D.1383 + D.1386]>;
Rewritten this is:
b.da
With -fdefault-integer-8 the following code:
program test_rrspacing
real x
x = 3.0
x = rrspacing(x)
print *, x, spacing(x), spacing(3.0)
x = 3.0
x = spacing(x)
print *, x
end
gives:
0.750 1.6777216E+07 2.3841858E-07
1.6777216E+07
instead of
1.2582912E+07 1.0
the following code
integer i
do i = 1, 10
print *, selected_int_kind (i)
end do
end
gives with -fdefault-integer-8 '4294967424' 10 times on PPC Darwin8 and
4294967297
8589934593
12884901890
17179869186
21474836484
25769803780
pected failures 30
# of untested testcases 64
# of unsupported tests 172
/opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran version 4.3.0
20070802 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770
--- Comment #6 from widman at gimpel dot com 2007-08-02 15:56 ---
(In reply to comment #4)
> I should note that I do NOT want to see this bug fixed. I would prefer to hear
> that you won't "fix" it at all. So I can exploit this behavior as there is no
> standards-compliant way of achievi
--- Comment #19 from dominiq at lps dot ens dot fr 2007-08-02 15:49 ---
Created an attachment (id=14009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14009&action=view)
gdb session from entering pack_internal to the crash
I have also had a look to the results of -fdump-tree-origi
--- Comment #13 from axel at freakout dot de 2007-08-02 15:05 ---
Subject: Re: gcc 4.2.0 compiled vanilla kernel
2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pluto at agmk dot net:
>
> my gcc-4.2.1 (which is almost like FSF release) produces for attached
> preprocess
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:43 ---
Subject: Bug 25446
Author: froydnj
Date: Thu Aug 2 14:42:53 2007
New Revision: 127163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127163
Log:
PR middle-end/25446
* c-objc-common.c (c_cann
--- Comment #2 from froydnj at gcc dot gnu dot org 2007-08-02 14:40 ---
Subject: Bug 25445
Author: froydnj
Date: Thu Aug 2 14:40:36 2007
New Revision: 127162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127162
Log:
PR middle-end/25445
* varasm.c (default_binds
--- Comment #17 from hjl at lucon dot org 2007-08-02 14:20 ---
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > Created an attachment (id=13550)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=vie
--- Comment #9 from ghazi at gcc dot gnu dot org 2007-08-02 14:14 ---
(In reply to comment #8)
> In my nightly automated testing I got this last night:
> < FAIL: gcc.dg/pr28796-2.c (test for excess errors)
> < WARNING: gcc.dg/pr28796-2.c compilation failed to produce executable
> ---
> >
--- Comment #4 from bergner at gcc dot gnu dot org 2007-08-02 13:42 ---
Subject: Bug 24952
Author: bergner
Date: Thu Aug 2 13:42:06 2007
New Revision: 127160
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127160
Log:
Backport from mainline.
2006-02-24 Roger Sa
--- Comment #12 from pluto at agmk dot net 2007-08-02 13:29 ---
(In reply to comment #11)
> Created an attachment (id=14004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14004&action=view) [edit]
my gcc-4.2.1 (which is almost like FSF release) produces for attached
preprocessed f
--- Comment #8 from brett dot albertson at stratech dot com 2007-08-02
12:00 ---
In my nightly automated testing I got this last night:
< FAIL: gcc.dg/pr28796-2.c (test for excess errors)
< WARNING: gcc.dg/pr28796-2.c compilation failed to produce executable
---
> PASS: gcc.dg/pr28796-
--- Comment #18 from dominiq at lps dot ens dot fr 2007-08-02 09:53 ---
The test of #17 pass on AMD64 with gfortran 4.3.0 20070713, but fails on PPC
Darwin8 with gfortran 4.3.0 20070802.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32954
--- Comment #2 from rask at sygehus dot dk 2007-08-02 09:42 ---
It's still broken as of "4.3.0 20070729 (experimental)".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29493
--- Comment #17 from dominiq at lps dot ens dot fr 2007-08-02 08:06 ---
The following reduced cas:
integer,allocatable :: foo(:,:)
allocate(foo(0,1:7))
print *, pack(foo(:,1),foo(:,1)==0,(/1,2/))
deallocate(foo)
end
gives a "Bus error" when run. It works if I replace the mask b
I've installed gcc 4.2.1 and 4.3-svn in parallel, 4.2.1 as normal compiler, 4.3
with --program-suffix=-4.3 (and with contrib/download_ecj).
Trying to use gcjavac from 4.3 results in:
$ gcjavac-4.3 test.java
java.lang.NullPointerException
at java.lang.String.(libgcj.so.9)
at
org.eclipse.jdt.
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-02 07:56 ---
The essential point is that "b" is allocatable; "a" can be a parameter or a
simple dimension(2,2) array. The kind does also not matter. If one uses only
conjg or only transpose there is no error.
Also, if one reverts
66 matches
Mail list logo
