Re: Git ChangeLog policy for GCC Testsuite inquiry

2020-01-24 Thread H.J. Lu
On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote: > > On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote: > > > > In my experience the output of git log is a total mess so cannot > > > > replace ChangeLogs. But we can well decide to drop ChangeLog for > > > > the testsuite. > > > > > > Well,

Re: Git question: Rebasing a user branch

2020-02-04 Thread H.J. Lu
On Tue, Feb 4, 2020 at 2:03 PM Bill Schmidt wrote: > > I'm having a little difficulty with my workflow, and I'm hoping someone > can spot the problem. > > I have a user branch set up with the contrib/git-add-user-branch.sh > script. Here are the relevant portions of my .git/config: > > [remote "u

Re: GCC 9.3 Status Report (2020-02-28)

2020-02-28 Thread H.J. Lu
On Fri, Feb 28, 2020 at 5:42 AM Jakub Jelinek wrote: > > Status > == > > GCC 9.2 has been released more than half a year ago and it is time > for another release from the latest stable branch. Many people have > backported their fixes to 9 branch recently already, often together > with backpo

Re: Second GCC 8.4 Release Candidate available from gcc.gnu.org

2020-03-02 Thread H.J. Lu
elease 8.4 on Wednesday, March 4th. > I'd like to backport: commit r10-6965-g577350603a657590c4b54a4a966cb49497e2514c Author: H.J. Lu Date: Mon Mar 2 03:08:57 2020 -0800 lto: Also copy .note.gnu.property section When generating the separate file with LTO debug sections, we s

Re: Second GCC 8.4 Release Candidate available from gcc.gnu.org

2020-03-02 Thread H.J. Lu
On Mon, Mar 2, 2020 at 3:46 AM Jakub Jelinek wrote: > > On Mon, Mar 02, 2020 at 03:41:06AM -0800, H.J. Lu wrote: > > On Mon, Mar 2, 2020 at 2:46 AM Jakub Jelinek wrote: > > > > > > The second release candidate for GCC 8.4 is available from > > > > > &

Re: GCC 8.5 Status Report (2020-03-04)

2020-03-04 Thread H.J. Lu
On Wed, Mar 4, 2020 at 2:30 AM Jakub Jelinek wrote: > > Status > == > > GCC 8.4 has been released and the branch is again open for regression > and documentation fixes. History makes us expect a GCC 8.5 release > in fall of this year and it will be the last release from the GCC 8 > series. >

Re: GCC 8.5 Status Report (2020-03-04)

2020-03-04 Thread H.J. Lu
On Wed, Mar 4, 2020 at 5:01 AM Jakub Jelinek wrote: > > On Wed, Mar 04, 2020 at 04:52:20AM -0800, H.J. Lu wrote: > > I saw these new failures on Fedora 31: > > > > FAIL: 22_locale/numpunct/members/char/3.cc execution test > > FAIL: 22_locale/time_get/get_time/cha

X86 GCC automated testers are back online

2020-03-09 Thread H.J. Lu
X86 GCC automated testers are back online. They bootstrap and run testsuite for master branch and the current 2 release branches on Linux/x86-64 and Linux/i686: https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555912.html https://gcc.gnu.org/pipermail/gcc-testresults/2020-March/555909.ht

Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt

2015-06-30 Thread H.J. Lu
On Tue, Jun 30, 2015 at 4:33 AM, Zinovy Nis wrote: > Hi. > > > I'm building libgcc for a "iamcu" target (Pentium-like but with > soft-fp emulation, the only x86 with SoftFP I know) with > --enable-target-optspace. Support for i?86*-*-elfiamcu target has been checked in as of revision 225199. >

Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt

2015-06-30 Thread H.J. Lu
On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers wrote: > On Tue, 30 Jun 2015, Zinovy Nis wrote: > >> It works properly but I noticed that code the size for many arithmetic >> functions is much more larger than for soft-fp emulation provided by >> LLVM's compiler_rt library. > > Code size is discuss

RFC: Add R_X86_64_INDBR_GOTPCREL and R_386_INDBR_GOT32

2015-07-01 Thread H.J. Lu
To avoid indirect branch to locally defined functions, I am proposing to add a new relocation, R_X86_64_INDBR_GOTPCREL, to x86-64 psABI: 1. When branching to an external function, foo, toolchain generates call/jmp *foo@GOTPCREL(%rip) with R_X86_64_INDBR_GOTPCREL relocation, instead o

Re: Question about DRAP register and reserving hard registers

2015-07-09 Thread H.J. Lu
On Thu, Jul 9, 2015 at 9:31 AM, Steve Ellcey wrote: > On Mon, 2015-06-29 at 11:10 +0100, Richard Henderson wrote: > >> > OK, I think I have this part of the code working on MIPS but >> > crtl->drap_reg is used in the epilogue as well as the prologue even if >> > it is not 'live' in between. If I

Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc

2015-07-14 Thread H.J. Lu
On Tue, Jul 14, 2015 at 10:03 AM, Jim Wilson wrote: > On 07/14/2015 02:13 AM, Jan Beulich wrote: >> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead >> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways. > > in-tree/combined-tree builds aren't recommended a

Re: configure.{in -> ac} rename (commit 35eafcc71b) broke in-tree binutils building of gcc

2015-07-14 Thread H.J. Lu
On Tue, Jul 14, 2015 at 7:00 PM, wrote: > > > >> On Jul 15, 2015, at 9:20 AM, Alan Modra wrote: >> >>> On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote: >>> Alan, gcc maintainers, >>> >>> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead >>> of 2.24 as I had in

PATCH: Also check configure.ac in binutils source tree

2015-07-15 Thread H.J. Lu
On Tue, Jul 14, 2015 at 7:06 PM, H.J. Lu wrote: > On Tue, Jul 14, 2015 at 7:00 PM, wrote: >> >> >> >>> On Jul 15, 2015, at 9:20 AM, Alan Modra wrote: >>> >>>> On Tue, Jul 14, 2015 at 10:13:06AM +0100, Jan Beulich wrote: >>>> Al

[PATCH] PR rtl-optimization/67029: gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns

2015-08-05 Thread H.J. Lu
Since ira_implicitly_set_insn_hard_regs may be called outside of ira-lives.c, it can't use the local variable, preferred_alternatives. This patch adds an alternative_mask argument to ira_implicitly_set_insn_hard_regs. OK for master and 5 branch if there are no regressions on Linux/x86-64? H.J. --

Re: [PATCH] PR rtl-optimization/67029: gcc-5.2.0 unable to find a register to spill with O3 fsched-pressure fschedule-insns

2015-08-06 Thread H.J. Lu
On Thu, Aug 6, 2015 at 11:19 AM, Richard Sandiford wrote: > "H.J. Lu" writes: >> Since ira_implicitly_set_insn_hard_regs may be called outside of >> ira-lives.c, it can't use the local variable, preferred_alternatives. >> This patch

Re: Adding static-PIE support to binutils

2015-08-17 Thread H.J. Lu
On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: > For background on the static PIE model I'm working with, see the > following post to the GCC list: > > https://gcc.gnu.org/ml/gcc/2015-06/msg8.html > > So far, I've been prototyping static PIE support by having GCC pass > the following opti

Re: Adding static-PIE support to binutils

2015-08-17 Thread H.J. Lu
On Mon, Aug 17, 2015 at 3:43 PM, Rich Felker wrote: > On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> > For background on the static PIE model I'm working with, see the >> > following post

Re: Adding static-PIE support to binutils

2015-08-18 Thread H.J. Lu
On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote: > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> On Mon, Aug 17, 2015 at 02:19:34PM -0700, H.J. Lu wrote: >> > On Tue, Jun 23, 2015 at 9:18 PM, Rich Felker wrote: >> > > For background on the sta

Re: Adding static-PIE support to binutils

2015-08-18 Thread H.J. Lu
On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker wrote: > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote: >> On Mon, Aug 17, 2015 at 8:44 PM, Rich Felker wrote: >> > On Mon, Aug 17, 2015 at 10:42:56PM -0400, Rich Felker wrote: >> >> On Mon, Aug 17, 2015 at 0

Re: Adding static-PIE support to binutils

2015-08-18 Thread H.J. Lu
On Tue, Aug 18, 2015 at 5:58 PM, Rich Felker wrote: > On Tue, Aug 18, 2015 at 09:30:56AM -0700, H.J. Lu wrote: >> On Tue, Aug 18, 2015 at 9:08 AM, Rich Felker wrote: >> > On Tue, Aug 18, 2015 at 08:56:00AM -0700, H.J. Lu wrote: >> >> On Mon, Aug 17, 2015

Re: Moving to git

2015-08-21 Thread H.J. Lu
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan wrote: > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > wrote: >> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: Absolutely, a non-fast-forward push is anathema for anything other people might be working on. The

Re: Moving to git

2015-08-21 Thread H.J. Lu
On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf wrote: > > BTW while I have your attention: Why are you constantly creating > (rebasing) and deleting branches? Why not simply use a local git tree > for this purpose? I want to share my branches with people who have no access to my local git r

Re: Moving to git

2015-08-21 Thread H.J. Lu
On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> One very frustrating thing for me is "git bisect" doesn't always >> work. I think cherry-pick is OK, but probably not rebase nor merge. >> >> Can we e

Re: Moving to git

2015-08-21 Thread H.J. Lu
On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> up to date by "git merge origin/master". I never tried "git bisect" >> on it since I know that commits on that branch aren't consecutive. > > bisect works

Re: Moving to git

2015-08-21 Thread H.J. Lu
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote: > "H.J. Lu" writes: > >> "git bisect good"/"git bisect bad" land my tree not on trunk when >> they are used on commits from wide-int branch merge. > > Yes, that is bisect working a

RFC: Support x86 interrupt and exception handlers

2015-09-03 Thread H.J. Lu
The interrupt and exception handlers are called by x86 processors. X86 hardware puts information on stack and calls the handler. The requirements are 1. Both interrupt and exception handlers must use the 'IRET' instruction, instead of the 'RET' instruction, to return from the handlers. 2. All re

Re: RFC: Support x86 interrupt and exception handlers

2015-09-15 Thread H.J. Lu
On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote: > The interrupt and exception handlers are called by x86 processors. X86 > hardware puts information on stack and calls the handler. The > requirements are > > 1. Both interrupt and exception handlers must use the 'IRET'

Re: RFC: Support x86 interrupt and exception handlers

2015-09-15 Thread H.J. Lu
On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune wrote: > H.J. Lu writes: >> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote: >> > The interrupt and exception handlers are called by x86 processors. X86 >> > hardware puts information on stack and calls the handler.

Re: RFC: Support x86 interrupt and exception handlers

2015-09-16 Thread H.J. Lu
On Wed, Sep 16, 2015 at 12:07 AM, Matthew Fortune wrote: > H.J. Lu writes: >> On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune >> wrote: >> > H.J. Lu writes: >> >> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu wrote: >> >> > The interrupt and ex

Re: RFC: Support x86 interrupt and exception handlers

2015-09-17 Thread H.J. Lu
On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: >> To implement interrupt and exception handlers for x86 processors, a >> compiler should support: >> >> 1. void * __builtin_ia32_interrupt_data (void) > > I got a feedback on the name of this builtin function. Since &

Re: RFC: Support x86 interrupt and exception handlers

2015-09-21 Thread H.J. Lu
On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: > On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: >>> To implement interrupt and exception handlers for x86 processors, a >>> compiler should support: >>> >>> 1. void * __builtin_ia32_interrupt_data (void

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-21 Thread H.J. Lu
On Mon, Sep 21, 2015 at 11:52 AM, John Criswell wrote: > On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: >> >> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote: >>> >>> On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote: >>>>> >>>>> To i

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-21 Thread H.J. Lu
On Mon, Sep 21, 2015 at 2:23 PM, John Criswell wrote: > On 9/21/15 4:45 PM, H.J. Lu wrote: >> >> On Mon, Sep 21, 2015 at 11:52 AM, John Criswell >> wrote: >>> >>> On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote: >>>> >>>> On Thu, Se

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-21 Thread H.J. Lu
On Mon, Sep 21, 2015 at 3:40 PM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu via cfe-dev" >> To: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 11:27:18 AM >> Subject: Re: [cfe-dev] RFC: Suppor

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-21 Thread H.J. Lu
On Mon, Sep 21, 2015 at 4:03 PM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu" >> To: "Hal Finkel" >> Cc: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 5:57:36 PM >> Subject:

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-22 Thread H.J. Lu
On Tue, Sep 22, 2015 at 1:11 AM, Hal Finkel wrote: > - Original Message - >> From: "H.J. Lu" >> To: "Hal Finkel" >> Cc: "GCC Development" , cfe-...@lists.llvm.org >> Sent: Monday, September 21, 2015 7:17:20 PM >> Subject:

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-22 Thread H.J. Lu
On Tue, Sep 22, 2015 at 1:41 AM, David Chisnall wrote: > On 21 Sep 2015, at 21:45, H.J. Lu via cfe-dev wrote: >> >> The main purpose of x86 interrupt attribute is to allow programmers >> to write x86 interrupt/exception handlers in C WITHOUT assembly >> stubs to avoid

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-22 Thread H.J. Lu
On Tue, Sep 22, 2015 at 4:44 AM, David Chisnall wrote: > On 22 Sep 2015, at 12:39, H.J. Lu via cfe-dev wrote: >> >> The center piece of my proposal is not to change how parameters >> are passed in compiler. As for user experience, the feedbacks on >> my proposal from

Re: [cfe-dev] RFC: Support x86 interrupt and exception handlers

2015-09-23 Thread H.J. Lu
On Tue, Sep 22, 2015 at 11:13 AM, Richard Henderson wrote: > > HJ, I think Hal is right. Providing the data via arguments is vastly superior > to providing it via builtins. I had actually been thinking the same thing > myself. > > It should be easy to check that the function has the correct sig

Re: different results from objdump for Ubuntu and Windows

2015-09-28 Thread H.J. Lu
On Mon, Sep 28, 2015 at 2:23 PM, Helen Tang wrote: > I built a gcc toolchain on Ubuntu and cygwin on Windows. The results > from objdump are different. Is this normal? Is there a way to make > them the same? It shouldn't happen on the same input file. If it does, please open a bug report. -- H

Re: gold on trunk breaks aarch64- and arm32-linux (Re: [gold][PATCH] PR gold/19119: Gold accepts bogus target emulation)

2015-10-25 Thread H.J. Lu
On Sun, Oct 25, 2015 at 10:37 AM, Matthias Klose wrote: > On 15.10.2015 17:57, Cary Coutant wrote: >>> >>> PR gold/19119 >>> * options.h (General_options): Remove "obsolete" from -m. >> >> >> I'm a little reluctant to remove "obsolete" from the description -- >> maybe "deprecated

Re: gold on trunk breaks powerpc-, aarch64- and arm32-linux (Re: [gold][PATCH] PR gold/19119: Gold accepts bogus target emulation)

2015-10-25 Thread H.J. Lu
On Sun, Oct 25, 2015 at 4:50 PM, Matthias Klose wrote: > On 25.10.2015 18:40, H.J. Lu wrote: >> >> On Sun, Oct 25, 2015 at 10:37 AM, Matthias Klose wrote: >>> >>> On 15.10.2015 17:57, Cary Coutant wrote: >>>>> >>>>> >>>

Updated x86-64 psABI

2015-11-18 Thread H.J. Lu
Hi, The x86-64 psABI has been updated to revision 248. Main changes are 1. Support Intel MPX. 2. Add a chapter for linker optimization. 3. Add 2 new relocations, R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX. MPX supported has been checked into GCC 5 and ld in binutils 2.25. Linker optimization

Re: Updated x86-64 psABI

2015-11-19 Thread H.J. Lu
On Wed, Nov 18, 2015 at 1:47 PM, H.J. Lu wrote: > Hi, > > The x86-64 psABI has been updated to revision 248. Main changes are > > 1. Support Intel MPX. > 2. Add a chapter for linker optimization. > 3. Add 2 new relocations, R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.

[middle-end] How to handle fake register in DECL_INCOMING_RTL?

2015-11-21 Thread H.J. Lu
When implementing interrupt attribute for x86 interrupt handlers, we have a difficult time to access interrupt data passed down by x86 processors. On x86, interrupt handlers are only called by processors which push interrupt data onto stack at the address where the normal return address is. Inter

RFC: Intel386 psABI version 1.1 draft

2015-11-24 Thread H.J. Lu
Hi, Here is the Intel386 psABI version 1.1 draft: https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-20151120.pdf Main changes are 1. Add AVX-512 support. 2. Add linker optimization to combine GOTPLT and GOT slots. 3. Add R_386_GOT32X relocation and linker optimization. 4. Add FS/GS Bas

Re: RFC: Intel386 psABI version 1.1 draft

2015-12-07 Thread H.J. Lu
On Tue, Nov 24, 2015 at 8:16 AM, H.J. Lu wrote: > Hi, > > Here is the Intel386 psABI version 1.1 draft: > > https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-20151120.pdf > > Main changes are > > 1. Add AVX-512 support. > 2. Add linker optimization to com

Re: x86 interrupt attribute

2016-01-18 Thread H.J. Lu
On Mon, Jan 18, 2016 at 9:39 AM, Wink Saville wrote: > What is the status of the x86 interrupt attribute patch? > > One of the last references I see is here and an attempt to update the > middle-end here. > > -- Wink You can try hjl/interrupt/stage1 branch in git repo, which is queued for GCC 7.

Re: x86 interrupt attribute

2016-01-18 Thread H.J. Lu
anch about once a week. > On Mon, Jan 18, 2016 at 9:47 AM H.J. Lu wrote: >> >> On Mon, Jan 18, 2016 at 9:39 AM, Wink Saville wrote: >> > What is the status of the x86 interrupt attribute patch? >> > >> > One of the last references I see is here and an at

RFA: Add GCC Runtime Library Exception to include/plugin-api.h

2016-01-22 Thread H.J. Lu
include/plugin-api.h defines an ABI between linker and compiler, which can be used to implement linker plug-in by any compilers. I'd like to add GCC Runtime Library Exception to include/plugin-api.h so that the linker plug-in can have non-GPL licenses. Thanks. -- H.J.

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

2016-01-28 Thread H.J. Lu
On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: > I using hjl/interrupt/gcc-5-branch and my program is crashing when I > issue an INT xx. The problem appears to me to be that using > __attribute__ ((interrupt)) causes the a IRET to be emitted when an > IRETQ should be emitted. Below is my tri

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

2016-01-28 Thread H.J. Lu
On Thu, Jan 28, 2016 at 10:26 AM, H.J. Lu wrote: > On Thu, Jan 28, 2016 at 9:06 AM, Wink Saville wrote: >> I using hjl/interrupt/gcc-5-branch and my program is crashing when I >> issue an INT xx. The problem appears to me to be that using >> __attribute__ ((interrupt)) ca

Re: Compiling with -m64 using attribute interrupt emits IRET not IRETQ

2016-01-28 Thread H.J. Lu
On Thu, Jan 28, 2016 at 11:06 AM, Wink Saville wrote: > Thanks. How are you testing? > > * { dg-do compile } */ /* { dg-options "-O2 -Wall -g" } */ void __attribute__((interrupt)) fn (void *frame) { } /* { dg-final { scan-assembler-not "add(l|q)\[\\t \]*\\$\[0-9\]*,\[\\t \]*%\[re\]?sp" } } */ /

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

2016-02-02 Thread H.J. Lu
o that the linker plug-in can have non-GPL licenses. > > This is OK with me. > > -cary Here is a patch. OK for trunk? Thanks. -- H.J. From 3f8f62505774116d5de233ca36f60e3f8a840516 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" Date: Tue, 2 Feb 2016 14:02:03 -0800 Subject: [PATCH

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

2016-02-02 Thread H.J. Lu
On Tue, Feb 2, 2016 at 4:23 PM, David Edelsohn wrote: > On Tue, Feb 2, 2016 at 5:03 PM, H.J. Lu wrote: >> On Tue, Feb 2, 2016 at 1:35 PM, Cary Coutant wrote: >>>> include/plugin-api.h defines an ABI between linker and compiler, >>>> which can be used to implemen

RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-07 Thread H.J. Lu
Empty struct value is passed differently in C and C++ on Intel386 and x86-64. Different compilers use different calling conventions on the same platform: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 The same compiler behaves different on different platforms: https://llvm.org/bugs/show_bug.

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-07 Thread H.J. Lu
On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: > * H. J. Lu: > >> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >> how to pass/return empty struct: >> >> 1. "collection". A collection is a structure, union or C++ class. >> 2. "empty collection". An empty collecti

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-07 Thread H.J. Lu
On Sun, Feb 7, 2016 at 11:36 AM, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify >>> how to pass/return empty struct: >>> >>> 1

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-07 Thread H.J. Lu
On Sun, Feb 7, 2016 at 12:08 PM, Florian Weimer wrote: > * H. J. Lu: > >>> Any syntactical array argument (at the C level) is should be passed as >>> a pointer. The language appears to change that. >> >> I didn't use aggregate so that array is excluded here. >> >>> For 2., static members and non-

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-07 Thread H.J. Lu
On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote: > * H. J. Lu: > >>> I tested GCC 5.3.1 and Clang 3.5.0. >>> >>> GCC Clang >>> s0 non-emptynon-empty >>> s1 non-emptyempty >>> s2 non-emptyempty >>> s3 emptyempty >>> s4 emptyempty >>> s5 no

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: > On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote: >> * H. J. Lu: >> >>>> I tested GCC 5.3.1 and Clang 3.5.0. >>>> >>>> GCC Clang >>>> s0 non-emptynon-empty &g

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote: > On 8 February 2016 at 13:54, H.J. Lu wrote: >> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote: >> >> The standard-layout POD is well defined: >> >> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote: > On 8 February 2016 at 15:42, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely >> wrote: >>> On 8 February 2016 at 13:54, H.J. Lu wrote: >>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 8:15 AM, Jonathan Wakely wrote: > On 8 February 2016 at 16:05, H.J. Lu wrote: >> My understanding is >> >> A type that is standard-layout means that it orders and packs its >> members in a way that is compatible with C. >> >> What is

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote: >>> A type is a standard-layout type, or it isn't. >> >> How about "An empty record is standard-layout Plain Old Data (POD) >> type and ..."? > > That's redundant, all POD types are standard-layout types. > Apparently, not all standard-layout

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely wrote: > On 8 February 2016 at 18:26, Jonathan Wakely wrote: >> On 8 February 2016 at 17:58, H.J. Lu wrote: >>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely >>> wrote: >>>>>> A type is a stand

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely wrote: > On 8 February 2016 at 18:31, H.J. Lu wrote: >> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely >> wrote: >>> On 8 February 2016 at 18:26, Jonathan Wakely wrote: >>>> On 8 February 2016 at 17:58

Linux-abi group

2016-02-08 Thread H.J. Lu
Hi, I created a mailing list to discuss Linux specific,.processor independent modification and extension of generic System V Application Binary Interface: https://groups.google.com/d/forum/linux-abi I will start to document existing Linux extensions, like STT_GNU_IFUNC. I will propose some new e

Re: Linux-abi group

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: > * H. J. Lu: > >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https://groups.google.com/d/forum/linux-abi >> >> I will start t

Re: Linux-abi group

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 11:33 AM, Szabolcs Nagy wrote: > * H.J. Lu [2016-02-08 11:24:53 -0800]: >> I created a mailing list to discuss Linux specific,.processor independent >> modification and extension of generic System V Application Binary Interface: >> >> https:

Re: Linux-abi group

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 11:44 AM, Florian Weimer wrote: > * H. J. Lu: > >> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer wrote: >>> * H. J. Lu: >>> I created a mailing list to discuss Linux specific,.processor independent modification and extension of generic System V Application Binar

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely wrote: > On 8 February 2016 at 19:23, Richard Smith wrote: >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here: >> >> http://mentorembedded.github.io/cxx-abi/abi.html#definitions > > Thanks. So there's no problem using "POD f

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
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: >> > On 8 February 2016 at 19:23, Richard Smith wrote: >> >> "POD for the purpo

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
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 at 12:05 PM, H.J. Lu wrote: >> >> >> >> On Mon, Feb 8

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
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. Following the algorithm in section 3.2.3, each > eightbyte is classified as NO_CLASS, and thus i

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
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 12:38 PM,

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
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:35 PM, Richard Smith &

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 2:55 PM, Richard Smith 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

Re: Linux-abi group

2016-02-08 Thread H.J. Lu
On Mon, Feb 8, 2016 at 3:08 PM, 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 mo

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-09 Thread H.J. Lu
On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote: > 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 &

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-09 Thread H.J. Lu
On Tue, Feb 9, 2016 at 6:45 AM, H.J. Lu wrote: > On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote: >> 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:

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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

Re: Linux-abi group

2016-02-11 Thread H.J. Lu
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

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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,

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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 par

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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".

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-11 Thread H.J. Lu
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

Re: Linux-abi group

2016-02-11 Thread H.J. Lu
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 stand

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-12 Thread H.J. Lu
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; >> }; > > What about it? It's an empty struct. (And it declares a function and >

Re: gnu-gabi group

2016-02-15 Thread H.J. Lu
On Mon, Feb 15, 2016 at 7:37 AM, Alexandre Oliva wrote: > On Feb 12, 2016, Pedro Alves wrote: > > >>> wonderful. I am not a big fan of google groups mailinglists, they seem >>> to make it hard to subscribe and don't have easy to access archives. >>> Having a local gnu-gabi group on sourceware.org

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
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; >>> }; >> >&

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
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 6:58 AM, Matthijs van Duin >> > wrote: >> >> On 11 February

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
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 AM, H.J. Lu wrote: >>>> >>>> On Fri, Feb 12,

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
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 PM, H.J. Lu wrote: >>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Sm

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
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 PM, H.J. Lu wrote: >>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Sm

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-16 Thread H.J. Lu
On Tue, Feb 16, 2016 at 3:36 PM, Richard Smith wrote: > 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 Sm

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

2016-02-18 Thread H.J. Lu
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

  1   2   3   4   5   6   7   8   9   10   >