Re: Aldy Hernandez and Andrew MacLeod as VRP maintainers

[Aldy Hernandez via Gcc]

On 6/17/21 12:18 AM, Jeff Law wrote:
I am pleased to announce that the GCC Steering Committee has appointed 
Aldy Hernandez and Ian MacLeod as maintainers for the VRP subsystem 
(EVRP, VRP, Ranger).


I don't know who this Ian is, but I'm sure we'll get along splendidly :).



Aldy/Andrew, please update the MAINTAINERS file appropriately.


Done.

Thanks.
Aldy
>From 9f12bd79c0bd162cdbfab528f2e8dac43fb53d68 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Thu, 17 Jun 2021 09:49:43 +0200
Subject: [PATCH] Add amacleod and aldyh as *vrp and ranger maintainers.

ChangeLog:

	* MAINTAINERS (Various Maintainers): Add Andrew and myself
	as *vrp and ranger maintainers.
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a0e6c718ea5..e04477831eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -224,6 +224,8 @@ option handling		Joseph Myers		
 middle-end		Jeff Law		
 middle-end		Ian Lance Taylor	
 middle-end		Richard Biener		
+*vrp, ranger		Aldy Hernandez		
+*vrp, ranger		Andrew MacLeod		
 tree-ssa		Andrew MacLeod		
 tree browser/unparser	Sebastian Pop		
 scev, data dependence	Sebastian Pop		
-- 
2.31.1

Re: Aldy Hernandez and Andrew MacLeod as VRP maintainers

[Gerald Pfeifer]

On Thu, 17 Jun 2021, Aldy Hernandez via Gcc wrote:
> On 6/17/21 12:18 AM, Jeff Law wrote:
>> I am pleased to announce that the GCC Steering Committee has appointed Aldy
>> Hernandez and Ian MacLeod as maintainers for the VRP subsystem (EVRP, VRP,
>> Ranger).
> I don't know who this Ian is, but I'm sure we'll get along splendidly :).

:-)

Happy Vrpping (or would that we warping, maybe)?

Gerald

Re: docs: Unification of "enabled by default at -O{,1}

[Martin Liška]

On 6/16/21 7:13 PM, Martin Sebor wrote:

On 6/11/21 6:53 AM, Martin Liška wrote:

Hello.

First, note that -O is equal to -O1 :) I noticed we don't use it consistently
in documentation:

$ git grep 'at.*-O1}' | cat

gcc/ada/gnat_ugn.texi:pick it based on the optimization level: 1 for 
@code{-O1}, @code{-O2} or


...

Is the later (and more common variant) preferred?


I think -O1 should be preferred wherever the manual means to refer
to -O1.  It's clearer that way mainly because other compilers have
different meanings for -O than GCC (e.g., in IBM XLC it corresponds
to -O2 and in Oracle C it's equivalent to level 3).


Thanks for clarification! Makes sense.



This is in line with the POSIX description of the c99 command which
leaves the -O level unspecified if none is provided.

Martin


Good, I'm going to apply the following patch.

Martin
>From 8eac92a07e386301f7b09f7ef6146e6e3ac6b6cd Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Thu, 17 Jun 2021 11:48:59 +0200
Subject: [PATCH] docs: Use -O1 as a canonical value for -O option

gcc/ChangeLog:

	* doc/invoke.texi: Use consistently -O1 instead of -O.
---
 gcc/doc/invoke.texi | 74 ++---
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index fe812cbd512..af2ce189fae 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9944,7 +9944,7 @@ This option causes GCC to create markers in the internal representation
 at the beginning of statements, and to keep them roughly in place
 throughout compilation, using them to guide the output of @code{is_stmt}
 markers in the line number table.  This is enabled by default when
-compiling with optimization (@option{-Os}, @option{-O}, @option{-O2},
+compiling with optimization (@option{-Os}, @option{-O1}, @option{-O2},
 @dots{}), and outputting DWARF 2 debug information at the normal level.
 
 @item -gvariable-location-views
@@ -10223,7 +10223,7 @@ that do not involve a space-speed tradeoff.
 As compared to @option{-O}, this option increases both compilation time
 and the performance of the generated code.
 
-@option{-O2} turns on all optimization flags specified by @option{-O}.  It
+@option{-O2} turns on all optimization flags specified by @option{-O1}.  It
 also turns on the following optimization flags:
 
 @c Please keep the following list alphabetized!
@@ -10370,7 +10370,7 @@ instructions and checks if the result can be simplified.  If loop unrolling
 is active, two passes are performed and the second is scheduled after
 loop unrolling.
 
-This option is enabled by default at optimization levels @option{-O},
+This option is enabled by default at optimization levels @option{-O1},
 @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -ffp-contract=@var{style}
@@ -10398,7 +10398,7 @@ Note that @option{-fno-omit-frame-pointer} doesn't guarantee the frame pointer
 is used in all functions.  Several targets always omit the frame pointer in
 leaf functions.
 
-Enabled by default at @option{-O} and higher.
+Enabled by default at @option{-O1} and higher.
 
 @item -foptimize-sibling-calls
 @opindex foptimize-sibling-calls
@@ -10552,7 +10552,7 @@ This option is the default for optimized compilation if the assembler and
 linker support it.  Use @option{-fno-merge-constants} to inhibit this
 behavior.
 
-Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
+Enabled at levels @option{-O1}, @option{-O2}, @option{-O3}, @option{-Os}.
 
 @item -fmerge-all-constants
 @opindex fmerge-all-constants
@@ -10638,7 +10638,7 @@ long} on a 32-bit system, split the registers apart and allocate them
 independently.  This normally generates better code for those types,
 but may make debugging more difficult.
 
-Enabled at levels @option{-O}, @option{-O2}, @option{-O3},
+Enabled at levels @option{-O1}, @option{-O2}, @option{-O3},
 @option{-Os}.
 
 @item -fsplit-wide-types-early
@@ -10750,18 +10750,18 @@ Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
 @opindex fauto-inc-dec
 Combine increments or decrements of addresses with memory accesses.
 This pass is always skipped on architectures that do not have
-instructions to support this.  Enabled by default at @option{-O} and
+instructions to support this.  Enabled by default at @option{-O1} and
 higher on architectures that support this.
 
 @item -fdce
 @opindex fdce
 Perform dead code elimination (DCE) on RTL@.
-Enabled by default at @option{-O} and higher.
+Enabled by default at @option{-O1} and higher.
 
 @item -fdse
 @opindex fdse
 Perform dead store elimination (DSE) on RTL@.
-Enabled by default at @option{-O} and higher.
+Enabled by default at @option{-O1} and higher.
 
 @item -fif-conversion
 @opindex fif-conversion
@@ -10770,7 +10770,7 @@ includes use of conditional moves, min, max, set flags and abs instructions, and
 some tricks doable by standard arithmetics.  The use of conditional execution
 on chips where it is available is controlled by @option{-fif-

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Richard Earnshaw via Gcc]

On 17/06/2021 01:40, Jason Merrill via Gcc wrote:

On 6/16/21 8:17 PM, Martin Sebor wrote:

On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor > wrote:


    On 6/16/21 2:49 PM, Jason Merrill wrote:
 > On 6/15/21 11:42 PM, Jason Merrill wrote:
 >> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
    mailto:gcc@gcc.gnu.org>
 >> >> wrote:
 >>
 >>     On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
 >>  > On Fri, 11 Jun 2021, Martin Sebor via Gcc wrote:
 >>  >
 >>  >> On 6/11/21 11:32 AM, Jonathan Wakely wrote:
 >>  >>> On Fri, 11 Jun 2021 at 18:02, Martin Sebor wrote:
 >>   My objection is to making our policies and tools more
 >> restrictive
 >>   than they need to be.  We shouldn't expect everyone to
    study
 >> whole
 >>   manuals just to figure out how to successfully 
commit a

 >> change (or
 >>   learn how to format it just the right way).  It should
    be easy.
 >>  >>>
 >>  >>> I agree, to some extent. But consistency is also 
good. The

 >>     conventions
 >>  >>> for GNU ChangeLog formatting exist for a reason, and so
    do the
 >>  >>> conventions for good Git commit messages.
 >>  >>>
 >>   Setting this discussion aside for a moment and using a
 >> different
 >>   example, the commit hook rejects commit messages that
    don't
 >> start
 >>   ChangeLog entries with tabs.  It also rejects commit
 >> messages that
 >>   don't list all the same test files as those changed by
    the
 >> commit
 >>   (and probably some others as well).  That's in my view
 >> unnecessary
 >>   when the hook could just replace the leading spaces 
with

 >> tabs and
 >>   automatically mention all the tests.
 >>  
 >>   I see this proposal as heading in the same direction.
 >> Rather than
 >>   making the script fix things up if we get them wrong
    it would
 >>     reject
 >>   the commit, requiring the user to massage the 
ChangeLog by

 >>     hand into
 >>   an unnecessarily rigid format.
 >>  >>>
 >>  >>> You cannot "fix things up" in a server-side receive 
hook,

 >> because
 >>  >>> changing the commit message would alter the commit
    hash, which
 >>     would
 >>  >>> require the committer to do a rebase to proceed. That
    breaks the
 >>  >>> expected behaviour and workflow of a git repo.
 >>  >>>
 >>  >>> You can use the scripts on the client side to verify
    your commit
 >>  >>> message before pushing, so you don't have to be 
surprised

 >> when the
 >>  >>> server rejects it.
 >>  >>
 >>  >> That sounds like a killer argument.  Do we have shared
 >> client-side
 >>  >> scripts that could fix things up for us, or are we each
    on our
 >> own
 >>  >> to write them?
 >>  >
 >>  > I hope I got your view wrong.  If not: the "scripts 
fixing

 >>  > things up for us" direction is flawed (compared to the
    "scripts
 >>  > rejecting bad formats"), unless offered as a non-default
    option;
 >>  > please don't proceed.
 >>  >
 >>  > Why?  For one, there'll always be bugs in the scripting.
 >>  > Mitigate those situations: while wrongly rejecting a
    commit is
 >>  > bad, wrongly "fixing things up" is worse, as a general 
rule.

 >>  > Better avoid that.  (There's probably a popular "pattern
    name"
 >>  > for what I try to describe.)
 >>
 >>     The word that comes to mind is Technophobia.  Is it wise to
    trust
 >>     compilers to transform programs from their source form into
 >>     executables?  What if there are bugs in either?  What about
    the OS?
 >>     The whole computer, or the Internet?  Our cars? 
Fortunately, there's

 >>     more to gain than to lose by trusting automation.  If there
    weren't
 >>     human progress would be stuck sometime in the 1700's.
 >>
 >>     But we're not talking about anything anywhere that 
sophisticated

 >>     here: a sed script to copy and paste a piece of text in
 >>     the description of a change from one place to another.  It's
    been
 >>     done a few times before with more important data than
    ChangeLogs.
 >>
 >>
 >> git gcc-commit-mklog already automates most of the process.  It
    could
 >> also automate adding [PRx] to the first line.  Is that what
    you're
 >> asking for?
 >
 > Like, say:

    I don't think this solves the problem Xionghu Luo was asking about:
    https://gcc.gnu.org/pipermail/gc

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Thu, 17 Jun 2021 at 02:01, Martin Sebor wrote:
>
> On 6/16/21 6:40 PM, Jason Merrill wrote:
> > On 6/16/21 8:17 PM, Martin Sebor wrote:
> >> 3) adds the PR component/n to each ChangeLog
> >
> > This would be reverting the r12-771 change, which seems both unrelated
> > and undesirable.
>
> Now I'm confused.  Isn't that just what caused the problem to begin
> with?  (The bug not being updated with the commit because it's not
> in the ChangeLog entries?)


No.

The original problem is that the PR wasn't in the body of the commit AT ALL.

The current mklog.py will do this:

PR cmpt/

gcc/ChangeLog:

* blah.c (blah): Blah blah.

That will cause updates to bugzilla, it works fine. You do not need to
change it to:

gcc/ChangeLog:

PR cmpt/
* blah.c (blah): Blah blah.

That would also work, but isn't necessary (and would be reverting the
r12-771 change).

Either of the forms above will update bugzilla. The original problem
was that neither of those forms was used.

Difficulties in merging patterns

[Richard Biener]

I'm trying to merge

(define_insn "avx_addsubv4df3"
  [(set (match_operand:V4DF 0 "register_operand" "=x")
(vec_merge:V4DF
  (minus:V4DF
(match_operand:V4DF 1 "register_operand" "x")
(match_operand:V4DF 2 "nonimmediate_operand" "xm"))
  (plus:V4DF (match_dup 1) (match_dup 2))
  (const_int 5)))]
  "TARGET_AVX"
  "vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "type" "sseadd")
   (set_attr "prefix" "vex")
   (set_attr "mode" "V4DF")])

(define_insn "sse3_addsubv2df3"
  [(set (match_operand:V2DF 0 "register_operand" "=x,x")
(vec_merge:V2DF
  (minus:V2DF
(match_operand:V2DF 1 "register_operand" "0,x")
(match_operand:V2DF 2 "vector_operand" "xBm,xm"))
  (plus:V2DF (match_dup 1) (match_dup 2))
  (const_int 1)))]
  "TARGET_SSE3"
  "@
   addsubpd\t{%2, %0|%0, %2}
   vaddsubpd\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sseadd")
   (set_attr "atom_unit" "complex")
   (set_attr "prefix" "orig,vex")
   (set_attr "mode" "V2DF")])

(define_insn "avx_addsubv8sf3"
  [(set (match_operand:V8SF 0 "register_operand" "=x")
(vec_merge:V8SF
  (minus:V8SF
(match_operand:V8SF 1 "register_operand" "x")
(match_operand:V8SF 2 "nonimmediate_operand" "xm"))
  (plus:V8SF (match_dup 1) (match_dup 2))
  (const_int 85)))]
  "TARGET_AVX"
  "vaddsubps\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "type" "sseadd")
   (set_attr "prefix" "vex")
   (set_attr "mode" "V8SF")])

(define_insn "sse3_addsubv4sf3"
  [(set (match_operand:V4SF 0 "register_operand" "=x,x")
(vec_merge:V4SF
  (minus:V4SF
(match_operand:V4SF 1 "register_operand" "0,x")
(match_operand:V4SF 2 "vector_operand" "xBm,xm"))
  (plus:V4SF (match_dup 1) (match_dup 2))
  (const_int 5)))]
  "TARGET_SSE3"
  "@
   addsubps\t{%2, %0|%0, %2}
   vaddsubps\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sseadd")
   (set_attr "prefix" "orig,vex")
   (set_attr "prefix_rep" "1,*")
   (set_attr "mode" "V4SF")])

but the difficulty is in the (const_int ..) operand to (vec_merge ..).
I've tried sth like

(define_mode_attr addsub_cst [(V4DF "(const_int 5)") (V2DF "(const_int 
1)")
  (V4SF "(const_int 5)") (V8SF "(const_int 
85)")])
(define_insn "vec_addsub"
  [(set (match_operand:VF_128_256 0 "register_operand" "=x")
(vec_merge:VF_128_256
  (minus:VF_128_256
(match_operand:VF_128_256 1 "register_operand" "x")
(match_operand:VF_128_256 2 "nonimmediate_operand" "xm"))
  (plus:VF_128_256 (match_dup 1) (match_dup 2))
  ADDSUB_CST))]
  ""
  "%vaddsub\t{%2, %1, %0|%0, %1, %2}"

but genpreds doesn't like whatever syntax I try to use at this place
 (), ...

Is this somehow possible and is there an existing example I can look at?

Thanks,
Richard.

Re: Difficulties in merging patterns

[Jakub Jelinek via Gcc]

On Thu, Jun 17, 2021 at 03:21:05PM +0200, Richard Biener wrote:
> but the difficulty is in the (const_int ..) operand to (vec_merge ..).
> I've tried sth like
> 
> (define_mode_attr addsub_cst [(V4DF "(const_int 5)") (V2DF "(const_int 
> 1)")
>   (V4SF "(const_int 5)") (V8SF "(const_int 
> 85)")])

Have you tried making addsub_cst just "5" "1" or "85" and use (const_int
)?
If even that doesn't work, make it (match_operand ... "const_int_operand" "n")
and check the value in the insn condition using INTVAL (operands[xxx]) == 

?

> (define_insn "vec_addsub"
>   [(set (match_operand:VF_128_256 0 "register_operand" "=x")
> (vec_merge:VF_128_256
>   (minus:VF_128_256
> (match_operand:VF_128_256 1 "register_operand" "x")
> (match_operand:VF_128_256 2 "nonimmediate_operand" "xm"))
>   (plus:VF_128_256 (match_dup 1) (match_dup 2))
>   ADDSUB_CST))]
>   ""
>   "%vaddsub\t{%2, %1, %0|%0, %1, %2}"
> 
> but genpreds doesn't like whatever syntax I try to use at this place
>  (), ...
> 
> Is this somehow possible and is there an existing example I can look at?
> 
> Thanks,
> Richard.

Jakub

GCC, standard library functions/builtins and POSIX conformance

[Vincent Lefevre]

The GCC manual says:

 If you need a Standard compliant library, then you need to find one, as
GCC does not provide one.  The GNU C library (called 'glibc') provides
ISO C, POSIX, BSD, SystemV and X/Open compatibility for GNU/Linux and
HURD-based GNU systems; no recent version of it supports other systems,
though some very old versions did.  Version 2.2 of the GNU C library
includes nearly complete C99 support.  You could also ask your operating
system vendor if newer libraries are available.

However, even if the GNU C library is used, GCC also provides some
builtins, and it is not clear whether when there is a difference
between ISO C and POSIX (e.g. an undefined behavior in C and some
defined behavior in POSIX), the GCC builtin just conforms to ISO C,
or also conforms to POSIX. So, IMHO, some clarification is needed.

An example is remquo(x,y,*quo) when y ≠ 0 and the result is NaN. ISO C
currently fails to define the behavior concerning *quo, making this call
undefined behavior. But in POSIX, this call is valid and *quo just takes
an (implicitly) unspecified value[*].

[*] https://austingroupbugs.net/view.php?id=713

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Difficulties in merging patterns

[Richard Biener]

On Thu, 17 Jun 2021, Jakub Jelinek wrote:

> On Thu, Jun 17, 2021 at 03:21:05PM +0200, Richard Biener wrote:
> > but the difficulty is in the (const_int ..) operand to (vec_merge ..).
> > I've tried sth like
> > 
> > (define_mode_attr addsub_cst [(V4DF "(const_int 5)") (V2DF "(const_int 
> > 1)")
> >   (V4SF "(const_int 5)") (V8SF "(const_int 
> > 85)")])
> 
> Have you tried making addsub_cst just "5" "1" or "85" and use (const_int
> )?

Ah, that works!  Now I only have to figure out the correct attributes
and alternatives.  For reference, this is what I have at the moment.
Will play further tomorrow.

(define_mode_attr addsub_cst [(V4DF "5") (V2DF "1")
  (V4SF "5") (V8SF "85")])
(define_insn "vec_addsub3"
  [(set (match_operand:VF_128_256 0 "register_operand" "=x")
(vec_merge:VF_128_256
  (minus:VF_128_256
(match_operand:VF_128_256 1 "register_operand" "x")
(match_operand:VF_128_256 2 "nonimmediate_operand" "xm"))
  (plus:VF_128_256 (match_dup 1) (match_dup 2))
  (const_int )))]
  "TARGET_SSE3"
  "%vaddsub\t{%2, %1, %0|%0, %1, %2}"
  [(set_attr "type" "sseadd")
   (set_attr "prefix" "vex")
   (set_attr "mode" "")])

Richard.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/17/21 4:18 AM, Jonathan Wakely wrote:

On Thu, 17 Jun 2021 at 02:01, Martin Sebor wrote:


On 6/16/21 6:40 PM, Jason Merrill wrote:

On 6/16/21 8:17 PM, Martin Sebor wrote:

3) adds the PR component/n to each ChangeLog


This would be reverting the r12-771 change, which seems both unrelated
and undesirable.


Now I'm confused.  Isn't that just what caused the problem to begin
with?  (The bug not being updated with the commit because it's not
in the ChangeLog entries?)



No.

The original problem is that the PR wasn't in the body of the commit AT ALL.


But I see [PR100085] right there at the end of the summary line:

  https://gcc.gnu.org/pipermail/gcc/2021-June/236346.html

and here:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f700e4b0ee3ef53b48975cf89be26b9177e3a3f3



The current mklog.py will do this:

 PR cmpt/

gcc/ChangeLog:

 * blah.c (blah): Blah blah.

That will cause updates to bugzilla, it works fine. You do not need to
change it to:

gcc/ChangeLog:

 PR cmpt/
 * blah.c (blah): Blah blah.

That would also work, but isn't necessary (and would be reverting the
r12-771 change).

Either of the forms above will update bugzilla. The original problem
was that neither of those forms was used.


You mean the sole reason why Bugzilla wasn't updated was that
the component was missing from the PR?  And the proposed change
is to reject commits without the component bit?  Why?

Martin

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Michael Matz]

Hello,

On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:

> > The original problem is that the PR wasn't _in the body_ of the commit 
> 
> But I see [PR100085] right there at the end of the _summary line_:

Emphasis mine.


Ciao,
Michael.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/17/21 9:11 AM, Michael Matz wrote:

Hello,

On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:


The original problem is that the PR wasn't _in the body_ of the commit


But I see [PR100085] right there at the end of the _summary line_:


Emphasis mine.


Let me make sure I understand: we ask users to put PR numbers
on the first line but the script doesn't consider the first line
a part of the "body" and so it doesn't use the PRs mentioned on
it to update Bugzilla?

If I got that right, why on earth not?  That makes no sense to me.
Are we worried about unrelated PR mentioned on the first line
triggering updates to unrelated bugs?

Martin

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jakub Jelinek via Gcc]

On Thu, Jun 17, 2021 at 09:33:06AM -0600, Martin Sebor wrote:
> On 6/17/21 9:11 AM, Michael Matz wrote:
> > Hello,
> > 
> > On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:
> > 
> > > > The original problem is that the PR wasn't _in the body_ of the commit
> > > 
> > > But I see [PR100085] right there at the end of the _summary line_:
> > 
> > Emphasis mine.
> 
> Let me make sure I understand: we ask users to put PR numbers
> on the first line but the script doesn't consider the first line
> a part of the "body" and so it doesn't use the PRs mentioned on
> it to update Bugzilla?

No.  The only thing that is linked to bugzilla is what appears in the
ChangeLog entry (intentionally so, not putting the PR into the ChangeLog
part means one doesn't see that in the ChangeLog).
And we ask users to put the PR numbers both on the first line (== subject
of mail) and in the ChangeLog entry.

The reason this thread started was that several people made the mistake
where they only mentioned PR in the first line and nowhere else and bugzilla
wasn't updated.  This is now fixed, such commits are rejected and so they
won't make the same mistake again.

Jakub

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jonathan Wakely via Gcc]

On Thu, 17 Jun 2021 at 16:33, Martin Sebor  wrote:
>
> On 6/17/21 9:11 AM, Michael Matz wrote:
> > Hello,
> >
> > On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:
> >
> >>> The original problem is that the PR wasn't _in the body_ of the commit
> >>
> >> But I see [PR100085] right there at the end of the _summary line_:
> >
> > Emphasis mine

Right. How are we still discussing this part of the original issue?!

>
> Let me make sure I understand: we ask users to put PR numbers
> on the first line but the script doesn't consider the first line
> a part of the "body" and so it doesn't use the PRs mentioned on
> it to update Bugzilla?

AFAIK Bugzilla does not process a "PRn" string anywhere in the
commit log. It only processes the full "PR component/" form. This
is stated in the docs:

"The body of the commit message should still contain the full form (PR
/n) within the body of the commit message so that
Bugzilla will correctly notice the commit."

We want it on the subject line for **our** benefit, not bugzilla's. So
that the outout of 'git log --oneline' shows useful context.

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Joseph Myers]

On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote:

> It seems a bit dangerous to me to rely on just extracting PR numbers from
> tests.  What if the patch is just adjusting a test to make it compatible with
> the remainder of the change?

Also, that a test is added for a PR, or a commit is relevant to a PR, is a 
weaker property than the commit *resolving* the PR.  The fact that a 
commit *resolves* a PR (allows it to be marked as resolved, or the 
regression markers to be updated if it's resolved in master but the fix 
still needs to be backported) needs to be explicitly affirmed by the 
committer (possibly based on a question asked by a script) rather than 
assumed by default based on the PR being mentioned somewhere.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jakub Jelinek via Gcc]

On Thu, Jun 17, 2021 at 05:12:52PM +, Joseph Myers wrote:
> On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote:
> 
> > It seems a bit dangerous to me to rely on just extracting PR numbers from
> > tests.  What if the patch is just adjusting a test to make it compatible 
> > with
> > the remainder of the change?
> 
> Also, that a test is added for a PR, or a commit is relevant to a PR, is a 
> weaker property than the commit *resolving* the PR.  The fact that a 
> commit *resolves* a PR (allows it to be marked as resolved, or the 
> regression markers to be updated if it's resolved in master but the fix 
> still needs to be backported) needs to be explicitly affirmed by the 
> committer (possibly based on a question asked by a script) rather than 
> assumed by default based on the PR being mentioned somewhere.

mklog as is doesn't fill in the details (descriptions of the changes
to each function etc.), nor is realiable in many cases, and with Jason's
recent change just fills in the first and last part of the first line
but not the important middle part.
So, the developer has to hand edit it anyway and that I'd consider also
be the right time when the verification whether the PR being mentioned
is the right one etc.  So no need to add a question asked by the script
at another point.

Jakub

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Jason Merrill via Gcc]

On Thu, Jun 17, 2021 at 1:14 PM Joseph Myers 
wrote:

> On Thu, 17 Jun 2021, Richard Earnshaw via Gcc wrote:
>
> > It seems a bit dangerous to me to rely on just extracting PR numbers from
> > tests.  What if the patch is just adjusting a test to make it compatible
> with
> > the remainder of the change?
>
> Also, that a test is added for a PR, or a commit is relevant to a PR, is a
> weaker property than the commit *resolving* the PR.  The fact that a
> commit *resolves* a PR (allows it to be marked as resolved, or the
> regression markers to be updated if it's resolved in master but the fix
> still needs to be backported) needs to be explicitly affirmed by the
> committer (possibly based on a question asked by a script) rather than
> assumed by default based on the PR being mentioned somewhere.
>

Indeed, we would need to be cautious about adding such automation.  But
there isn't any now; the only danger is of an unrelated patch showing up in
a comment on a PR.  Which we already get when I mess up the PR number in my
test (oops).

Jason

Re: git gcc-commit-mklog doesn't extract PR number to ChangeLog

[Martin Sebor via Gcc]

On 6/17/21 10:32 AM, Jonathan Wakely wrote:

On Thu, 17 Jun 2021 at 16:33, Martin Sebor  wrote:


On 6/17/21 9:11 AM, Michael Matz wrote:

Hello,

On Thu, 17 Jun 2021, Martin Sebor via Gcc wrote:


The original problem is that the PR wasn't _in the body_ of the commit


But I see [PR100085] right there at the end of the _summary line_:


Emphasis mine


Right. How are we still discussing this part of the original issue?!


Because no has explained *why* there had to be an issue to begin
with: the rationale for ignoring the piece of data that was in
the commit message and that could have been used to update Bugzilla.
I have just gone through the whole discussion again in case I missed
it but I couldn't find an answer.



Let me make sure I understand: we ask users to put PR numbers
on the first line but the script doesn't consider the first line
a part of the "body" and so it doesn't use the PRs mentioned on
it to update Bugzilla?


AFAIK Bugzilla does not process a "PRn" string anywhere in the
commit log. It only processes the full "PR component/" form. This
is stated in the docs:

"The body of the commit message should still contain the full form (PR
/n) within the body of the commit message so that
Bugzilla will correctly notice the commit."

We want it on the subject line for **our** benefit, not bugzilla's. So
that the outout of 'git log --oneline' shows useful context.


But *why* do we not want to use the short PR in the subject to
update Bugzilla?

It sounds like our tooling (since r12-771) massages ChangeLogs
based on the PR component/ in the commit description.  There
also is a way to determine the component for a PR  by querying
Bugzilla (the -p option to mklog.py).  So why are we required to
duplicate the PR in two places in the commit message and why do
we need to provide the component?  In other words, why can
the original problem not be solved by making our tooling
smarter instead of rejecting such commits?

Martin

Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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_AND_HI 0xb0007fff
> >
> > A bit in the output pr_data field is set only if it is set in all
> > relocatable input pr_data fields.  If all bits in the the output
> > pr_data field are zero, this property should be removed from output.
> >
> > If the bit is 1, all input relocatables have the feature.  If the
> > bit is 0 or the property is missing, the info is unknown.
> >
> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> >
> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> >
> > A bit in the output pr_data field is set if it is set in any
> > relocatable input pr_data fields. If all bits in the the output
> > pr_data field are zero, this property should be removed from output.
> >
> > If the bit is 1, some input relocatables have the feature.  If the
> > bit is 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.
>
> Here is the binutils patch to implement it.
>

If there are no objections, I will check it in tomorrow.


-- 
H.J.

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Fangrui Song via Gcc]

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. 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 in all
> relocatable input pr_data fields.  If all bits in the the output
> pr_data field are zero, this property should be removed from output.
>
> If the bit is 1, all input relocatables have the feature.  If the
> bit is 0 or the property is missing, the info is unknown.


How to use AND in practice?
Are you going to add .note.gnu.property to all of crt1.o crti.o
crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
files written in assembly?


> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
>
>  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
>  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
>
> A bit in the output pr_data field is set if it is set in any
> relocatable input pr_data fields. If all bits in the the output
> pr_data field are zero, this property should be removed from output.
>
> If the bit is 1, some input relocatables have the feature.  If the
> bit is 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.

Here is the binutils patch to implement it.



If there are no objections, I will check it in tomorrow.


If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
very kind of you if you can collect more use cases before generalizing
this into a non-arch-specific GNU PROPERTY.

The "copy relocations on protected data symbols" thing is x86 specific
and only applies with gcc+GNU ld+glibc.
Non-x86 architectures don't have this thing.
gold doesn't have this thing.
clang doesn't have this thing.

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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. 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 in all
> >> > relocatable input pr_data fields.  If all bits in the the output
> >> > pr_data field are zero, this property should be removed from output.
> >> >
> >> > If the bit is 1, all input relocatables have the feature.  If the
> >> > bit is 0 or the property is missing, the info is unknown.
>
> How to use AND in practice?
> Are you going to add .note.gnu.property to all of crt1.o crti.o
> crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> files written in assembly?
>
> >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> >> >
> >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> >> >
> >> > A bit in the output pr_data field is set if it is set in any
> >> > relocatable input pr_data fields. If all bits in the the output
> >> > pr_data field are zero, this property should be removed from output.
> >> >
> >> > If the bit is 1, some input relocatables have the feature.  If the
> >> > bit is 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.
> >>
> >> Here is the binutils patch to implement it.
> >>
> >
> >If there are no objections, I will check it in tomorrow.
>
> If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> very kind of you if you can collect more use cases before generalizing
> this into a non-arch-specific GNU PROPERTY.
>
> The "copy relocations on protected data symbols" thing is x86 specific
> and only applies with gcc+GNU ld+glibc.
> Non-x86 architectures don't have this thing.
> gold doesn't have this thing.
> clang doesn't have this thing.

It will be used to remove copy relocation and implement canonical function
pointers, which will benefit protected data and function.

-- 
H.J.

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Fāng-ruì Sòng via Gcc]

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:
> > >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_AND_HI 0xb0007fff
> > >> >
> > >> > A bit in the output pr_data field is set only if it is set in all
> > >> > relocatable input pr_data fields.  If all bits in the the output
> > >> > pr_data field are zero, this property should be removed from output.
> > >> >
> > >> > If the bit is 1, all input relocatables have the feature.  If the
> > >> > bit is 0 or the property is missing, the info is unknown.
> >
> > How to use AND in practice?
> > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > files written in assembly?
> >
> > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > >> >
> > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > >> >
> > >> > A bit in the output pr_data field is set if it is set in any
> > >> > relocatable input pr_data fields. If all bits in the the output
> > >> > pr_data field are zero, this property should be removed from output.
> > >> >
> > >> > If the bit is 1, some input relocatables have the feature.  If the
> > >> > bit is 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.
> > >>
> > >> Here is the binutils patch to implement it.
> > >>
> > >
> > >If there are no objections, I will check it in tomorrow.
> >
> > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > very kind of you if you can collect more use cases before generalizing
> > this into a non-arch-specific GNU PROPERTY.
> >
> > The "copy relocations on protected data symbols" thing is x86 specific
> > and only applies with gcc+GNU ld+glibc.
> > Non-x86 architectures don't have this thing.
> > gold doesn't have this thing.
> > clang doesn't have this thing.
>
> It will be used to remove copy relocation and implement canonical function
> pointers, which will benefit protected data and function.

The action items in
https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
can be applied without a GNU PROPERTY.

If we want to enforce the link-time check that a shared object is no longer
compatible with copy relocations, just make the shared object's non-weak
definitions protected, and add a GNU ld diagnostic like gold
(https://sourceware.org/bugzilla/show_bug.cgi?id=19823)

---

For functions,

On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since at least
4.1.2 (oldest gcc I can find on godbolt):

  __attribute__((visibility("protected")))
  void *addr() { return (void*)addr; }

  // a protected non-definition declaration is the same.

  // while asm(".protected addr") can use GOT, it is super rare if ever exists
  // outside glibc elf/vis*.c

I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
the same diagnostic:

  relocation R_X86_64_PC32 against protected function `addr' can not
be used when making a shared object

I think we can assert that taking the address of a protected function
never works with GNU ld.
So no compatibility concern.
Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
doesn't need any GNU PROPERTY.

---

For variables, if an object file/archive member does not have GNU PROPERTY, do
you consider it incompatible with "single global definition"? That is why I
mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
written in assembly.

If you consider such an object compatible with "single global definition", I
don't see why a GNU PROPERTY is needed.

If you consider such an object incompatible with "single global definition", I
don't see how "single global definition" benefits can be claimed giving so many
prebuilt object files without GNU PROPERTY.

If we still want "absolutely no copy relocation for -fno-pic", just use GOT for
default visibility external data access
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112)
Some architectures may not like it (i386/ppc32), just leave them behind.
Modern architectures can do it. When things get matured, add a ld warning,
then add a ld.so warning. When things get more matured, change the warnings to
errors.

Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can
preempt global) and Solaris LD_BREADTH (breadth-first order based dependency
order) and LD_NODIRECT (direct bindings). At some point, introduce a behav

Re: Build failure due to format-truncation

[Martin Sebor via Gcc]

On 6/16/21 6:26 PM, José Rui Faustino de Sousa wrote:

On 16/06/21 20:37, Martin Sebor wrote:

I don't really think the warning is doing
anything wrong



I completely agree. I am not complaining about the warning, I am 
complaining that there is code in gcc which raises this warning and 
breaks the build.


I was assuming that this was being triggered by some option that I was 
using but, on further investigation, the -Wformat-truncation flag is 
being set by -Wall which AFAICT is set by the build process itself...


Correct.



So this is starting to look like something that really should be 
fixed... What bugs me is why it seems that I was the only one who 
noticed...


What stage does this happens in, and if stage 1, what is the system 
compiler?  You need GCC 12 to reproduce it and as far as I can see

it needs -O0 (or -Og or -Os).  That seems like a unique setup.  If
this is stage 1 it doesn't use -Werror so warnings shouldn't keep
the build from succeeding.  If some later stage and you're using
any unusual options (like -Og or -Os) then that would also be
unusual.  Otherwise I'll need more info to understand what's going
on.

Martin



Thank you very much.

Best regards,
José Rui

gcc-9-20210617 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210617 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210617/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision de0fcacd568bbd86726df7a5416edd08a525c93a

You'll find:

 gcc-9-20210617.tar.xzComplete GCC

  SHA256=b8b5e78479485b4670e6c3077166dc9463c63fb5b9713cb16cc99f2812ed52d8
  SHA1=f65c4296bcb21844dd2bafec0075566172e00ab2

Diffs from 9-20210610 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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:
> > > >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_AND_HI 0xb0007fff
> > > >> >
> > > >> > A bit in the output pr_data field is set only if it is set in all
> > > >> > relocatable input pr_data fields.  If all bits in the the output
> > > >> > pr_data field are zero, this property should be removed from output.
> > > >> >
> > > >> > If the bit is 1, all input relocatables have the feature.  If the
> > > >> > bit is 0 or the property is missing, the info is unknown.
> > >
> > > How to use AND in practice?
> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > > files written in assembly?
> > >
> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > > >> >
> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > > >> >
> > > >> > A bit in the output pr_data field is set if it is set in any
> > > >> > relocatable input pr_data fields. If all bits in the the output
> > > >> > pr_data field are zero, this property should be removed from output.
> > > >> >
> > > >> > If the bit is 1, some input relocatables have the feature.  If the
> > > >> > bit is 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.
> > > >>
> > > >> Here is the binutils patch to implement it.
> > > >>
> > > >
> > > >If there are no objections, I will check it in tomorrow.
> > >
> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > > very kind of you if you can collect more use cases before generalizing
> > > this into a non-arch-specific GNU PROPERTY.
> > >
> > > The "copy relocations on protected data symbols" thing is x86 specific
> > > and only applies with gcc+GNU ld+glibc.
> > > Non-x86 architectures don't have this thing.
> > > gold doesn't have this thing.
> > > clang doesn't have this thing.
> >
> > It will be used to remove copy relocation and implement canonical function
> > pointers, which will benefit protected data and function.
>
> The action items in
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> can be applied without a GNU PROPERTY.
>
> If we want to enforce the link-time check that a shared object is no longer
> compatible with copy relocations, just make the shared object's non-weak
> definitions protected, and add a GNU ld diagnostic like gold
> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
>
> ---
>
> For functions,
>
> On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since at least
> 4.1.2 (oldest gcc I can find on godbolt):
>
>   __attribute__((visibility("protected")))
>   void *addr() { return (void*)addr; }
>
>   // a protected non-definition declaration is the same.
>
>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
>   // outside glibc elf/vis*.c
>
> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> the same diagnostic:
>
>   relocation R_X86_64_PC32 against protected function `addr' can not
> be used when making a shared object
>
> I think we can assert that taking the address of a protected function
> never works with GNU ld.
> So no compatibility concern.
> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> doesn't need any GNU PROPERTY.
>
> ---
>
> For variables, if an object file/archive member does not have GNU PROPERTY, do
> you consider it incompatible with "single global definition"? That is why I
> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a 
> members
> written in assembly.
>
> If you consider such an object compatible with "single global definition", I
> don't see why a GNU PROPERTY is needed.
>
> If you consider such an object incompatible with "single global definition", I
> don't see how "single global definition" benefits can be claimed giving so 
> many
> prebuilt object files without GNU PROPERTY.

Please see the slides in

https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8

which includes

Dynamic Linker for Single Global Definition
• Check the single global definition marker on all components, the executable
and its dependency shared libraries.
• Issue an error/warning if the marker is not consistent on all components.
• Disallow copy relocation against def

Re: Build failure due to format-truncation

[José Rui Faustino de Sousa via Gcc]

On 17/06/21 20:51, Martin Sebor wrote:
What stage does this happens in, and if stage 1, what is the system 
compiler? 

>

I am not sure if this happens also in the earlier stages, I would have 
to do a complete rebuild and that would take some time.


I have built gcc using an altered "opts.c" so that it compiles without 
problems. After that replacing the file with the original one generates 
the error. So this is happening at the later stages of compilation.



You need GCC 12 to reproduce it and as far as I can see
it needs -O0 (or -Og or -Os). 

>

No problems with 11, 10 or 9, with the same flags.


That seems like a unique setup.  If
this is stage 1 it doesn't use -Werror so warnings shouldn't keep
the build from succeeding.  If some later stage and you're using
any unusual options (like -Og or -Os) then that would also be
unusual.  Otherwise I'll need more info to understand what's going
on.



This is the full command issued by make:

/home/jrfsousa/Work/gcc/build-master/./prev-gcc/xg++ 
-B/home/jrfsousa/Work/gcc/build-master/./prev-gcc/ 
-B/opt/gcc/gcc-master/x86_64-pc-linux-gnu/bin/ -nostdinc++ 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 

-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 

-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
 -I/home/jrfsousa/Work/gcc/gcc-master/libstdc++-v3/libsupc++ 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
 -fno-PIE -c   -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check   -fchecking=1 
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-master/gcc -I../../gcc-master/gcc/. 
-I../../gcc-master/gcc/../include 
-I../../gcc-master/gcc/../libcpp/include 
-I../../gcc-master/gcc/../libcody 
-I/home/jrfsousa/Work/gcc/build-master/./gmp 
-I/home/jrfsousa/Work/gcc/gcc-master/gmp 
-I/home/jrfsousa/Work/gcc/build-master/./mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpc/src 
-I../../gcc-master/gcc/../libdecnumber 
-I../../gcc-master/gcc/../libdecnumber/bid -I../libdecnumber 
-I../../gcc-master/gcc/../libbacktrace 
-I/home/jrfsousa/Work/gcc/build-master/./isl/include 
-I/home/jrfsousa/Work/gcc/gcc-master/isl/include  -o opts.o -MT opts.o 
-MMD -MP -MF ./.deps/opts.TPo ../../gcc-master/gcc/opts.c


Applying the command by hand still fails, with or without the flags I 
used (-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check), after removing 
"-Wall" the compilation succeeds without problems.


Thank you very much.

Best regards,
José Rui

Re: Build failure due to format-truncation

[Martin Sebor via Gcc]

On 6/17/21 5:04 PM, José Rui Faustino de Sousa wrote:

On 17/06/21 20:51, Martin Sebor wrote:
What stage does this happens in, and if stage 1, what is the system 
compiler? 

 >

I am not sure if this happens also in the earlier stages, I would have 
to do a complete rebuild and that would take some time.


I have built gcc using an altered "opts.c" so that it compiles without 
problems. After that replacing the file with the original one generates 
the error. So this is happening at the later stages of compilation.



You need GCC 12 to reproduce it and as far as I can see
it needs -O0 (or -Og or -Os). 

 >

No problems with 11, 10 or 9, with the same flags.


That seems like a unique setup.  If
this is stage 1 it doesn't use -Werror so warnings shouldn't keep
the build from succeeding.  If some later stage and you're using
any unusual options (like -Og or -Os) then that would also be
unusual.  Otherwise I'll need more info to understand what's going
on.



This is the full command issued by make:

/home/jrfsousa/Work/gcc/build-master/./prev-gcc/xg++ 
-B/home/jrfsousa/Work/gcc/build-master/./prev-gcc/ 
-B/opt/gcc/gcc-master/x86_64-pc-linux-gnu/bin/ -nostdinc++ 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 

-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu 

-I/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
  -I/home/jrfsousa/Work/gcc/gcc-master/libstdc++-v3/libsupc++ 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs 
-L/home/jrfsousa/Work/gcc/build-master/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
  -fno-PIE -c   -O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 

  ^^^

Right, with -O0 we understand why it happens.  So you must have set
CXXFLAGS to -O0 (you might have said that and I forgot; if so, sorry
if I sent you on a wild goose chase). That's also the unusual part
and why others haven't run into it.  Normally stage 2 and later build
with -O2 or higher.

Does that make sense?

Martin


-fno-omit-frame-pointer -fstrict-overflow -fstack-check   -fchecking=1 
-DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-master/gcc -I../../gcc-master/gcc/. 
-I../../gcc-master/gcc/../include 
-I../../gcc-master/gcc/../libcpp/include 
-I../../gcc-master/gcc/../libcody 
-I/home/jrfsousa/Work/gcc/build-master/./gmp 
-I/home/jrfsousa/Work/gcc/gcc-master/gmp 
-I/home/jrfsousa/Work/gcc/build-master/./mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpfr/src 
-I/home/jrfsousa/Work/gcc/gcc-master/mpc/src 
-I../../gcc-master/gcc/../libdecnumber 
-I../../gcc-master/gcc/../libdecnumber/bid -I../libdecnumber 
-I../../gcc-master/gcc/../libbacktrace 
-I/home/jrfsousa/Work/gcc/build-master/./isl/include 
-I/home/jrfsousa/Work/gcc/gcc-master/isl/include  -o opts.o -MT opts.o 
-MMD -MP -MF ./.deps/opts.TPo ../../gcc-master/gcc/opts.c


Applying the command by hand still fails, with or without the flags I 
used (-O0 -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments 
-fno-omit-frame-pointer -fstrict-overflow -fstack-check), after removing 
"-Wall" the compilation succeeds without problems.


Thank you very much.

Best regards,
José Rui

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Fāng-ruì Sòng via Gcc]

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 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. 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 in all
> > >> > relocatable input pr_data fields.  If all bits in the the output
> > >> > pr_data field are zero, this property should be removed from output.
> > >> >
> > >> > If the bit is 1, all input relocatables have the feature.  If the
> > >> > bit is 0 or the property is missing, the info is unknown.
> >
> > How to use AND in practice?
> > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > files written in assembly?
> >
> > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > >> >
> > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > >> >
> > >> > A bit in the output pr_data field is set if it is set in any
> > >> > relocatable input pr_data fields. If all bits in the the output
> > >> > pr_data field are zero, this property should be removed from output.
> > >> >
> > >> > If the bit is 1, some input relocatables have the feature.  If the
> > >> > bit is 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.
> > >>
> > >> Here is the binutils patch to implement it.
> > >>
> > >
> > >If there are no objections, I will check it in tomorrow.
> >
> > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > very kind of you if you can collect more use cases before generalizing
> > this into a non-arch-specific GNU PROPERTY.
> >
> > The "copy relocations on protected data symbols" thing is x86 specific
> > and only applies with gcc+GNU ld+glibc.
> > Non-x86 architectures don't have this thing.
> > gold doesn't have this thing.
> > clang doesn't have this thing.
>
> It will be used to remove copy relocation and implement canonical function
> pointers, which will benefit protected data and function.

The action items in
https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
can be applied without a GNU PROPERTY.

If we want to enforce the link-time check that a shared object is no longer
compatible with copy relocations, just make the shared object's non-weak
definitions protected, and add a GNU ld diagnostic like gold
(https://sourceware.org/bugzilla/show_bug.cgi?id=19823)

---

For functions,

On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since at least
4.1.2 (oldest gcc I can find on godbolt):

  __attribute__((visibility("protected")))
  void *addr() { return (void*)addr; }

  // a protected non-definition declaration is the same.

  // while asm(".protected addr") can use GOT, it is super rare if ever exists
  // outside glibc elf/vis*.c

I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
the same diagnostic:

  relocation R_X86_64_PC32 against protected function `addr' can not
be used when making a shared object

I think we can assert that taking the address of a protected function
never works with GNU ld.
So no compatibility concern.
Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
doesn't need any GNU PROPERTY.

---

For variables, if an object file/archive member does not have GNU PROPERTY, do
you consider it incompatible with "single global definition"? That is why I
mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
written in assembly.

If you consider such an object compatible with "single global definition", I
don't see why a GNU PROPERTY is needed.

If you consider such an object incompatible with "single global definition", I
don't see how "single global definition" benefits can be claimed giving so many
prebuilt object files without GNU PROPERTY.


Please see the slides in

https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8

which includes

Dynamic Linker for Single Global Definition
• Check the single global definition marker on all components, the executable
and its dependency shared libraries.
• Issue an error/warning if the marker is not consistent on all components.


This is not appealing from a compatibility point of view.
It is common that a system has mixed shared objects:

-fsingle-global-definition => a.so (marker value 1)
no -fsingle-global-definition => b.so (marker value 0

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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 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. 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 in all
> >> > > >> > relocatable input pr_data fields.  If all bits in the the output
> >> > > >> > pr_data field are zero, this property should be removed from 
> >> > > >> > output.
> >> > > >> >
> >> > > >> > If the bit is 1, all input relocatables have the feature.  If the
> >> > > >> > bit is 0 or the property is missing, the info is unknown.
> >> > >
> >> > > How to use AND in practice?
> >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> >> > > files written in assembly?
> >> > >
> >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> >> > > >> >
> >> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> >> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> >> > > >> >
> >> > > >> > A bit in the output pr_data field is set if it is set in any
> >> > > >> > relocatable input pr_data fields. If all bits in the the output
> >> > > >> > pr_data field are zero, this property should be removed from 
> >> > > >> > output.
> >> > > >> >
> >> > > >> > If the bit is 1, some input relocatables have the feature.  If the
> >> > > >> > bit is 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.
> >> > > >>
> >> > > >> Here is the binutils patch to implement it.
> >> > > >>
> >> > > >
> >> > > >If there are no objections, I will check it in tomorrow.
> >> > >
> >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> >> > > very kind of you if you can collect more use cases before generalizing
> >> > > this into a non-arch-specific GNU PROPERTY.
> >> > >
> >> > > The "copy relocations on protected data symbols" thing is x86 specific
> >> > > and only applies with gcc+GNU ld+glibc.
> >> > > Non-x86 architectures don't have this thing.
> >> > > gold doesn't have this thing.
> >> > > clang doesn't have this thing.
> >> >
> >> > It will be used to remove copy relocation and implement canonical 
> >> > function
> >> > pointers, which will benefit protected data and function.
> >>
> >> The action items in
> >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> >> can be applied without a GNU PROPERTY.
> >>
> >> If we want to enforce the link-time check that a shared object is no longer
> >> compatible with copy relocations, just make the shared object's non-weak
> >> definitions protected, and add a GNU ld diagnostic like gold
> >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> >>
> >> ---
> >>
> >> For functions,
> >>
> >> On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since at 
> >> least
> >> 4.1.2 (oldest gcc I can find on godbolt):
> >>
> >>   __attribute__((visibility("protected")))
> >>   void *addr() { return (void*)addr; }
> >>
> >>   // a protected non-definition declaration is the same.
> >>
> >>   // while asm(".protected addr") can use GOT, it is super rare if ever 
> >> exists
> >>   // outside glibc elf/vis*.c
> >>
> >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> >> the same diagnostic:
> >>
> >>   relocation R_X86_64_PC32 against protected function `addr' can not
> >> be used when making a shared object
> >>
> >> I think we can assert that taking the address of a protected function
> >> never works with GNU ld.
> >> So no compatibility concern.
> >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> >> doesn't need any GNU PROPERTY.
> >>
> >> ---
> >>
> >> For variables, if an object file/archive member does not have GNU 
> >> PROPERTY, do
> >> you consider it incompatible with "single global definition"? That is why I
> >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a 
> >> members
> >> written in assembly.
> >>
> >> If you consider such an object compatible with "single global definition", 
> >> I
> >> don't see why a GNU PROPERTY is needed.
> >>
> >> If you consider such an object incompatible with "single global 
> >> definition", I
> >> 

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Fāng-ruì Sòng via Gcc]

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 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:
> > >> > > >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_AND_HI 0xb0007fff
> > >> > > >> >
> > >> > > >> > A bit in the output pr_data field is set only if it is set in 
> > >> > > >> > all
> > >> > > >> > relocatable input pr_data fields.  If all bits in the the output
> > >> > > >> > pr_data field are zero, this property should be removed from 
> > >> > > >> > output.
> > >> > > >> >
> > >> > > >> > If the bit is 1, all input relocatables have the feature.  If 
> > >> > > >> > the
> > >> > > >> > bit is 0 or the property is missing, the info is unknown.
> > >> > >
> > >> > > How to use AND in practice?
> > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > >> > > files written in assembly?
> > >> > >
> > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > >> > > >> >
> > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > >> > > >> >
> > >> > > >> > A bit in the output pr_data field is set if it is set in any
> > >> > > >> > relocatable input pr_data fields. If all bits in the the output
> > >> > > >> > pr_data field are zero, this property should be removed from 
> > >> > > >> > output.
> > >> > > >> >
> > >> > > >> > If the bit is 1, some input relocatables have the feature.  If 
> > >> > > >> > the
> > >> > > >> > bit is 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.
> > >> > > >>
> > >> > > >> Here is the binutils patch to implement it.
> > >> > > >>
> > >> > > >
> > >> > > >If there are no objections, I will check it in tomorrow.
> > >> > >
> > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd 
> > >> > > be
> > >> > > very kind of you if you can collect more use cases before 
> > >> > > generalizing
> > >> > > this into a non-arch-specific GNU PROPERTY.
> > >> > >
> > >> > > The "copy relocations on protected data symbols" thing is x86 
> > >> > > specific
> > >> > > and only applies with gcc+GNU ld+glibc.
> > >> > > Non-x86 architectures don't have this thing.
> > >> > > gold doesn't have this thing.
> > >> > > clang doesn't have this thing.
> > >> >
> > >> > It will be used to remove copy relocation and implement canonical 
> > >> > function
> > >> > pointers, which will benefit protected data and function.
> > >>
> > >> The action items in
> > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > >> can be applied without a GNU PROPERTY.
> > >>
> > >> If we want to enforce the link-time check that a shared object is no 
> > >> longer
> > >> compatible with copy relocations, just make the shared object's non-weak
> > >> definitions protected, and add a GNU ld diagnostic like gold
> > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > >>
> > >> ---
> > >>
> > >> For functions,
> > >>
> > >> On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since at 
> > >> least
> > >> 4.1.2 (oldest gcc I can find on godbolt):
> > >>
> > >>   __attribute__((visibility("protected")))
> > >>   void *addr() { return (void*)addr; }
> > >>
> > >>   // a protected non-definition declaration is the same.
> > >>
> > >>   // while asm(".protected addr") can use GOT, it is super rare if ever 
> > >> exists
> > >>   // outside glibc elf/vis*.c
> > >>
> > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > >> the same diagnostic:
> > >>
> > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > >> be used when making a shared object
> > >>
> > >> I think we can assert that taking the address of a protected function
> > >> never works with GNU ld.
> > >> So no compatibility concern.
> > >> Fixing it 
> > >> (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> > >> doesn't need any GNU PROPERTY.
> > >>
> > >> ---
> > >>
> > >> For variables, if an object file/archive member does not have GNU 
> > >> PROPERTY, do
> > >> you consider it incompati

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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 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:
> > > >> > > >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_AND_HI 0xb0007fff
> > > >> > > >> >
> > > >> > > >> > A bit in the output pr_data field is set only if it is set in 
> > > >> > > >> > all
> > > >> > > >> > relocatable input pr_data fields.  If all bits in the the 
> > > >> > > >> > output
> > > >> > > >> > pr_data field are zero, this property should be removed from 
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, all input relocatables have the feature.  If 
> > > >> > > >> > the
> > > >> > > >> > bit is 0 or the property is missing, the info is unknown.
> > > >> > >
> > > >> > > How to use AND in practice?
> > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a 
> > > >> > > object
> > > >> > > files written in assembly?
> > > >> > >
> > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > > >> > > >> >
> > > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > > >> > > >> >
> > > >> > > >> > A bit in the output pr_data field is set if it is set in any
> > > >> > > >> > relocatable input pr_data fields. If all bits in the the 
> > > >> > > >> > output
> > > >> > > >> > pr_data field are zero, this property should be removed from 
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, some input relocatables have the feature.  
> > > >> > > >> > If the
> > > >> > > >> > bit is 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.
> > > >> > > >>
> > > >> > > >> Here is the binutils patch to implement it.
> > > >> > > >>
> > > >> > > >
> > > >> > > >If there are no objections, I will check it in tomorrow.
> > > >> > >
> > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, 
> > > >> > > it'd be
> > > >> > > very kind of you if you can collect more use cases before 
> > > >> > > generalizing
> > > >> > > this into a non-arch-specific GNU PROPERTY.
> > > >> > >
> > > >> > > The "copy relocations on protected data symbols" thing is x86 
> > > >> > > specific
> > > >> > > and only applies with gcc+GNU ld+glibc.
> > > >> > > Non-x86 architectures don't have this thing.
> > > >> > > gold doesn't have this thing.
> > > >> > > clang doesn't have this thing.
> > > >> >
> > > >> > It will be used to remove copy relocation and implement canonical 
> > > >> > function
> > > >> > pointers, which will benefit protected data and function.
> > > >>
> > > >> The action items in
> > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > > >> can be applied without a GNU PROPERTY.
> > > >>
> > > >> If we want to enforce the link-time check that a shared object is no 
> > > >> longer
> > > >> compatible with copy relocations, just make the shared object's 
> > > >> non-weak
> > > >> definitions protected, and add a GNU ld diagnostic like gold
> > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > > >>
> > > >> ---
> > > >>
> > > >> For functions,
> > > >>
> > > >> On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since 
> > > >> at least
> > > >> 4.1.2 (oldest gcc I can find on godbolt):
> > > >>
> > > >>   __attribute__((visibility("protected")))
> > > >>   void *addr() { return (void*)addr; }
> > > >>
> > > >>   // a protected non-definition declaration is the same.
> > > >>
> > > >>   // while asm(".protected addr") can use GOT, it is super rare if 
> > > >> ever exists
> > > >>   // outside glibc elf/vis*.c
> > > >>
> > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > > >> the same diagnostic:
> > > >>
> > > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > > >> be used when making a shared object
> > > >>
> > > >> I think we can assert that taking the address of a prot

Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via Gcc]

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 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:
> > > >> > > >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_AND_HI 0xb0007fff
> > > >> > > >> >
> > > >> > > >> > A bit in the output pr_data field is set only if it is set in 
> > > >> > > >> > all
> > > >> > > >> > relocatable input pr_data fields.  If all bits in the the 
> > > >> > > >> > output
> > > >> > > >> > pr_data field are zero, this property should be removed from 
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, all input relocatables have the feature.  If 
> > > >> > > >> > the
> > > >> > > >> > bit is 0 or the property is missing, the info is unknown.
> > > >> > >
> > > >> > > How to use AND in practice?
> > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a 
> > > >> > > object
> > > >> > > files written in assembly?
> > > >> > >
> > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI
> > > >> > > >> >
> > > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000
> > > >> > > >> >  #define GNU_PROPERTY_UINT32_OR_HI 0xb000
> > > >> > > >> >
> > > >> > > >> > A bit in the output pr_data field is set if it is set in any
> > > >> > > >> > relocatable input pr_data fields. If all bits in the the 
> > > >> > > >> > output
> > > >> > > >> > pr_data field are zero, this property should be removed from 
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, some input relocatables have the feature.  
> > > >> > > >> > If the
> > > >> > > >> > bit is 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.
> > > >> > > >>
> > > >> > > >> Here is the binutils patch to implement it.
> > > >> > > >>
> > > >> > > >
> > > >> > > >If there are no objections, I will check it in tomorrow.
> > > >> > >
> > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, 
> > > >> > > it'd be
> > > >> > > very kind of you if you can collect more use cases before 
> > > >> > > generalizing
> > > >> > > this into a non-arch-specific GNU PROPERTY.
> > > >> > >
> > > >> > > The "copy relocations on protected data symbols" thing is x86 
> > > >> > > specific
> > > >> > > and only applies with gcc+GNU ld+glibc.
> > > >> > > Non-x86 architectures don't have this thing.
> > > >> > > gold doesn't have this thing.
> > > >> > > clang doesn't have this thing.
> > > >> >
> > > >> > It will be used to remove copy relocation and implement canonical 
> > > >> > function
> > > >> > pointers, which will benefit protected data and function.
> > > >>
> > > >> The action items in
> > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > > >> can be applied without a GNU PROPERTY.
> > > >>
> > > >> If we want to enforce the link-time check that a shared object is no 
> > > >> longer
> > > >> compatible with copy relocations, just make the shared object's 
> > > >> non-weak
> > > >> definitions protected, and add a GNU ld diagnostic like gold
> > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > > >>
> > > >> ---
> > > >>
> > > >> For functions,
> > > >>
> > > >> On x86-64, gcc -fpic has been using  leaqaddr()(%rip), %rax since 
> > > >> at least
> > > >> 4.1.2 (oldest gcc I can find on godbolt):
> > > >>
> > > >>   __attribute__((visibility("protected")))
> > > >>   void *addr() { return (void*)addr; }
> > > >>
> > > >>   // a protected non-definition declaration is the same.
> > > >>
> > > >>   // while asm(".protected addr") can use GOT, it is super rare if 
> > > >> ever exists
> > > >>   // outside glibc elf/vis*.c
> > > >>
> > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > > >> the same diagnostic:
> > > >>
> > > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > > >> be used when making a shared object
> > > >>
> > > >> I think we can assert that taking the address of a prot