On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote:
> Instead of rejecting commits that don't mention all the same PRs on
> the first line of the commit as in the ChangeLog entries it seems
> that the Git commit script could extract the PR references from
> just the ChangeLong entries
On 6/10/21 1:09 PM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote:
Instead of rejecting commits that don't mention all the same PRs on
the first line of the commit as in the ChangeLog entries it seems
that the Git commit script could extract the PR referen
On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote:
> > Just look at the start of this thread. Some people put
> > the [PRn] only in the first line of the commit. And that is
> > what these changes want to diagnose, that is an error and results
> > in bugzilla not being updated.
>
On 6/10/21 3:28 PM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote:
Just look at the start of this thread. Some people put
the [PRn] only in the first line of the commit. And that is
what these changes want to diagnose, that is an error and results
in bug
ation and one can see it e.g. here:
https://splichal.eu/scripts/sphinx/gcc/_build/html/gcc-command-options/options-to-request-or-suppress-warnings.html#cmdoption-Wprio-ctor-dtor
I find the style you have below right now clearer than keeping both
options in the same heading and adding a Note expla
> Quite a few projects under the GNU project[1] have dissociated
themselves from the FSF, so "as defined by the FSF" perhaps doesn't
apply as consistently as it did before.
That doesn't really answer any of my questions, though.
ers as well, given that it
being guided by the mission statement is plainly stated on the GCC
homepage. But of course, it is also accountable to the people directly
involved.
I think the SC needs to clarify whether it gets to do whatever it
wants and change the mission of the project at will, for
On Thu, 10 Jun 2021 at 18:06, Martin Sebor wrote:
>
> On 6/10/21 9:56 AM, Jonathan Wakely wrote:
> > On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote:
> >>
> >> On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
> >>> On Thu, 10 Jun 2021 at 11:08, Jakub
On Thu, 10 Jun 2021 at 22:16, Martin Sebor wrote:
> I don't see why the script users should be subjected to this tedium
> when it can be done in the script itself with (presumably) only
> a little more effort. The proposed change is, IMO, a step in
> the wrong direction.
I don't see why "improve
On Fri, 11 Jun 2021 at 10:08, Jonathan Wakely wrote:
>
> On Thu, 10 Jun 2021 at 18:06, Martin Sebor wrote:
> > By "the subject line" are you referring to what the ChangeLog calls
> > $git_description, and, AFAICS, consists of multiple lines? (Based
> > on the Example patch on the conventions page
> I was wondering where can we send a patch to add binutils (latest )
> to that docker hub image
Those images are maintained by Docker Inc. and nothing to do with the
GCC project:
https://docs.docker.com/docker-hub/official_images/
"All Official Images contain a User Feedback secti
these situations, and I believe it said one
had to stream in those symbols from the .gnu.lto_.decl section.
However, on the GCC Internals there is also the following mention: "If
the DECL_INITIAL is the error_mark_node, there is an initializer, but
it is given by an explicit statement later in the
On Fri, Jun 11, 2021 at 12:07 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am looking for a small clarification. I understand that during late
> SIMPLE_IPA_PASSes some statically initialized global variables might
> have error_mark_node trees in their DECL_INITIAL field.
>
&g
On Fri, 11 Jun 2021 at 16:45, Joseph Myers wrote:
>
> On Fri, 11 Jun 2021, Jonathan Wakely via Gcc wrote:
>
> > If you're not already doing a brief "subject" line in your git
> > commits, you're Doing It Wrong!
>
> If you don't have a subject l
requiring the user to massage the ChangeLog by hand into
an unnecessarily rigid format.
Martin
PS I think I referred to mklog.py when I meant gcc-commit-mklog,
confusing the discussion and probably even myself. Sorry about
that. The mklog.py script is great. It helps us avoid some of
these mi
On Fri, Jun 11, 2021 at 11:02:52AM -0600, 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 t
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
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
le
roceed. 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
> On Jun 11, 2021, at 11:50 AM, Joseph Myers wrote:
>
> ...
>
> "make" at top level should build all the info manuals and man pages, as at
> present (if a suitable Sphinx version is installed), and "make install"
> should install them, in the same directories as at present.
>
> "make html"
On 6/11/21 9:37 PM, Markus Faehling wrote:
Hello,
I'm currently facing a problem where I cannot get both gcc and clang
warning-free simultaneously in my project. My code looks somewhat like
this:
class Test {
int a_;
void b() {};
};
This code gives me the(usually very u
On 6/11/21 3:37 PM, Markus Faehling wrote:
Hello,
I'm currently facing a problem where I cannot get both gcc and clang
warning-free simultaneously in my project. My code looks somewhat like
this:
class Test {
int a_;
void b() {};
};
This code gives me the(usually very u
On Fri, Jun 11, 2021 at 04:03:34PM -0400, Jason Merrill via Gcc wrote:
> You can use #pragma to disable a warning for a particular section of code:
>
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wattributes"
> class Test {
> [[maybe_un
Here's another #pragma solution to your problem:
class Test {
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wpragmas" // so GCC ignores next line
# pragma GCC diagnostic ignored "-Wunused-private-field"
int a_;
# pragma GCC diagnostic pop
void b
.debug_info section."
and a gcov file with 0 functions.
Does create_llvm_prof has the same limitation?
Eugene
-Original Message-
From: Wei Mi
Sent: Wednesday, May 26, 2021 7:52 PM
To: Eugene Rozenfeld
Cc: Andi Kleen ; Hongtao Yu ; Xinliang David
Li ; Jan Hubicka ; gcc@gcc.gnu.org
Hi, all.
Please CC me when I am mentioned into a mail.
On Thu, 2021-05-20 at 15:16 +0200, Richard Biener via Gcc wrote:
> On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote:
> >
> > On 5/20/21 2:54 PM, Richard Biener wrote:
> > > So why did you go from applying this pe
Sent from my MacBook Air
Hi all,
While moving the simple A CMP 0 ? A : -A patterns from
fold_cond_expr_with_comparison to match, I ran into an issue where
using cond directly in the patterns work while "for cnd (cond
vec_cond)" don't work.
It looks like in the first case we are able to correctly handle the
cond first ope
On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski wrote:
>
> Hi all,
> While moving the simple A CMP 0 ? A : -A patterns from
> fold_cond_expr_with_comparison to match, I ran into an issue where
> using cond directly in the patterns work while "for cnd (cond
> vec_cond)" don't work.
> It looks like
On Sat, Jun 12, 2021 at 5:21 PM Andrew Pinski wrote:
>
> On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski wrote:
> >
> > Hi all,
> > While moving the simple A CMP 0 ? A : -A patterns from
> > fold_cond_expr_with_comparison to match, I ran into an issue where
> > using cond directly in the patterns
On Fri, Jun 11, 2021 at 4:39 AM Jonathan Wakely wrote:
>
> > I was wondering where can we send a patch to add binutils (latest )
> > to that docker hub image
>
> Those images are maintained by Docker Inc. and nothing to do with the
> GCC project:
>
> http
On June 13, 2021 4:03:16 AM GMT+02:00, Andrew Pinski wrote:
>On Sat, Jun 12, 2021 at 5:21 PM Andrew Pinski
>wrote:
>>
>> On Sat, Jun 12, 2021 at 4:54 PM Andrew Pinski
>wrote:
>> >
>> > Hi all,
>> > While moving the simple A CMP 0 ? A : -A patterns from
>> > fold_cond_expr_with_comparison to ma
went through supergraph.cc <http://supergraph.cc/> and can see the splitting
happening in the constructor’s (supergraph::supergraph() ) at the end of first
pass.
>
> Or you could attack the problem from the other direction, by looking at
> what GCC generates for a vfunc call, and
ike GitHub ) ? or can I create a branch on remote
> also ?
At some point we want you to be able to push patches to trunk, so as a
step towards that I think it would be good for you to have a personal
branch on the gcc git repository.
A guide to getting access is here:
https://gcc.gnu.org/gitw
Show 0-based offsets for std::tuple members, to match with std::get.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): don't increment
self.count until after generating the result string.
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 13 +++
std::tuple elements are retrieved via std::get<> (template) not
[] (array); have the generated output string match this.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): Use <> not [].
---
The previous patch seems uncontroversial to me. I don't know about this
On Fri, Jun 11, 2021 at 4:03 PM Jason Merrill wrote:
> On 6/11/21 3:37 PM, Markus Faehling wrote:
> > Hello,
> >
> > I'm currently facing a problem where I cannot get both gcc and clang
> > warning-free simultaneously in my project. My code looks somewhat l
On 6/9/2021 5:48 AM, Aldy Hernandez wrote:
Hi Jeff. Hi folks.
What started as a foray into severing the old (forward) threader's
dependency on evrp, turned into a rewrite of the backwards threader
code. I'd like to discuss the possibility of replacing the current
backwards threader with
On Mon, Jun 14, 2021 at 12:02 AM Jeff Law via Gcc wrote:
>
>
>
> On 6/9/2021 5:48 AM, Aldy Hernandez wrote:
> > Hi Jeff. Hi folks.
> >
> > What started as a foray into severing the old (forward) threader's
> > dependency on evrp, turned into a rewrite
Hi John,
But they did offer some tentative support for my second suggestion of changing the meaning of bare
"netbsd" --- "netbsdaout" would still be available to unambiguously request
a.out for anyone that wants it.
I think that this would be OK for the binutils, providing that when configur
Patches need go to gcc-patches@ not gcc@ (and libstdc++ patches need
to be CC'd to libstdc++@ as well).
dnesday, May 26, 2021 7:52 PM
> To: Eugene Rozenfeld
> Cc: Andi Kleen ; Hongtao Yu ; Xinliang
> David Li ; Jan Hubicka ;
> gcc@gcc.gnu.org; Wenlei He
> Subject: Re: [EXTERNAL] Re: State of AutoFDO in GCC
>
> Thanks. Good to know the build works with newer protobuf.
>
> Wei.
&g
On 6/14/2021 12:40 AM, Richard Biener wrote:
I bet it's going to be tougher to remove DOM's threader. It knows how
to do thinks like resolve memory references using temporary equivalences
and such. But I bet it's enough to drop the VRP based threaders.
Yes. In fact I am wondering if addi
On 6/15/21 6:03 AM, Jeff Law wrote:
On 6/14/2021 12:40 AM, Richard Biener wrote:
I bet it's going to be tougher to remove DOM's threader. It knows how
to do thinks like resolve memory references using temporary equivalences
and such. But I bet it's enough to drop the VRP based threaders
💡
https://bit.ly/3xaa1Pc
Gabor Kerenyi
here a URL for your branch?
>>
>> no, currently it only local branch on my machine. Should I upload it on
>> a hosting site ( like GitHub ) ? or can I create a branch on remote
>> also ?
>
> At some point we want you to be able to push patches to trunk, so as a
>
On 6/14/2021 11:39 PM, Aldy Hernandez wrote:
On 6/15/21 6:03 AM, Jeff Law wrote:
On 6/14/2021 12:40 AM, Richard Biener wrote:
I bet it's going to be tougher to remove DOM's threader. It knows how
to do thinks like resolve memory references using temporary
equivalences
and such. But
hosting site ( like GitHub ) ? or can I create a branch on remote
> > > also ?
> >
> > At some point we want you to be able to push patches to trunk, so as
> > a
> > step towards that I think it would be good for you to have a personal
> > branch on the gcc gi
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&#
On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
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 Se
On Wed, 16 Jun 2021 at 03:03, Martin Sebor 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
On 6/15/21 9: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,
Hi all,
I recently did a search on a git log of gcc trunk looking for a particular
commit of mine, so was searching for my name, and I came across a commit
from Uroš that lists me as the Author. I did not author that commit and
talking with Uroš offline, he assures me that he didn't use --a
>Is there someone who an dig into the commit below
>and try to find out how the author field was incorrectly set?
That gets set when the local commit is done, before pushing it to the
server. I don't think there's any way to find out how/why that
happened after the fact.
You did author the commit
在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:
Is there someone who an dig into the commit below
and try to find out how the author field was incorrectly set?
That gets set when the local commit is done, before pushing it to the
server. I don't think there's any way to find out ho
On 6/13/21 11:48 AM, José Rui Faustino de Sousa via Gcc wrote:
Hi All!
While building I started to get this error:
../../gcc-master/gcc/opts.c: In function ‘void
print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned
int, gcc_options*, unsigned int)’:
../../gcc-master/gcc
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
..
On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>
> 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道:
> >> Is there someone who an dig into the commit below
> >> and try to find out how the author field was incorrectly set?
> >
> > That gets set when the local
On 6/16/21 1:32 PM, Uros Bizjak wrote:
> On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote:
>> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with
>> `git commit --amend`
>> (which changed the commit message but did not reset the author), then
>> rebased the modified commit
hat's
255 characters long the snprintf output will be truncated. This
warning is only issued at level 2 (-Wformat-truncation=2) which
points out more instances of possible truncation than the more
conservative level 1.
These are the flags I use to build gcc:
-O0 -g3 -ggdb3 -gdwarf-4 -fva
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,
Community,
The official glibc IRC channel is now on OFTC as #glibc.
gcc developers, please feel free to visit #glibc :-)
We also have an unofficial IRC channel #glibc on Libera.Chat
--
Cheers,
Carlos.
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:
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).
Aldy/Andrew, please update the MAINTAINERS file appropriately.
Thanks,
jeff
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:
> >>
> >&g
On 6/16/21 5:45 PM, Jason Merrill wrote:
On Wed, Jun 16, 2021 at 5:46 PM Martin Sebor <mailto:mse...@gmail.com>> 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
, 2021 at 10:04 PM Martin Sebor via Gcc
mailto:gcc@gcc.gnu.org>
>> <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote:
>>
>> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
>> > On Fri, 11 Jun 2021, Martin Sebor vi
errill wrote:
>> On Tue, Jun 15, 2021 at 10:04 PM Martin Sebor via Gcc
mailto:gcc@gcc.gnu.org>
>> <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote:
>>
>> On 6/15/21 6:56 PM, Hans-Peter Nilsson wrote:
>
ill 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>
>> <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote:
>>
>> On 6/15/21 6:56 PM, Hans-P
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 :).
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 <mailto:mse...@gmail.com>> wrote:
On 6/16/21 2:49 PM, Jason Merrill wrote:
> On 6/15/21 11:
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, b
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)") (
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
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: w
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 co
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
> &
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
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
>
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]
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
se 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.
t;> > 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.
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
b
>> >
> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf
> > > >> >
> > > >> > --
> > > >> > H.J.
> > > >>
> > &g
ake 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
t relocatables have the feature. If the
> >> > > >> > bit is 0 or the property is missing, the info is unknown.
> >> > > >> >
> >> > > >> > The PDF is at
> >> > > >> >
> >> > > >
output
> > > >> > > >> > pr_data field are zero, this property should be removed from
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, some input re
output
> > > >> > > >> > pr_data field are zero, this property should be removed from
> > > >> > > >> > output.
> > > >> > > >> >
> > > >> > > >> > If the bit is 1, some input re
On 17/06/2021 18:21, Jakub Jelinek wrote:
> 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 t
On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
> But with -p added, it becomes rather nice. For instance:
>
>git diff |./contrib/mklog.py -b foo/12394 -b 100123 -p
>
> nows prints:
>
> PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517
> PR fortran/100123 - -ftree-fr
hyphen space description
after the PR component/nn and it is also pitty we don't allow anymore
what used to be common in the gcc/cp ChangeLog for C++ papers.
That used to be either written after the PR, or without it:
PR c++/88337 - Implement P1327R1: Allow dynamic_cast in con
On Fri, 18 Jun 2021 at 12:26, Tobias Burnus wrote:
>
> On 18.06.21 13:10, Jonathan Wakely wrote:
>
> > On Fri, 18 Jun 2021 at 12:05, Tobias Burnus wrote:
> >> PR c++/12394 - internal compiler error: in write_type, at cp/mangle.c:1517
> >> PR fortran/100123 - -ftree-fre gives incorrect result in su
Hi,
I am having some trouble understanding the semantics of OBJ_TYPE_REF.
I understand that it is made of three operands:
1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use.
2. OBJ_TYPE_REF_OBJECT: Is the object on whose behalf the lookup is
being performed
3. OBJ_TYPE_REF_TOKEN:
On Fri, Jun 18, 2021 at 3:03 PM Erick Ochoa via Gcc wrote:
>
> Hi,
>
> I am having some trouble understanding the semantics of OBJ_TYPE_REF.
> I understand that it is made of three operands:
>
> 1. OBJ_TYPE_REF_EXPR: An expression that evaluates the value to use.
> 2. OBJ
On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
wrote:
> On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
> > On 17/06/2021 18:21, Jakub Jelinek wrote:
> >> mklog as is doesn't fill in the details (descriptions of the changes
> >> to each function etc.), nor is r
Add GNU_PROPERTY_1_NEEDED:
#define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
to indicate the needed properties by the object file.
Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:
#define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION (1U << 0)
to indicate that the object file
overed the option recently). I was
going to propose something similar to your solution:
https://gcc.gnu.org/pipermail/gcc/2021-June/236460.html
but I'm happy to let you run with it.
Thanks
Martin
In that sense, there would be a precedent in terms of actual usage.
--
Teach compute_ob
On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote:
On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
wrote:
On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
On 17/06/2021 18:21, Jakub Jelinek wrote:
mklog as is doesn't fill in the details (descriptions of the changes
to each function etc.)
> On 18 Jun 2021, at 17:47, Martin Sebor via Gcc wrote:
>
> On 6/18/21 8:41 AM, Jason Merrill via Gcc wrote:
>> On Fri, Jun 18, 2021 at 7:06 AM Tobias Burnus
>> wrote:
>>> On 18.06.21 11:32, Richard Earnshaw via Gcc wrote:
>>>> On 17/06/2021 18:
3901 - 4000 of 10345 matches
Mail list logo
