This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Syntax Extensions): New section.
(Statement Exprs): Make it a subsection of the above.
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Nonlocal Gotos): Group with other built-ins sections.
(Constructing Calls): Likewise.
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* extend.texi (Aggregate Types): New section.
(Variable Length): Make it a subsection of the above.
(
On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
>
> * François Dumont:
>
> > + // Get hash code for a node that comes from another _Hashtable.
> > + // Reuse a cached hash code if the hash function is stateless,
> > + // otherwise recalculate it using our own hash function.
> >
* Jonathan Wakely:
> On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
>>
>> * François Dumont:
>>
>> > + // Get hash code for a node that comes from another _Hashtable.
>> > + // Reuse a cached hash code if the hash function is stateless,
>> > + // otherwise recalculate it using
On 3/13/25 2:04 PM, Richard Biener wrote:
I think this is done by convert_vector_to_array_for_subscript in
c-common/, note that this handles lvalue conversion as well which
means it will not work in lvalue context where you'd possibly want
sth like a
TARGET_EXPR
but then the caller needs t
On Thu, Mar 13, 2025 at 4:55 AM Patrick Palka wrote:
> On Wed, 12 Mar 2025, Patrick Palka wrote:
>
> > On Wed, 12 Mar 2025, Patrick Palka wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> > > perhaps 13?
> > >
> > > N.B. the use of a constrained auto instead of
I'm not opposed to refactoring but what's the reason for it? We have a large
number of similar tests that also include all possible types. And aren't all
the tests you touch FAILing anyway right now? (Due to the combine change...)
Yes, the cond_widen_complicate-3 need some tweak for the asm
Hi Ayan,
> On 11 Mar 2025, at 14:53, Ayan Shafqat wrote:
>
> Hello Kyrylo,
>
> On Tue, Mar 11, 2025 at 08:55:46AM +, Kyrylo Tkachov wrote:
>> This looks ok to me.
>> GCC is currently in a regression fixing stage so normally such a change
>> would wait until stage 1 reopens.
>> But this loo
On Thu, 13 Mar 2025, Tejas Belagod wrote:
> On 3/13/25 1:28 PM, Richard Biener wrote:
> > On Thu, 13 Mar 2025, Tejas Belagod wrote:
> >
> >> On 3/12/25 4:45 PM, Richard Biener wrote:
> >>> On Wed, 12 Mar 2025, Tejas Belagod wrote:
> >>>
> On 3/10/25 7:21 PM, Richard Biener wrote:
> > On
On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> > On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> > > > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> > > >
>
On 3/13/25 1:28 PM, Richard Biener wrote:
On Thu, 13 Mar 2025, Tejas Belagod wrote:
On 3/12/25 4:45 PM, Richard Biener wrote:
On Wed, 12 Mar 2025, Tejas Belagod wrote:
On 3/10/25 7:21 PM, Richard Biener wrote:
On Sat, 8 Mar 2025, Tejas Belagod wrote:
On 3/8/25 12:55 AM, Tejas Belagod wrot
Hi!
On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> On Wed, 12 Mar 2025, Jakub Jelinek wrote:
>
> > On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
> > > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> > >
> > > > On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Bi
On 3/12/25 4:45 PM, Richard Biener wrote:
On Wed, 12 Mar 2025, Tejas Belagod wrote:
On 3/10/25 7:21 PM, Richard Biener wrote:
On Sat, 8 Mar 2025, Tejas Belagod wrote:
On 3/8/25 12:55 AM, Tejas Belagod wrote:
On 3/7/25 5:34 PM, Richard Biener wrote:
On Fri, 7 Mar 2025, Tejas Belagod wrote:
On Thu, 13 Mar 2025 at 09:54, Jonathan Wakely wrote:
>
> On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
> >
> > * Jonathan Wakely:
> >
> > > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
> > >>
> > >> * François Dumont:
> > >>
> > >> > + // Get hash code for a node that comes fro
On Thu, 13 Mar 2025 at 09:58, Jonathan Wakely wrote:
>
> On Thu, 13 Mar 2025 at 09:54, Jonathan Wakely wrote:
> >
> > On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
> > >
> > > * Jonathan Wakely:
> > >
> > > > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
> > > >>
> > > >> * François
Hi,
since updating to Fedora 41 I have been seeing ignored python exceptions
like the following when using 'git gcc-verify' =
contrib/gcc_changelog/git_check_commit.py.
Checking 90fcc1f4f1a5537e8d30628895a07cbb2e7e16ff: OK
Exception ignored in:
Traceback (most recent call last):
File "/usr/l
the gcobol and gcobc binaries are currently installed without honoring
the program prefix and program suffix. Honor these while installing.
Ok for the trunk?
Matthias
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -34,8 +34,10 @@
# - the compiler proper (eg: cc1plus)
# - define
On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
> >>
> >> * François Dumont:
> >>
> >> > + // Get hash code for a node that comes from another _Hashtable.
> >> > + // Reuse a cached hash code if the has
On Wed, 12 Mar 2025, Richard Sandiford wrote:
> We have long had the fold:
>
> /* Pattern match
> tem = (sizetype) ptr;
> tem = tem & algn;
> tem = -tem;
> ... = ptr p+ tem;
>and produce the simpler and easier to analyze with respect to alignment
> ... = ptr & ~algn;
Andrew Pinski writes:
> The fix for this depends on much more infrastructure which won't
> be done for another few weeks. Pengxuan is working on the fix for GCC 16.
> So let's xfail the testcase since it is a minor code quality regression.
> we get:
> ```
> moviv0.2s, 0
> ins
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBOL, with all
copyrights for that already with the FSF)?
Is the existence of this in upstream [1] just u
Simon Sobisch writes:
> Thanks for your work on adding a testsuite. Can you please explain why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that already with the FSF)?
>
I don't think any
On Fri, 14 Mar 2025 13:30:39 +0800, Monk Chiang wrote:
> Hi Jin Ma,
> This situation is the same on x86. When using -O0, the lpad instruction
> is merely a redundant instruction and does not affect the execution result.
> This is the ASM result for x86, and there is also an endbr64 in foo().
>
Hi David,
Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi:
>
> I skip your initiial part. I think this was all discussed before
(also in WG14) and I still come to different conclusions. Just
two comments:
...
>
> The VLA semantics are also problematic. User can side-effe
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Additional Numeric Types): New section.
(__int128): Make it a subsection of the above.
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return
This series of patches attempts to bring some organization to the
current random order of topics within the "C Extensions" chapter of
the manual. It's broken up into pieces for easier reviewing (should
anybody care to do that), but there's little in the way of actual text
changes to review; the en
On Thu, 13 Mar 2025, Jonathan Wakely wrote:
> On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> >
> > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> >
> > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > wrote:
> > > >
> > > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > >
Hi Jin Ma,
This situation is the same on x86. When using -O0, the lpad instruction
is merely a redundant instruction and does not affect the execution result.
This is the ASM result for x86, and there is also an endbr64 in foo().
https://godbolt.org/z/M1fTendE3
On Wed, Mar 12, 2025 at 5:4
The -ansi option has essentially been superseded by the more general
-std= option, and all the additional information about its effects is
already covered elsewhere in the manual. I also cleaned up some
confusing text about alternate keywords that I noticed while
confirming this.
gcc/ChangeLog
On Thu, 13 Mar 2025, Michal Jires wrote:
> This adds missing documentation for LTO flags.
>
> Ok?
OK.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * doc/invoke.texi: (Optimize Options):
> Add incremental LTO flags.
> ---
> gcc/doc/invoke.texi | 26 +++---
> 1 file ch
101 - 132 of 132 matches
Mail list logo
