[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319
James Kuyper Jr. changed:
What|Removed |Added
CC||jameskuyper at verizon dot net
--- Comment #11 from James Kuyper Jr. ---
(In reply to Tim Rentsch from comment #10)
...
> Four: Despite the last observation, the "one special guarantee" clause
> (and hence also DR 257) is clearly not germane to this problem. The
> reason for this is that the "one special guarantee" clause is concerned
> with read access ("inspect" is the word used in the Standard), but the
> example code has no read accesses, only write accesses. That paragraph
> of the Standard is not relevant here.
The example code includes the statement
return xp->x;
Which does in fact inspect (read) the value currently stored in a variable that
is part of the common initial sequence. The fact that if fails to read the
value most recently written to that location is the defect that's being
reported.
[Bug rtl-optimization/14319] incorrect optimization of union of structs with common initial sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14319 --- Comment #12 from James Kuyper Jr. --- (In reply to Wolfgang Bangerth from comment #2) > I can't believe the wording means what you imply. Assume that caller > and callee are in different translation units, then there is no > way for the compiler to see that the two arguments to the called function > may in fact be members of the same union. Complying with this requirement does not require positively determining whether they are members of the same union. It requires only that code be generated that would correctly handle the possibility that they are members of the same union. This basically means that anti-aliasing optimizations that would ordinarily be enabled by the fact that two struct types are different would have to be disabled anywhere within the scope of such a union declaration unless a) the implementation can be certain that they aren't different members of the same union object OR b) the implementation applies those optimizations only if the relevant pointers do not point at the same location. > So the only way to assume that they could alias each other is to > search the universe for a union type in which both of them are members. > That certainly can't be the intent of the standard or DR. It only makes > sense, if as RTH says the access is through such a union. Why would it be necessary to "search the universe"? The rule very explicitly only applies "anywhere that a declaration of the complete type of the union is visible." Whether such a declaration is currently visible is something the implementation must already keep track of, in order to determine whether the definition of an object of the union's type is permitted.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 James Kuyper Jr. changed: What|Removed |Added CC||jameskuyper at verizon dot net --- Comment #28 from James Kuyper Jr. --- (In reply to Martin Sebor from comment #17) > The C Union Visibility rule was intended to cover that case. The trouble is > that the rule tends to be interpreted differently by different people, users > and implementers alike: Is it the union object that must be visible at the > point of the access, or just the union type? The relevant wording is "anywhere that a declaration of the completed type of the union is visible.", so it's unambiguously the type, not the object, which must be visible. A declaration of the completed type can be visible without any objects of that type being visible, and that's sufficient for this rule to apply. > ... Must the access be performed > using the union object, or just the union type, or neither? It says only that "it is permitted to inspect the common initial part"; it imposes no restrictions on how the inspection may be performed. Clearly, inspection through an lvalue of the union's type must be permitted, but it is also permitted to use the more indirect methods which are the subject of this bug report, simply because the standard says nothing to restrict the permission it grants to the more direct cases.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #31 from James Kuyper Jr. --- (In reply to rguent...@suse.de from comment #29) > On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote: ... > > The relevant wording is "anywhere that a declaration of the completed type > > of > > the union is visible.", so it's unambiguously the type, not the object, > > which > > must be visible. A declaration of the completed type can be visible without > > any > > objects of that type being visible, and that's sufficient for this rule to > > apply. > > > > > ... Must the access be performed > > > using the union object, or just the union type, or neither? > > > > It says only that "it is permitted to inspect the common initial part"; it > > imposes no restrictions on how the inspection may be performed. Clearly, > > inspection through an lvalue of the union's type must be permitted, but it > > is > > also permitted to use the more indirect methods which are the subject of > > this > > bug report, simply because the standard says nothing to restrict the > > permission > > it grants to the more direct cases. > > Note I repeatedly said this part of the standard is just stupid. As a judgement call, I reserve the right to disagree with you on that point, particularly if that judgement was based primarily on the following misconception: > ... It makes > most if not all type-based alias analysis useless. How could that be true? It only applies to pairs of struct types that are the types of members of the same union, it only applies within the scope of a completed definition of that union's type, and it doesn't apply if the implementation can prove to itself that the two objects in question are not actually members of the same union object. It seems to me that the need to take this rule into consideration would come up pretty infrequently. Code which relies upon this feature to implement a C-style approximation to inheritance has been fairly common, which is precisely why the C committee decided to create this rule, to make sure such code had well-defined behavior. > Which means I'll refuse any patches implementing it in a way that affects > default behavior. A clean patch (I really can't think of any clean > approach besides forcing -fno-strict-aliasing!) with some extra flag > (well, just use -fno-strict-aliasing ...) would be fine with me. I can understanding not making this the default behavior if you feel that way; I only use gcc in fully standard-conforming mode, anyway, so that doesn't matter to me. However, personally, I would prefer it if gcc's fully-conforming mode took full advantage of all the optimization opportunities legitimately enabled by 6.5p7 (which does not include opportunities revoked by 6.5.2.3p6).
[Bug c/46926] New: Paired sin() cos() calls optimized to sincos() call.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
Summary: Paired sin() cos() calls optimized to sincos() call.
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jameskuy...@verizon.net
I discovered this problem when porting from a mandriva Linux system using gcc
4.2.2 to a centos linux system using gcc 4.4.4. After much simplification, I
can now demonstrate the problem with an extremely short example program:
#include
#include
void sincos(double val, double *sin_val, double *cos_val)
{
*sin_val = sin(val);
*cos_val = cos(val);
return;
}
int func(
double * pd
){
double cosine, sine;
/* must use value accessed through pointer; bug disappears
* without the pointer access.
*/
cosine = cos(*pd);
sine = sin(*pd);
/* Need to use cosine[] and sine[], or optimizer drops them. */
return cosine < 0.0 && sine > 0.0 ? EXIT_FAILURE : EXIT_SUCCESS;
}
int main (void)
{
double d=0.0;
return func(&d) ;
}
In the original program, the sincos() function defined above occurred in a
third-party library designed for use with a fully conforming implementation of
C90. Such implementations cannot provide a sincos() function in their standard
C library in any way that would conflict with a user-defined function of the
same name. I compiled and linked this program using the following command:
gcc -ansi -pedantic -O1 -g sincos_prob.c -lm -o sincos_prob
When I execute the program, it produces a bus error. gdb indicates that the bus
error occurs inside a recursive (!?) call to sincos(). The problem does not
come up if I lower the optimization level to -O0.
The reason appears to be that, at optimization levels of 1 or higher, paired
calls to sin() and cos(), like those that occur in two seperate locations
above, are replaced with a single call to sincos() - in itself, a seemingly
reasonable thing to do. The sincos() definition provided by the third party
library is used in place of the one provided as an extension in the C standard
library, which also seems reasonable. Where this all goes wrong is inside the
body of the third-party library's definition of sincos(). The sin()/cos()
optimization turns that function into an infinitely recursive call to itself.
Because sincos() is not a C standard library routine, the code given above does
not violate any constraint, and has well defined behavior - behavior which does
not include generating a bus error.
When invoked in a mode that's supposed to be fully conforming to either C90 or
C99, the compiler should not generate spurious calls to functions whose names
are not reserved to the implementation. Use of a reserved name, such as
__sincos(), seems to me like it would be the simplest fix for this problem.
[Bug c/46926] Paired sin() cos() calls optimized to sincos() call.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926 --- Comment #2 from James Kuyper Jr. 2010-12-13 18:41:55 UTC --- info gcc says: Functions which would normally be built in but do not have semantics defined by ISO C (such as `alloca' and `ffs') are not built-in functions with `-ansi' is used.
