[Please CC me; I'm not subscribed]
On Thu, 24 Jan 2019 11:59 at Richard Biener wrote:
> On Wed, Jan 23, 2019 at 12:33 PM Jakub Jelinek wrote:
> > On Wed, Jan 23, 2019 at 10:40:43AM +, Jonathan Wakely wrote:
> > > There's a patch to add __builtin_dynamic_object_size to clang:
> > > https://rev
On Tue, Feb 23, 2016 at 8:28 AM, H.J. Lu wrote:
> On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> I thought
>>>
>>> ---
>>> An empty type is a type where it and all of its subobjects (recursively)
>>> are of class, structure, union, or
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Feb 2016, Richard Smith wrote:
>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively) are of class, structure, union, or array type. No
>> >>
On Thu, Feb 18, 2016 at 6:35 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Feb 2016, H.J. Lu wrote:
>
>> Here is the new definition:
>>
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type. No memory slot nor
>> register shoul
On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 1:10 P
On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 12:25 P
On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>> wrote:
>>>> On Tue, Feb 16, 2016 at 10:24
On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>
>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>> > On Fri, Feb 12, 2016 at
On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> > wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>>
On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
>>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
>>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
&
On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote:
>> Do we really need an 'empty type' special case?
>>
>> The x86_64 psABI already seems clear that empty types with size <= 16
>> are not passed at all.
On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>>>
>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith
>>> wrote:
>>> > On Mon, Feb 8, 2016 a
ly affect the behavior of types larger than 16
bytes that contain no data. It doesn't seem worth breaking ABI to more
efficiently pass those.
On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>>
>> On Mon, Feb 8, 2016 at 12:38
On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>
> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote:
> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote:
> >>
> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely
> >> wrote:
> >> &g
On Thu, Jan 22, 2015 at 12:05 PM, H.J. Lu wrote:
> On Thu, Jan 22, 2015 at 12:00 PM, H.J. Lu wrote:
>> On Thu, Jan 22, 2015 at 11:54 AM, Richard Smith
>> wrote:
>>> On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote:
>>>> Here is the link:
>>>>
&
On Thu, Jan 22, 2015 at 4:35 AM, H.J. Lu wrote:
> Here is the link:
>
> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
The document contains this claim (as do many other psABI documents):
"Bit-fields that are neither signed nor unsigned
always have non-negative values. Although the
On Sat, Oct 20, 2012 at 7:36 PM, Gabriel Dos Reis
wrote:
> On Sat, Oct 20, 2012 at 2:24 PM, Jordan Rose wrote:
>> While throwing things out there, why not just optionally allow constexpr
>> functions to coexist with non-constexpr functions of the same name, like
>> inline and non-inline?
I thi
On Fri, Oct 19, 2012 at 10:53 PM, Chandler Carruth wrote:
>
> On Fri, Oct 19, 2012 at 10:04 PM, Richard Smith
> wrote:
> >
> > [Crossposted to both GCC and Clang dev lists]
> >
> > Hi,
> >
> > One issue facing library authors wanting to use C
e 'functionally equivalent not not
equivalent' [14.5.5.1/7] rule grants compilers licence to
ignore any particularly tricky cases. That said, I think
my suggestion, above, of mangling the unmangled, unqualified
name gets around this.
Richard Smith
set (or enough information to regenerate
it); or mangle the name after overload resolution and loose
the ability to mangle 'functionally equivalent' expressions
accurately. The latter sounds far easier, but is contrary
to the spirit of the existing ABI.
Richard Smith
;
public:
static const bool value = sizeof(fn(0)) == sizeof(yes);
};
If so, that's excellent news.
Richard Smith
Doug Gregor wrote:
> Hi Richard,
>
> On 7/26/07, Richard Smith <[EMAIL PROTECTED]> wrote:
>
> > A three line example exhibiting the ICE is:
> >
> > template struct helper {};
> > template void check( helper* );
> > int main() { check(0); }
&
n fairly arcane code, it
can nevertheless occur in legal code: I've generally
encountered it when developing type traits using template
metaprogramming.
Richard Smith
not a valid preprocessing token, the behavior is undefined."
The passage in the ISO C standard is 6.10.3.3/3, and
includes the same text.
--
Richard Smith
25 matches
Mail list logo