t; Is that real or a bogus message?
>
> (My local disk isn't full, fortunately :)
>
GCC bugzilla was very slow a few hours earlier. Now it seems OK.
--
H.J.
e:
[hjl@gnu-cfl-3 usr]$ ls -d /usr/gcc*
/usr/gcc-10.2.1-32bit /usr/gcc-12.3.1-32bit /usr/gcc-14.0.1-x32
/usr/gcc-10.2.1-mx32 /usr/gcc-12.3.1-mx32 /usr/gcc-6.4.1-x32
/usr/gcc-10.2.1-x32/usr/gcc-12.3.1-x32/usr/gcc-7.4.1-x32
/usr/gcc-11.2.1-32bit /usr/gcc-13.2.1-32bit /usr/gcc-8.4.1-x32
/usr/gcc-11.2.1-mx32 /usr/gcc-13.2.1-mx32 /usr/gcc-9.3.1-x32
/usr/gcc-11.2.1-x32/usr/gcc-13.2.1-x32
[hjl@gnu-cfl-3 usr]$
--
H.J.
her the old or new
> interface is used.
>
> Thanks,
> Florian
>
It sounds good to me.
Thanks.
--
H.J.
On Wed, Apr 26, 2023 at 4:37 PM H.J. Lu wrote:
>
> On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote:
> >
> > On 4/26/23 21:23, H.J. Lu wrote:
> > > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote:
> > >>
> > >> On 11/15/22 16:47, Martin
On Wed, Apr 26, 2023 at 1:24 PM Martin Liška wrote:
>
> On 4/26/23 21:23, H.J. Lu wrote:
> > On Wed, Apr 26, 2023 at 6:52 AM Martin Liška wrote:
> >>
> >> On 11/15/22 16:47, Martin Liška wrote:
> >>> Hi.
> >>>
> >>> I'
_64-linux and checked ABI difference with
> > abidiff.
>
> Hello.
>
> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
It caused the bootstrap failure:
https://gcc.gnu.org/pipermail/gcc-regression/2023-April/077674.html
> Martin
>
> >
> > Pushed as r13-4068-g3037f11fb86eda.
> >
> > Cheers,
> > Martin
>
--
H.J.
egister_frame_info_bases (begin, ob, 0, 0);
> > }
>
> This means no EH frames are ever registered, and so exceptions cannot be
> handled!
>
> So, why does __EH_FRAME_BEGIN__ have alignment 4 and not of __alignof__ (void
> *) ? Is this a bug?
>
> Thanks,
> Joe
This is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576
--
H.J.
On Fri, Dec 31, 2021 at 2:19 PM Noah Goldstein wrote:
>
> On Fri, Dec 31, 2021 at 4:14 PM Noah Goldstein
> wrote:
> >
> > On Fri, Dec 31, 2021 at 2:36 PM H.J. Lu wrote:
> > >
> > > On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein
> > > wrote:
le.
>
> bzero does not have the interface ambiguity that bcmp has. So the
> only reason for not using it would be namespace cleanliness.
bzero isn't a standard C function and it isn't optimized like memset
in glibc.
--
H.J.
On Fri, Dec 31, 2021 at 12:21 PM Noah Goldstein wrote:
>
> On Fri, Dec 31, 2021 at 12:20 PM H.J. Lu wrote:
> >
> > Update MEMSET_VDUP_TO_VEC0_AND_SET_RETURN to use PXOR, which has lower
> > lantency and higher throughput than VPBROADCAST, for zero constant.
> >
; ===
>
> https://gcc.gnu.org/pipermail/gcc/2021-October/237464.html
Hi,
I'd like to add an option to disable copy relocation:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583022.html
Thanks.
--
H.J.
On Thu, Oct 28, 2021 at 10:43 AM Joseph Myers wrote:
>
> On Wed, 27 Oct 2021, H.J. Lu via Libc-alpha wrote:
>
> > Linker adds glibc versions in GNU_PROPERTY_1_GLIBC_2_NEEDED to the
> > .gnu.version_r section and removes GNU_PROPERTY_1_GLIBC_2_NEEDED note
> > when gene
ot a property note.
> >> Property notes seem the wrong approach for this. And there is no reason
> >> to make this specific to glibc.
> >>
> >> However, I still very much dislike this proposal.
> >>
> >
> > Can you share your concerns?
>
> See the other thread (mostly on libc-alpha I think).
>
OK. Let's resolve it in the glibc community first.
Thanks.
--
H.J.
er
> > glibc binaries.
>
> Solaris uses SHT_SUNW_verneed sections for this, not a property note.
> Property notes seem the wrong approach for this. And there is no reason
> to make this specific to glibc.
>
> However, I still very much dislike this proposal.
>
Can you share your concerns?
Thanks.
--
H.J.
Motivations:
1. Some binaries which require new ELF features, like DT_RELR, only
work with the new glibc binary. They crash at run-time with the older
glibc binaries.
2. Somes binaries compiled with the new language features, like C2X
printf specifiers, only generate correct results with the new
-
> Total P1-P3 366 + 76
> Total 600 + 79
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/pipermail/gcc/2021-April/235923.html
I'd like to backport:
https://gcc.gnu.org/g:3f04e3782536ad2f9cfbb8cfe6630e9f9dd8af4c
to fix this GCC 11 regression:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023
--
H.J.
-
> Total P1-P3 366 + 76
> Total 600 + 79
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/pipermail/gcc/2021-April/235923.html
Hi,
I'd like to backport this regression fix:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=cc11b924bfe7752edbba052ca71653f46a60887a
to GCC 11 for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395
Thanks.
--
H.J.
On Mon, Jun 21, 2021 at 7:36 AM Michael Matz wrote:
>
> Hello,
>
> On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote:
>
> > > > • Disallow copy relocation against definition with the STV_PROTECTED
> > > > visibility in the shared library with the marker.
> >
On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song wrote:
>
> On 2021-06-18, H.J. Lu via llvm-dev wrote:
> >Add GNU_PROPERTY_1_NEEDED:
> >
> > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
> >
> >to indicate the needed properties by the object file.
&g
object file requires canonical function pointers and
cannot be used with copy relocation.
The PDF file is at
https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf
--
H.J.
On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng wrote:
>
> On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu wrote:
> >
> > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote:
> > >
> > > On 2021-06-17, H.J. Lu wrote:
> > > >On Thu, Jun 17, 2021 at 1:25 P
On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng wrote:
>
> On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu wrote:
> >
> > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote:
> > >
> > > On 2021-06-17, H.J. Lu wrote:
> > > >On Thu, Jun 17, 2021 at 1:25 P
On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng wrote:
>
> On 2021-06-17, H.J. Lu wrote:
> >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote:
> >>
> >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote:
> >> >
> >> > On Thu, Jun 17, 2021 at 1
On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng wrote:
>
> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote:
> >
> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote:
> > >
> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > > &g
On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote:
>
> On 2021-06-17, H.J. Lu via llvm-dev wrote:
> >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote:
> >>
> >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
> >> >
> >> > 1.
On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote:
>
> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
> >
> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
> >
> > #define GNU_PROPERTY_UINT32_AND_LO 0xb000
> > #define GNU_PROPERTY_UINT32_AN
supposed to
> be built natively by the gcc-10.2.0 compiler you have just created.
>
Are you aware that you can build a 32-bit OS with x86-64? You can try
-mx32 with
GCC on Ubuntu. You will get more registers as well as IP relative addressing.
--
H.J.
any advice that would help us deal with this problem.
>
> Thanks,
> Richard Barnes
>
> Stratus Technologies
>
--
H.J.
On Sat, Apr 17, 2021 at 11:25 AM Fangrui Song wrote:
>
>
> On 2021-04-17, H.J. Lu wrote:
> >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
> >>
> >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
> >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
>
> On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
> >>
> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
> >>
> >> #define GNU
On Fri, Aug 14, 2020 at 8:25 AM Kaylee Blake wrote:
>
> On 7/8/20 10:41 pm, H.J. Lu wrote:
> > On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote:
> >>
> >> On 2/5/20 11:49 pm, H.J. Lu wrote:
> >>> On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils
s I used to build Linux/x86-64 GCC toolchain:
https://gitlab.com/hjl.tools/x86-64-linux-toolchain
--
H.J.
ace which
is implemented in glibc on users/intel/lam/master branch:
https://gitlab.com/x86-glibc/glibc/-/tree/users/intel/lam/master
and in GCC on users/intel/lam/master branch:
https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
--
H.J.
On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
>
> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>
> #define GNU_PROPERTY_UINT32_AND_LO 0xb000
> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff
>
> A bit in the output pr_data field is set only if it is set
ng
> non-standard stuff for that specific purpose.
>
FWIW, on x86, GCC 11 can inline all calls to memset, memcpy and
memcmp with -minline-all-stringops.
--
H.J.
s.
>
> The problem I'm having is that, in every attempt, the glibc headers and
> libraries from under /usr end up getting used instead of the custom
> glibc ones at some point leading to build failures.
>
> Does anyone have a recipe available for doing this?
Try scripts/build-many-glibcs.py in glibc source.
--
H.J.
0 or the property is missing, the info is unknown.
The PDF is at
https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf
--
H.J.
On Thu, Jan 7, 2021 at 7:45 PM Fangrui Song wrote:
>
> On Thu, Jan 7, 2021 at 6:07 PM H.J. Lu wrote:
> >
> > On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote:
> > >
> > > On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote:
> > > >
> &
On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote:
>
> On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote:
> >
> > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote:
> > >
> > > * Fangrui Song:
> > >
> > > > Hi, I filed https://gcc.gnu.
uot;gcc/" looks a lot better than just "gcc"
> (and similar for other dirs, but less bad). (I often left it out
> completely if it would have been just gcc/, since it was just for
> humans, pretty much all of the changelog format is not machine-parseable
> without AI advances anyway, so heh).
>
> But 1 and 2 are much worse indeed :-) Unnecessary words distract from
> the actual content.
I also vote for option 5.
--
H.J.
whether you have
> reasonably-sized displacements available. I think there are some ABIs
> where the optimization is theoretically possible, but impractical
> because the ilimit it imposes on data segment (think AArch64 without
> adrp).
--
H.J.
d":
>
> Which now also makes sense, because as the --help text says "only
> relevant for ET_REL files".
>
> So you did find a real mystery, for some reason the way the vmlinux
> image is created does get relocations correctly applied, but they (or
> at least some) are still left behind in the ELF image even though they
> are no longer needed (and if you do try to use/apply them, you get
> wrong results). We should probably find out if this happened during
> the upstream build or during distro packaging.
Check if CONFIG_X86_NEED_RELOCS is enabled for your kernel.
--
H.J.
x27;t know where that comma after the commit id came from, but something
> appears to have broken the update_version_git cron job.
Could it be
commit ce2d9549f2b2bcb70a1a6f8f4e776e1ed427546b
Author: Ulrich Weigand
Date: Tue Nov 24 19:30:01 2020 +0100
Revert: "Fix -ffast-math flags handling inconsistencies"
This reverts commit c4fa3728ab4f78984a549894e0e8c4d6a253e540,
^^^
which caused a regression in the default for flag_excess_precision.
--
H.J.
On Fri, Nov 20, 2020 at 7:26 AM Martin Liška wrote:
>
> On 11/20/20 2:42 PM, H.J. Lu wrote:
> > Should contrib/gcc_update handle it?
>
> I don't know how publicly known is the script?
> I personally do not used it.
>
I always run
$ ./contrib/gcc_update --touch
after rebase.
--
H.J.
xi.in is older that tm.texi, but it's fine as both tm.texi.in
> and tm.texi are not modified.
>
> Ideas how to improve the error message? It took me some time to realize
> that 'touch tm.texi.in' is what I need.
Should contrib/gcc_update handle it?
--
H.J.
; Thanks,
> Richard.
>
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
H.J.
ne description. This is not written anywhere, by default, but
> there's a way to get it.
>
>cd /gcc
>make mddump
>less tmp-mddump.md
>
> Not only are all the define_subst expanded, but so are all the other
> iterators.
Shouldn't it be documented?
--
H.J.
ral different 16-bit floating point formats
> floating around.
Do you need to check mixed formats in different relocatable/shared
object files at link-time and in different shared objects/executable at
run-time?
H.J.
On Tue, May 5, 2020 at 6:42 PM Kaylee Blake wrote:
>
> On 2/5/20 11:49 pm, H.J. Lu wrote:
> > On Wed, Mar 18, 2020 at 6:46 PM Kaylee Blake via Binutils
> > wrote:
> >>
> >> On 19/3/20 12:02 pm, H.J. Lu wrote:
> >>> Kaylee, is your paper w
enumerated by palettes. Two palettes are
supported: palette 0 represents the initialized state and palette 1
consists of 8 tile registers of up to 1 KB size, which is controlled
by a tile control register.
https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/12
--
H.J.
From
uldn't be required in which level: I
> think the current suggestions all sound good, ultimately it's always going
> to be some compromise.
>
We can have x86-64, x86-64-v1, x86-64-v2, .. These pseudo names
should be clearly documented.
--
H.J.
Invariant Sections. It doesn't end up in our
> > product documentation, where it would be confusing if it discusses
> > unsupported CPUs.
> >
> > Everything that can be installed locally becomes outdated and
> > problematic. The psABI supplement is a PDF document, so we can't easily
> > link to the appropriate section. The specification found there would
> > also not be targeted at programmers, but rather at compiler and dynamic
> > linker writers.
> >
> > Did you have something else in mind?
>
> Not really - the whole stuff just adds to the ways ISV could optimize
> their binaries all of which are not very well documented in a place
> that discusses such optimization ...
>
> But yeah, extensively documenting all the ways and reasons
> to optimize binaries is certainly out-of-scope for the task of
> adding just one other way.
>
> So a website works for me. Having a source representation
> of said website that is easy to embed into a whitepaper or
> even GCCs texi documentation for example would of course
> be nice.
We made up -march=x86-64. We can extend pseudo x86-64
with more variants.
--
H.J.
rk
>
> P.S. I don't particular like the numbered names, but well, bike-shed...
--
H.J.
the lowest architecture
> >> level that is applicable?
> >
> > H.J. has patches for ELF program properties. I think
> > GNU_PROPERTY_X86_ISA_1_NEEDED would convey this information. This
> > proposal and the glibc patches are independent of that.
>
> From (partly
with the recommended directory name. Checking for
> excess flags will be tricky in this context, though, and if we miss
> something, a wrong recommendation will be the result.
>
> Thanks,
> Florian
--
H.J.
to set a
> baseline for the entire distribution (i.e., everything would be built to
> level A or maybe even level C), and these libraries would then be
> installed in the default location.
>
> I'll be glad if I can get any feedback on this proposal. I plan to turn
> it into a merge request for the x86-64 psABI document eventually.
>
Looks good. I like it. My only concerns are
1. Names like “x86-100”, “x86-101”, what features do they support?
2. I have a library with AVX2 and FMA, which directory should it go?
Can we pass such info to ld.so and ld.so prints out the best directory
name?
--
H.J.
fact it *does* seem to allow that,
> it's just some "let's send a gazillion emails" script that is
> misbehaving.
>
These are all the reasons why I don't use GCC repo for my personal
branches.
--
H.J.
op
> infrastructure and tuning, for whose Honza has much deeper
> understanding than me.
>
> Thanks for your understanding,
> Uros.
Thanks for your hard works over the years. Wish you the best.
--
H.J.
On Wed, May 20, 2020 at 7:23 AM Martin Liška wrote:
>
> On 5/20/20 3:57 PM, H.J. Lu wrote:
> > On Wed, May 20, 2020 at 6:55 AM Martin Liška wrote:
> >>
> >> On 5/20/20 3:48 PM, H.J. Lu wrote:
> >>> On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote:
On Wed, May 20, 2020 at 6:55 AM Martin Liška wrote:
>
> On 5/20/20 3:48 PM, H.J. Lu wrote:
> > On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote:
> >>
> >> On 5/20/20 1:31 PM, H.J. Lu wrote:
> >>> On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote:
On Wed, May 20, 2020 at 6:47 AM Martin Liška wrote:
>
> On 5/20/20 1:31 PM, H.J. Lu wrote:
> > On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote:
> >>
> >> On 5/20/20 12:59 AM, H.J. Lu wrote:
> >>> I got:
> >>>
> >>> $ g
On Wed, May 20, 2020 at 1:40 AM Martin Liška wrote:
>
> On 5/20/20 12:59 AM, H.J. Lu wrote:
> > I got:
> >
> > $ git push origin releases/gcc-10
> > Enumerating objects: 15, done.
> > Counting objects: 100% (15/15), done.
> > Delta compression using up
as
(cherry picked from commit 453954451be68d22462442268a29f54809182d2b)
Shouldn't it be allowed?
--
H.J.
ing a patch
> to the last but one release branch.
You need to resolve conflicts and update commit message with
$ git cherry-pick --continue
--
H.J.
t is that we
> deliberately fixed up retpoline to be register-based *specifically* for the
> purpose of being CET-compatible, so it's somewhat daft for GCC to be claiming
> they are incompatible.
>
GCC needs to be told that external thunk is CET compatible.
--
H.J.
t; recompile and fix the world :)
All codes which manually change return address on stack must be updated
to also adjust shadow stack.
--
H.J.
On Tue, Apr 28, 2020 at 8:06 AM Jan Beulich wrote:
>
> On 28.04.2020 17:00, H.J. Lu wrote:
> > On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper
> > wrote:
> >>
> >> On 28/04/2020 14:00, H.J. Lu wrote:
> >>> On Tue, Apr 28, 2020 at 5:43 AM Andrew Coo
On Tue, Apr 28, 2020 at 6:41 AM Andrew Cooper wrote:
>
> On 28/04/2020 14:00, H.J. Lu wrote:
> > On Tue, Apr 28, 2020 at 5:43 AM Andrew Cooper
> > wrote:
> >> Hello,
> >>
> >> I raised https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93654 but it has
&g
ssary to disable TLSv1
> completely. I can understand that weak ciphers get disabled. There are
> probably some ciphers for TLSv1 that could still be allowed thus
> letting older browsers access gcc.gnu.org/soureware.org.
>
> Regards,
> Gunther Nikl
--
H.J.
a whole (preferred) or relax the
> > limit on bounces?
>
> is still valid.
>
> Some kind of reaction would be appreciated.
>
> Regards
>
> Thomas
>
>
--
H.J.
failures as well as new passes, are also reported:
https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072492.html
https://gcc.gnu.org/pipermail/gcc-regression/2020-March/072495.html
--
H.J.
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
xecution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
Are they expected?
--
H.J.
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
> > >
> > &
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
+return strcpy (newname, name);
/* Copy over .comment section under the same name if present. Solaris
ld uses them to relax its checking of ELF gABI access rules for
COMDAT sections in objects produced by GCC. */
I'd like to backport it to GCC 9 if possible.
--
H.J.
uiltins
> (thus creating a new branch). It seems like there may be a missing
> "users/" needed someplace. But I am not at all confident that's
> correct. I'm a little suspicious of the push spec in my config.
>
> Can someone with strong git-fu give me any suggestions?
>
> Best regards,
> Bill
>
--
H.J.
comments. This is common practice, and a good idea because bad
> commit messages are always a bummer, ChangeLog or not.
>
Libgcrypt includes ChangeLog entries in git commit messages:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git
In each patch, commit log starts with ChangeLog entries without leading
TABs followed by separator line with -- and then commit message. They
have a script to extract ChangeLog for release.
--
H.J.
R 89980) makes me wonder
> if it is, in fact, safe. I can see the broken bootstrap today
> in a clean build yet the bootstrap I did just before checking
> in the change went fine.
>
You need to do a clean bootstrap.
--
H.J.
gt; P3 25 - 3
> P4 165
> P5 24
> --- ---
> Total P1-P3 229 + 3
> Total 418 + 3
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2019-02/msg00027.html
--
H.J.
t;, a separate pattern is required.
> Since an argument can be either negated or not, and we can use three
> logic ops (or, and, xor) there would be 72 patterns. So maybe a new
> optimization pass would be easier to create and maintain? (Just a silly
> guess.)
>
> I'd be grateful for any comments and advice.
>
> best regards
> Wojciech
>
> [1] https://github.com/WojciechMula/ternary-logic
Please open a gcc bug:
https://gcc.gnu.org/bugzilla/
and CC me. We will look into it.
Thanks.
--
H.J.
).
>
> figure 3.4 pp23 does not clarify xmm* use for vector return at all - only
> mentioning floating point.
>
> = status
>
> In any event, GCC passes the vec32 return in memory,
> LLVM conversely passes it in xmm0:1 (at least for the versions I’ve tried).
>
> which leads to an ABI discrepancy when GCC is used to build code on systems
> based on LLVM.
>
> Please could the X86 maintainers clarify the intent (and maybe consider
> enhancing the footnote classification notes to make things clearer)?
>
> - and then we can figure out how to deal with the systems that are already
> implemented - and how to move forward.
>
> (as an aside, in any event, it seems inefficient to pass through memory when
> at least xmm0:1 are already set aside for return value use).
Please open a bug to keep track.
Thanks.
--
H.J.
ag or configure
> option to switch
> the new interface off if not supported (maybe automatically based on the
> math.h header).
>
> Wilco
--
H.J.
y.
> In Fedora it will not make a difference, as the whole distro is
> built with -mcet -fcf-protection on i?86/x86_64.
>
I submitted a patch to add -mnop to enable multi-byte NOP code
generation which can be used with -fcf-protection to implement
indirect branch and return address tracking without -mcet:
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00868.html
--
H.J.
On Tue, Mar 27, 2018 at 8:55 AM, H.J. Lu wrote:
> On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
>> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>>
>>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>>> in libgcc counts how many stac
On Tue, Mar 27, 2018 at 8:43 AM, Florian Weimer wrote:
> On 03/27/2018 01:26 PM, H.J. Lu wrote:
>
>> 2. Since shadow stack is never saved and restored by compiler, unwinder
>> in libgcc counts how many stack frame it has to unwind and uses INCSSP
>> to pop shadow stack
-10/msg01741.html
I also opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086
I have a patch at
https://github.com/hjl-tools/gcc/commit/e9ff815941406e38fa629947af4d809b9129e860
which requires unwind ABI extension.
I'd like to see them fixed to get working Intel CET support in
GCC 8.
Thanks.
--
H.J.
On Mon, Mar 26, 2018 at 11:31 PM, Florian Weimer wrote:
> On 03/27/2018 12:43 AM, H.J. Lu wrote:
>>
>> On Linux, when alternate signal stack is used with thread cancellation,
>> _Unwind_Resume fails when it tries to unwind shadow stack from signal
>> handler on alterna
. _Unwind_ForcedUnwind_Phase2 sets frames to 1 for
_URC_NO_REASON_CANCEL
BTW, I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85086
--
H.J.
gt; openmp-simd and I always get a call to _ZGVbN2v_sin. Is there anyway
> to stop the use of the vectorized calls (without turning off -Ofast)?
Have you tried -lm?
--
H.J.
On Wed, Jan 31, 2018 at 7:56 AM, H.J. Lu wrote:
> On Wed, Jan 31, 2018 at 7:44 AM, Cory Fields wrote:
>> After looking at this for quite a while, I'm afraid I'm unsure how to
>> proceed.
>>
>> As of now, static and static-pie
command-line, you
1. Remove -static and -pie.
2. Add -static-pie.
> for static before static-pie ?
>
--
H.J.
On Tue, Jan 30, 2018 at 11:18 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 2:14 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
>>> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>>>> On Tue, Jan 30, 2018 at 10:26 AM, Cor
On Tue, Jan 30, 2018 at 11:07 AM, Cory Fields wrote:
> On Tue, Jan 30, 2018 at 1:35 PM, H.J. Lu wrote:
>> On Tue, Jan 30, 2018 at 10:26 AM, Cory Fields wrote:
>>> Hi list
>>>
>>> I'm playing with -static-pie and musl, which seems to be in good shape
&g
by adding "-static"
Why not adding "-static-pie" instead of "-static"?
> to my builds, produce static-pie binaries. But at the moment, that
> attempts to add an interp section.
>
> So my question is, if no conflicting options are found, why not hoist
> "-static -pie" to "-static-pie" ?
>
> Regards,
> Cory
--
H.J.
, bringing up an existing bug
> takes an entire minute.
>
Same here. When I opened a new bug today, it timed out. I had to look up
the database to see if I opened it or not.
--
H.J.
n symbol,
There is no need for PLT since hidden symbol is defined locally. But
GCC ignores hidden visibility for libcalls, like memcpy. If GCC treats
them like normal calls, your scheme and my testcase should work.
> But anyway, doesn't matter terribly much if I understand :p
>
>
ult version.
> Is there any way for me to force the version for these symbols aswell?
> I'm aware that I can disable the whole mechanism with -freestanding, but I
> don't want to cripple the optimiser.
I think this is related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67220
--
H.J.
at the top of the stack, like this:
>
> __x86_indirect_thunk_rax:
> .LFB2:
> .cfi_startproc
> call.LIND5
> .LIND4:
> pause
> lfence
> jmp .LIND4
> .LIND5:
> .cfi_def_cfa_offset 16
> mov %rax, (%rsp)
> ret
> .cfi_endproc
>
> The unwinder should then use the other return address, from the caller of
> the thunk routine.
Can you open a GCC bug to track it?
Thanks.
--
H.J.
th __x86_indirect_thunk_reg, linker can convert call
via GOT to direct branch if function is locally defined:
https://groups.google.com/forum/#!topic/x86-64-abi/eED5lzn3_Mg
H.J.
1 - 100 of 1203 matches
Mail list logo
