This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] fix PR39701 testsuite failures


On Fri, Apr 10, 2009 at 12:17 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
> Interestingly enough, these failures had three different root causes,
> and each of them triggered a different observation on something dubious
> in GCC.
>
> One was due to a disabled folding due to my patch when
> -fno-delete-null-pointer-checks (including -O0 -O1). ?I fixed this by
> considering &x to be non-zero if x is stack allocated.
>
> ?Observation: I think however that it does not make sense to have
> ?-fdelete-null-pointer-checks only at -O2 or higher -- it it is not
> ?an optimization option, rather it describes the semantics of the
> ?target, and it should be enabled uniformly at all optimization levels.
> ?If there are places that we consider optimizations, they should be
> ?guarded by "(optimize >= 2 && flag_delete_null_pointer_checks).
>
> One is a Fortran front-end bug due to the same disabled folding. ?There
> is a mismatch in that "&stat" is compared with a zero constant whose
> type is "stat"'s type.
>
> ?Observation: This is easily fixed, but can be improved by just
> ?deleting the conditionals emitted for the Fortran ALLOCATE intrinsics.
> ?It never happens that those conditionals of the form "pstat == 0"
> ?enter the "then" block, because pstat is always an ADDR_EXPR of a
> ?stack-allocated variable. ?It may be easier to just pass around the
> ?DECL of the stat variable itself. ?I'll leave this to the Fortran
> ?maintainers.
>
> The third kind of failure is in the PR36901 testcases, which do
>
> ?int sc = (&sc > 0);
>
> to emit a pedwarn, and this now triggers an "initializer is not
> constant" error when -fno-delete-null-pointer-checks. ?Previously, the
> comparison was folded to true. ?My first impression is that the warning
> *is* correct (you need to wait until linking to know the address of &sc
> with -fno-delete-null-pointer-checks). ?So I'm changing it to
>
> ?int sc = (&sc > 0) ? 1 : 1;
>
> This abuses the COND ? A : A folding to make sure that the initializer
> is considered constant.
>
> ?Observation: I'm CCing Joseph to understand how and if this is correct
> ?from a C standard point of view, since this seems to me like a case
> ?of extra folding performed by GCC on initializers.
>
> I'm posting this early to give maintainers time to comment since the
> patch touches many areas; in the meanwhile I bubblestrapped the patch on
> i686-pc-linux-gnu, and the affected tests now pass. ?A full
> bootstrap/regtest is running (this time *with* the patch, unlike
> yesterday...).
>
> Paolo
>
> 2009-04-10 ?Paolo Bonzini ?<bonzini@gnu.org>
>
> ? ? ? ?* fold-const.c (tree_single_nonzero_warnv_p): Pass non-static
> ? ? ? ?variables as non-NULL even with -fdelete-null-pointer-checks.
>
> fortran:
> 2009-04-10 ?Paolo Bonzini ?<bonzini@gnu.org>
>
> ? ? ? ?* trans.c (gfc_allocate_with_status): Fix type mismatches
> ? ? ? ?on "pstat == 0".
>
> testsuite:
> 2009-04-10 ?Paolo Bonzini ?<bonzini@gnu.org>
>
> ? ? ? ?* gcc.dg/pr36901.h: Make initializer foldable to constant.
>

Shouldn't ChangeLog mention PR 39701?

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]