This PR is meant to track one leftover item related to procedure pointer
components: No pointer assignment checking is performed yet when a PPC is
involved, cf. the TODO comment in expr.c (gfc_check_pointer_assign).
Short test case:
implicit none
type :: t1
procedure(integer), pointer,
Another PPC leftover item, cf. trans-types.c (gfc_get_ppc_type): When
translating the Fortran frontend structures to a backend tree, the argument
list of procedure pointer components is currently not being used.
This becomes visible in a test case like this:
implicit none
procedure(foo),
On AIX 5.3, g++ version 4.4.0 and 4.4.1 cannot find the libstdc++ in default
location. This did not occur with 4.3.x.
The problem has been already discussed on the mailing list in this thread:
http://gcc.gnu.org/ml/gcc-help/2009-06/msg00092.html
and a patch was issued. It was supposedly committed
--- Comment #34 from irar at il dot ibm dot com 2009-07-27 08:36 ---
(In reply to comment #33)
Using the example from comment 23 with
...
gfortran shows: test.f90:12: note: not vectorized: unsupported use in stmt.
and needs 2.272s. (By comparison. 4.4 needs 3.688s.)
This is for the
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-07-27 09:11
---
Closing (fixed).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-27 09:13 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #35 from burnus at gcc dot gnu dot org 2009-07-27 09:18 ---
(In reply to comment #34)
Does ifort vectorize the exact same implemantion of minloc?
I tried to convert the minloc implementation into Fortran loops - and the
result is at
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-27 09:24 ---
Subject: Bug 40863
Author: burnus
Date: Mon Jul 27 09:24:41 2009
New Revision: 150107
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150107
Log:
2009-07-27 Tobias Burnus bur...@net-b.de
PR
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-27 09:27 ---
FIXED on the trunk (4.5). Thanks for the bug report and sorry for the breakage.
Feel free to open a PR if build warnings show up in libgfortran. In principle,
there should be none. (I have forgotten why we cannot
--- Comment #3 from burnus at gcc dot gnu dot org 2009-07-27 09:32 ---
Subject: Bug 40851
Author: burnus
Date: Mon Jul 27 09:32:20 2009
New Revision: 150108
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150108
Log:
2009-07-26 Tobias Burnus bur...@net-b.de
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2009-07-27 09:33 ---
Thanks for the report. FIXED on the trunk (4.5); I will soon backport it to
4.4/4.3.
(Workaround: Do not use INTENT for pointers [which is a Fortran 2003 feature].)
--
burnus at gcc dot gnu dot org changed:
--- Comment #21 from paolo dot carlini at oracle dot com 2009-07-27 09:34
---
Thanks Jason. I'm tentatively recategorizing as libstdc++, then. In general,
I'm not at all sure what we should do about it, however, now that Concepts are
gone. I don't think we can hope to avoid, here and
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 09:40 ---
Confirmed. Fails with gfortran 4.1 to 4.5 and is thus no regression, but it
works with ifort, g95, openf95, and NAG f95.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-07-27 10:08 ---
The following looks wrong:
gfc_resolve_transfer (gfc_expr *f, gfc_expr *source ATTRIBUTE_UNUSED,
gfc_expr *mold, gfc_expr *size)
[...]
if (mold-ts.type == BT_CHARACTER !mold-ts.cl-length
On line 9382 of gcc/cp/decl.c there is this code
error (funcdef_flag
? %qs defined in a non-class scope
: %qs declared in a non-class scope, name);
Normally the first argument of error will be extracted for translation.
Apparently
--- Comment #36 from jakub at gcc dot gnu dot org 2009-07-27 11:02 ---
Here is the loop in C and vectorized by hand as well:
#include emmintrin.h
float arr[1024];
unsigned int
foo (unsigned int end)
{
unsigned int pos = 1;
unsigned int i;
float limit = __FLT_MAX__;
for (i = 0;
--- Comment #37 from jakub at gcc dot gnu dot org 2009-07-27 11:10 ---
Oh, and on 64-bit arches and float or 32-bit arches and double there is another
complication - the comparison has different mode size from the cond_expr for
pos. For 32-bit pos and 64-bit double it could perhaps
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-27 11:24
---
I think this is a pervasive issue and we have at least another couple of PRs
about it in Bugzilla. Please check / commonize, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
--- Comment #1 from simon_baldwin at yahoo dot com 2009-07-27 12:08 ---
Committed revision 150109.
--
simon_baldwin at yahoo dot com changed:
What|Removed |Added
--- Comment #18 from dennis dot wassel at googlemail dot com 2009-07-27
12:40 ---
It still happens in 4.4.1:
/localdata/install/gcc/objdir-gcc-4.4.1/./gcc/xgcc
-B/localdata/install/gcc/objdir-gcc-4.4.1/./gcc/
-B/localdata/i686-pc-linux-gnu/bin/ -B/localdata/i686-pc-linux-gnu/lib/
--- Comment #38 from irar at il dot ibm dot com 2009-07-27 12:44 ---
I am not sure that that kind of computation can be generated automatically,
since in general the order of caclulation of cond_expr cannot be changed.
However, the loop can be split:
for (i = 0; i end; i++)
if
--- Comment #39 from burnus at gcc dot gnu dot org 2009-07-27 13:15 ---
(In reply to comment #38)
However, the loop can be split: [..]
making the first loop vectorizable (inner-most loop vectorization).
OK. I tried it with a Fortran program:
The option -fwhole-programs marks all functions in that file as local to that
file, which facilitates inlining and dead-code elimination.
That of cause assumes that all declarations are properly unified, which should
be the case with -fwhole-file. However, the following Polyhedron testcases fail
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-07-27
14:01 ---
Not having much luck regression testing this one. Revision 148492 and 148493
both fail to bootstrap on x86_64-apple-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-27 14:47 ---
(Note: -fwhole-program implies -fwhole-file; the -On option is required.)
Test case. Run with -O1 -fwhole-program.
Fails with: test.f90:(.text+0x1b): undefined reference to `three_'
program prog
call
--- Comment #40 from jakub at gcc dot gnu dot org 2009-07-27 14:51 ---
If the cond_expr compute a minimum or maximum and the other cond_exprs compute
something based on the IV at the extremum, then I don't see why it couldn't be
vectorized by computing extremes of odd/even and
bcs .L3
mov r0, r4
@ sp needed for prologue
pop {r4, r5, r6, pc}
.size time_math, .-time_math
.ident GCC: (GNU) 4.5.0 20090727 (experimental)
--
ramana at gcc dot gnu dot org changed:
What|Removed
The following program shows that wrapping a simple class around a function
pointer costs important optimizations. If you change the #if 1 to #if 0,
you'll see that the call is completely optimized away.
#if 1
struct pf
{
inline pf(int(*x)(int)) : x(x) {}
inline int operator()(int a) const
--- Comment #51 from danglin at gcc dot gnu dot org 2009-07-27 15:10
---
Doesn't occur if I configure with --disable-libstdcxx-pch.
This problem also causes the following fails (4.4.2):
FAIL: 26_numerics/complex/pow.cc (test for excess errors)
FAIL:
--- Comment #2 from ludo at gnu dot org 2009-07-27 15:25 ---
All this was due to our build script building the `configure-gcc' target early
on, which apparently confused the build process. Sigh.
This bug can be closed now.
Sorry for the noise.
Ludo'.
--
ludo at gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-27 15:36 ---
So one problem is that nothing after SRA (before inlining) constant props g
into the call expression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from goeran at uddeborg dot se 2009-07-27 15:41 ---
(In reply to comment #2)
Translation fixes goto the translation team which is not part of the GCC team
really.
Indeed. In this case that would be tp...@listor.tp-sv.se.
But fortunately, I happened to stumble on this
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-27 15:45 ---
(In reply to comment #1)
So one problem is that nothing after SRA (before inlining) constant props g
into the call expression.
So there is no abstraction penalty really just a missing inlining.
--
pinskia at
When I compile the module listed below with gfortran 4.5 I get the message:
f951: internal compiler error: in gfc_set_constant_character_len, at
fortran/decl.c:1112
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- Comment #2 from goeran at uddeborg dot se 2009-07-27 16:00 ---
(In reply to comment #1)
I think this is a pervasive issue and we have at least another couple of PRs
about it in Bugzilla. Please check / commonize, thanks!
I'm not sure exactly what you mean with this. This
--- Comment #3 from dave at boost-consulting dot com 2009-07-27 16:26
---
The missing inlining is the cause, abstraction penalty is the symptom.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40874
--- Comment #3 from manu at gcc dot gnu dot org 2009-07-27 16:55 ---
(In reply to comment #2)
I tried to look for more similar cases. But I couldn't find anything. Not
that it is all that easy to search for. Neither error nor ? are
particularly good search terms. :-) So I may
--- Comment #4 from goeran at uddeborg dot se 2009-07-27 17:01 ---
(In reply to comment #3)
Try grep -e ' error ([^]' gcc/*.c -A 1
Ah, ok. I tried to search for similar BUGZILLA reports. Not for similar cases
in the code.
But sure, I can search the code instead. BRB
--
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-27 17:08 ---
(In reply to comment #4)
(In reply to comment #3)
Try grep -e ' error ([^]' gcc/*.c -A 1
Ah, ok. I tried to search for similar BUGZILLA reports. Not for similar
cases
in the code.
Sorry, I didn't understand
--- Comment #6 from goeran at uddeborg dot se 2009-07-27 17:11 ---
(In reply to comment #5)
Sorry, I didn't understand that was what you wanted.
What I WANTED was to do what Paolo Carlini asked about in comment 1. I'm not
sure if I understood him correctly either.
--
Beginning with the OpenMP API Version 2.5, this case should fail at
compile-time. The gfortran compiler does not reject this case, but gets a
segmentation fault at run-time.
The OpenMP API Version 3.0 (May 2008) lists the following restriction to a
private clause on p 91. lines 29-30:
*
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-27 17:53
---
never mind, you are just lazy, then say it more explicitly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-27 17:57
---
I would say let's add Martin (and Honza) in CC, he did a lot of improvements
for similar issues (which I pointed out a lot of time ago to Honza).
--
paolo dot carlini at oracle dot com changed:
--- Comment #8 from paolo dot carlini at oracle dot com 2009-07-27 18:04
---
Sorry about some harshness on my part, but in my opinion we should really have
a single PR about this issue and PR34836, PR29917, PR29017, and maybe a few
more...
--
--- Comment #9 from manu at gcc dot gnu dot org 2009-07-27 18:06 ---
I am not going to work on this. Unsubscribing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
--- Comment #10 from goeran at uddeborg dot se 2009-07-27 18:22 ---
(In reply to comment #8)
... but in my opinion we should really have
a single PR about this issue and PR34836, PR29917, PR29017
Then I did misunderstand you.
These are examples of what meant needed to be handled on
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-27 18:26 ---
Subject: Bug 40848
Author: janus
Date: Mon Jul 27 18:26:34 2009
New Revision: 150134
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150134
Log:
2009-07-27 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #11 from paolo dot carlini at oracle dot com 2009-07-27 18:27
---
Yes, in similar cases either we have a single PR or at least we have a dummy
Bugzilla PR bundling together related issues as blocking it. You can find many
examples.
--
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-27 18:30
---
preprocessed source not forthcoming
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from paolo dot carlini at oracle dot com 2009-07-27 18:40
---
Such dummy PRs have the summary starting with [Meta] and all the related
issues it groups are listed in the field depends on (sorry I confused
depends/blocks in my previous message).
--
--- Comment #1 from hjl dot tools at gmail dot com 2009-07-27 19:07 ---
I also see it on Linux/x86. It is an known issue:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00266.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
This PR is a reminder to check some places where a new gfc_charlen is allocated
without properly setting it into a namelist (ns-cl_list). Each of them may
potentially produce a memory leak (though I'm not completely sure):
* expr.c (simplify_const_ref)
* symbol.c (gfc_set_default_type,
--- Comment #13 from goeran at uddeborg dot se 2009-07-27 19:27 ---
If I can give any useful help, I'm certainly willing to do so. I'll search for
bugs to add to a meta-bug if you wish. What would the criteria for inclusion
be? Just anything having to do with translation? Anything
These test cases illustrate that gfortran ignores the COLLAPSE(M) clause on
an !$OMP DO when the value given is not a constant (or declared as a variable
having the parameter attribute. Other compilers supporting OpenMP API 3.0
raise an error when the primary test case is compiled.
The expected
POSIX 2001 specifies that va_copy
(http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is
defined by stdarg.h. However, when compiling with -std=c89
-D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2,
but a quick peek in svn makes it look this this is
POSIX 2001 specifies that va_copy
(http://www.opengroup.org/onlinepubs/009695399/functions/va_copy.html) is
defined by stdarg.h. However, when compiling with -std=c89
-D_POSIX_C_SOURCE=200112L this does not happen. I've encountered this in 4.3.2,
but a quick peek in svn makes it look this this is
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:46 ---
Created an attachment (id=18258)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18258action=view)
Source file illustrating the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
--- Comment #2 from bmerry at gmail dot com 2009-07-27 19:47 ---
Created an attachment (id=18259)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18259action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
--- Comment #1 from bmerry at gmail dot com 2009-07-27 19:48 ---
System threw an HTTP error 500 but managed to create a bug, so now there are
two copies. Rejecting this one, bug 40880 is the real one.
--
bmerry at gmail dot com changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-27 19:48 ---
*** This bug has been marked as a duplicate of 40880 ***
*** This bug has been marked as a duplicate of 40880 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-27 19:48 ---
*** Bug 40879 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40880
--- Comment #14 from paolo dot carlini at oracle dot com 2009-07-27 19:50
---
First, thanks for your help. I went quickly through your own bugs, and indeed,
I don't think they could reasonably all belong to the same meta-bug. However, I
think a meta-bug is definitely in order grouping
gfortran should have a flag (-Wobsolescent or similar) to turn on warnings
about obsolescent features. These features are listed in chapter B.2 in the
Fortran standard. They are not forbidden by the standard, but are redundant and
can be replaced by newer and better features.
The standard also
The following test program induces an infinite recursion in
gfc_get_derived_type:
implicit none
type :: t
real :: data
procedure(foo), pointer, nopass :: ppc
end type
type(t) :: o,o2
o%ppc = foo
o2 = o%ppc()
contains
function foo()
type(t) :: foo
foo%data = 5.
foo%ppc =
Meta bug to collect cases where proper translation isn't possible, but where it
would be, with fairly trivial modifications of the source code. This was
requested in the discussion of bug 40872.
--
Summary: [meta-bug] Translation breakage with trivial fixes
Product: gcc
--- Comment #15 from goeran at uddeborg dot se 2009-07-27 20:43 ---
Bug 40872 created as a tracker bug, with almost all my own bugs, and a few
others that also seemed to qualify as trivial. I excluded bugs that referred
to errors in the actual translations (l10n rather than i18n).
--- Comment #1 from dodji at gcc dot gnu dot org 2009-07-27 20:43 ---
Subject: Re: New: namespaces represented incorrectly in
debug_pubnames
I am regression testing this patchlet that seems to fix the problem in
trunk ...
--- Comment #2 from dodji at gcc dot gnu dot org
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||34836
Status|UNCONFIRMED |NEW
Ever
--- Comment #4 from joseph at codesourcery dot com 2009-07-27 21:02 ---
Subject: Re: New: stdarg.h does not define va_copy when building
for C89+POSIX
On Mon, 27 Jul 2009, bmerry at gmail dot com wrote:
POSIX 2001 specifies that va_copy
--- Comment #1 from janus at gcc dot gnu dot org 2009-07-27 21:05 ---
Here is a preliminary patch which makes the test case compile:
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 150133)
arm/neon.md, cris/cris.md, mmix/mmix.md, spu/spu-builtins.md and
stormy16/predicates.md contain calls to the functions error or
internal_error, whose operands would normally be extracted for
translation, but exgettext does not process .md files. Since gettext
doesn't know about .md files it might
c-typeck.c:build_indirect_ref takes an argument errorstring, which may
be array indexing, unary * or - and is not translated. It should
instead take an enum and pass three distinct full sentences to
error_at.
--
Summary: build_indirect_ref i18n problems
Product: gcc
--- Comment #16 from paolo dot carlini at oracle dot com 2009-07-27 21:19
---
Many thanks again!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40872
--- Comment #9 from zlynx at acm dot org 2009-07-27 21:26 ---
I built GCC using libunwind and binutils 2.19.1 and there is the same problem.
The registers are *not* being restored to the right values after the exception
return.
In the following assembly code you can clearly see that
Given this simple program:
main()
{
int i;
for (i = 0; i 10; i++)
f2();
}
compiled with -O2
gcc33-hammer detects that the loop index is not used in the loop body
and rewrites it to a downwards counting loop, elimitinating one instruction
(inc/cmp - dec)
movl
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-27 23:51 ---
Changing dg-do would be very messy. Instead, use the existing dg-add-options.
Add the following to libstdc++-v3/testsuite/dg-options.exp:
---
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-07-28 02:00
---
I will get started on this.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-07-28 03:09
---
As a work-around, re-arranging the derived type like this:
type tao_plot_page_struct
real size(2)
real shape_height_max
type (tao_title_struct) title
end type
May help, until I get this sorted
Consider the following code:
int (*indirect_func)();
int indirect_call()
{
return indirect_func();
}
gcc 4.4.0 generates the following with -O2 -mcpu=cortex-a8 -S:
indirect_call:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movwr3,
--- Comment #1 from lessen42 at gmail dot com 2009-07-28 05:14 ---
Created an attachment (id=18261)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18261action=view)
Use blx for indirect function calls on armv5+
This fixes the test case and the obvious cases of this I found in x264;
85 matches
Mail list logo
