On Thu, Sep 11, 2025 at 07:14:51PM +0200, Richard Biener wrote:
> Yes, RTL expansion inserts an AND operation when !SHIFT_COUNT_TRUNCATED.
> What I was saying there's no way to get a negative shift count flip shift
> direction to RTL - it would require a target specific intrinsic that's a
> builti
On Thu, Sep 11, 2025 at 11:14 AM Jakub Jelinek wrote:
>
> On Thu, Sep 11, 2025 at 11:02:26AM +0200, Richard Biener via Gcc wrote:
> > > Does the doc need clarification on the semantics of RTL shift
> > > operations when the shift amount is out of range?
> >
> > The SHIFT_COUNT_TRUNCATED target mac
On Wed, 10 Sept 2025, 07:23 Florian Weimer via Gcc, wrote:
> * Chris Packham via Gcc:
>
> > Is there any attribute I can set on the memset like functions that will
> let
> > gcc know to perform the same kinds of checks as the standard memset
> > function?
>
> There's the “access” function attribu
* Chris Packham via Gcc:
> Is there any attribute I can set on the memset like functions that will let
> gcc know to perform the same kinds of checks as the standard memset
> function?
There's the “access” function attribute. It covers at least some
aspects.
Thanks,
Florian
On Mon, Sep 8, 2025 at 12:47 AM Chris Packham via Gcc wrote:
>
> Hi GCC,
>
> For various reasons I find myself working with a few code bases that define
> their own wrappers for memset(). Unfortunately these wrappers defeat gccs
> ability to detect when the size of the pointer is passed instead of
On Wed, Sep 10, 2025 at 1:16 PM NightStrike wrote:
>
>
>
> On Mon, Sep 8, 2025, 03:47 Chris Packham via Gcc wrote:
>>
>> Hi GCC,
>>
>> For various reasons I find myself working with a few code bases that define
>> their own wrappers for memset(). Unfortunately these wrappers defeat gccs
>> abilit
On Mon, Sep 8, 2025, 03:47 Chris Packham via Gcc wrote:
> Hi GCC,
>
> For various reasons I find myself working with a few code bases that define
> their own wrappers for memset(). Unfortunately these wrappers defeat gccs
> ability to detect when the size of the pointer is passed instead of the
>
Hi Jakub, Jonathan,
On Tue, Sep 09, 2025 at 10:01:13PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 09, 2025 at 08:59:21PM +0100, Jonathan Wakely via Gcc wrote:
> > On Tue, 9 Sept 2025 at 20:53, Alejandro Colomar via Gcc
> > wrote:
> > >
> > > Hi!
> > >
> > > I'm trying to test some patch I've writ
On Tue, Sep 09, 2025 at 08:59:21PM +0100, Jonathan Wakely via Gcc wrote:
> On Tue, 9 Sept 2025 at 20:53, Alejandro Colomar via Gcc
> wrote:
> >
> > Hi!
> >
> > I'm trying to test some patch I've written, and found some build error
> > that seems entirely unrelated to my patch. git-blame(1) point
On Tue, 9 Sept 2025 at 20:53, Alejandro Colomar via Gcc wrote:
>
> Hi!
>
> I'm trying to test some patch I've written, and found some build error
> that seems entirely unrelated to my patch. git-blame(1) points to:
>
> 52d754a1a620 (2025-09-09; "Fortran: make STAT/LSTAT/FSTAT intrinsics
On 9/9/25 02:56, Jonathan Wakely wrote:
I was going to correct the fact that this list of options enabled by
-Wextra doesn't mention that -Wunterminated-string-initialization is
only valid for C and ObjC:
@gccoptlist{-Wabsolute-value @r{(only for C/ObjC)}
-Walloc-size
-Wcalloc-transposed-args
-W
Hi Rainer,
On Mon, Sep 08, 2025 at 09:37:40PM +0200, Rainer Orth via Gcc wrote:
> I've just tried to file a PR, but each time on submission I only get
>
> First, you must pick a product on which to enter a bug:
>
> and all my input is lost. I've triple-checked that I *had* selected the
>
On 9/3/25 8:40 PM, Qing Zhao wrote:
I have one question (might be a stupid question):
Should we consider a call to C++’s constructor as the initialization to that
variable?
For example:
S::S (&s);
Should we consider the above as an initialization to the variable s?
then -ftrivial-auto-var-i
On 30/08/25 20:02, Andrew Pinski wrote:
> To begin with it will be on mastodon:
> https://hachyderm.io/@gnutoolsweekly
>
> But I might move it over to more blog like site instead of a social
> media. Though was thinking about hosting on the wiki. I still have not
> decided.
>
> I started a few
On Thu, Sep 4, 2025 at 6:32 AM Adhemerval Zanella Netto
wrote:
>
>
>
> On 30/08/25 20:02, Andrew Pinski wrote:
> > To begin with it will be on mastodon:
> > https://hachyderm.io/@gnutoolsweekly
> >
> > But I might move it over to more blog like site instead of a social
> > media. Though was thinki
On Wed, Sep 03, 2025 at 03:38:53PM +0200, Jakub Jelinek via Gcc wrote:
> But there is one thing the paper doesn't care about, which looks like a show
> stopper to me, in particular the stuff -Wtrivial-auto-var-init warning warns
> about. Consider:
I've filed https://github.com/cplusplus/CWG/issue
Week 1 (August 31, 2025)
* Today is the last day to submit proposals and last day to
register to GNU Tools Cauldron 2025 *
GCC update:
Mailing list update:
* discussion about `Providing more precise "excess errors" message in DejaGnu`
https://inbox.sourceware.org/gcc/6e61550e-1ce3-48cf
On Wed, Sep 3, 2025 at 3:24 PM Mark Wielaard wrote:
>
> Hi Andrew,
>
> On Sat, Aug 30, 2025 at 04:02:42PM -0700, Andrew Pinski via Gdb wrote:
> > To begin with it will be on mastodon:
> > https://hachyderm.io/@gnutoolsweekly
> >
> > But I might move it over to more blog like site instead of a soci
Hi Andrew,
On Sat, Aug 30, 2025 at 04:02:42PM -0700, Andrew Pinski via Gdb wrote:
> To begin with it will be on mastodon:
> https://hachyderm.io/@gnutoolsweekly
>
> But I might move it over to more blog like site instead of a social
> media. Though was thinking about hosting on the wiki. I still
On Wed, 2025-09-03 at 18:54 +0200, Basile Starynkevitch wrote:
> Hello
>
> Is there any open source GCC plugin extracting the call graph information?
>
> https://fse.studenttheses.ub.rug.nl/9153/1/hoogendorp10.pdf is relevant (but
> I don't know if there is an open source tool usable on Linux)
> On Sep 3, 2025, at 12:32, Jakub Jelinek wrote:
>
> On Wed, Sep 03, 2025 at 03:23:39PM +, Qing Zhao wrote:
>>
>>
>>> On Sep 3, 2025, at 09:38, Jakub Jelinek wrote:
>>>
>>> On Tue, Sep 02, 2025 at 09:35:04PM +, Qing Zhao wrote:
> I think I've mentioned it earlier, but -ftrivial-
On Wed, Sep 03, 2025 at 03:23:39PM +, Qing Zhao wrote:
>
>
> > On Sep 3, 2025, at 09:38, Jakub Jelinek wrote:
> >
> > On Tue, Sep 02, 2025 at 09:35:04PM +, Qing Zhao wrote:
> >>> I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
> >>> work at all for C++.
> >> You
> On Sep 3, 2025, at 09:38, Jakub Jelinek wrote:
>
> On Tue, Sep 02, 2025 at 09:35:04PM +, Qing Zhao wrote:
>>> I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
>>> work at all for C++.
>> You mean that -ftrivial-auto-var-init hasn’t work at all for C++’s auto
>> var
On Tue, Sep 02, 2025 at 09:35:04PM +, Qing Zhao wrote:
> > I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
> > work at all for C++.
> You mean that -ftrivial-auto-var-init hasn’t work at all for C++’s auto
> variables with non-trivial ctors?
Yeah. Actually, it probab
> On 3 Jul 2025, at 11:31, Kyrylo Tkachov via Gcc wrote:
>
>
>
>> On 3 Jul 2025, at 05:35, David Edelsohn via Gcc wrote:
>>
>> I am pleased to announce that the GCC Steering Committee has appointed
>> Tamar Christina as AArch64 maintainer. I am pleased to announce that the
>> GCC Steering
On Tue, 2 Sept 2025 at 10:47, Andre Vehreschild via Gcc wrote:
>
> Er, well, I missed to tell what I did to the branch:
>
> - rebased to current master,
> - reverted a squashed commit, and
> - applied 8 separate commits.
>
> So nothing spectacular. Nothing I would expect anything to chew on for so
On Tue, 2 Sept 2025 at 11:00, Jonathan Wakely wrote:
>
> On Tue, 2 Sept 2025 at 10:47, Andre Vehreschild via Gcc
> wrote:
> >
> > Er, well, I missed to tell what I did to the branch:
> >
> > - rebased to current master,
> > - reverted a squashed commit, and
> > - applied 8 separate commits.
> >
On Tue, Sep 2, 2025 at 11:01 AM Rainer Orth via Gcc wrote:
>
> I'm currently trying to push to the repo for an hour, but only get
>
> remote: -
> remote: -- Another user is currently pushing changes to this repository. --
> remo
On Tue, Sep 02, 2025 at 11:39:18AM +0200, Andre Vehreschild wrote:
> Hi Jakub,
>
> I am pushing to gfortran-test. The process seems to be finished, but is not
> returning (sorry it's in German):
>
> Objekte aufzählen: 11679, fertig.
> Zähle Objekte: 100% (11679/11679), fertig.
> Delta-Kompression
Er, well, I missed to tell what I did to the branch:
- rebased to current master,
- reverted a squashed commit, and
- applied 8 separate commits.
So nothing spectacular. Nothing I would expect anything to chew on for so long.
- Andre
On Tue, 2 Sep 2025 11:39:18 +0200
Andre Vehreschild wrote:
On Tue, 2 Sep 2025 11:00:41 +0100
Jonathan Wakely wrote:
> On Tue, 2 Sept 2025 at 10:47, Andre Vehreschild via Gcc
> wrote:
> >
> > Er, well, I missed to tell what I did to the branch:
> >
> > - rebased to current master,
> > - reverted a squashed commit, and
> > - applied 8 separate commits.
>
Ok, terminated here.
Sorry for blocking the whole repo for so long. I didn't know.
Regards,
Andre
On Tue, 2 Sep 2025 11:42:24 +0200
Jakub Jelinek wrote:
> On Tue, Sep 02, 2025 at 11:39:18AM +0200, Andre Vehreschild wrote:
> > Hi Jakub,
> >
> > I am pushing to gfortran-test. The proces
Hi,
> On Sep 1, 2025, at 05:19, Jakub Jelinek wrote:
>
> Hi!
>
> I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
> work at all for C++.
You mean that -ftrivial-auto-var-init hasn’t work at all for C++’s auto
variables with non-trivial ctors?
> With C++26 P2795R5 bein
On 2025-08-28 16:18, Thiago Jung Bauermann via Gcc wrote:
> "Richard Earnshaw (lists)" writes:
>
>> On 28/08/2025 15:01, Iain Sandoe wrote:
>>>
>>> … the classification is useful, but the false positive “new fail / old fail
>>> went away”
>>> pairs are a real nuiscance .. hopefully we can have s
On Mon, Sep 1, 2025 at 11:19 AM Jakub Jelinek wrote:
> Hi!
>
> I think I've mentioned it earlier, but -ftrivial-auto-var-init= doesn't
> work at all for C++.
> With C++26 P2795R5 being voted in, if we were to default to say
> -ftrivial-auto-var-init=zero for -std=c++26/-std=gnu++26, that would me
On Tue, Sep 2, 2025 at 12:11 PM Andre Vehreschild wrote:
>
> On Tue, 2 Sep 2025 11:00:41 +0100
> Jonathan Wakely wrote:
>
> > On Tue, 2 Sept 2025 at 10:47, Andre Vehreschild via Gcc
> > wrote:
> > >
> > > Er, well, I missed to tell what I did to the branch:
> > >
> > > - rebased to current maste
Hi Jakub,
I am pushing to gfortran-test. The process seems to be finished, but is not
returning (sorry it's in German):
Objekte aufzählen: 11679, fertig.
Zähle Objekte: 100% (11679/11679), fertig.
Delta-Kompression verwendet bis zu 28 Threads.
Komprimiere Objekte: 100% (2995/2995), fertig.
Schrei
On Tue, Sep 02, 2025 at 11:04:45AM +0200, Richard Biener via Gcc wrote:
> On Tue, Sep 2, 2025 at 11:01 AM Rainer Orth via Gcc wrote:
> >
> > I'm currently trying to push to the repo for an hour, but only get
> >
> > remote:
> > -
On Mon, 1 Sep 2025, Jonathan Wakely wrote:
-rw-rw-r--. 1 gccadmin gcc 1132364 2. Jun 2015 lwg-active.html
-rw-rw-r--. 1 gccadmin gcc 1414040 2. Jun 2015 lwg-closed.html
-rw-rw-r--. 1 gccadmin gcc 4344911 2. Jun 2015 lwg-defects.html
>> I just recalled that in 2017 you wer
On Sun, 31 Aug 2025 at 00:32, Gerald Pfeifer wrote:
>
> On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> > I found (and removed) some more sphinx leftovers under /onlinedocs/cpp/
>
> Thanks!
>
> I found some time and dug into this. Addressing this properly means to
> update some of our scripting, for
On 8/29/25 7:48 AM, Christophe Lyon wrote:
On Fri, 29 Aug 2025 at 11:35, Richard Earnshaw via Gcc wrote:
On 29/08/2025 04:08, Jacob Bachmeyer wrote:
On 8/28/25 10:10, Jeff Law wrote:
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
[...]
Well
On Sun, 31 Aug 2025 at 09:51, Gerald Pfeifer wrote:
>
> On Sun, 31 Aug 2025, Jonathan Wakely wrote:
> >> $ ll /www/gcc/htdocs/onlinedocs/libstdc++/ext/
> >> total 6760
> >> -rw-rw-r--. 1 gccadmin gcc 1132364 2. Jun 2015 lwg-active.html
> >> -rw-rw-r--. 1 gccadmin gcc 1414040 2. Jun 2015
On Mon, 1 Sept 2025 at 11:37, Richard Earnshaw (lists)
wrote:
>
> On 29/08/2025 14:48, Christophe Lyon wrote:
> > On Fri, 29 Aug 2025 at 11:35, Richard Earnshaw via Gcc
> > wrote:
> >>
> >> On 29/08/2025 04:08, Jacob Bachmeyer wrote:
> >>> On 8/28/25 10:10, Jeff Law wrote:
> On 8/28/25 8:09
On 29/08/2025 14:48, Christophe Lyon wrote:
> On Fri, 29 Aug 2025 at 11:35, Richard Earnshaw via Gcc
> wrote:
>>
>> On 29/08/2025 04:08, Jacob Bachmeyer wrote:
>>> On 8/28/25 10:10, Jeff Law wrote:
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
> On 28/08/2025 15:01, Iain Sandoe wro
On Sun, 31 Aug 2025, Jonathan Wakely wrote:
>> $ ll /www/gcc/htdocs/onlinedocs/libstdc++/ext/
>> total 6760
>> -rw-rw-r--. 1 gccadmin gcc 1132364 2. Jun 2015 lwg-active.html
>> -rw-rw-r--. 1 gccadmin gcc 1414040 2. Jun 2015 lwg-closed.html
>> -rw-rw-r--. 1 gccadmin gcc 4344911 2. Jun
On Sun, 31 Aug 2025, 00:32 Gerald Pfeifer, wrote:
> On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> > I found (and removed) some more sphinx leftovers under /onlinedocs/cpp/
>
> Thanks!
>
> I found some time and dug into this. Addressing this properly means to
> update some of our scripting, for wh
On 8/30/25 11:49, Rob Savoye wrote:
On 8/29/25 10:47 PM, Jacob Bachmeyer wrote:
There is an option for XML logs that is currently a bit "half-baked"
and, as far as I can tell, what it
Sorry about that, I'm probably the only one that ever used it.
Hopefully, you are right about that and re
On 8/28/25 13:27, Joseph Myers wrote:
On Thu, 28 Aug 2025, Jeff Law via Gcc wrote:
I find the classification this would provide useful, like I like the
(internal compiler error) classification we already have. I would
of course not duplicate all of th eabove message but only
'(unrecognizable in
On 8/30/25 12:22, David Malcolm wrote:
On Sat, 2025-08-30 at 10:49 -0600, Rob Savoye via Gcc wrote:
On 8/29/25 10:47 PM, Jacob Bachmeyer wrote:
There is an option for XML logs that is currently a bit "half-
baked"
and, as far as I can tell, what it
Sorry about that, I'm probably the only
On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> Ugh, there are literally hundreds of pages still there:
>
> $ grep -R 'generator.*Docutils' gccint | wc -l
> 245
> $ grep -R 'generator.*Docutils' gfortran | wc -l
> 323
It looks like you addressed these back then?
What I still found under /www/gc
On Sat, 26 Apr 2025, Jonathan Wakely wrote:
> I found (and removed) some more sphinx leftovers under /onlinedocs/cpp/
Thanks!
I found some time and dug into this. Addressing this properly means to
update some of our scripting, for which I have a prototype ready.
On the libstdc++ my updated scri
On Sat, 2025-08-30 at 10:49 -0600, Rob Savoye via Gcc wrote:
> On 8/29/25 10:47 PM, Jacob Bachmeyer wrote:
>
> > There is an option for XML logs that is currently a bit "half-
> > baked"
> > and, as far as I can tell, what it
> Sorry about that, I'm probably the only one that ever used it. Th
On Fri, 2025-08-29 at 10:40 +0100, Richard Earnshaw via Gcc wrote:
> On 29/08/2025 10:36, Iain Sandoe wrote:
> >
> >
> > > On 29 Aug 2025, at 10:32, Richard Earnshaw
> > > wrote:
> > >
> > > On 29/08/2025 04:08, Jacob Bachmeyer wrote:
> > > > On 8/28/25 10:10, Jeff Law wrote:
> > > > > On 8/28/
On 8/29/25 10:47 PM, Jacob Bachmeyer wrote:
There is an option for XML logs that is currently a bit "half-baked"
and, as far as I can tell, what it
Sorry about that, I'm probably the only one that ever used it. The
entire idea of the .sum files was so the output could be easily diff'd,
XML
On 8/29/25 04:40, Richard Earnshaw wrote:
On 29/08/2025 10:36, Iain Sandoe wrote:
On 29 Aug 2025, at 10:32, Richard Earnshaw
wrote:
On 29/08/2025 04:08, Jacob Bachmeyer wrote:
[...]
The problem with detecting duplicate names in the DejaGnu framework
is that it would add memory overhead that
On Fri, 29 Aug 2025 at 11:35, Richard Earnshaw via Gcc wrote:
>
> On 29/08/2025 04:08, Jacob Bachmeyer wrote:
> > On 8/28/25 10:10, Jeff Law wrote:
> >> On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
> >>> On 28/08/2025 15:01, Iain Sandoe wrote:
> [...]
> >>>
> >>> Well really, the compa
On 29/08/2025 04:08, Jacob Bachmeyer wrote:
On 8/28/25 10:10, Jeff Law wrote:
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
[...]
Well really, the compare-tests script should report duplicate results
as a problem as well, since
PASS: abcd
...
On 29/08/2025 10:36, Iain Sandoe wrote:
On 29 Aug 2025, at 10:32, Richard Earnshaw wrote:
On 29/08/2025 04:08, Jacob Bachmeyer wrote:
On 8/28/25 10:10, Jeff Law wrote:
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
[...]
Well really, the com
> On 29 Aug 2025, at 10:32, Richard Earnshaw wrote:
>
> On 29/08/2025 04:08, Jacob Bachmeyer wrote:
>> On 8/28/25 10:10, Jeff Law wrote:
>>> On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
> [...]
Well really, the compare-tests sc
On 8/28/25 10:10, Jeff Law wrote:
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
[...]
Well really, the compare-tests script should report duplicate results
as a problem as well, since
PASS: abcd
...
PASS: abcd
is just a dup pass/fail waiting t
On Thu, 28 Aug 2025, Sam James via Gcc wrote:
> > Classifications really don't belong in the test name (the thing after
> > "PASS: " or "FAIL: ", until end of line) at all, they belong as separate
> > metadata so the set of test names can be stable when the testsuite itself
> > doesn't change.
Joseph Myers writes:
> On Thu, 28 Aug 2025, Jeff Law via Gcc wrote:
>
>> > I find the classification this would provide useful, like I like the
>> > (internal compiler error) classification we already have. I would
>> > of course not duplicate all of th eabove message but only
>> > '(unrecogniza
Hi Sam,
> When a test fails with 'excess errors', there's often only one actual
> error (an excess "(error|warning|note):") and it'd be nice to not have
> to dig in the .log files to fish that out.
I think such a move would be a bad mistake. Consider ICEs where you
have something like
FAIL: gcc
On Thu, 28 Aug 2025, Jeff Law via Gcc wrote:
> > I find the classification this would provide useful, like I like the
> > (internal compiler error) classification we already have. I would
> > of course not duplicate all of th eabove message but only
> > '(unrecognizable insn)' in the above case.
On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
On 28/08/2025 15:01, Iain Sandoe wrote:
On 28 Aug 2025, at 14:36, Jeff Law via Gcc wrote:
On 8/28/25 5:42 AM, Richard Biener via Gcc wrote:
On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc wrote:
Hi Sam,
When a test fails wit
> On 28 Aug 2025, at 16:10, Jeff Law via Gcc wrote:
>
>
>
> On 8/28/25 8:09 AM, Richard Earnshaw (lists) wrote:
>> On 28/08/2025 15:01, Iain Sandoe wrote:
>>>
>>>
On 28 Aug 2025, at 14:36, Jeff Law via Gcc wrote:
On 8/28/25 5:42 AM, Richard Biener via Gcc wrote
"Richard Earnshaw (lists)" writes:
> On 28/08/2025 15:01, Iain Sandoe wrote:
>>
>> … the classification is useful, but the false positive “new fail / old fail
>> went away”
>> pairs are a real nuiscance .. hopefully we can have some brainstorming
>> @cauldron about
>> ways to deal with this (e
On 28/08/2025 15:01, Iain Sandoe wrote:
>
>
>> On 28 Aug 2025, at 14:36, Jeff Law via Gcc wrote:
>>
>>
>>
>> On 8/28/25 5:42 AM, Richard Biener via Gcc wrote:
>>> On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc wrote:
Hi Sam,
> When a test fails with 'excess errors', ther
> On 28 Aug 2025, at 14:36, Jeff Law via Gcc wrote:
>
>
>
> On 8/28/25 5:42 AM, Richard Biener via Gcc wrote:
>> On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc wrote:
>>>
>>> Hi Sam,
>>>
When a test fails with 'excess errors', there's often only one actual
error (an excess
On 8/28/25 5:42 AM, Richard Biener via Gcc wrote:
On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc wrote:
Hi Sam,
When a test fails with 'excess errors', there's often only one actual
error (an excess "(error|warning|note):") and it'd be nice to not have
to dig in the .log files to fis
On Thu, Aug 28, 2025 at 1:12 PM Rainer Orth via Gcc wrote:
>
> Hi Sam,
>
> > When a test fails with 'excess errors', there's often only one actual
> > error (an excess "(error|warning|note):") and it'd be nice to not have
> > to dig in the .log files to fish that out.
>
> I think such a move would
Thanks you're right, thought I checked but turned out there was still a
lingering printf in my code... All working now, appreciate it! :)
From: Jonathan Wakely
Sent: 21 August 2025 14:42:30
To: Thomas de Bock
Cc: gcc@gcc.gnu.org
Subject: [ext] Re: DejaGnu
On 8/25/25 2:13 PM, Mark Wielaard wrote:
Thanks, I found
https://muxup.com/2024q4/rootless-cross-architecture-debootstrap
which seems to describe such a setup at least for Debian supported
arches. Is there a collection of non-official arches?
No idea. It's been quite some time since I put t
Hi Jeff,
On Mon, Aug 25, 2025 at 07:15:48AM -0600, Jeff Law wrote:
> On 8/24/25 4:03 PM, Mark Wielaard wrote:
> >On Sun, Aug 24, 2025 at 08:07:32AM -0600, Jeff Law wrote:
> >>On 8/24/25 6:39 AM, Mark Wielaard wrote:
> >>>If the port has a (qemu) emulator we could create a x86_64 container
> >>>for
On 8/24/25 4:03 PM, Mark Wielaard wrote:
Hi Jeff,
On Sun, Aug 24, 2025 at 08:07:32AM -0600, Jeff Law wrote:
On 8/24/25 6:39 AM, Mark Wielaard wrote:
If the port has a (qemu) emulator we could create a x86_64 container
for it and run it once a month/week on one of the faster
builder.sourcewa
On Sun, Aug 24, 2025 at 2:39 PM Mark Wielaard wrote:
>
> Hi,
>
> On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote:
> > On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc
> > wrote:
> > > I think we should have a requirement of the bare minimum for a port is a
> > > main
Hi Jeff,
On Sun, Aug 24, 2025 at 08:07:32AM -0600, Jeff Law wrote:
> On 8/24/25 6:39 AM, Mark Wielaard wrote:
> >If the port has a (qemu) emulator we could create a x86_64 container
> >for it and run it once a month/week on one of the faster
> >builder.sourceware.org workers.
>
> That's what my te
Hi Joel,
On Sun, Aug 24, 2025 at 08:28:29AM -0500, Joel Sherrill wrote:
> On Sun, Aug 24, 2025, 7:41 AM Mark Wielaard wrote:
> > On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote:
> > > That said, I'd like to move away from gcc-testresults as a vetting
> > > tool to something
On 8/24/25 6:39 AM, Mark Wielaard wrote:
Hi,
On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote:
On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc wrote:
I think we should have a requirement of the bare minimum for a port is a
maintainer.
I also vote to have a test
On Sun, Aug 24, 2025, 7:41 AM Mark Wielaard wrote:
> Hi,
>
> On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote:
> > On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc
> wrote:
> > > I think we should have a requirement of the bare minimum for a port is
> a
> > > maintain
Hi,
On Wed, Aug 13, 2025 at 08:53:44AM +0200, Richard Biener via Gcc wrote:
> On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc
> wrote:
> > I think we should have a requirement of the bare minimum for a port is a
> > maintainer.
> > I also vote to have a testresults for the target at least
- Am 18. Aug 2025 um 15:19 schrieb Jørgen Kvalsvik j...@lambda.is:
> On 8/18/25 14:37, Sebastian Huber wrote:
[...]
> I tried this program:
>
> int a(int i);
> int b(int i);
> int c(int i);
>
> int f(int i, int j, int k, int l, int m)
> {
> if (i && j && (k || !l || m)) {
> if (a(i) ||
Ujjwal Shekhar writes:
> Thank you for your reply! This definitely looks interesting, and I can see
> myself using it quite a bit as well.
You're welcome! And thanks for your interest.
>
> As a first step, I’m looking into Clang’s __builtin_dump_struct. In the
> meantime, are there any initia
work that might have been done but not updated yet?
Thanks,
Ujjwal
From: Sam James
Sent: 22 August 2025 00:05
To: Ujjwal Shekhar via Gcc
Cc: Ujjwal Shekhar
Subject: Re: Guidance on potential directions for contributing to GCC
Ujjwal Shekhar via Gcc writes
Ujjwal Shekhar via Gcc writes:
> Greetings,
> I’m a final-year university student with some extra time this
> semester, and I’d like to contribute to GCC (not as part of
> GSoC). Although I don’t have prior compiler development experience, I
> have strong working knowledge of C/C++ and low-level
On Thu, 21 Aug 2025 at 15:39, Thomas de Bock via Gcc wrote:
>
> Hey, I'm working on an optimization pass that merges the comparisons in
> defaulted struct equality operators, the spaceship-* testcases all pass,
> except for spaceship-eq12.C:
>
>
> FAIL: g++.dg/cpp2a/spaceship-eq12.C -std=gnu++2
Hi, gcc@gcc.gnu.org
I was just wondering if you had a chance to review the previous email I send to
you.
I understand the value of your time so I'd like to know what's the best way to
reach you and when can we discuss this in more detail?
Waiting,
.
On Wed, 20 Aug 2025 at 08:40, Claudio Bantaloukas wrote:
>
> I can set up the forge bot user to do a regular sync using the same infra
> used for the PRs.
> Just give the go ahead.
That would be useful, thanks.
gcc-TEST/master and gcc-TEST/trunk should both be sync'd with
gcc-mirror/master on so
I can set up the forge bot user to do a regular sync using the same infra used
for the PRs.
Just give the go ahead.
From: Mark Wielaard
Date: Wednesday, 20 August 2025 at 01:38
To: Andrew Pinski
Cc: fo...@sourceware.org , gcc@gcc.gnu.org
Subject: Re: Messed up trunk branch on gcc-test on
Hi,
On Tue, Aug 19, 2025 at 04:42:33PM -0700, Andrew Pinski wrote:
> Hi all,
> I accidentally messed up the trunk branch on gcc-test repo on the forge.
> I clicked merge+fastforward button on a pull request thinking it was just a
> rebase for the pull request.
> Since it is just the test repo, I
On 8/18/25 14:37, Sebastian Huber wrote:
- Am 18. Aug 2025 um 9:33 schrieb Jørgen Kvalsvik j...@lambda.is:
On 8/18/25 02:58, Sebastian Huber wrote:
Hello,
I have question to the counters used for the condition coverage implementation
in tree-profile.cc
/* Stores the incoming edge and pre
- Am 18. Aug 2025 um 9:33 schrieb Jørgen Kvalsvik j...@lambda.is:
> On 8/18/25 02:58, Sebastian Huber wrote:
>> Hello,
>>
>> I have question to the counters used for the condition coverage
>> implementation
>> in tree-profile.cc
>>
>> /* Stores the incoming edge and previous counters (in SS
On 8/18/25 02:58, Sebastian Huber wrote:
Hello,
I have question to the counters used for the condition coverage implementation
in tree-profile.cc
/* Stores the incoming edge and previous counters (in SSA form) on that edge
for the node e->deston that edge for the node e->dest. The counter
On 03.08.2025 17:18, Jeff Law wrote:
[...]
Mine tests:
--target_board=h8300-sim\{-mh/-mint32,-ms/-mint32,-msx/-mint32\}
In simpler terms it'll test -mh, -ms -msx, each with -mint32.
Not sure what yours is testing, but additional coverage is useful.
I also run tests on simulator, usually with
> On 13 Aug 2025, at 15:43, Jeff Law via Gcc wrote:
> On 8/13/25 12:53 AM, Richard Biener via Gcc wrote:
>
>> That said, I'd like to move away from gcc-testresults as a vetting
>> tool to something
>> more modern. Possibly a good(?) GSoC project, set up github CI
>> runners for this?
> Yes,
On 8/13/25 12:53 AM, Richard Biener via Gcc wrote:
Having testresults also shows the port builds (as a cross at least) and is
able to build its target libraries. IMO broken ports are worse than
unmaintained ones, esp. if we release with those.
Right.
Ideally we'd have build bots with pub
On Tue, Aug 12, 2025 at 10:43 PM Andrew Pinski via Gcc wrote:
>
> Here is the list of ports without a maintainer in MAINTAINERS with some
> extra information on when the last time the port was touched for non
> infrastructure changes:
> epiphany - Jeff Law and Jakub Jelinek did a fix each in 2024
> On 12 Aug 2025, at 22:13, Joseph Myers via Gcc wrote:
>
> On Tue, 12 Aug 2025, Andrew Pinski via Gcc wrote:
>
>> I think we should have a requirement of the bare minimum for a port is a
>> maintainer.
>> I also vote to have a testresults for the target at least once a year.
>
> Maintainers
On Tue, 12 Aug 2025, Andrew Pinski via Gcc wrote:
> I think we should have a requirement of the bare minimum for a port is a
> maintainer.
> I also vote to have a testresults for the target at least once a year.
Maintainers should also show some sign of action on things requiring
changes across
On Tue, Aug 12, 2025 at 3:44 PM Andrew Pinski via Gcc
wrote:
> Here is the list of ports without a maintainer in MAINTAINERS with some
> extra information on when the last time the port was touched for non
> infrastructure changes:
> epiphany - Jeff Law and Jakub Jelinek did a fix each in 2024 be
1 - 100 of 63637 matches
Mail list logo
