I was working on PR68425,
my untested patch :
diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c
--- a/trunk/gcc/c/c-typeck.c(revision 232768)
+++ b/trunk/gcc/c/c-typeck.c(working copy)
@@ -5856,7 +5856,7 @@
component name is taken from the spelling stack. */
static void
On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith wrote:
> On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote:
>>
>> On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin
>> wrote:
>> > On 20 February 2016 at 23:35, H.J. Lu wrote:
>> >> Can a compiler tell if a copy constructor or destructor is trivial
>> >>
On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin
wrote:
> On 20 February 2016 at 23:35, H.J. Lu wrote:
>> Can a compiler tell if a copy constructor or destructor is trivial
>> from the class declaration without function body?
>
> Yes, the mere presence of the declaration suffices to render it
>
On 20 February 2016 at 23:35, H.J. Lu wrote:
> Can a compiler tell if a copy constructor or destructor is trivial
> from the class declaration without function body?
Yes, the mere presence of the declaration suffices to render it
non-trivial (unless explicitly declared "= default" like I did with
On Sat, Feb 20, 2016 at 11:40 AM, Matthijs van Duin
wrote:
> On 20 February 2016 at 20:34, H.J. Lu wrote:
>> Is there a class, which meets the above definition, with a member function
>> which can't be passed without a memory slot or a register?
>
> The EmptyInt class in my first post in this th
On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote:
> There's at least one easy answer in there:
>
> > If implementations must support annotation, what form should that
> annotation take? P0190R0 recommends the [[carries_dependency]]
> attribute, but I am not picky as long as i
On 20 February 2016 at 20:34, H.J. Lu wrote:
> Is there a class, which meets the above definition, with a member function
> which can't be passed without a memory slot or a register?
The EmptyInt class in my first post in this thread. It has no
non-static data members, has standard layout, and h
On Sat, Feb 20, 2016 at 10:50 AM, Matthijs van Duin
wrote:
> On 20 February 2016 at 18:55, H.J. Lu wrote:
>> struct dummy0
>> {
>> };
>>
>> struct dummy
>> {
>> dummy0 d[20];
>>
>> dummy0 * foo (int i);
>> };
>>
>> dummy0 *
>> dummy::foo (int i)
>> {
>> return &d[i];
>> }
>>
>> dummy0 *
>>
On 20 February 2016 at 18:55, H.J. Lu wrote:
> struct dummy0
> {
> };
>
> struct dummy
> {
> dummy0 d[20];
>
> dummy0 * foo (int i);
> };
>
> dummy0 *
> dummy::foo (int i)
> {
> return &d[i];
> }
>
> dummy0 *
> bar (dummy d, int i)
> {
> return d.foo (i);
> }
1. This has undefined behavio
On Sat, 20 Feb 2016, H.J. Lu wrote:
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
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, un
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
> 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 ty
2015-06-16 17:23 GMT+03:00 Joseph Myers :
> On Mon, 15 Jun 2015, Andrew Pinski wrote:
>
>> > results in asm redirection for log to __log_finite and final vector
>> > function name becomes _ZGVbN2v___log_finite.
>> >
>> > With point of view from C Library side, it reflects in addition of asm
>> > re
12 matches
Mail list logo
