Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Sam James writes: > Sam James writes: > >> Richard Biener writes: >> >>> On Thu, Aug 28, 2025 at 9:14 PM Sam James wrote: >>>> >>>> Joseph Myers writes: >>>> >>>> > On Thu, 28 Aug 2025, Sam James wrote: >&

Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Sam James writes: > Richard Biener writes: > >> On Thu, Aug 28, 2025 at 9:14 PM Sam James wrote: >>> >>> Joseph Myers writes: >>> >>> > On Thu, 28 Aug 2025, Sam James wrote: >>> > >>> >> Joseph Myers writes: &

Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Richard Biener writes: > On Thu, Aug 28, 2025 at 9:14 PM Sam James wrote: >> >> Joseph Myers writes: >> >> > On Thu, 28 Aug 2025, Sam James wrote: >> > >> >> Joseph Myers writes: >> >> >> >> > On Thu, 28 Aug 202

Re: [PATCH] Fix assertion when trying to represent Ada arrays in CodeView

Mark Harmstone writes: > The LF_ARRAY CodeView type represents a C- or C++-style array, which a > length known at compile time. We were crashing when using -gcodeview > with Ada (bug #121157), as the DW_AT_upper_bound value is not an > unsigned integer but something more complicated: > > 0x01

Re: [RFC] c++: Vectorizing default struct and std::array equality

Thomas de Bock writes: > From 289487b58709575a90fca0cbebc6ae968aba73ab Mon Sep 17 00:00:00 2001 > From: Thomas de Bock > Date: Thu, 28 Aug 2025 16:10:08 +0100 > Subject: [PATCH] Vectorizing default struct and std::array equality Not a review (and I'm not the person to do it), but some small com

Re: [PATCH 09/14] lto: Add toplevel assembly heuristics

Andrew Pinski writes: > On Thu, Aug 28, 2025 at 2:26 PM Andi Kleen wrote: >> >> Jakub Jelinek writes: >> >> > On Wed, Aug 27, 2025 at 03:52:11PM +0200, Michal Jires wrote: >> >> This new pass heuristically detects symbols referenced by toplevel >> >> assembly to prevent their optimization. >> >

Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Joseph Myers writes: > On Thu, 28 Aug 2025, Sam James wrote: > >> Joseph Myers writes: >> >> > On Thu, 28 Aug 2025, Richard Biener wrote: >> > >> >> I wonder if we can piggy-back on the existing --with-glibc-version=... >> >> some

Re: [PATCH] fixincludes: Replace fgrep in genfixes script

Rainer Orth writes: > Hi Jonathan, > >> On Thu, 28 Aug 2025 at 18:40, Rainer Orth wrote: >>> >>> Hi Jonathan, >>> >>> > POSIX says fgrep is obsolescent and grep -F should be used instead. >>> >>> grep -F isn't portable, unfortunately At least it's not supported by >>> Solaris /bin/grep). It may

Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Joseph Myers writes: > On Thu, 28 Aug 2025, Richard Biener wrote: > >> I wonder if we can piggy-back on the existing --with-glibc-version=... >> somehow? > > Indeed, that's the correct way to handle such features so that cross > compilers default to the same correct configuration as native. Do

Re: [PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

Richard Biener writes: > On Thu, Aug 28, 2025 at 7:23 AM Sam James wrote: >> >> GNU2 TLS descriptors were introduced in 2006 (r0-73091-g5bf5a10b1ccacf) >> but were only opt-in with -mtls-dialect=gnu2. They are more efficient >> and it's time to enable them by def

[PATCH] i386: default to -mtls-dialect=gnu2 if appropriate

GNU2 TLS descriptors were introduced in 2006 (r0-73091-g5bf5a10b1ccacf) but were only opt-in with -mtls-dialect=gnu2. They are more efficient and it's time to enable them by default. Builds on the --with-tls= machinery from r16-3355-g96a291c4bb0b8a. We achieve this for GNU/Linux IA-32/X86-64 targ

Re: [PATCH] Move pr121656.c to gcc.dg/torture

"H.J. Lu" writes: > Move pr121656.c to gcc.dg/torture and replace weak attribute with noipa > attribute. Verified by reverting > > 56ca14c4c4f Fix invalid right shift count with recent ifcvt changes > > to trigger > > FAIL: gcc.dg/torture/pr121656.c -O1 execution test > FAIL: gcc.dg/torture/p

Re: [PATCH] Add a test for PR tree-optimization/121656

"H.J. Lu" writes: > PR tree-optimization/121656 > * gcc.dg/pr121656.c: New file. > > Signed-off-by: H.J. Lu > --- > gcc/testsuite/gcc.dg/pr121656.c | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 gcc/testsuite/gcc.dg/pr121656.c > > diff --git a/g

Re: [PATCH] i386: wire up --with-tls to control -mtls-dialect= default

Sam James writes: > Allow passing --with-tls= at configure-time to control the default value > of -mtls-dialect= for i386 and x86_64. The default itself (gnu) is not changed > unless --with-tls= is passed. > > --with-tls= is already wired up for ARM and RISC-V. > > gcc/

Re: [COMMITTED htdocs] gcc-{11,12}: mention they're no longer supported

Jakub Jelinek writes: > On Sun, Aug 10, 2025 at 11:46:53PM +0200, Gerald Pfeifer wrote: >> On Mon, 4 Aug 2025, Sam James wrote: >> > .. as we did for <= 10. >> : >> > GCC 11 Release Series >> > >> > +(This release series is no longer su

Re: [PATCH] i386: wire up --with-tls to control -mtls-dialect= default

Uros Bizjak writes: > On Sat, Aug 23, 2025 at 11:13 AM Uros Bizjak wrote: >> >> On Sat, Aug 23, 2025 at 2:42 AM Sam James wrote: >> > >> > Allow passing --with-tls= at configure-time to control the default value >> > of -mtls-dialect= for i386 a

[PATCH] i386: wire up --with-tls to control -mtls-dialect= default

Allow passing --with-tls= at configure-time to control the default value of -mtls-dialect= for i386 and x86_64. The default itself (gnu) is not changed unless --with-tls= is passed. --with-tls= is already wired up for ARM and RISC-V. gcc/ChangeLog: PR target/120933 * config.gcc (

Re: [PATCH] Regenerate common.opt.urls for -fdiagnostics-show-context

Qing Zhao writes: > When -fdiagnostics-show-context[=DEPTH] was added, they were documented, but > common.opt.urls wasn't regenerated. > > gcc/ChangeLog: > > * common.opt.urls: Regenerate. > > Okay for committing? It should be OK to go in as obvious. Thanks! > > Thanks. > > Qing > --- >

Re: [PATCH] Add ia64*-*-* to the list of obsolete targets

Frank Scheiner writes: > Dear all, > > On 11.08.25 09:49, Richard Biener wrote: >> On Sun, 10 Aug 2025, Jeff Law wrote: >>> On 8/10/25 3:24 PM, Andrew Pinski wrote: I just looked and the last testsuite results for ia64 was back in June 2024. There has been no movement since. Can we agai

Re: [PATCH] diagnostics: fix build on hosts where unsigned == size_t

Sam James writes: > David Malcolm writes: > >> [...] >> Test bootstrap on x86_64 in progress. Is there an easy way to force >> the bootstrap to use 32-bit? > > Try ~/git/gcc/configure --host=i686-pc-linux-gnu > --build=i686-pc-linux-gnu --target=i686-pc-linux-

Re: [PATCH] diagnostics: fix build on hosts where unsigned == size_t

David Malcolm writes: > [...] > Test bootstrap on x86_64 in progress. Is there an easy way to force > the bootstrap to use 32-bit? Try ~/git/gcc/configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i686-pc-linux-gnu CC="gcc -m32" CXX="g++ -m32".

[COMMITTED] testsuite: fix escaping of square brackets

This fails for me as: +ERROR: g++.dg/cpp26/constexpr-new3.C -std=c++26: unknown dg option: 2 for " dg-error 40 "accessing value of 'int [2]' object through a 'long int' glvalue in a constant expression" " otherwise. Escape '[' and ']'. gcc/testsuite/ChangeLog: * g++.dg/cpp26/constexpr

Re: [PATCH] hurd: Add OPTION_GLIBC_P and OPTION_GLIBC

Samuel Thibault writes: > Hello, > > We are still waiting on this... CCing Thomas who is the only listed hurd maintainer. > > Samuel > > Samuel Thibault, le lun. 12 mai 2025 01:57:16 +0200, a ecrit: >> Hello, >> >> Are there any news on this? >> >> Samuel >> >> Samuel Thibault, le lun. 10 fé

[COMMITTED htdocs] gcc-{11,12}: mention they're no longer supported

.. as we did for <= 10. --- Committed as obvious. htdocs/gcc-11/index.html | 2 ++ htdocs/gcc-12/index.html | 2 ++ 2 files changed, 4 insertions(+) diff --git a/htdocs/gcc-11/index.html b/htdocs/gcc-11/index.html index c2bde497..e600e153 100644 --- a/htdocs/gcc-11/index.html +++ b/htdocs/gcc-11

[PATCH] gcc: drop placement new workaround for old bootstrap compilers

Since r15-4719-ga9ec1bc06bd3cc, we require GCC 5.4, so a workaround for < GCC 4.3 is long-obsolete. Before that, we required GCC 4.8.3 too. i.e. it shouldn't be possible to build GCC with such a compiler for quite some time. gcc/ChangeLog: PR libstdc++/29286 * Makefile.in (ALIASIN

[PATCH] zlib: refresh version in configure

zlib/ChangeLog: * configure: Regenerate. * configure.ac: Set version to 1.3.1. --- Pushed obvious followup to zlib sync. zlib/configure| 20 ++-- zlib/configure.ac | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/zlib/configure b/zlib/

Re: [PATCH] [sanitizer_common] Remove reference to obsolete termio ioctls (#138822)

Jakub Jelinek writes: > On Fri, Jul 25, 2025 at 07:51:41PM +0100, Sam James wrote: >> Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9. >> >> The termio ioctls are no longer used after commit 59978b21ad9c >> ("[sanitizer_common] Remove in

Re: [PATCH] Fix UB in string_slice::operator== (PR 121261)

Alfie Richards writes: > Hi, > > Small fix to resolve an UBSAN diagnostic. > > Reg tested for Aarch64 > To be sure: checked with bootstrap-ubsan too? (though note that it doesn't error out by default, so you'd need to grep the logs or set UBSAN_OPTIONS to make it error out) > Thanks, > Alfie >

Re: [PATCH] [sanitizer_common] Remove reference to obsolete termio ioctls (#138822)

Jakub Jelinek writes: > On Fri, Jul 25, 2025 at 07:51:41PM +0100, Sam James wrote: >> Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9. > > I thought it got reverted on the glibc side: > https://sourceware.org/git/?p=gl

[PATCH] [sanitizer_common] Remove reference to obsolete termio ioctls (#138822)

Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9. The termio ioctls are no longer used after commit 59978b21ad9c ("[sanitizer_common] Remove interceptors for deprecated struct termio (#137403)"), remove them. Fixes this build error: ../../../../libsanitizer/sanitizer_commo

Re: [PATCH] zlib: import zlib-1.3.1

Jeff Law writes: > On 7/20/25 6:54 PM, Sam James wrote: >> This is vanilla zlib-1.3.1 imported over the existing zlib/ dir with: >> * README adjusted to add the GCC note at the top; >> * GCC's ChangeLog merged with the upstream one, as before; >> * Deleted up

[PATCH] contrib: add 'zlib' to ignored_prefixes

This fixes the same problem for syncing zlib that H.J. hit for libffi in r12-4561-g25ab851dd333d7. contrib/ChangeLog: PR other/105404 * gcc-changelog/git_commit.py (ignored_prefixes): Add zlib/. --- Committed as obvious. Thank you to pinskia for the hint and iains for rubberduckin

Re: [PATCH] arm: avoid gcc_s dependency

Pierre Ossman writes: > On 14/07/2025 22:24, Sam James wrote: >> A patch rebased against trunk would also be appreciated. See >> https://gcc.gnu.org/contribute.html for the needed format. >> > > The patch applies cleanly against trunk, so nothing is needed there.

Re: [PATCH] arm: avoid gcc_s dependency

Kyrylo Tkachov writes: > + arm maintainers. > > Hi Pierre, > >> On 14 Jul 2025, at 14:07, Pierre Ossman wrote: >> >> Suggested fix for this issue: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60428 >> >> Did not get any response there, so seeing if this is a better forum for >> suggest

Re: [PATCH v2] x86-64: Add --enable-x86-64-mfentry

"H.J. Lu" writes: > On Sat, Jul 12, 2025 at 6:58 AM Siddhesh Poyarekar > wrote: >> >> On 2025-07-11 15:28, Uros Bizjak wrote: >> >> Why not just switch over unconditionally? __fentry__ seems like a >> >> better alternative to mcount overall and it has been around long enough >> >> that even ol

Re: [PATCH] x86-64: Add --enable-x86-64-mfentry

Uros Bizjak writes: > On Fri, Jul 11, 2025 at 2:33 PM Siddhesh Poyarekar > wrote: >> >> On 2025-07-08 18:07, Sam James wrote: >> >> OK in principle, but please allow some time for distro maintainers >> >> (CC'd) to voice their opinion. >>

Re: [PATCH] x86-64: Add --enable-x86-64-mfentry

Siddhesh Poyarekar writes: > On 2025-07-08 18:07, Sam James wrote: >>> OK in principle, but please allow some time for distro maintainers >>> (CC'd) to voice their opinion. >> It looks good to me and I plan on us using it. I'd like opinions >> from &g

Re: [PATCH] x86-64: Add --enable-x86-64-mfentry

Uros Bizjak writes: > On Thu, Jul 3, 2025 at 12:01 PM H.J. Lu wrote: >> >> When profiling is enabled with shrink wrapping, the mcount call may not >> be placed at the function entry after >> >> pushq %rbp >> movq %rsp,%rbp >> >> As the result, the profile data may be skewed which makes PGO less

Re: [PATCH] x86: Preserve frame pointer for no_callee_saved_registers attribute

"H.J. Lu" writes: > Update functions with no_callee_saved_registers/preserve_none attribute > to preserve frame pointer since caller may use it to save the current > stack: > > pushq %rbp > movq %rsp, %rbp > ... > call function > ... > leave > ret > > If callee changes frame pointer without resto

Re: Do not drop discriminator when inlining

Jan Hubicka writes: >> > That is why I checked for loc != UNKNOWN_LOCATION. I did not expect >> > UNKNOWN_LOCATION to have discriminators. What they are good for? >> >> I have no idea, this was simply a defensive review where it's no >> longer obvious that inlined_function_outer_scope_p would s

[COMMITTED] Fixup dropping REG_EQUAL note in ext-dce

Followup to r16-1613-g34e1e5e33ec3eb. remove_reg_equal_equiv_notes's 2nd argument is 'no_rescan' which we accidentally had on, tripping an assert in combine or ira because we hadn't left things in a consistent state. Fix the thinko by enabling rescanning. gcc/ChangeLog: PR rtl-optimizatio

Re: [COMMITTED] Check if constant is a member before returning it.

Andrew MacLeod writes: > There is a bug in irange::set_range_from_bitmask where if the bitmask > indicated the result is a singleton, it would simply return that > singleton.  It never actually checked to see if that singleton was > actually contained in the range, in which case it should return

Re: [PATCH] Add newlib to gitignore

Thomas Schwinge writes: > Hi! > > On 2025-06-02T22:01:44+0530, Arijit Kumar Das > wrote: >>> Umm, I don't think so. I've been building crosses with gcc for decades. >>> It should not be necessary, though it may sometimes be convenient. > > Right. Similarly to how it's, for example, documented

Re: [PATCH v25 1/3] c: Add _Countof operator

Alejandro Colomar writes: > [...] > diff --git a/gcc/testsuite/gcc.dg/countof-vla.c > b/gcc/testsuite/gcc.dg/countof-vla.c > new file mode 100644 > index ..cc225df20689 > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/countof-vla.c > @@ -0,0 +1,35 @@ > +/* { dg-do compile } */ > +/* { dg

Re: [14.x PATCH] c: Allow bool and enum null pointer constants [PR112556]

Joseph Myers writes: > On Wed, 14 May 2025, Sam James wrote: > >> > (cherry picked from commit 3d525fce70fa0ffa0b22af6e213643e1ceca5ab5) >> > --- >> > As discussed on the PR, I feel like this is worth having for 14 as we're >> > asking upstreams to

Re: [14.x PATCH] c: Allow bool and enum null pointer constants [PR112556]

Sam James writes: > From: Joseph Myers > > As reported in bug 112556, GCC wrongly rejects conversion of null > pointer constants with bool or enum type to pointers in > convert_for_assignment (assignment, initialization, argument passing, > return). Fix the code there to allo

Re: [AUTOFDO][AARCH64] Add support for profilebootstrap

Kugan Vivekanandarajah writes: > Add support for autoprofiledbootstrap in aarch64. > This is similar to what is done for i386. Added > gcc/config/aarch64/gcc-auto-profile for aarch64 profile > creation. > > How to run: > configure --with-build-config=bootstrap-lto > make autoprofiledbootstrap > >

Re: [PATCH] ltmain.in: don't suppress output for PIC compilations

Sam James writes: > When working on xz, I set `-Werror=suggest-attribute=returns_nonnull`, and > the build failed (as I expected it to), but with no visible error from > the compiler. There's a mysterious '>/dev/null 2>&1' on the second line where > lib

Re: [PATCH] gimple: Don't assert that switch has nondefault cases during lowering [PR120080]

Filip Kastl writes: > Hi, > > bootstrapped and regtested on x86_64 linux. Ok to push? > > Filip Kastl > No testcase? I think pinskia's reduced testcase from the bug should be fine. I can handle adding that later if needed though.

[14.x PATCH] c: Allow bool and enum null pointer constants [PR112556]

From: Joseph Myers As reported in bug 112556, GCC wrongly rejects conversion of null pointer constants with bool or enum type to pointers in convert_for_assignment (assignment, initialization, argument passing, return). Fix the code there to allow BOOLEAN_TYPE and ENUMERAL_TYPE; it already allow

Re: [PATCH] i386: Implement Thread Local Storage on Windows

Julian Waters writes: > gcc bootstrap works on my end pretty well, but you know what they say, > no one likes an "It works on my device" developer :) The reason he asked is https://gcc.gnu.org/contribute.html#patches (it's convention to state how you tested it & on what platforms) and whether th

Re: [PATCH] libphobos: enable for sparc64-unknown-linux-gnu

Iain Buclaw writes: > Excerpts from Sam James's message of April 20, 2025 2:46 am: >> This bootstraps with some test failures but works well enough to build >> 11..15. >> >> libphobos/ChangeLog: >> >> * configure.tgt: Add sparc64-unknown-linux-gnu as a supported target. >> --- >> As discus

Re: [PATCH v4] libstdc++: Implement C++26 features (P2546R5)

Jonathan Wakely writes: > [...] > +void > +std::breakpoint() noexcept > +{ > + PROBE(std::breakpoint); > + > + if (__gnu_cxx::debugger_signal_for_breakpoint > 0) > +std::raise(__gnu_cxx::debugger_signal_for_breakpoint); > + glib's https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gbackt

Re: [PATCH 0/3][RFC] Remove TARGET_LRA_P hook

John Paul Adrian Glaubitz writes: > Hello, > > > > >> This mini-series removes the TARGET_LRA_P hook, forcing all targets >> to use LRA. I have not touched the targets that define -mlra >> in terms of a 'Target Mask(XXX)' since IIRC there's no way to >> "default" that. I'd expect those to wrong

Re: Update GCC16 to use libffi 3.4.8

Simon Sobisch writes: > As GCC15 is now strict on dynamic function as > int *func() > to mean exactly zero arguments via its default -std=gnu23, I'm looking > into a dynamic option that would work for C23 and recognized libffi > being built as part of GCC and being part of its source tree, wh

Re: [PATCH 1/3] Force targets to use LRA which opted out via hook_bool_void_false

Richard Biener writes: > * config/alpha/alpha.cc (TARGET_LRA_P): Remove define. > * config/bfin/bfin.cc (TARGET_LRA_P): Likewise. > * config/c6x/c6x.cc (TARGET_LRA_P): Likewise. > * config/fr30/fr30.cc (TARGET_LRA_P): Likewise. > * config/frv/frv.cc (TARGET_LRA_P): L

Re: [PATCH 2/3] Flip default to LRA for targets with -mlra

Richard Biener writes: > This flips the default to LRA for targets with an -mlra option not > using Mask(..). Please tag PR113934 for avr, PR113939 for m68k, PR113933 for pa, and PR55212 for sh.

[committed htdocs v2] bugs: improve "ABI changes" subsection

C++ ABI for C++ standards with full support by GCC (rather than those marked as experimental per https://gcc.gnu.org/projects/cxx-status.html) should be stable. It's certainly not the case in 2025 that one needs a full world rebuild for C++ libraries using e.g. the default standard or any other sup

Re: [PATCH] debug/78685 - reword -Og documentation

Richard Biener writes: > On Mon, 28 Apr 2025, Alexander Monakov wrote: > >> >> On Mon, 28 Apr 2025, Richard Biener wrote: >> >> > The following rewords the documentation for -Og which over-promises >> > the ability to debug the generated code. While -Og enables >> > var-tracking and thus impro

Re: [PATCH v2] gcc: do not apply store motion on loop with no exits.

ywgrit writes: > I encountered one problem with loop-im pass. > I compiled the program dhry2reg which belongs to > unixbench(https://github.com/kdlucas/byte-unixbench). > > The gcc used > gcc (GCC) 12.3.0 > > The commands executed as following > make > ./Run -c -i 1 dhry2reg > > The results are

Re: [PATCH 30/61] MSA: Make MSA and microMIPS R5 unsupported

Xi Ruoyao writes: > On Wed, 2025-04-23 at 12:43 +, Aleksandar Rakic wrote: >> From 16b3207aed5e4846fde4f3ffa1253c65ef6ba056 Mon Sep 17 00:00:00 2001 >> From: Aleksandar Rakic >> Date: Wed, 23 Apr 2025 14:14:17 +0200 >> Subject: [PATCH] Make MSA and microMIPS R5 unsupported >> >> There are n

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Jakub Jelinek writes: > On Mon, Apr 21, 2025 at 10:52:22AM +0200, Richard Biener wrote: >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> > >> > On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: >> > > That's one option, but maybe it's better the other way round: instead of >

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Jakub Jelinek writes: > On Mon, Apr 21, 2025 at 10:16:39AM +0100, Sam James wrote: >> Sam James writes: >> >> > Richard Biener writes: >> > >> >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> >>> >> >>> O

Re: [PATCH] sanitizer: Store no_sanitize attribute value in uint32 instead of unsigned

Kees Cook writes: > On Thu, Apr 10, 2025 at 05:17:51PM -0700, Keith Packard wrote: >> A target using 16-bit ints won't have enough bits to hold the whole >> flag_sanitize set. Be explicit about using uint32 for the attribute data. >> >> Signed-off-by: Keith Packard >> --- >> gcc/c-family/c-att

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Sam James writes: > Richard Biener writes: > >> On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >>> >>> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: >>> > That's one option, but maybe it's better the other way round: in

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Richard Biener writes: > On Fri, Apr 18, 2025 at 8:10 PM Jakub Jelinek wrote: >> >> On Fri, Apr 18, 2025 at 06:04:29PM +0200, Rainer Orth wrote: >> > That's one option, but maybe it's better the other way round: instead of >> > excluding known-bad targets, restrict cobol to known-good ones >> >

Re: [PATCH] cobol: Allow for undefined NAME_MAX [PR119217]

Robert Dubner writes: >> -Original Message- >> From: Jakub Jelinek >> Sent: Friday, April 18, 2025 14:10 >> To: Rainer Orth >> Cc: Richard Biener ; Andreas Schwab >> ; gcc-patches@gcc.gnu.org; Robert Dubner >> ; James K. Lowden >> Subject: Re: [PATCH] cobol: Allow for undefined NAME_MA

[PATCH] libphobos: enable for sparc64-unknown-linux-gnu

This bootstraps with some test failures but works well enough to build 11..15. libphobos/ChangeLog: * configure.tgt: Add sparc64-unknown-linux-gnu as a supported target. --- As discussed on IRC. OK? I'd like to backport it to branches in due course once they're all open and some time on t

Re: [PATCH] avoid-store-forwarding: Fix reg init on load-elimination [PR119160]

Philipp Tomsich writes: > Applied to trunk (16.0.0), thank you! > Should this be backported to the GCC-15 release branch as well? BTW, what's the plan for enabling this on trunk now by default? (I don't recall if some other issues were left.)

Re: [PATCH 1/2] DSE: Support triming of some more memset [PR87901]

Andrew Pinski writes: > DSE has support for trimming memset (and memset like) statements. > In this case we have `MEM [(char * {ref-all})&z] = {};` in > the IR and when we go to trim it, we call build_fold_addr_expr which leaves > around This looks cut off?

Re: [PATCH] Add COBOL information to gcc.gnu.org index.html

Robert Dubner writes: > Okay for htdocs/master? > > From d412e45d5afeecded3c8cf1b6b2865e088a480cc Mon Sep 17 00:00:00 2001 > From: Robert Dubner > Date: Thu, 17 Apr 2025 15:12:26 -0400 > Subject: [PATCH] Add COBOL information to gcc.gnu.org index.html > > * htdocs/index.html: Add COBOL inf

[PATCH v2] doc: say "compatible types" for -fstrict-aliasing

Include the term used in the standard to ease further research for users, and while at it, rephrase the description of the rule entirely using Alexander Monakov's suggestion: it was previously wrong (and imprecise) as "the same address" may well be re-used later on, and the issue is the access via

Re: [PATCH] doc: say "compatible types" for -fstrict-aliasing

Jakub Jelinek writes: > On Wed, Mar 26, 2025 at 10:41:52AM +0000, Sam James wrote: >> Include the term used in the standard to ease further research for users. >> >> gcc/ChangeLog: >> >> * doc/invoke.texi: Use "compatible types" term. >> --

Re: [PATCH] PR tree-optimization/119712 - Always reflect lower bits from mask in subranges.

Andrew MacLeod writes: > This was a fun one!   An actual bug, and it took a while to sort out.  > After chasing down some red herrings, this turns out to be an issue of > interaction between the range and value masks and intervening > calculations. (Just want to say thanks for the detailed commi

Re: [r15-9427 Regression] FAIL: gcc.dg/ipa/pr119530.c execution test on Linux/x86_64

"haochen.jiang" writes: > On Linux/x86_64, > > de1c734a8ae034c92f485e7f58b7fcb1c921ecd2 is the first bad commit > commit de1c734a8ae034c92f485e7f58b7fcb1c921ecd2 > Author: Martin Jambor > Date: Mon Apr 14 14:21:15 2025 +0200 > > ipa-cp: Make propagation of bits in IPA-CP aware of type conv

[PATCH] ltmain.in: don't suppress output for PIC compilations

When working on xz, I set `-Werror=suggest-attribute=returns_nonnull`, and the build failed (as I expected it to), but with no visible error from the compiler. There's a mysterious '>/dev/null 2>&1' on the second line where liblzma_la-common.o is built without PIC. With -fPIC, IPA doesn't end up d

Re: [PATCH] c++: Fix various Wnarrowing minor issues

Vishnu Mohandas writes: > Hello, > This is a possible fix for Wnarrowing warning issues. > Bootstrapped on x86_64 Linux. Please see my remarks at https://inbox.sourceware.org/gcc-patches/87iknbzfw4@gentoo.org/.

Re: [PATCH] Improve [-W..] display for -Wformat

Vishnu Mohandas writes: > Hello, Hi, > The patch below proposes a possible improvement for the issue mentioned in > bug 65445. Although I'm not certain that it > address all the concerns, it does seem to make it better.> Unfortunately, I see a few issues here. There needs to be a ChangeLog en

[COMMITTED htdocs] gcc-3.2/changes: fix 'several' typo

--- Pushed. htdocs/gcc-3.2/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-3.2/changes.html b/htdocs/gcc-3.2/changes.html index 7b9ea63f..4ab9fdce 100644 --- a/htdocs/gcc-3.2/changes.html +++ b/htdocs/gcc-3.2/changes.html @@ -59,7 +59,7 @@ C++ -

Re: [PATCH] Makefile.tpl: Implement per-stage GDCFLAGS [PR116975]

Iain Buclaw writes: > Hi, > > This patch implements STAGE1_GDCFLAGS and others to the configure > machinery, allowing the GDCFLAGS for each bootstrap stage of building > gdc to be overriden, as is the case with CXXFLAGS for other front-ends. > > This is limited to just the generation of recipes f

Re: combine: Re-enable 2->2 combinations, with limits [PR116398]

Richard Sandiford writes: > This series is an update of: > > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/679924.html > > As discussed in that thread, the changes since last time are to make > distribute_links start from the last use, where easy, and to avoid > an unnecessary insn walk

Re: [PATCH] testsuite: Fix up strub-internal-pr112938.C test for C++2{0,3,6}

Jakub Jelinek writes: > On Thu, Mar 27, 2025 at 12:05:21AM +0000, Sam James wrote: >> The test was being ignored because dg.exp looks for .C in g++.dg/. >> >> gcc/testsuite/ChangeLog: >> PR middle-end/112938 >> >> * g++.dg/strub-internal-pr11293

[PATCH] aarch64: change another CRC test

Fixed the iteration number in crc-crc32-data16.c test from 8 to 16 to match the test name, just like in r15-9038-gdf55a933cfc675. gcc/testsuite/ChangeLog: * gcc.target/aarch64/crc-crc32-data16.c: Fix iteration count to match testname. --- Do we need this as well? Untested so far.

Re: [committed] testsuite: Fix up atomic-inst-ldlogic.c

Jakub Jelinek writes: > Hi! > > r15-8956 changed in the test: > -/* { dg-final { scan-assembler-times "ldclr\t" 16} */ > +/* { dg-final { scan-assembler-times "ldclr\t" 16 } */ > which made it even worse than before, when the directive has > been silently ignored because it didn't match the regex

Re: [committed] cobol: Eliminate cobolworx UAT errors when compiling with -Os

ghtened out, everything is working without > the flag_strict_aliasing modification. > > Thanks for asking, and thanks for listening. > >> -Original Message- >> From: Robert Dubner >> Sent: Friday, April 4, 2025 16:02 >> To: Sam James >> Cc: GCC Patches &g

Re: [PATCH] wwwdocs: Clarify DCO name/identity and (anonymous) pseudonym policy

NightStrike writes: > How is an online only name different from an anonymous pseudonym? It doesn’t > seem to me that your changes actually > clarify anything. To me, they make it more ambiguous. The idea is to not have something throwaway (please also don't toppost).

Re: [committed] cobol: Eliminate cobolworx UAT errors when compiling with -Os

Robert Dubner writes: > From e70fe5ed46ab129a8b1da961c47d3fb75b11b988 Mon Sep 17 00:00:00 2001 > From: Bob Dubner mailto:rdub...@symas.com > Date: Fri, 4 Apr 2025 13:48:58 -0400 > Subject: [PATCH] cobol: Eliminate cobolworx UAT errors when compiling with > -Os > > Testcases compiled with -Os were

Re: [PATCH] testsuite: arm: Fix dg-final in short-vfp-1.c [PR119556]

Christophe Lyon writes: > Recent syntactic fixes enabled the test, but the result was failing. > > It turns out it was missing a space between the register arguments in > the scan-assembler-times directives. Great find, thanks. > > gcc/testsuite/ChangeLog: > > PR target/119556 > * g

Re: [committed] testsuite: Fix up atomic-inst-ldlogic.c

Christophe Lyon writes: > Le dim. 30 mars 2025, 22:10, Sam James a écrit : > > Jakub Jelinek writes: > > > Hi! > > > > r15-8956 changed in the test: > > -/* { dg-final { scan-assembler-times "ldclr\t" 16} */ > > +/* { dg-final { scan-

[PATCH] testsuite: arm: fixup more dg-final syntax

... as Richard E mentioned on the ML. Followup to r15-8956-ge90d6c2639c392. gcc/testsuite/ChangeLog: * gcc.target/arm/short-vfp-1.c: Add whitespace around brace. --- Pushed. gcc/testsuite/gcc.target/arm/short-vfp-1.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

Re: [PATCH] doc: document incremental LTO flags

Michal Jires writes: > On Thu, 2025-03-27 at 15:33:44 +0000, Sam James wrote: >> >> One thing I wasn't quite sure on yet: is -flto-partition=cache automatic >> with -flto-incremental? Or is it just an optional flag I can pass for >> more effective incrementa

Re: [PATCH 12/12] testsuite, s390: fix broken dg directives

David Malcolm writes: > Found by dg-lint. > > gcc/testsuite/ChangeLog: > * gcc.target/s390/target-attribute/tattr-1.c: Fix missing trailing > close brace on dg-do directive. > * gcc.target/s390/target-attribute/tattr-2.c: Likewise. I've cherry-picked the remaining ones and reso

Re: [PATCH 1/3] testsuite: harmless dg-* whitespace fixes

Harald Anlauf writes: > Sam, > > who approved the fortran testsuite changes? We've been doing them as obvious by consensus since last year. I'm sorry for the error. > > Am 27.03.25 um 14:28 schrieb Sam James: >> These just fix inconsistent/unusual style to avoid

Re: [PATCH 5/6] testsuite: fix more dg-* whitespace issues

Marek Polacek writes: > On Thu, Mar 27, 2025 at 12:38:55AM +0000, Sam James wrote: >> A handful of cosmetic ones in here but most meant the directive wasn't >> doing anything. > > This patch breaks g++.dg/template/explicit-args6.C for me. See PR119490. I can XFAIL i

[PATCH] testsuite: revert Fortran change

Revert part of my change from r15-8973-g1307de1b4e7d5e; as Harald points out, the comment explains why this is there. It's a hack but it needs to stay for now. (I did have this marked as a TODO in my branch and didn't leave a proper note as to why, so it's my fault.) gcc/testsuite/ChangeLog:

[PATCH] testsuite: aarch64: fix another unbalanced }

In r15-8956-ge90d6c2639c392, I missed one, so while it did fix a problem, it also exposed another because the braces were now unbalanced. There's IMO more to do here with ideally whitespace before the } when using scan-assembler-times but let's do that later. gcc/testsuite/ChangeLog: * g

Re: [PATCH] doc: document incremental LTO flags

Michal Jires writes: > This adds missing documentation for LTO flags. > > Ok? > > gcc/ChangeLog: > > * doc/invoke.texi: (Optimize Options): > Add incremental LTO flags. > --- > gcc/doc/invoke.texi | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) > >

[PATCH 3/3] testsuite: fix dg-* typos

I have a handful more of these left but those introduce FAILs, while these all introduce new PASSes. libstdc++-v3/ChangeLog: * testsuite/std/format/string_neg.cc: Add missing brace for dg-error. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/fd-datagram-socket.c: Fix 'dg-message' sp

[PATCH 2/3] testsuite: fix typos in comments

This fixes some 'scan-tree-dump-times' (vs '-time') typos and one or two others I noticed in passing. gcc/testsuite/ChangeLog: * g++.dg/warn/Winvalid-memory-model.C: Fix typo in comment. * gcc.dg/builtin-dynamic-object-size-19.c: Ditto. * gcc.dg/builtin-object-size-19.c: D

[PATCH 1/3] testsuite: harmless dg-* whitespace fixes

These just fix inconsistent/unusual style to avoid noise when grepping and also people picking up bad habits when they see it (as similar mistakes can be harmful). gcc/testsuite/ChangeLog: * c-c++-common/goacc/pr69916.c: Fix unusual whitespace in dg-*. * g++.old-deja/g++.abi/vtabl

  1   2   3   4   5   6   >