--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
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
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
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
--- 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
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 #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
> >
--- 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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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|
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 #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
--- 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 #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 #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 #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 #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 #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 #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:38 ---
Same place to ICE for bounds_check_5.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 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
--- 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 #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 #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
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
66 matches
Mail list logo
