On Wed, 25 Jun 2014, Richard Biener wrote: > On Tue, 24 Jun 2014, Jan Hubicka wrote: > > > > > The problem is that the patch fails testcases that assume we do such > > > > folding at parsing > > > > time. > > > > > > > > ./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-1.c (test for excess > > > > errors) > > > > ./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-2.c (test for excess > > > > errors) > > > > ./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-3.c (test for excess > > > > errors) > > > > ./testsuite/gcc/gcc.sum:FAIL: gcc.dg/pr36901-4.c (test for excess > > > > errors) > > > > > > > > Here we accept the source as compile time constant while I think it is > > > > not: > > > > int sc = (&sc > 0); > > > > > > > > Does it seem resonable to turn those testcases into one testing for > > > > error and > > > > live with delaying the folding oppurtunities to early opts? They are > > > > now caught > > > > by ccp1 pass usually. > > > > > > IMHO all symbol visibility related foldings are very premature if done > > > in the frontends (well, most of fold-const.c is ...). Of course > > > everything depends on whether there exists a frontend that requires > > > these foldings for correctness ... > > > > Yeah, in my testing it seems that C frontend do care in the testcase above > > - we > > used to accept code that does test nonzeroness of address as a constant, > > while we > > don't. > > Clang (IMO correctly) reject it. If we are OK with changing the bhaviour, > > I will > > just commit the patch and remove the testcase above (or turn it into error > > check) > > Well, I'd say we ask Joseph.
The cases accepted as constants in static initializers (beyond what ISO C requires to be accepted) are to some extent pragmatic based on what people are actually using there. I don't see an obvious need to accept this particular case, though you might only discover later through distribution builds if it is in fact in use. -- Joseph S. Myers jos...@codesourcery.com
