On 02/11/16 23:13, David Malcolm wrote:
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MEL
On Thu, Feb 11, 2016 at 04:38:28PM +, Joseph Myers wrote:
> I think that none of the ABI extensions in question are anything to do
> with Linux, the kernel. Rather, they are ABI extensions for userspace in
> the GNU system, which apply the same under multiple kernels (but so
On Thu, 2016-02-11 at 19:54 +0100, Basile Starynkevitch wrote:
> Hello All,
>
> I am busy merging the GCC trunk branch (i.e. future GCC 6) into the
> MELT
> branch & plugin.
>
> I am noticing a strange thing.
>
> I was able to merge GCC trunk svn rev. 227945 into the MELT branch
> (svn
> rev.
On Thu, Feb 11, 2016 at 10:50:29AM -0500, Ed Maste via llvm-commits wrote:
> On 8 February 2016 at 18:08, Joseph Myers wrote:
> > On Mon, 8 Feb 2016, H.J. Lu wrote:
> >
> >> >> I was referring to program properties:
> >> >>
> >> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>
H.J. Lu wrote:
On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
wrote:
On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
wrote:
H.J,
I think we are fragmenting with too many standards and mailing lists.
This
new discussion group and eventually th
Hello All,
I am busy merging the GCC trunk branch (i.e. future GCC 6) into the MELT
branch & plugin.
I am noticing a strange thing.
I was able to merge GCC trunk svn rev. 227945 into the MELT branch (svn
rev. 233352) without any issues.
Now, I am trying to merge into the MELT branch
svn m
On Thu, Feb 11, 2016 at 04:38:28PM +, Joseph Myers wrote:
> I think that none of the ABI extensions in question are anything to do
> with Linux, the kernel. Rather, they are ABI extensions for userspace in
> the GNU system, which apply the same under multiple kernels (but some of
> them may
On February 11, 2016 6:39:02 PM GMT+01:00, Cristina Georgiana Opriceana
wrote:
>Hello,
>
>Is there any implementation for replacing all uses of a variable with
>another variable in gimple?
>
>If I want to replace the uses of a variable with another one, do I
>have to do this by hand, investigate
Hello,
Is there any implementation for replacing all uses of a variable with
another variable in gimple?
If I want to replace the uses of a variable with another one, do I
have to do this by hand, investigate the type of the instruction and
perform a replacement where necessary or is there any so
On Thu, Feb 11 2016, Matthew Fortune wrote:
> No I think this is backwards it is the left half that shadows the next
> register and pieces are taken from the right. I've attempted a description
> below to see if it helps.
>
> I don't believe (in the MIPS case) we could unconditionally view the eve
On Thu, 11 Feb 2016, Suprateeka R Hegde wrote:
> H.J,
>
> I think we are fragmenting with too many standards and mailing lists. This new
> discussion group and eventually the resulting standards, all might be put
> under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>
> The Intro on LSB says
On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
wrote:
> On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
>>
>> On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
>> wrote:
>>>
>>> H.J,
>>>
>>> I think we are fragmenting with too many standards and mailing lists.
>>> This
>>> new discussion group and
On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
wrote:
H.J,
I think we are fragmenting with too many standards and mailing lists. This
new discussion group and eventually the resulting standards, all might be
put under LSB http://refspecs.linuxfounda
On 8 February 2016 at 18:08, Joseph Myers wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discu
On Thu, Feb 11, 2016 at 6:54 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, H.J. Lu wrote:
>
>> Any suggestions on new wording, something like
>>
>> 1. "class type". A class type is a structure, union or C++ class.
>> 2. "empty type". An empty type is a type where it and all of its
>>
To avoid depending again on precise wording of definitions in C++
standard it may be worth being explicit about the requirement to be
trivially copyable *and* destructible, since although the former
implies the latter in the C++ standard this is not obvious from the
terminology (although you also n
Hi,
On Thu, 11 Feb 2016, H.J. Lu wrote:
> Any suggestions on new wording, something like
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty type". An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Does it cover
>
>
On Thu, Feb 11, 2016 at 6:30 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, Jonathan Wakely wrote:
>
>> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
>> > You never define "POD for the purposes of layout", and I can only
>> > interpret it as being equivalent to "standard-layout".
Hi,
On Thu, 11 Feb 2016, Jonathan Wakely wrote:
> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> > You never define "POD for the purposes of layout", and I can only
> > interpret it as being equivalent to "standard-layout".
>
> As Richard pointed out, it's defined in the C++ ABI.
Whic
On Thu, Feb 11, 2016 at 6:18 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 15:00, H.J. Lu wrote:
>> I intentionally exclude C++ specific features in my propose.
>
> Yet you use a definition from the Itanium C++ ABI which itself depends
> on multiple definitions in a particular version of
On 11 February 2016 at 15:00, H.J. Lu wrote:
> I intentionally exclude C++ specific features in my propose.
Yet you use a definition from the Itanium C++ ABI which itself depends
on multiple definitions in a particular version of the C++ standard,
which depend on C++ specific features.
This make
On Thu, Feb 11, 2016 at 5:44 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 13:58, H.J. Lu wrote:
>> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>>
>> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>
> Sorry, I overlooked that.
>
> I still stand by
On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
wrote:
> H.J,
>
> I think we are fragmenting with too many standards and mailing lists. This
> new discussion group and eventually the resulting standards, all might be
> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>
> The Intro o
On 11 February 2016 at 13:58, H.J. Lu wrote:
> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
Sorry, I overlooked that.
I still stand by my viewpoint however that triviality of copying and
destruction is th
On Thu, Feb 11, 2016 at 4:40 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 11:53, H.J. Lu wrote:
>> Since this isn't Plain Old Data (POD) for the purposes of layout, it
>> isn't covered by my proposal for psABI. I leave this to C++ ABI.
>
> You never define "POD for the purposes of layou
On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> You never define "POD for the purposes of layout", and I can only
> interpret it as being equivalent to "standard-layout".
As Richard pointed out, it's defined in the C++ ABI.
On 11 February 2016 at 11:53, H.J. Lu wrote:
> Since this isn't Plain Old Data (POD) for the purposes of layout, it
> isn't covered by my proposal for psABI. I leave this to C++ ABI.
You never define "POD for the purposes of layout", and I can only
interpret it as being equivalent to "standard-l
Sorry for the slow response...
Andreas Arnez writes:
> On Mon, Jan 25 2016, Matthew Fortune wrote:
>
> > My dwarf knowledge is not brilliant but I have had to recently
> > consider it for MIPS floating point ABI changes aka FPXX and friends.
> > I don't know exactly where this fits in to your wh
On Thu, Feb 11, 2016 at 2:47 AM, Matthijs van Duin
wrote:
> On 8 February 2016 at 22:40, H.J. Lu wrote:
>> "empty type". An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>
> Note that the term "empty type" is commonly used in type theory to
On 8 February 2016 at 22:40, H.J. Lu wrote:
> "empty type". An empty type is either an array of empty types or a
> class type where every member is of empty type.
Note that the term "empty type" is commonly used in type theory to
denote a (or the) type with no values. The closest thing C has wo
H.J,
I think we are fragmenting with too many standards and mailing lists.
This new discussion group and eventually the resulting standards, all
might be put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
The Intro on LSB says:
http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-
31 matches
Mail list logo
