Re: [patch] [4.6] Backport strict-volatile-bitfields fix PR51200
Ping On Tue, Dec 27, 2011 at 10:19 AM, Ye Joey wrote: > Fix PR51200. Backport trunk 182545, 182649, 182685 to 4.6. > > OK to 4.6? > > - Joey > > 2011-12-20 Bernd Schmidt > > PR middle-end/51200 > * expr.c (store_field): Avoid a direct store if the mode is larger > than the size of the bit field. > * stor-layout.c (layout_decl): If flag_strict_volatile_bitfields, > treat non-volatile bit fields like volatile ones. > * toplev.c (process_options): Disallow combination of > -fstrict-volatile-bitfields and ABI versions less than 2. > * config/arm/arm.c (arm_option_override): Don't enable > flag_strict_volatile_bitfields if the ABI version is less than 2. > * config/h8300/h8300.c (h8300_option_override): Likewise. > * config/rx/rx.c (rx_option_override): Likewise. > * config/m32c/m32c.c (m32c_option_override): Likewise. > * config/sh/sh.c (sh_option_override): Likewise. > > 2011-12-22 Joey Ye > > * toplev.c (process_options): Fix typo. > > testsute > 2011-12-20 Bernd Schmidt > > PR middle-end/51200 > * gcc.target/arm/volatile-bitfields-4.c: New test. > * c-c++-common/abi-bf.c: New test. > > 2011-12-26 Joey Ye > > PR middle-end/51200 > * gcc.dg/volatile-bitfields-2.c: New test.
Re: [Patch, fortran] Fix temporary allocation for class assignment.
Dear Paul, Paul Richard Thomas wrote: > c = [ a, b ] Is exactly the abomination that I did not want to exist! What happens if 'a' and 'b' have different dynamic types? Actually, I start to get lost in the fine prints. One finds: "The dynamic type of an array constructor is the same as its declared type." That means that for "[a, b]" one has as constructor type the declared type of each ac-value, which has to be the same. Thus, one has declared type of "a" equals dynamic type of "a" - and the same for "b" with "a" and "b" having the same type. The question gets more interesting with: [ t2 :: a, b] Here, "a" and "b" need to be of declared type "t2" or of one extension of it - and can have any dynamic type. But due to the "t2" only components which are also in "t2" matter. See also PR 51864 > That's accepted by the Cray compiler (7.1.4.111) and produces: >5 5 5 5 5 5 5 5 Which is the expected and valid result. > Though, if one changes "t ::" to "t2 ::", the result is the slightly > surprising >5 5 6 6 5 5 5 5 >6 5 5 5 6 6 6 6 That code is actually invalid. Either both need to be of type "t" or one needs to a type spec and - for "[ t2 :: a, b]" also a different declared type. > I think that code is valid Fortran 2003/2008. But to cheer you up: Unlimited > polymorphic expressions are not allowed in array constructors (cf. C4107). Surely it cannot be valid? "C4106 (R472) An ac-value shall not be unlimited polymorphic." The reason is probably that class(*) is type compatible with everything thus this loophole had to be closed. PS I know how to fix PR51634 will get on to it as soon as I have a moment. Great! Tobias
Re: [Patch, fortran] Fix temporary allocation for class assignment.
Dear Tobias, The following example that you provided: > Do you mean something like the following: > > ! > type t > integer :: i = 5 > end type t > type, extends(t) :: t2 > integer :: j = 6 > end type t2 > > class(t), allocatable :: a(:), b(:), c(:) > allocate(t :: a(3)) > allocate(t :: b(5)) > allocate(t :: c(8)) > c = [ a, b ] > select type(c) > type is(t) > print '(*(i2))', c%i > type is(t2) > print '(*(i2))', c%i > print '(*(i2))', c%j > end select > end > ! Is exactly the abomination that I did not want to exist! What happens if 'a' and 'b' have different dynamic types? > > That's accepted by the Cray compiler (7.1.4.111) and produces: > 5 5 5 5 5 5 5 5 > Though, if one changes "t ::" to "t2 ::", the result is the slightly > surprising > 5 5 6 6 5 5 5 5 > 6 5 5 5 6 6 6 6 > > I think that code is valid Fortran 2003/2008. But to cheer you up: Unlimited > polymorphic expressions are not allowed in array constructors (cf. C4107). Surely it cannot be valid? > Can you add a small note in the comment before the function which mentions > that eltype == NULL_TREE is handed in a special way? > No problem. Thanks for the review. Cheers Paul PS I know how to fix PR51634 will get on to it as soon as I have a moment.
[PATCH] Fix tree_function_versioning with void type DECL_RESULT (PR tree-optimization/51865)
Hi!
The recent changes in tree_function_versioning broke the following
testcase. If DECL_RESULT exists, but has void type, then we used to
remap_decl it before, but now we don't, so in this case the same RESULT_DECL
is used in two different functions, which upsets ipa-pta, but could upset
other code too.
Fixed by calling remap_decl again for void type. Bootstrapped/regtested
on x86_64-linux and i686-linux (on x86_64 including ada). Ok for trunk?
2012-01-15 Jakub Jelinek
PR tree-optimization/51865
* tree-inline.c (tree_function_versioning): Call remap_decl
on DECL_RESULT whenever it has VOID_TYPE_P type.
* gcc.dg/pr51865.c: New test.
--- gcc/tree-inline.c.jj2012-01-13 21:47:35.0 +0100
+++ gcc/tree-inline.c 2012-01-15 20:00:00.350918475 +0100
@@ -5201,9 +5201,9 @@ tree_function_versioning (tree old_decl,
/* Add local vars. */
add_local_variables (DECL_STRUCT_FUNCTION (old_decl), cfun, &id, false);
- if (VOID_TYPE_P (TREE_TYPE (DECL_RESULT (old_decl
+ if (DECL_RESULT (old_decl) == NULL_TREE)
;
- else if (skip_return)
+ else if (skip_return && !VOID_TYPE_P (TREE_TYPE (DECL_RESULT (old_decl
{
DECL_RESULT (new_decl)
= build_decl (DECL_SOURCE_LOCATION (DECL_RESULT (old_decl)),
--- gcc/testsuite/gcc.dg/pr51865.c.jj 2012-01-15 20:09:00.035734459 +0100
+++ gcc/testsuite/gcc.dg/pr51865.c 2012-01-15 20:08:42.0 +0100
@@ -0,0 +1,25 @@
+/* PR tree-optimization/51865 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fipa-pta" } */
+
+void fn (const char *, const char *) __attribute__ ((__noreturn__));
+int var;
+
+inline void
+foo (void)
+{
+ if (__builtin_expect (var != 0, 0))
+fn ("a", "b");
+};
+
+void
+bar (void)
+{
+ foo ();
+};
+
+void
+baz (void)
+{
+ foo ();
+};
Jakub
Re: useless_type_conversion_p vs pointer sizes
> So two different sized pointers to aggregate types will also have a > problem? Nope, you misread the test: /* Changes in machine mode are never useless conversions unless we deal with aggregate types in which case we defer to later checks. */ if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type) && !AGGREGATE_TYPE_P (inner_type)) return false; This will return false for any couple of pointers with different modes. -- Eric Botcazou
[wwwdocs PATCH] for Re: GCC mirror
On Wed, 11 Jan 2012, NetGull Administrator wrote: > I've just set up a new GCC mirror. Information is as follows: > > URL: http://www.netgull.com/gcc/ > Frequency:once a day > Location:San Jose, California, United States, North America > Contact: ad...@netgull.com > > Please, add my GCC mirror to your mirror list; > for any further clarification don't hesitate to contact me. I just added your server, per the patch below. Thanks for mirroring us and letting us know about it! Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.214 diff -u -3 -p -r1.214 mirrors.html --- mirrors.html25 Oct 2011 17:46:07 - 1.214 +++ mirrors.html15 Jan 2012 19:48:01 - @@ -53,6 +53,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet.bs) US, Phoenix: http://fileboar.com/gcc/";>fileboar.com, thanks to Grigory Rayskin (rayskin73 at gmail.com) US, Saint Louis: http://gcc.petsads.us";>http://gcc.petsads.us, thanks to Sergey Kutserey (s.kutserey at gmail.com) +US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin at netgull.com US, Tampa: http://mirrors-us.seosue.com/gcc/";>http://mirrors-us.seosue.com/gcc/, thanks to Peter Vrzak (petervrzak at gmail.com)
Re: [patch] Flag-controlled type conversions/promotions
On Sun, Jan 15, 2012 at 01:39:23PM -0500, Zydrunas Gimbutas wrote: > Hi, > > Everything seems to be ok in this patch, except for minor typos in > documentation: REAl -> REAL, alignement -> alignment. Good catch. > It would also be nice to extend the type conversion facility to > include -fdefault-real-16, -fdefault-double-16, -fdefault-real-10, > -fdefault-double-10, and add conversions for logical types, to > complete the conversion table. These are not very commonly used > (except for -fdefault-real-16, -fdefault-double-16, which would > correspond to -r16 and -autodouble flags in some compilers), so we > should be fine at this time. Well, historically, -fdefault-real-8, -fdefault-integer-8, and -fdefault-double-8 were provided for backwards compatibility with g77's -r8, -d8, and -i8 options. There was no consideration for other compilers.* Thus, I would discourage these new options in favor of your -freal-N-real-M options. * Craig Burley may have included -r8, -i8, and -d8 to be compatible with other compilers, but I'm too lazy to go code spelunking. -- Steve
Re: [committed] Adjust ssa-dom-thread-4.c for MIPS
On Sun, Jan 15, 2012 at 10:45 AM, Andrew Pinski wrote: > On Sun, Jan 15, 2012 at 10:31 AM, Richard Sandiford > wrote: >> ssa-dom-thread-4.c was failing for MIPS because the mips.h definition: >> >> #define LOGICAL_OP_NON_SHORT_CIRCUIT 0 >> >> caused "var1 || var2" conditions to be split into two rather than >> converted into "(var1 != 0) | (var2 != 0)". I don't know whether >> the MIPS definition still makes sense (probably not for Octeon2 >> at least) but it's too late to change it for this release. > > For non floating point types it does not make sense (but then again > Octeon2 does not have implement floating point instructions). I mean it makes sense for non floating point types. For floating point comparisons we should not combine at all. I am working on a patch for 4.8 to do that. Thanks, Andrew Pinski
[committed] Fix a MIPS16 hard-float optimisation
gcc.dg/torture/stackalign/builtin-apply-4.c was failing for MIPS16
hard-float with -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects.
We created a specialised out-of-line version of bar() that was
called by (rather than inlined into) main(). So we had the
equivalent of:
static double __attribute__((noinline)) bar (void) { return 1.0; }
double foo (void) { return bar (); }
Compiled without -fpic this worked fine, but compiled with -fpic it hit:
/* If this is a locally-defined and locally-binding function,
avoid the stub by calling the local alias directly. */
if (mips16_local_function_p (fn))
{
*fn_ptr = mips16_local_alias (fn);
return NULL_RTX;
}
The problem is that these local aliases are only defined (and only
needed) for functions that take arguments in floating-point registers,
so we got a link error trying to call bar()'s local alias.
Tested on mips64-linux-gnu and applied.
Richard
gcc/
* config/mips/mips.c (mips16_build_call_stub): Don't use a stub
for calls to locally-binding MIPS16 functions if only the return
type uses float regs.
Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c 2012-01-15 18:22:47.0 +
+++ gcc/config/mips/mips.c 2012-01-15 18:31:58.0 +
@@ -6172,6 +6172,13 @@ mips16_build_call_stub (rtx retval, rtx
if (mips16_stub_function_p (fn))
return NULL_RTX;
+ /* If we're calling a locally-defined MIPS16 function, we know that
+ it will return values in both the "soft-float" and "hard-float"
+ registers. There is no need to use a stub to move the latter
+ to the former. */
+ if (fp_code == 0 && mips16_local_function_p (fn))
+return NULL_RTX;
+
/* This code will only work for o32 and o64 abis. The other ABI's
require more sophisticated support. */
gcc_assert (TARGET_OLDABI);
Re: [committed] Adjust ssa-dom-thread-4.c for MIPS
On Sun, Jan 15, 2012 at 10:31 AM, Richard Sandiford wrote: > ssa-dom-thread-4.c was failing for MIPS because the mips.h definition: > > #define LOGICAL_OP_NON_SHORT_CIRCUIT 0 > > caused "var1 || var2" conditions to be split into two rather than > converted into "(var1 != 0) | (var2 != 0)". I don't know whether > the MIPS definition still makes sense (probably not for Octeon2 > at least) but it's too late to change it for this release. For non floating point types it does not make sense (but then again Octeon2 does not have implement floating point instructions). Thanks, Andrew Pinski
Re: [patch] Flag-controlled type conversions/promotions
Hi, Everything seems to be ok in this patch, except for minor typos in documentation: REAl -> REAL, alignement -> alignment. It would also be nice to extend the type conversion facility to include -fdefault-real-16, -fdefault-double-16, -fdefault-real-10, -fdefault-double-10, and add conversions for logical types, to complete the conversion table. These are not very commonly used (except for -fdefault-real-16, -fdefault-double-16, which would correspond to -r16 and -autodouble flags in some compilers), so we should be fine at this time. Thanks to everyone for making this work! Zydrunas On Fri, Jan 13, 2012 at 6:43 PM, Steve Kargl wrote: > On Wed, Nov 09, 2011 at 06:09:58PM -0500, Andreas Kloeckner wrote: >> Hi there, >> >> please find attached the patch and the Changelog entry for our work on >> the fortran bug #48426. >> >> The attached patch implements the options >> >> -finteger-4-integer-8 >> -freal-4-real-8 >> -freal-4-real-10 >> -freal-4-real-16 >> -freal-8-real-4 >> -freal-8-real-10 >> -freal-8-real-16 >> >> to implement a variety of automatic type promotions. (This is particularly >> helpful if one wants to quickly check whether a certain code has a bug >> limiting >> its precision away from full machine accuracy.) >> > > I plan to commit the attached patch this weekend. > > 2011-11-09 Zydrunas Gimbutas > Andreas Kloeckner > Steven G. Kargl > > PR fortran/48426 > * gfortran.h (gfc_option_t): Add members flag_*_kind to store kind. > * lang.opt: Add options -freal-4-real-8, -freal-4-real-10, > -freal-4-real-16, -freal-8-real-4, -freal-8-real-10, -freal-8-real-16 > and -finteger-4-integer-8. User-desired type conversion information. > * decl.c (gfc_match_old_kind_spec,kind_expr): Type conversions > in declaration parsing. > * trans-types.c (gfc_init_kinds): User-specified type conversion > checked for current backend. > * primary.c (match_integer_constant,match_real_constant): Implement > type conversion in constant parsing. > * options.c (gfc_init_options,gfc_handle_option): Translate input > options to flags in internal options data structure. > * invoke.texi: Document new options. Re-order options in Options > summary section. > > -- > Steve
[committed] Adjust ssa-dom-thread-4.c for MIPS
ssa-dom-thread-4.c was failing for MIPS because the mips.h definition:
#define LOGICAL_OP_NON_SHORT_CIRCUIT 0
caused "var1 || var2" conditions to be split into two rather than
converted into "(var1 != 0) | (var2 != 0)". I don't know whether
the MIPS definition still makes sense (probably not for Octeon2
at least) but it's too late to change it for this release.
Tested on mips64-linux-gnu and x86_64-linux-gnu. Applied.
Richard
gcc/testsuite/
* gcc.dg/tree-ssa/ssa-dom-thread-4.c: Expect 4 threaded edges for MIPS.
Index: gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c2012-01-15
18:19:31.0 +
+++ gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c2012-01-15
18:26:13.0 +
@@ -58,6 +58,9 @@ bitmap_ior_and_compl (bitmap dst, const_
code we missed the edge when the first conditional is false
(b_elt is zero, which means the second conditional is always
zero. */
-/* { dg-final { scan-tree-dump-times "Threaded" 3 "dom1"} } */
+/* { dg-final { scan-tree-dump-times "Threaded" 3 "dom1" { target { !
mips*-*-* } } } } */
+/* MIPS defines LOGICAL_OP_NON_SHORT_CIRCUIT to 0, so we split var1 || var2
+ into two conditions, rather than use (var1 != 0) | (var2 != 0). */
+/* { dg-final { scan-tree-dump-times "Threaded" 4 "dom1" { target mips*-*-* }
} } */
/* { dg-final { cleanup-tree-dump "dom1" } } */
Re: [PATCH] MIPS16 TLS support for GCC
Richard Sandiford writes: > gcc/ > 2012-01-08 Chung-Lin Tang > Richard Sandiford > > * config/mips/mips-protos.h (SYMBOL_FORCE_TO_MEM): Delete. > (SYMBOL_32_HIGH): Likewise. > (mips_output_tls_reloc_directive): Declare. > * config/mips/mips.h (PIC_FUNCTION_ADDR_REGNUM): Move to mips.md. > (mips_use_pcrel_pool_p, mips_lo_relocs, mips_hi_relocs): Declare. > * config/mips/mips.c (mips_use_pcrel_pool_p): New variable. > (mips_lo_relocs, mips_hi_relocs): Make extern. > (mips16_stub_function): Move up file. > (mips_classify_symbol): Remove SYMBOL_FORCE_TO_MEM handling. > (mips_symbolic_constant_p): Likewise. Remove SYMBOL_32_HIGH too. > (mips_symbol_insns_1): Likewise. Check mips_use_pcrel_pool_p. > (mips_cannot_force_const_mem): Use mips_use_pcrel_pool_p instead > of SYMBOL_FORCE_TO_MEM. Only check mips_tls_symbol_ref_1 > if it's false. > (mips_get_tp): Add MIPS16 support. > (mips_legitimize_tls_address): Remove MIPS16 sorry(). > Generalize DTPREL and TPREL handling. > (mips_init_relocs): Initialize mips_use_pcrel_pool_p. > Add MIPS16 TLS support. > (mips_output_tls_reloc_directive): New function. > (mips16_rewrite_pool_refs): Ignore UNSPEC_TLS_GET_TPs. > * config/mips/predicates.md (symbolic_operand_with_high) > (tls_reloc_operand): New predicates. > (force_to_mem_operand): Use mips_use_pcrel_pool_p. > * config/mips/mips.md (UNSPEC_UNSHIFTED_HIGH): New unspec. > (PIC_FUNCTION_ADDR_REGNUM): Moved from mips.h. > (*unshifted_high): New instruction. Use it for MIPS16 > high splitter. > (consttable_tls_reloc, tls_get_tp_mips16_): New patterns. > (*tls_get_tp_mips16_call_): Likewise. > > gcc/testsuite/ > * gcc.target/mips/code-readable-2.c: Allow the jump table address > to be loaded from the constant pool, rather than via %hi and %lo. > > libgcc/ > 2012-01-08 Chung-Lin Tang > Richard Sandiford > > * config/mips/libgcc-mips16.ver (__mips16_rdhwr): Add. > * config/mips/mips16.S (__mips16_rdhwr): New function. > * config/mips/t-mips16 (LIB1ASMFUNCS): Add _m16rdhwr. This wouldn't normally be "stage 4" material, but since it was posted just before stage 3 closed, I went ahead and applied it. I'll update the web pages "soon". Richard
Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations
On Fri, Jan 13, 2012 at 10:58 AM, Richard Sandiford
wrote:
The problem my patch solves is the answer to the question "Is the
choosen non-live temporary register untouched over the insn
sequence?". The answer: "Yes, if it was not set or clobbered by any
insn in the sequence".
>>>
>>> Are you sure that you don't need to do this in addition to the existing
>>> test,
>>> instead of in lieu of the existing test?
>>
>> Yes, because new test ALWAYS includes the registers that were wrongly
>> marked as dead by previous test due to REG_UNUSED and noclobber
>> processing.
>
> Yeah, the patch looks like the right fix to me FWIW. Being able to use
> DF_INSN_DEFS in this way is part of the point of having df: when going
> from one insn to the next within the same bb, there are no "hidden"
> influences that would cause a register to become live outside of
> DF_INSN_DEFS. The only requirement is that we call df_insn_rescan
> on new instructions, and we do (in peep2_update_life, where we need
> it for df_simulate_one_insn_backwards).
>
> Or to put it another way: the insn-to-insn changes in the current liveness
> sets are all produced by df_simulate_one_insn_{backwards,forwards}, which
> uses the same information. So I don't think there's any reason why we
> need to keep the current code as well.
Patch was approved offline by Richard Sandiford, so committed to
mainline SVN, will be committed to release branches after bootstrap &
regression tests.
Thanks,
Uros.
Re: libgo patch committed: Update to weekly.2011-12-22
On Sat, Jan 14, 2012 at 12:18 AM, Ian Lance Taylor wrote:
>> This is the same problem with -fdump-go-spec we discussed a couple of
>> months ago [1]. In short, alpha linux doesn't just include
>> with hardcoded numbers in asm/ioctls.h, but
>> builds ioctl arguments as shown in [1]. Probably, this is the right
>> way ...
>
> Oh yeah.
>
> I think I've worked out a way to handle this kind of thing. With luck
> this patch will fix the problem. Bootstrapped on
> x86_64-unknown-linux-gnu, although that doesn't really test it properly.
> Committed to mainline. Please let me know if this helps.
The library compiles OK, with following small patch:
--cut here--
Index: mksysinfo.sh
===
--- mksysinfo.sh(revision 183192)
+++ mksysinfo.sh(working copy)
@@ -538,7 +538,7 @@
# We need TIOCGWINSZ.
if ! grep '^const TIOCGWINSZ' ${OUT} >/dev/null 2>&1; then
if grep '^const _TIOCGWINSZ_val' ${OUT} >/dev/null 2>&1; then
-echo 'const TIOCGWINSZ = TIOCGWINSZ_val' >> ${OUT}
+echo 'const TIOCGWINSZ = _TIOCGWINSZ_val' >> ${OUT}
fi
fi
--cut here--
Thanks,
Uros.
Fix gcc.dg/torture/pr8081.c char signedness assumption
The condition was always optimized to 1. Tested on powerpc-linux and
checked in as obvious.
Andreas.
2012-01-15 Andreas Schwab
* gcc.dg/torture/pr8081.c: Fix char signedness assumption.
Index: gcc.dg/torture/pr8081.c
===
--- gcc.dg/torture/pr8081.c (revision 183191)
+++ gcc.dg/torture/pr8081.c (working copy)
@@ -16,11 +16,11 @@ main (int argc, char **argv)
{
return *(block *) &b;
}
- b.val[0] = -1;
- b.val[9] = -2;
+ b.val[0] = 1;
+ b.val[9] = 2;
a=retframe_block ();
- if (a.val[0] != -1
- || a.val[9] != -2)
+ if (a.val[0] != 1
+ || a.val[9] != 2)
abort ();
return 0;
}
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: [Patch,testsuite]: Fix testcase that bangs long and int against void*
Rainer Orth schrieb: Mike Stump writes: On Jan 13, 2012, at 4:33 AM, Georg-Johann Lay wrote: This test case is obviously written for 32-bit platforms, thus added "dg-require-effective-target ilp32" to ensure that the pointer mess won't lead to FAILs because of warning: cast to pointer from integer of different size and warning: cast from pointer to integer of different size Ok to apply? Ok. * gcc.dg/lto/20091013-1_0.c: Add dg-require-effective-target ilp32. I wonder if the fix is right, though: the testcase currenly passes for 64-bit multilibs, but won't run there any longer if the patch is applied. Rainer What about int32plus instead of ilp32? That's still not exactly what the test case needs but closer than ilp32. Johann
Re: [Patch, fortran] Fix temporary allocation for class assignment.
Dear Paul, Paul Richard Thomas wrote: Please reassure me that class array constructors do not, cannot and will never occur!:-) Do you mean something like the following: ! type t integer :: i = 5 end type t type, extends(t) :: t2 integer :: j = 6 end type t2 class(t), allocatable :: a(:), b(:), c(:) allocate(t :: a(3)) allocate(t :: b(5)) allocate(t :: c(8)) c = [ a, b ] select type(c) type is(t) print '(*(i2))', c%i type is(t2) print '(*(i2))', c%i print '(*(i2))', c%j end select end ! That's accepted by the Cray compiler (7.1.4.111) and produces: 5 5 5 5 5 5 5 5 Though, if one changes "t ::" to "t2 ::", the result is the slightly surprising 5 5 6 6 5 5 5 5 6 5 5 5 6 6 6 6 I think that code is valid Fortran 2003/2008. But to cheer you up: Unlimited polymorphic expressions are not allowed in array constructors (cf. C4107). Bootstrapped and regtested on Fc9/x86_64 - OK for trunk? OK. Thanks for the patch. *** gfc_trans_create_temp_array (stmtblock_t + /* This signals a class array for which we need the size of the + dynamic type. Generate an eltype and then the class expression. */ + if (eltype == NULL_TREE&& initial) Can you add a small note in the comment before the function which mentions that eltype == NULL_TREE is handed in a special way? Tobias
