Hi Monk,
On Fri, Nov 15, 2024 at 06:53:09PM +0800, Monk Chiang wrote:
> gcc/ChangeLog:
> * gcc/config/riscv/riscv.cc
> (riscv_file_end_indicate_exec_stack): Add .note.gnu.property.
> * gcc/config/riscv/linux.h (TARGET_ASM_FILE_END): Define.
>
> [...]
> diff --git a/gcc/config/ri
Hi Jakub,
On Tue, 2025-01-07 at 20:22 +0100, Jakub Jelinek wrote:
> DWARF has voted in yesterday https://dwarfstd.org/issues/241209.1.html ,
> which is basically just a guarantee that the DWARF 6 draft
> DW_AT_language_{name,version} attribute codes and content of
> https://dwarfstd.org/languages-
commit 56946c801a7c ("gimple: Add limit after which slower switchlower
algs are used [PR117091] [PR117352]") introduced a limit on the number
of cases of a switch. It also bails out on finding jump tables if the
switch is too large. This introduces a compile time regression during
bootstrap. A risc
On Mon, Dec 09, 2024 at 11:24:39AM +0100, Mark Wielaard wrote:
> On Mon, 2024-12-02 at 11:16 +0100, Mark Wielaard wrote:
> > Adjust the DCO text to match the broader community usage and
> > clarifications around the use of real names, known identities and
> > (anonymous) pseud
Hi,
On Mon, 2024-12-02 at 11:16 +0100, Mark Wielaard wrote:
> Adjust the DCO text to match the broader community usage and
> clarifications around the use of real names, known identities and
> (anonymous) pseudonyms.
>
> These changes clarify what was meant by "real name
Hi Kito,
On Thu, Dec 05, 2024 at 03:12:03PM +0800, Kito Cheng wrote:
> function_shape::get_name is the funciton for building intrinsic function name,
> the result should not be changed by others once it built.
>
> So add const to the return type to make sure no one change that by
> accident.
Thi
Hi Jeff,
On Sun, 2024-12-01 at 08:56 -0700, Jeff Law wrote:
> commit 148e20466c2c246df9472efed0f2ae94cb65a0f8
> Author: Matevos Mehrabyan
> Date: Mon Nov 11 13:00:10 2024 -0700
>
> [PATCH v6 09/12] Add symbolic execution support.
>
> Gives an opportunity to execute the code on bit
Adjust the DCO text to match the broader community usage and
clarifications around the use of real names, known identities and
(anonymous) pseudonyms.
These changes clarify what was meant by "real name" and that it is not
required to be a "legal name" or any other stronger requirement than a
known
Hi Jason,
On Fri, Nov 22, 2024 at 05:13:30PM +0100, Jason Merrill wrote:
> My take has been that this change is not necessary for us because
> the FSF can accept copyright assignment for pseudonymous
> contributions, so individual reviewers don't need to adjudicate
> whether a particular pseudonym
Hi Carlos,
On Thu, Nov 21, 2024 at 02:26:39PM -0500, Carlos O'Donell wrote:
> On 11/21/24 1:47 PM, Sam James wrote:
> > Mark Wielaard writes:
> >> On Thu, 2024-11-21 at 12:04 -0500, Carlos O'Donell wrote:
> >>
> >> I suggest including the actual cla
Hi Carlos,
On Thu, 2024-11-21 at 12:04 -0500, Carlos O'Donell wrote:
> Adjust the DCO text to match the broader community usage including
> the Linux kernel use around "real names."
We made a similar change to switch from "real names" to "known
identifies" for elfutils a year ago:
https://sourcew
Hi Jakub,
On Thu, Nov 21, 2024 at 10:16:13AM +0100, Jakub Jelinek via Gdb wrote:
> From what I can read in gdb, it doesn't seem to care about exact standard
> revision, all it cares about is if the TU is C, C++, Fortran, Ada etc.
> So, from this POV perhaps we shouldn't switch at all and ignore al
Hi Antoni,
On Wed, Nov 20, 2024 at 11:11:01AM -0500, Antoni Boucher wrote:
> From what I understand, pull requests on forge.sourceware.org can be
> removed at any time, so I could lose track of the status of my
> patches.
It is an experiment, and the experiment could fail for various
reasons. At
Hi,
Random request...
On Tue, Nov 19, 2024 at 11:14:38AM -0500, David Malcolm wrote:
> > Here's the updated patch and answers below.
> >
> > (GitHub link if you find it easier for review:
> > https://github.com/antoyo/libgccjit/pull/5)
> >
> > Thanks.
>
> Thanks; I looked over the patch via t
Hi Sam,
On Mon, 2024-11-11 at 07:54 +, Sam James wrote:
> STAGE1_CFLAGS can be used to accelerate the just-built stage1 compiler
> which especially improves its performance on some of the large generated
> files during bootstrap. It defaults to nothing (i.e. -O0).
>
> The downside is that if
Hi all,
The gcc-patches list recently saw a couple of bounces of emails that
didn't pass dmarc policy (with p=reject) with spf and dkim failing.
All people who got unsubscribed because of this have been resubscribed
again.
To prevent getting email on the list that don't pass a strict dmarc
polic
These comment typos were found in the valgrind fork of libiberty
demangle code.
libiberty/ChangeLog:
* cplus-dem.c: Change preceeded to preceded.
include/ChangeLog:
* safe-ctype.h: Change accidently to accidentally.
---
include/safe-ctype.h | 2 +-
libiberty/cplus-dem.c | 2 +-
Hi Maciej,
On Sat, Oct 19, 2024 at 04:54:06PM +0100, Maciej W. Rozycki wrote:
> On Wed, 12 Jun 2024, Maciej W. Rozycki wrote:
>
> > > Hence we decided to check for it in CI instead.
> > >
> > > Hope the trade-off sounds reasonable
> >
> > I have reviewed the thread referred and I note that a c
Hi (adding Philippe to CC who knows a bit more about Valgrind vs Ada),
On Sat, Oct 05, 2024 at 06:07:27AM +0100, Sam James wrote:
> Jeff Law writes:
>
> > On 10/2/24 8:39 PM, Sam James wrote:
> >> Valgrind doesn't error out by default which means bootstrap issues like
> >> in PR116945 can easily
avr added an -mlra option, but the avr.opt.url file wasn't
regenerated.
Note that commit 149a23ee2568 ("AVR: -mlra is not documeted in TEXI.")
did add the Undocumented flag, but that still needs the avr.op.urls
file to be updated.
Fixes: 09a87ea666b2 ("AVR: ad target/113934 - Add option -mlra to
The testcase uses -march=rv64gcv and dg-do run, so should be
restricted to a riscv_v target.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116202-run-1.c (dg-do run):
Add target riscv_v.
---
gcc/testsuite/gcc.target/riscv/rvv/base/pr116202-run-1.c | 2 +-
1 file changed,
Hi,
On Fri, Aug 09, 2024 at 08:15:31PM -0700, Andrew Pinski wrote:
> I had been wondering the same until I looked into it earlier today.
> Linaro CI's does `--disable-bootstrap` and there was no extra
> testsuite failures with the patch.
> So Linaro CI's is not catching all the bugs that a develop
Hi,
On Thu, Aug 08, 2024 at 02:07:50PM -0700, Andrew Pinski wrote:
> On Fri, Aug 2, 2024 at 7:30 AM Jeff Law wrote:
> > > 2024-08-01 Surya Kumari Jangala
> > >
> > > gcc/
> > > PR rtl-optimization/PR116028
> > > * lra-constraints.cc (split_reg): Spill register before call
> > >
Hi,
On Wed, 2024-07-17 at 13:55 +0200, Mark Wielaard wrote:
> On Sun, 2024-07-14 at 15:31 +0200, Alejandro Colomar wrote:
> > On Sun, Jul 14, 2024 at 01:37:02PM GMT, Jonathan Wakely wrote:
> > > On Sun, 14 Jul 2024, 12:30 Alejandro Colomar via Gcc-help, <
> > &g
Hi Maciej (Hi David, added to CC),
On Mon, 2024-05-27 at 05:19 +0100, Maciej W. Rozycki wrote:
> As reported in PR target/79646 and fixed by a change proposed by Abe we
> have a couple of issues with the descriptions of the VAX floating-point
> format options in the option definition file. Add
Hi,
On Mon, 2024-05-20 at 12:37 -0400, David Malcolm wrote:
> On Mon, 2024-05-20 at 16:19 +, Jiang, Haochen wrote:
> > Thanks for your help! I haven't noticed this file is newly added to
> > GCC.
> > I suppose that is why the buildbot is reporting something the whole
> > afternoon for me.
> >
risc-v added an -mfence-tso option. i386 removed Xeon Phi ISA support
options. But the opt.urls files weren't regenerated.
Fixes: a6114c2a6911 ("RISC-V: Implement -m{,no}fence-tso")
Fixes: e1a7e2c54d52 ("i386: Remove Xeon Phi ISA support")
gcc/ChangeLog:
* config/riscv/riscv.opt.urls: Re
Hi Evgeny,
Adding David to the CC, who might know the details.
On Mon, May 13, 2024 at 08:44:12AM +, Evgeny Karpov wrote:
> Sunday, May 12, 2024
>
> Thank you for reviewing our changes related to the refactoring of
> extracting the MinGW implementation from ix64.
>
> It was expected to move t
The new cygming.opt.urls and mingw.opt.urls in the
gcc/config/mingw/cygming.opt.urls directory need to generated by make
regenerate-opt-urls in the gcc subdirectory. They still contained
references to the gcc/config/i386 directory from which they were
copied.
Fixes: 1f05dfc131c7 ("Reuse MinGW from
Fixes: df7bfdb7dbf2 ("c++: reference cast, conversion fn [PR113141]")
A new warning option -Wcast-user-defined was added to c.opt and
documented in doc/invoke.texi. But c.opt.urls wasn't regenerate.
gcc/c-family/ChangeLog:
* c.opt.urls: Regenerate.
---
gcc/c-family/c.opt.urls | 3 +++
1
The new support for gcov modified condition/decision coverage
introduced two new flags for gcc, -Wcoverage-too-many-conditions and
-fcondition-coverage. But didn't regenerate the gcc/common.opt.urls.
Fixes: 08a52331803f ("Add condition coverage (MC/DC)")
gcc/ChangeLog:
* common.opt.urls:
LoongArch added an -mtls-dialect option, causing the similarly
named option for i386 get renumbered.
Fixes: b253b4695dda ("LoongArch: Add support for TLS descriptors.")
gcc/ChangeLog:
* config/i386/i386.opt.urls: Regenerate.
---
Pushed as obvious.
gcc/config/i386/i386.opt.urls | 2 +-
Hi,
On Mon, Apr 01, 2024 at 11:08:08AM +0800, Lulu Cheng wrote:
> Fixes: d28ea8e5a704 ("LoongArch: Split loongarch_option_override_internal
> into smaller procedures")
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch.opt.urls: Regenerate.
This looks OK to me. I cann
Hi YunQiang Su,
On Fri, Mar 15, 2024 at 03:33:28PM +0800, YunQiang Su wrote:
> Great work. The CI works well now: it blames me ;)
> https://builder.sourceware.org/buildbot/#/builders/269/builds/3846
>
> When I add '-mstrict-align' option to MIPS,
> the riscv.opt.urls, sysv4.opt.urls, xtensa.opt.u
On Tue, Mar 05, 2024 at 08:34:31AM -0500, David Malcolm wrote:
> > I committed that patch, but was not fast enough actually enabling the
> > buildbot and missed another fixlet needed first.
> >
> > OK, to push the attached regeneration patch?
>
> Yes
Thanks, pushed. And now also pushed the build
tted that patch, but was not fast enough actually enabling the
buildbot and missed another fixlet needed first.
OK, to push the attached regeneration patch?
Thanks,
Mark
From e5c2b9983d7c09e5a21fa587dc9cd03d53d67a23 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Tue, 5 Mar 2024 13:01:
Hi,
On Sat, Feb 24, 2024 at 06:42:58PM +0100, Mark Wielaard wrote:
> On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote:
> > Mark Wielaard 于2024年2月19日周一 06:58写道：
> > > So, I did try the regenerate-opt-urls locally, and it did generate the
> > > attached d
It is fine for robots to crawl the wiki pages, but they should perform
actions, generate huge diffs, search/highlight pages or generate
calendars.
---
htdocs/robots.txt | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index 057c5899..36be4d13 100644
---
Hi,
On Thu, Feb 22, 2024 at 11:57:50AM +0800, YunQiang Su wrote:
> Mark Wielaard 于2024年2月19日周一 06:58写道：
> > So, I did try the regenerate-opt-urls locally, and it did generate the
> > attached diff. Which seems to show we really need this automated.
> >
> > Going ov
On Sun, 2024-02-18 at 23:58 +0100, Mark Wielaard wrote:
> So I think the regenerate-opt-urls check does work as intended. So
> lets automate it, because it looks like nobody regenerated the
> url.opts after updating the documentation.
>
> But we should first apply this diff. C
Hi David,
On Thu, Jan 04, 2024 at 09:57:09AM -0500, David Malcolm wrote:
> I've pushed the .opt.urls patch kit to gcc trunk [1], so hopefully the
> CI check you wrote can go live now.
And then I was on vacation myself and forgot. I am sorry.
So, I did try the regenerate-opt-urls locally, and it
commit a945c346f57ba40fc80c14ac59be0d43624e559d updated
libgomp/plugin/configfrag.ac but didn't regenerate/update
libgomp/configure which includes that configfrag.
libgomp/Changelog:
* configure: Regenerate.
---
libgomp/configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
Some spiders are hitting bugzilla hard generating dependency trees
or graphs, downloading large attachements or requesting all bugs
in xml format. Disallow all that.
---
htdocs/robots.txt | 4
1 file changed, 4 insertions(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index b9fc830d..
d to master it does flag and generate
the attached diff (I assume that is expected).
Cheers,
Mark>From 83914698dfb77a85496e93e3faa5de9131347cb8 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Fri, 15 Dec 2023 01:43:27 +0100
Subject: [PATCH] Add regenerate-opt-urls to gcc-autoregen
Add gcc buil
Hi David,
On Fri, Dec 08, 2023 at 06:35:56PM -0500, David Malcolm wrote:
> On Tue, 2023-11-21 at 23:43 +, Joseph Myers wrote:
> > On Tue, 21 Nov 2023, Tobias Burnus wrote:
> >
> > > On 21.11.23 14:57, David Malcolm wrote:
> > > > On Tue, 2023-11-21 at 02:09 +0100, Hans-Peter Nilsson wrote:
>
Although cgit is more efficient than gitweb it still is not great
for bots to go through it.
---
htdocs/robots.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/htdocs/robots.txt b/htdocs/robots.txt
index c650057b..b9fc830d 100644
--- a/htdocs/robots.txt
+++ b/htdocs/robots.txt
@@ -6,6 +6,7
There is a new buildbot check that all autotool files are generated
with the correct versions (automake 1.15.1 and autoconf 2.69).
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
Correct one file that was generated with the wrong version.
libiberty/
* aclocal.m4: Rebuild.
Hi Gerald,
On Wed, Oct 04, 2023 at 12:17:48AM +0200, Gerald Pfeifer wrote:
> On Tue, 19 Sep 2023, Mark Wielaard wrote:
> >> Although there were some positive responses (on list and on irc) it is
> >> sometimes hard to know if there really is consensus for these kind of
>
Hi,
On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are
Hi all,
On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> >
> > - subject_prefix (genera
Hi all,
On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> Adding Jeff to CC who is the official gcc-patches mailinglist admin.
> [...]
> Yes, it is expected for emails that come from domains with a dmarc
> policy. That is because the current settings of the
Hi Richard,
On Thu, Sep 14, 2023 at 11:07:21AM +0200, Richard Biener wrote:
> On Tue, Sep 12, 2023 at 5:00 PM Mark Wielaard wrote:
> > The only visible change (apart from no more From rewriting) is that
> > HTML multi-parts aren't scrubbed anymore (that would be a messag
Hi Thomas,
On Thu, Sep 14, 2023 at 09:00:39AM +0200, Thomas Schwinge wrote:
> >> Let me know if you want Jeff (or me or one of the other overseers) make
> >> the above changes to the gcc-patches mailman settings.
> >
> > yes, please!
>
> Yes, please! For all mailing lists, globally.
Call me a l
Hi Maxim,
Adding Jeff to CC who is the official gcc-patches mailinglist admin.
On Tue, 2023-09-12 at 11:08 +0400, Maxim Kuvyrkov wrote:
> Normally, notifications from Linaro TCWG precommit CI are sent only to
> patch author and patch submitter. In this case the sender was rewritten
> to "Benjami
Hi all,
On Tue, 2023-06-20 at 07:11 -0600, Jeff Law wrote:
> On 6/20/23 04:56, Robin Dapp wrote:
> > > Could you merge it ?
> > > By the way, could Lehua get the write access?
> >
> > IMHO nothing stands in the way but I'll defer to Jeff to have
> > the "official seal" :)
> > Once he ACKs Lehua n
On Wed, 2023-03-29 at 15:40 -0700, Andrew Pinski wrote:
> On Wed, Mar 29, 2023 at 3:08 PM Gerald Pfeifer wrote:
> >
> > Business as usual - 301 Moved Permanently.
>
> Just FYI, dwarfstd is now hosted by sourceware too. So I doubt these
> URLs will change after this.
Indeed, see
https://inbox.so
Hi John,
On Tue, Dec 06, 2022 at 12:57:17PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/6/22 12:40, Arthur Cohen wrote:
> > > Can't wait to see this becoming available in the distributions :D.
> > >
> > > I will make sure we get the frontend enabled in Debian as soon as
> > > possible.
> >
Hi Christophe,
On Mon, Nov 21, 2022 at 01:35:34PM +0100, Christophe Lyon wrote:
> On 11/21/22 13:32, Mark Wielaard wrote:
> > > I've just sent a fix:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606887.html
> > >
> > > Hopefully that o
Hi Christophe,
On Mon, 2022-11-21 at 13:12 +0100, Christophe Lyon wrote:
> On 11/21/22 11:16, Mark Wielaard wrote:
> > On Fri, Nov 18, 2022 at 12:42:10PM -0700, Jeff Law wrote:
> > > > * genmultilib: Add sanity check.
> > >
> > > OK. It s
Hi,
On Fri, Nov 18, 2022 at 12:42:10PM -0700, Jeff Law wrote:
> > * genmultilib: Add sanity check.
>
> OK. It should be interesting to see if it trips.
It trips up various buildbot setups:
https://builder.sourceware.org/buildbot/#/changes/13720
Error calling ../../gcc/gcc/genmultilib: Numb
Hi,
On Wed, Nov 09, 2022 at 08:49:22AM +0100, Richard Biener via Gcc wrote:
> On Wed, Nov 9, 2022 at 1:09 AM Sam James via Gcc-patches
> wrote:
> > > On 9 Nov 2022, at 00:00, Joseph Myers wrote:
> > > On Tue, 8 Nov 2022, Sam James via Gcc wrote:
> >
> > If that's your expectation, that's fine, b
r/mjw/gccrs/commit/?h=no-Rust-old
if someone wants to push that, to merge for a v4.
Thanks,
Mark>From cdcfe27cfba23402f91200c64c1ef8e0bf3528a0 Mon Sep 17 00:00:00 2001
From: Mark Wielaard
Date: Sun, 30 Oct 2022 16:03:16 +0100
Subject: [PATCH] dwarf2out.c: Don't emit DW_LANG_Rust_ol
Hi Martin,
On Thu, 2022-08-25 at 11:52 +0200, Martin Liška wrote:
> What about limit increase, how much space do we have on sourceware
> infrastructure?
Feel free to increase the limits, there is a couple of hundred GB free
on sourceware and we can add more.
The public-inbox instance at inbox.so
Ping. Is this OK to commit now?
I am not sure who can approve this.
On Sun, Jan 16, 2022 at 01:35:34AM +0100, Mark Wielaard wrote:
> Rust symbols can have a .suffix because of compiler transformations.
> These can be ignored in the demangled name. Which is what this patch
> imple
Hi,
On Mon, Jan 24, 2022 at 08:34:39PM +0100, Jakub Jelinek wrote:
> The following patch uses DW_ATE_GNU_{,complex_}float128 (new extensions
> equal to corresponding HP extensions) instead of DW_ATE_float,
> another possibility would be DW_ATE_GNU_precision attribute on the
> DW_TAG_base_type that
Rust symbols can have a .suffix because of compiler transformations.
These can be ignored in the demangled name. Which is what this patch
implements. By stopping at the first dot for v0 symbols and searching
backwards to the ending 'E' for legacy symbols.
An alternative implementation could be to
Hi Eddy,
On Mon, Dec 20, 2021 at 01:50:52PM +0200, Eduard-Mihai Burtescu wrote:
> Apologies for the delay, the email fell through the cracks somehow.
And then I went on vacation... Sorry this fairly simple patch takes so
long.
> The updated patch looks like it would work alright, only needs a co
Hi Eddy,
On Fri, 2021-12-03 at 01:14 +0200, Eduard-Mihai Burtescu wrote:
> On Fri, Dec 3, 2021, at 00:07, Mark Wielaard wrote:
> > On Thu, Dec 02, 2021 at 07:35:17PM +0200, Eduard-Mihai Burtescu
> > wrote:
> > > That also means that for consistency, suffixes li
Hi,
On Fri, Dec 03, 2021 at 06:58:36AM +1100, Nicholas Nethercote wrote:
> On Fri, 3 Dec 2021 at 04:17, Mark Wielaard wrote:
> >
> > * rust-demangle.c (rust_demangle_callback): Ignore everything
> > after '.' char in sym for v0.
> >
>
&g
Hi Eddy,
On Thu, Dec 02, 2021 at 07:35:17PM +0200, Eduard-Mihai Burtescu wrote:
> On Thu, Dec 2, 2021, at 19:17, Mark Wielaard wrote:
> > Rust v0 symbols can have a .suffix because if compiler transformations.
>
> For some context, the suffix comes from LLVM (I believe as part of
Rust v0 symbols can have a .suffix because if compiler transformations.
These can be ignored it the demangled name. Which is what this patch
implements). But an alternative implementation could be to follow what
C++ does and represent these as [clone .suffix] tagged onto the
demangled name. But thi
On Fri, 2021-02-19 at 18:04 +0100, Mark Wielaard wrote:
> * gcc-11/changes.html (General Improvements): Add a section on
> the DWARF version 5 default.
Ping. OK to commit?
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 6a47b0b8..9734eee8 10
* gcc-11/changes.html (General Improvements): Add a section on
the DWARF version 5 default.
---
htdocs/gcc-11/changes.html | 30 ++
1 file changed, 30 insertions(+)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index de75b8d6..04c
Hi Paul,
On Fri, Jan 29, 2021 at 02:04:02PM -0600, Paul A. Clarke wrote:
> On Fri, Jan 29, 2021 at 12:22:41PM +0100, Mark Wielaard wrote:
> > The infinite loop is because off isn't updated to noff before calling
> > continue in the while loop. Moving the last line of the loo
Hi Paul,
On Thu, Jan 28, 2021 at 08:25:20PM -0600, Paul A. Clarke wrote:
> The subject commit, 3804e937b0e252a7e42632fe6d9f898f1851a49c, causes a
> failure in the test suite for the IBM Advance Toolchain. The test in
> question uses "perf probe" to set a tracepoint at "main" in a newly built
> (w
Hi David,
On Mon, 2021-01-18 at 11:31 -0500, David Edelsohn wrote:
> On Mon, Jan 18, 2021 at 6:01 AM Mark Wielaard wrote:
> > Thanks, I hadn't tested against AIX. Could you also update
> > gcc/doc/invoke.texi (-gdwarf) with the defaults for AIX?
>
> Other targets
> On 15/01/2021 17:16, Jakub Jelinek via Gcc-patches wrote:
> > On Sun, Nov 15, 2020 at 11:41:24PM +0100, Mark Wielaard wrote:
> >> From: Mark Wielaard
> >> Date: Tue, 29 Sep 2020 15:52:44 +0200
> >> Subject: [PATCH] Default to DWARF5
> >>
> >
Hi,
On Sun, Jan 17, 2021 at 11:30:59AM -0800, sunil.k.pandey wrote:
> On Linux/x86_64,
>
> 3804e937b0e252a7e42632fe6d9f898f1851a49c is the first bad commit
> commit 3804e937b0e252a7e42632fe6d9f898f1851a49c
> Author: Mark Wielaard
> Date: Tue Sep 29 15:52:44 2020 +0200
&
Hi David,
On Sun, Jan 17, 2021 at 06:12:06PM -0500, David Edelsohn wrote:
> GCC now defaults to DWARF 5. AIX only supports DWARF 4 (3.5).
>
> This patch overrides the default DWARF version to 4 unless explicitly
> stated.
>
> gcc/ChangeLog:
>
> * config/rs6000/aix71
On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > &
Hi,
On Tue, 2020-10-06 at 16:57 -0400, Jason Merrill wrote:
> All three of these patches (Jakub's, and your two) look good to me,
> except that your add_filepath_AT_string patch is missing comments on
> some of the new functions.
I added documentation for the two new functions missing comments
Hi,
On Fri, 2020-09-18 at 17:21 +0200, Mark Wielaard wrote:
> On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> > Ok, here it is in patch form.
> > I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> > support), with latest gas (--gdwa
On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -9057,13 +9057,14 @@ possible.
> > @opindex gdwarf
> > Produce debuggin
Hi,
On Mon, 2020-08-24 at 19:38 +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:54PM +0200, Mark Wielaard wrote:
> > DWARF5 makes it possible to read loclists tables without consulting
> > the debuginfo tree by introducing a table header. Adding location
> > view
This adds a get_DW_UT_name function to dwarfnames using dwarf2.def
for use in binutils readelf to show the unit types in a DWARF5 header.
Also remove DW_CIE_VERSION which was already removed in binutils/gdb
and is not used in gcc.
include/ChangeLog:
* dwarf2.def: Add DWARF5 Unit type hea
we can more generally emit DW_FORM_line_str for
filepaths in CU DIEs for the name and comp_dir attribute. There
currently is a bit of a hack to do this in dwarf2out_early_finish, but
that only works when the assembler doesn't emit a DWARF5 .debug_line,
but gcc does it itself.
What do you thi
On Mon, 2020-08-24 at 22:26 +0200, Mark Wielaard wrote:
> On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> > On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > > Some DWARF tests scan the assembly output looking for constant values.
> > &
Hi,
On Tue, 2020-09-15 at 20:40 +0200, Jakub Jelinek wrote:
> Ok, here it is in patch form.
> I've briefly tested it, with the older binutils I have around (no --gdwarf-N
> support), with latest gas (--gdwarf-N that can be passed to as even when
> compiling C/C++ etc. code and emitting .debug_line
Hi,
I added some fixes to binutils gas to make sure that it always
generates DWARF5 style .debug_rnglists and .debug_line with
.debug_line_str which are more efficient than the older .debug_ranges
and .debug_line data.
There is also a pending patch to make it possible to always pass
--gdwarf-N to
eLog
index d34c08e924c..70d09729443 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,17 @@
+2020-09-07 Mark Wielaard
+
+ * as.texi (-g): Explicitly mention when .debug_info and .debug_line
+ are generated for the DWARF format.
+ (Loc): Add that it is an error to both
H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 9:33 AM Mark Wielaard wrote:
>> Hi,
>>
>> On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
>>> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard wrote:
>>>> My proposal, and what my strawman patch im
Hi,
On Sat, Aug 29, 2020 at 08:43:30AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 8:23 AM Mark Wielaard wrote:
> > My proposal, and what my strawman patch implements, is that gas will
> > generate a .debug_line section when -g is given and the debug types is
> > DWARF
Hi,
On Sat, Aug 29, 2020 at 07:34:35AM -0700, H.J. Lu wrote:
> On Sat, Aug 29, 2020 at 5:24 AM Mark Wielaard wrote:
> > On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> > > On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard wrote:
> > > > Would it be possi
Hi,
On Wed, Aug 26, 2020 at 04:38:21PM -0700, H.J. Lu wrote:
> On Wed, Aug 26, 2020 at 2:38 PM Mark Wielaard wrote:
> > Would it be possible to have something like the following in gas, so
> > that it doesn't try generating a .debug_line section if there already
> > i
|| (!emit_other_sections && !empty_debug_line))
On Mon, Aug 24, 2020 at 02:56:58PM +0200, Mark Wielaard wrote:
> This is needed to get DWARF version 5 .debug_line tables.
> It is also obviously wrong. It needs a check for whether as supports
> --gdwarf- for all versions we su
Hi,
On Mon, 2020-08-24 at 14:56 +0200, Mark Wielaard wrote:
> This afternoon there will be a BoF at the virtual Cauldron about
> DWARF5 and beyond.
> https://linuxplumbersconf.org/event/7/contributions/746/
>
> Here are some patches for GCC that I would like to discuss.
>
Hi Alex,
On Tue, 2020-08-25 at 01:05 -0300, Alexandre Oliva wrote:
> it would seem to
> make more sense to adopt and promote the proposed extension,
> implemented in =incompat5 in GCC, but it would need some
> implementation work in consumers to at least ignore the extension.
Is that what is desc
Hi,
On Mon, 2020-08-24 at 17:38 -0400, Jason Merrill wrote:
> > This looks incorrect to me, that is a workaround for a real GCC bug.
> >
> > Shouldn't we instead do something like (untested) following patch?
> > I mean, for DWARF < 5 the static data members were using DW_TAG_member,
> > which has
On Mon, Aug 24, 2020 at 07:44:27PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:56PM +0200, Mark Wielaard wrote:
> > Some DWARF tests scan the assembly output looking for constant values.
> > When using DWARF5 those constants might use DW_FORM_implicit_const,
>
Hi Jakub,
On Mon, Aug 24, 2020 at 07:40:51PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 24, 2020 at 02:56:55PM +0200, Mark Wielaard wrote:
> > In DWARF5 class variables (static data members) are represented with a
> > DW_TAG_variable instead of a DW_TAG_member. Make sure the
1 - 100 of 333 matches
Mail list logo
