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 t
t; would be an empty type, and that's not what we want. "Trivially copyable"
> is a reasonably common abstraction (if in doubt we could even define it in
> the ABI), and captures the idea that we need well (namely that a bit-copy
> is enough).
>
>
> Ciao,
> Michael.
--
H.J.
s never invoked as part of passing
> such an object around. Its copy constructor is a nop and requires no
> reference to the original object.
>
Do you have a precise wording to describe it?
--
H.J.
abi/
>
> The link to the "GNU GABI project web page" in
> https://sourceware.org/ml/gnu-gabi is broken.
How do I subscribe gnu-abi mailing list? The project page just
points to the mailing list archive. There is no option to subscribe
it.
--
H.J.
On Fri, Feb 19, 2016 at 1:00 PM, Markus Trippelsdorf
wrote:
> On 2016.02.19 at 12:57 -0800, H.J. Lu wrote:
>> On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
>> wrote:
>> >
>> > > Great. I'll ask overseers to create a mailinglist. [...]
>>
On Fri, Feb 19, 2016 at 1:16 PM, Mark Wielaard wrote:
> On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
>> How do I subscribe gnu-abi mailing list? The project page just
>> points to the mailing list archive. There is no option to subscribe
>> it.
>
> To subs
; is enough).
In this case:
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);
}
dummy shouldn't be passed as empty type. We need to have a clear
definition for what kinds of member functions are allowed in an empty
type.
--
H.J.
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);
>> };
>>
>&g
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 clas
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
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
On Sat, Feb 20, 2016 at 10:48 PM, Richard Smith wrote:
> On 20 Feb 2016 10:01 p.m., "H.J. Lu" wrote:
>>
>> On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith
>> wrote:
>> > On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote:
>> >>
>>
recursively)
> are of class, structure, union, or array type. No memory slot nor
> register should be used to pass or return an object of empty type that's
> trivially copyable.
> ---
>
> (With possibly a self-sufficient definition of trivially copyable, that's
> language agnostic)
>
Do you have an example in which an empty type defined above isn't
"trivially copyable"?
--
H.J.
On Tue, Feb 23, 2016 at 7:30 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> > ---
>> > 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 n
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 array type
On Tue, Feb 23, 2016 at 5:14 PM, Richard Smith wrote:
> 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
>&
On Fri, Feb 26, 2016 at 9:25 AM, Joel Sherrill
wrote:
> Hi
>
> Is there something special needed to commit via git? I got an odd error
> pushing some minor RTEMS patches and wondered what the proper procedure was.
What is "odd error"?
H.J.
excess errors)
on gcc-5-branch.
--
H.J.
--
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index d05953a..7d61d0e 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2016-03-02 H.J. Lu
+
+ Backport from mainline
+ 2015-11-25 Paolo Carlini
; is a good idea. Here is the updated change:
An empty type is a type where it and all of its subobjects (recursively)
are of structure, union, or array type. No memory slot nor register
should be used to pass or return an object of empty type.
Footnote: Array of empty type can only passed by reference in C and C++.
Languages may have exceptions like array in C/C++ and class in C++.
--
H.J.
e
the CSE pass, I run into
gcc_assert (!dom_info_available_p (CDI_DOMINATORS));
--
H.J.
On Thu, Mar 10, 2016 at 5:01 AM, Richard Biener
wrote:
> On Thu, Mar 10, 2016 at 1:48 PM, H.J. Lu wrote:
>> convert_scalars_to_vector in i386.c calls
>>
>> calculate_dominance_info (CDI_DOMINATORS);
>>
>> Shouldn't it call
>>
>> free_dominance_
On Thu, Mar 10, 2016 at 5:24 AM, Richard Biener
wrote:
> On Thu, Mar 10, 2016 at 2:16 PM, H.J. Lu wrote:
>> On Thu, Mar 10, 2016 at 5:01 AM, Richard Biener
>> wrote:
>>> On Thu, Mar 10, 2016 at 1:48 PM, H.J. Lu wrote:
>>>> conve
On Thu, Mar 10, 2016 at 5:41 AM, H.J. Lu wrote:
> On Thu, Mar 10, 2016 at 5:24 AM, Richard Biener
> wrote:
>> On Thu, Mar 10, 2016 at 2:16 PM, H.J. Lu wrote:
>>> On Thu, Mar 10, 2016 at 5:01 AM, Richard Biener
>>> wrote:
>>>> On Th
On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek wrote:
> On Thu, Mar 10, 2016 at 05:43:27AM -0800, H.J. Lu wrote:
>> > free_dominance_info (CDI_DOMINATORS);
>>
>> Since convert_scalars_to_vector may add instructions, dominance
>> info is no longer up to date.
>
>
On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu wrote:
> On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek wrote:
>> On Thu, Mar 10, 2016 at 05:43:27AM -0800, H.J. Lu wrote:
>>> > free_dominance_info (CDI_DOMINATORS);
>>>
>>> Since convert_scalars_to_vector may add
On Thu, Mar 10, 2016 at 12:18 PM, Richard Biener
wrote:
> On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu" wrote:
>>On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu wrote:
>>> On Thu, Mar 10, 2016 at 5:49 AM, Jakub Jelinek
>>wrote:
>>>> On Thu, M
On Thu, Mar 10, 2016 at 1:24 PM, Jeff Law wrote:
> On 03/10/2016 01:18 PM, Richard Biener wrote:
>>
>> On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu"
>> wrote:
>>>
>>> On Thu, Mar 10, 2016 at 6:57 AM, H.J. Lu wrote:
>>>>
>&
On Thu, Mar 10, 2016 at 1:30 PM, H.J. Lu wrote:
> On Thu, Mar 10, 2016 at 1:24 PM, Jeff Law wrote:
>> On 03/10/2016 01:18 PM, Richard Biener wrote:
>>>
>>> On March 10, 2016 6:02:58 PM GMT+01:00, "H.J. Lu"
>>> wrote:
>>>>
>>>&g
On Thu, Mar 10, 2016 at 7:03 PM, Jeff Law wrote:
> On 03/10/2016 08:00 PM, H.J. Lu wrote:
>>
>> On Thu, Mar 10, 2016 at 1:30 PM, H.J. Lu wrote:
>>>
>>> On Thu, Mar 10, 2016 at 1:24 PM, Jeff Law wrote:
>>>>
>>>> On 03/10/2016 01:18 PM, Ri
On Fri, Mar 11, 2016 at 2:06 AM, Richard Biener
wrote:
> On Fri, Mar 11, 2016 at 4:10 AM, H.J. Lu wrote:
>> On Thu, Mar 10, 2016 at 7:03 PM, Jeff Law wrote:
>>> On 03/10/2016 08:00 PM, H.J. Lu wrote:
>>>>
>>>> On Thu, Mar 10, 2016 at 1:30 PM, H.J. Lu
On Fri, Mar 11, 2016 at 4:58 AM, Richard Biener
wrote:
> On Fri, Mar 11, 2016 at 1:47 PM, H.J. Lu wrote:
>> On Fri, Mar 11, 2016 at 2:06 AM, Richard Biener
>> wrote:
>>> On Fri, Mar 11, 2016 at 4:10 AM, H.J. Lu wrote:
>>>> On Thu, Mar 10, 2016 at 7:03 PM,
On Fri, Mar 11, 2016 at 5:19 AM, Richard Biener
wrote:
> On Fri, Mar 11, 2016 at 2:02 PM, H.J. Lu wrote:
>> On Fri, Mar 11, 2016 at 4:58 AM, Richard Biener
>> wrote:
>>> On Fri, Mar 11, 2016 at 1:47 PM, H.J. Lu wrote:
>>>> On Fri, Mar 11, 2016 at 2:06 AM,
On Fri, Mar 11, 2016 at 5:50 AM, H.J. Lu wrote:
> On Fri, Mar 11, 2016 at 5:19 AM, Richard Biener
> wrote:
>> On Fri, Mar 11, 2016 at 2:02 PM, H.J. Lu wrote:
>>> On Fri, Mar 11, 2016 at 4:58 AM, Richard Biener
>>> wrote:
>>>> On Fri, Mar 11, 2016 at
On Fri, Mar 11, 2016 at 6:03 AM, Richard Biener
wrote:
> On Fri, Mar 11, 2016 at 3:01 PM, H.J. Lu wrote:
>> On Fri, Mar 11, 2016 at 5:50 AM, H.J. Lu wrote:
>>> On Fri, Mar 11, 2016 at 5:19 AM, Richard Biener
>>> wrote:
>>>> On Fri, Mar 11, 2016 at 2:02 P
On Fri, Mar 11, 2016 at 6:45 AM, H.J. Lu wrote:
> On Fri, Mar 11, 2016 at 6:03 AM, Richard Biener
> wrote:
>> On Fri, Mar 11, 2016 at 3:01 PM, H.J. Lu wrote:
>>> On Fri, Mar 11, 2016 at 5:50 AM, H.J. Lu wrote:
>>>> On Fri, Mar 11, 2016 at 5:19 AM, Richard Bien
id2HH4IQAJ
I have a proposal to mark object file with
NT_GNU_PROPERTY_NO_COPY_ON_PROTECTED
https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
It requires changes in compiler, ld and ld.so.
--
H.J.
. All these are due to
incompatibility between protected symbol and copy relocation.
--
H.J.
uld you get when taking an address of a function
with protected visibility inside the shared library? Should it be
pointed to the function body or its PLT entry in the executable
which calls the function?
--
H.J.
On Mon, Apr 18, 2016 at 10:03 AM, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, H.J. Lu wrote:
>
>> > Any testcase the takes the address of a protected visibility variable
>> > defined in a shared library now can get the wrong answer, since you
>> > can argue th
On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Apr 2016, H.J. Lu wrote:
>
>> > reason is DSO code (also handcoded assembly) may reasonably expect to
>> > be able to load the address with a PC-relative load-address type
>> > inst
On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek wrote:
> On Mon, Apr 18, 2016 at 10:27:45AM -0700, H.J. Lu wrote:
>> On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote:
>> > Hi,
>> >
>> > On Mon, 18 Apr 2016, H.J. Lu wrote:
>> >
>> &g
ion. There is
at lease one GCC bug against protected symbol:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
which was reported by other people.
--
H.J.
On Tue, Apr 19, 2016 at 8:44 AM, H.J. Lu wrote:
> On Tue, Apr 19, 2016 at 8:37 AM, Cary Coutant wrote:
>>>> So with all this it sounds that current protected visibility is just
>>>> broken and we should forgo with it, making it equal to default
>>>> visibil
On Tue, Apr 19, 2016 at 8:52 AM, H.J. Lu wrote:
> On Tue, Apr 19, 2016 at 8:44 AM, H.J. Lu wrote:
>> On Tue, Apr 19, 2016 at 8:37 AM, Cary Coutant wrote:
>>>>> So with all this it sounds that current protected visibility is just
>>>>> broken and we s
't make what you said was true.
--
H.J.
in compiler,
ld and ld.so so that there is no surprise, either for correctness or
performance, at run-time.
--
H.J.
needs to happen. My worry is
> that we're so damn late in the gcc-6 cycle that it may need to be deferred
> to 6.2 or beyond.
Please keep in mind that many limitations can only be detected at
link-time or run-time, which are yet to be implemented, not at
compile-time.
--
H.J.
;>
>>>
>>> I am running with 4.2. Let me find the old email and see I should
>>> include it in our tree (I thought we did).
>>
>>
>> Found it. It looks like it was not put in yet:
>> https://bugzilla.kernel.org/show_bug.cgi?id=96311
>>
>> I know Jakub asked about a year ago saying it was not 4.1-rc1 yet.
>> Can someone look to see if it even made it into newer kernels?
>
> I know "a" fix is in modern Fedora kernels and I thought it came from
> upstream.
>
> Jeff
>
commit 1a48632ffed61352a7810ce089dc5a8bcd505a60
Author: Peter Hurley
Date: Mon Apr 13 13:24:34 2015 -0400
pty: Fix input race when closing
A read() from a pty master may mistakenly indicate EOF (errno == -EIO)
after the pty slave has closed, even though input data remains to be read.
For example,
--
H.J.
On Wed, Jul 20, 2016 at 3:07 PM, Andrew Pinski wrote:
> On Wed, Jul 20, 2016 at 2:57 PM, H.J. Lu wrote:
>> On Wed, Jul 20, 2016 at 2:20 PM, Jeff Law wrote:
>>> On 07/20/2016 03:09 PM, Andrew Pinski wrote:
>>>>
>>>> On Wed, Jul 20, 2016 at 2:02 PM, And
'compat' uses increased alignment value compatible uses GCC 4.8 and
earlier, 'abi' uses alignment value as specified by the psABI, and
'cacheline' uses increased alignment value to match the cache line
size. 'compat' is the default.
is supported by x86.
--
H.J.
skips it. Is this possible to pass/return empty
struct for C++ the same way as for C?
--
H.J.
implementation isn't tested nor verified. The
only real usage is
rdos64.h:#define REAL_PIC_OFFSET_TABLE_REGNUM R15_REG
which is correct.
We should fix Register Usage table in x86-64 psABI with the enclosed patch.
Any comments?
--
H.J.
---
diff --git a/low-level-sys-info.tex b/low-level-sys-inf
x27;t find any possible
usage for this relocation on function symbols.
Does anyone remember what it was supposed to be used for?
--
H.J.
On Thu, Nov 13, 2014 at 8:33 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 13 Nov 2014, H.J. Lu wrote:
>
>> x86-64 psABI has
>>
>> name@GOT: specifies the offset to the GOT entry for the symbol name
>> from the base of the GOT.
>>
>> name@GOTPLT: spec
tps://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html
Have you seen them?
--
H.J.
On Thu, Nov 13, 2014 at 9:03 AM, H.J. Lu wrote:
> On Thu, Nov 13, 2014 at 8:33 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 13 Nov 2014, H.J. Lu wrote:
>>
>>> x86-64 psABI has
>>>
>>> name@GOT: specifies the offset to the GOT entry for the
On Thu, Nov 13, 2014 at 10:37 AM, Ilya Verbin wrote:
> On 13 Nov 09:17, H.J. Lu wrote:
>> I noticed many libgomp test failures:
>>
>> https://gcc.gnu.org/ml/gcc-regression/2014-11/msg00309.html
>>
>> Have you seen them?
>
> Hi H.J.,
>
> I do not s
On Thu, Nov 13, 2014 at 11:20 AM, Ilya Verbin wrote:
> On 13 Nov 10:48, H.J. Lu wrote:
>> /usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M
>
> Looks like we should set flag_fat_lto_objects while compilation with
> offloading.
> I'll inves
On Thu, Nov 13, 2014 at 11:20 AM, Ilya Verbin wrote:
> On 13 Nov 10:48, H.J. Lu wrote:
>> /usr/local/bin/ld: /tmp/ccA8cExp.o: plugin needed to handle lto object^M
>
> Looks like we should set flag_fat_lto_objects while compilation with
> offloading.
> I'll inves
On Thu, Nov 13, 2014 at 12:53 PM, Ilya Verbin wrote:
> On 13 Nov 2014, at 23:11, H.J. Lu wrote:
>>
>> Section Headers:
>> [Nr] Name TypeAddress OffSize
>> ES Flg Lk Inf Al
>> [ 0] NULL000
your listing in the MAINTAINERS file.
>
> Happy hacking!
> David
>
Hi Maxim,
Have you added your name to MAINTAINERS?
--
H.J.
Hi,
Git tags are missing for GCC 4.9.1, 4.9.2, 4.8.3 and 4.7.4.
--
H.J.
On Mon, Nov 17, 2014 at 6:14 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 13 Nov 2014, H.J. Lu wrote:
>
>> Linker does:
>>
>> ... code that looks like it might create just one GOT slot ...
>>
>> So if a symbol is accessed by both @GOT and @PLTOFF, its
>&
On Tue, Nov 18, 2014 at 5:12 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 17 Nov 2014, H.J. Lu wrote:
>
>> It has nothing to do with large model.
>
> Yes, I didn't say so. I've used it only to force GCC to emit @GOT relocs
> (otherwise it would have used @GOTPCR
://www.sourceware.org/ml/binutils/2006-03/msg00276.html
place .plt after .text so that PLT is between text and GOT:
text
PLT
readonly data
GOT
instead of
PLT
text
readonly data
GOT
I implemented it on hjl/plt branch. Any comments?
Roland, will it be a problem for NaCL?
Thanks.
--
H.J.
One issue with
text
PLT
readonly data
GOT
layout is it uses smaller data size for larger text size since the layout with
data is
text
PLT
readonly data
GOT
data
The data size is reduced by PLT size. If PLT is very large, impact
may be visible.
--
H.J.
On Mon, Nov 17, 2014 at 6:14 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 13 Nov 2014, H.J. Lu wrote:
>
>> Linker does:
>>
>> ... code that looks like it might create just one GOT slot ...
>>
>> So if a symbol is accessed by both @GOT and @PLTOFF, its
>&
On Wed, Nov 19, 2014 at 8:38 AM, H.J. Lu wrote:
>
> One way to optimize it is to make PLT entry to use the normal GOT
> slot:
>
> jmp *name@GOTPCREL(%rip)
> 8 byte nop
>
> where name@GOTPCREL points to the normal GOT slot
> updated by R_X86_64_GLOB_DAT relocation at r
On Wed, Nov 19, 2014 at 3:54 PM, H.J. Lu wrote:
> On Wed, Nov 19, 2014 at 8:38 AM, H.J. Lu wrote:
>>
>> One way to optimize it is to make PLT entry to use the normal GOT
>> slot:
>>
>> jmp *name@GOTPCREL(%rip)
>> 8 byte nop
>>
>> where name@G
t; symbol based ones, so that also virtual calls can be resolved lazily.
>
>
> Ciao,
> Michael.
I fixed a bug on hjl/plt.got branch:
https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/hjl/plt.got
It passed glibc tests and bootstrapped GCC. It optimized functions like
std::bad_exception::~bad_exception()
__cxa_finalize
std::range_error::~range_error()
std::bad_array_length::~bad_array_length()
--
H.J.
rg/gmane.comp.gcc.patches/327449
>
> --
> Markus
Since there is no objection to back port LTO support from
libtool upstream, I will check it in shortly.
Thanks.
--
H.J.
kefile.def, but
> I do not know how to enter that information there. Could someone help?
>
>
I saw
-L/opt/gcc/p_build/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
Why aren't they sufficient for MacOS linker to find libstdc++.a?
--
H.J.
for which -L is not enough.
>
It seems to work on Linux.
--
H.J.
10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
>> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>> - 10.[[012]]*)
>> + 10.[[012]][[,.]]*)
>> _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
>> ${wl}sup
>>10.*)
>> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>>
>
--
H.J.
#x27;d like to be backported,
> please do so soon, and if there are any known issues on the branch, please
> make sure they are reported in bugzilla and let us RMs know about those.
>
I backported the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037
--
H.J.
On Fri, Dec 5, 2014 at 4:08 AM, H.J. Lu wrote:
> On Fri, Dec 5, 2014 at 1:18 AM, Jakub Jelinek wrote:
>> Status
>> ==
>>
>> It is time for another 4.8 release, I'd like to create 4.8.4 release
>> candidate at the end of the next week and if all goes we
On Tue, Nov 25, 2014 at 3:12 AM, Jonathan Wakely wrote:
> On 16 November 2014 at 15:51, H.J. Lu wrote:
>> Hi,
>>
>> Git tags are missing for GCC 4.9.1, 4.9.2, 4.8.3 and 4.7.4.
>
> I can't create the tags but these are the release commit
Oops. Hit the wrong button. I will check it in.
Thanks.
-- Forwarded message --
From: Uros Bizjak
Date: Sat, Dec 27, 2014 at 7:41 AM
Subject: Re: PATC: PR target/64409: ICE building Mesa 10.4.0 for x32 ABI
To: "H.J. Lu"
On Sat, Dec 27, 2014 at 3:54 PM, H.J. Lu w
et hook so that combine will allow a single
add-to-memory instruction for volatile memory reference on
architectures like x86?
--
H.J.
c.gnu.org/ml/gcc/2015-01/msg00032.html
Can we make an exception for
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00956.html
It was originally submitted in November, 2013:
https://gcc.gnu.org/ml/gcc-patches/2013-11/msg01515.html
--
H.J.
Intel's official name), and "x86-64" (with a dash
>>> instead of underscore) for the 64-bit architecture. But of course the
>>> target maintainers should have the final say on what names to use.
I like this suggestion. Thanks.
>>
>> Ping? Any thoughts?
>
> Let's ask Intel people ...
>
--
H.J.
;t be farther away from it, and it's also vendor specific. Our
> traditional i386 seems better to me (although it has its own problems, but
> I'm not aware of any better abbreviation in the wild that's vendor neutral
> and specifically means the 32bit incarnation of the x86 architecture).
>
The problem with i386 is it is a real processor. When someone says i386,
it isn't clear if it means the processor or 32-bit x86.
--
H.J.
On Tue, Jan 20, 2015 at 6:14 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 20 Jan 2015, H.J. Lu wrote:
>
>> > ia32 is confusing because ia64 (a well known term) sounds related but
>> > can't be farther away from it, and it's also vendor specific. Our
rises because the 32-bit x86 architecture was around under other names long
> before Intel re-named it.
>
> Since there seems to be arguments against using both "IA-32" and "i386" for
> the 32-bit x86 architecture, how about, uh, "32-bit x86"? With the other
> names in parentheses where appropriate? I think we could also ignore the
> 16-bit x86 variants for the purposes of GCC and just use "x86" instead of
> "i386 and x86-64".
>
Please don't invent a new name. It may confuse people.
--
H.J.
On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote:
>> Ping? Any thoughts?
>
> x86 for the family and x86-32/x86-64 for the 2 architectures?
>
Works for me.
--
H.J.
On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
wrote:
> On 01/20/2015 11:40 AM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore
>> wrote:
>>>
>>> Since there seems to be arguments against using both "IA-32" and "i3
On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore
wrote:
> On 01/20/2015 12:21 PM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
>> wrote:
>>>
>>>
>>> Ummm, this seems like an inconsistent position. "32-bit x
On Tue, Jan 20, 2015 at 11:43 AM, H.J. Lu wrote:
> On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore
> wrote:
>> On 01/20/2015 12:21 PM, H.J. Lu wrote:
>>>
>>> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore
>>> wrote:
>>>>
>>>>
Here is the link:
https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
--
H.J.
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:
>>
>> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
>
> The document contains this claim (as do many other psABI documents
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:
>>>
>>> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
>>
On Thu, Jan 22, 2015 at 1:13 PM, Joseph Myers wrote:
> On Thu, 22 Jan 2015, H.J. Lu wrote:
>
>> Here is the link:
>>
>> https://groups.google.com/forum/#!topic/ia32-abi/nq6cvH_VVV4
>
> I sent the following reply to the ia32-abi list but haven't yet received
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754
is a LTO bug where stage 1 and stage 2 compilers generate
different LTO IR. Is there a way to dump LTO IR to see the
actual difference in LTO IR?
Thanks.
--
H.J.
On Mon, Jan 26, 2015 at 12:57 AM, Richard Biener
wrote:
> On Fri, Jan 23, 2015 at 9:26 PM, H.J. Lu wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754
>>
>> is a LTO bug where stage 1 and stage 2 compilers generate
>> different LTO IR. Is there a wa
For the past couple days, gcc.gnu.org/sourceware.org is
quite slow for me when accessing git and bugzilla. Am
I the only one who has experienced it?
--
H.J.
FYI.
H.J.
-- Forwarded message --
From: H.J. Lu
Date: Thu, Feb 5, 2015 at 10:35 AM
Subject: ANNOUNCEMENT: Intel386 psABI version 1.0
To: IA32 System V Application Binary Interface
After almost 18 years, I am very pleased to announce "System V
Application Binary
Inte
{Target Hook} void
TARGET_ASM_ASSEMBLE_VISIBILITY (tree @var{decl}, int @var{visibility})
doc/tm.texi.in:@hook TARGET_ASM_ASSEMBLE_VISIBILITY
How is it used?
--
H.J.
On Fri, Feb 6, 2015 at 2:20 PM, H.J. Lu wrote:
> I saw
>
> config/darwin.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/darwin.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
> darwin_assemble_visibility
> config/i386/cygming.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/i
; IvyBridge. I will keep you posted if I find out more.
>
To compare 64-bit vs 32-bit performance on Linux against MacOS,
you MUST compile your code with -fPIC on Linux since -fPIC is
the default on MacOS.
--
H.J.
And TLSDESC/gnu2 model isn't implemented for x32.
There are no tests for TLSDESC/gnu2 model in glibc.
I have no ideas if it works in glibc master on x86-32 or
x86-64 today.
--
H.J.
101 - 200 of 1206 matches
Mail list logo
