Re: confirm subscribe to gcc@gcc.gnu.org
On Sat, Oct 28, 2017, at 12:06 AM, gcc-h...@gcc.gnu.org wrote: > Hi! This is the ezmlm program. I'm managing the > gcc@gcc.gnu.org mailing list. > > To confirm that you would like > >yub...@fastmail.com > > added to the gcc mailing list, please send > an empty reply to this address: > >gcc-sc.1509174385.nmbemkeeojmnoanlagae-yubinr=fastmail@gcc.gnu.org > > Usually, this happens when you just hit the "reply" button. > If this does not work, simply copy the address and paste it into > the "To:" field of a new message. > > This confirmation serves two purposes. First, it verifies that I am able > to get mail through to you. Second, it protects you in case someone > forges a subscription request in your name. > > Some mail programs are broken and cannot handle long addresses. If you > cannot reply to this request, instead send a message to > and put the > entire address listed above into the "Subject:" line. > > > --- Administrative commands for the gcc list --- > > I can handle administrative requests automatically. Please > do not send them to the list address! Instead, send > your message to the correct command address: > > To subscribe to the list, send a message to: > > > To remove your address from the list, send a message to: > > > Send mail to the following for info and FAQ for this list: > > > > Similar addresses exist for the digest list: > > > > To get messages 123 through 145 (a maximum of 100 per request), mail: > > > To get an index with subject and author for messages 123-456 , mail: > > > They are always returned as sets of 100, max 2000 per request, > so you'll actually get 100-499. > > To receive all messages with the same subject as message 12345, > send an empty message to: > > > The messages do not really need to be empty, but I will ignore > their content. Only the ADDRESS you send to is important. > > You can start a subscription for an alternate address, > for example "john@host.domain", just add a hyphen and your > address (with '=' instead of '@') after the command word: > > > To stop subscription for this address, mail: > > > In both cases, I'll send a confirmation message to that address. When > you receive it, simply reply to it to complete your subscription. > > If despite following these instructions, you do not get the > desired results, please contact my owner at > gcc-ow...@gcc.gnu.org. Please be patient, my owner is a > lot slower than I am ;-) > > --- Enclosed is a copy of the request I received. > > Return-Path: > Received: (qmail 4414 invoked by uid 48); 28 Oct 2017 07:06:24 - > Message-ID: <20171028070624.4411.qm...@sourceware.org> > From: anonym...@sourceware.org > Date: Sat, 28 Oct 2017 07:06:24 + > To: gcc-subscribe-yubinr=fastmail@sourceware.org > User-Agent: Heirloom mailx 12.4 7/29/08 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > >
Problems in IPA passes
Jan, What's the purpose behind calling vrp_meet and extract_range_from_unary_expr from within the IPA passes? AFAICT that is not safe to do. Various paths through those routines will access static objects within tree-vrp.c which may not be initialized when IPA runs (vrp_equiv_obstack, vr_value). While this seems to be working today, it's a failure waiting to happen. Is there any way you can avoid using those routines? I can't believe you really need all the complexity of those routines, particularly extract_range_from_unary_expr. Plus it's just downright fugly from a modularity standpoint. ? Jeff
Re: Problems in IPA passes
Dne 2017-10-28 09:28, Jeff Law napsal: Jan, What's the purpose behind calling vrp_meet and extract_range_from_unary_expr from within the IPA passes? AFAICT that is not safe to do. Various paths through those routines will access static objects within tree-vrp.c which may not be initialized when IPA runs (vrp_equiv_obstack, vr_value). While this seems to be working today, it's a failure waiting to happen. Is there any way you can avoid using those routines? I can't believe you really need all the complexity of those routines, particularly extract_range_from_unary_expr. Plus it's just downright fugly from a modularity standpoint. We now have three value range propagation passes. The original vrp, early vrp which is fater and ipa-cp which does IPA propagation. It seems sane to me for those three to share some infrastructure but I did not look in enough of detail into these to know if what we have right now is sane thing to do :) The VRP passes were introduced by Kugan and this part was mostly reviewed by Richi, so I am adding them to CC. The refactoring happened in https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00891.html Honza ? Jeff
Re: Problems in IPA passes
On October 28, 2017 9:28:38 AM GMT+02:00, Jeff Law wrote: > >Jan, > >What's the purpose behind calling vrp_meet and >extract_range_from_unary_expr from within the IPA passes? > >AFAICT that is not safe to do. Various paths through those routines >will access static objects within tree-vrp.c which may not be >initialized when IPA runs (vrp_equiv_obstack, vr_value). > >While this seems to be working today, it's a failure waiting to happen. Those functions are fine to use IIRC. >Is there any way you can avoid using those routines? I can't believe >you really need all the complexity of those routines, particularly >extract_range_from_unary_expr. Plus it's just downright fugly from a >modularity standpoint. The functions were designed to be workers for ranges like const_binop so they were supposed to be used elsewhere. Which is also why I wondered Andrew didn't use them... Richard. > >? > >Jeff
Re: [std-discussion] Is this union aliasing code well-defined?
On 10/27/2017 04:54 PM, Richard Biener wrote:
> On Fri, Oct 27, 2017 at 3:00 PM, Yubin Ruan wrote:
>> +Cc gcc-list.
>>
>> Does any gcc developer have any comments?
>
> See PR82224. The code is valid.
>
>> On Mon, Sep 25, 2017 at 01:41:55PM -0700, Myriachan wrote:
>>> This question that "supercat" posted on Stack Overflow ran into an
>>> interesting problem:
>>>
>>> https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/
>>>
>>> A copy of the code involved is as follows:
>>>
>>> struct s1 {unsigned short x;};
>>> struct s2 {unsigned short x;};
>>> union s1s2 { struct s1 v1; struct s2 v2; };
>>>
>>> static int read_s1x(struct s1 *p) { return p->x; }
>>> static void write_s2x(struct s2 *p, int v) { p->x=v;}
>>>
>>> int test(union s1s2 *p1, union s1s2 *p2, union s1s2 *p3)
>>> {
>>> if (read_s1x(&p1->v1))
>>> {
>>> unsigned short temp;
>>> temp = p3->v1.x;
>>> p3->v2.x = temp;
>>> write_s2x(&p2->v2,1234);
>>> temp = p3->v2.x;
>>> p3->v1.x = temp;
>>> }
>>> return read_s1x(&p1->v1);
>>> }
>>> int test2(int x)
>>> {
>>> union s1s2 q[2];
>>> q->v1.x = 4321;
>>> return test(q,q+x,q+x);
>>> }
>>> #include
>>> int main(void)
>>> {
>>> printf("%d\n",test2(0));
>>> }
>>>
>>>
>>> Both GCC and Clang in -fstrict-aliasing mode with optimizations are acting
>>> as if they ran into undefined behavior, and return 4321 instead of the
>>> expected 1234. This happens in both C and C++ mode. Intel C++ and Visual
>>> C++ return the expected 1234. All four compilers hardwire the result as a
>>> constant parameter to printf rather than call test2 or modify memory at
>>> runtime.
>>>
>>> From my reading of the C++ Standard, particularly [class.union]/5,
>>> assignment expressions through a union member access changes the active
>>> member of the union (if the union member has a trivial default constructor,
>>> which it does here, being C code). Taking the address of p2->v2 and p1->v1
>>> ought to be legal because those are the active members of the union at the
>>> time their pointers are taken.
>>>
>>> Is this a well-defined program, or is there subtle undefined behavior
>>> happening here?
Thanks.
As put in my stackoverflow answer[1], I believe this behavior is specified in
the GCC-online-doc, in section `-fstrict-alisgin'[2]:
Pay special attention to code like this:
union a_union {
int i;
double d;
};
int f() {
union a_union t;
t.d = 3.0;
return t.i;
}
The practice of reading from a different union member than the one most
recently written to (called *type-punning*) is common. Even with
*-fstrict-aliasing*, type-punning is allowed, provided the memory is
accessed through the union type. So, the code above works as expected.
See Structures unions enumerations and bit-fields implementation.
However, this code might not:
int f() {
union a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
Similarly, access by taking the address, casting the resulting pointer
and dereferencing the result has undefined behavior, even if the cast
uses a union type, e.g.:
int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
}
The -fstrict-aliasing option is enabled at levels -O2, -O3, -Os.
I think the second example above is similar to the OP's question (although the
C standard might not say so... so from my perspective if the second example
above is true, the OP's code is invalid.
Do anyone have any comment?
Yubin
[1]:
https://stackoverflow.com/questions/46205744/is-this-use-of-unions-strictly-conforming/46968235?noredirect=1#comment80930683_46968235
[2]: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
