"H.J. Lu" writes:
> On Mon, Sep 8, 2025 at 7:31 AM Sam James wrote:
>>
>> This didn't show up in my inbox for some reason, so sorry for awkward
>> reply:
>>
>> Can you do this? { dg-additional-options "-fPIE" { target pie } }
>>
Needed to add -fdep-fusion.
gcc/ChangeLog:
* common.opt.urls: Regenerate.
---
gcc/common.opt.urls | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/common.opt.urls b/gcc/common.opt.urls
index 3684edd63073..ddc5eaf9c6be 100644
--- a/gcc/common.opt.urls
+++ b/gcc/common.opt.urls
@
Gentoo uses hppa1.1*-*-linux* and hppa2.0*-*-linux* instead of Debian's
hppa-*-linux*.
libphobos/ChangeLog:
* configure.tgt: Add hppa[12]*-*-linux* as a supported target.
---
I thought I'd posted this ages ago but I can't find it right now. Tested
though with a full bootstrap chain from 1
Sam James writes:
> Sam James writes:
>
>> Back in GCC 8, with r8-5241-g8697bf9f46f361 (-gstatement-frontiers),
>> r8-6658-g58006663903200, r8-6657-gbd2b9f1e2d67ec (-gvariable-location-views),
>> some advanced GNU extensions to DWARF were introduced and enabled by de
--param verify-canonical-types was removed back in r0-81986-g7313518b90b280.
The same verification is controlled via our generic checking framework
these days.
gcc/ChangeLog:
* doc/generic.texi (TYPE_CANONICAL): Don't mention long-removed
--param verify-canonical-types=1.
---
I w
GNU Binutils now supports linking LTO and non-LTO objects into a single
mixed object file as of 2.44. Update the text to reflect this and fix
some minor grammar issues while at it.
gcc/ChangeLog:
PR ipa/116410
* doc/invoke.texi (Link Options): Update -flinker-output= text
"John Ericson" writes:
> The change looks good to me. Sorry about the breakage.
>
> (For context, after making the return type polymorphic, I was experiment with
> removing assumptions that it is even a
> pointer, but I never actually did that. The removal of the `= NULL` was just
> a stray bit
Unchanged instances are deliberate.
gcc/ChangeLog:
* doc/invoke.texi: Say 'whole-program' consistently where
appropriate.
---
OK?
gcc/doc/invoke.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a8585
Gerald Pfeifer writes:
> On Sat, 6 Sep 2025, Sam James wrote:
>> gcc/ChangeLog:
>>
>> * doc/generic.texi (TYPE_CANONICAL): Don't mention long-removed
>> --param verify-canonical-types=1.
>
> Okay. Just drop "=1" from the ChangeLog entry
For x86, the option is -momit-leaf-frame-pointer, not -fomit-leaf-frame-pointer.
gcc/ChangeLog:
* doc/invoke.texi (x86 Options): Fix '-momit-leaf-frame-pointer' typo.
---
Pushed.
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi
Gerald Pfeifer writes:
> Sam noticed that we had GNU Binutils capitalized inconsistently in
> doc/invoke.texi which motivated me to check other parts of our docs.
>
> This patch addresses the majority of remaining occurrences in our docs.
>
> Pushed.
>
> Gerald
Thanks for doing that, I should'v
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 the native compiler is buggy, there's a greater
risk of a failed bootst
Sandra Loosemore writes:
> On 9/6/25 08:18, Sam James wrote:
>> Sam James writes:
>>
>>> GNU Binutils now supports linking LTO and non-LTO objects into a single
>>> mixed object file as of 2.44. Update the text to reflect this and fix
>>> some min
Sam James writes:
> GNU Binutils now supports linking LTO and non-LTO objects into a single
> mixed object file as of 2.44. Update the text to reflect this and fix
> some minor grammar issues while at it.
>
> gcc/ChangeLog:
> PR ipa/116410
>
> * doc/invoke.tex
gcc/ChangeLog:
* doc/invoke.texi: Capitalize 'GNU Binutils' consistently.
---
OK?
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 46b13abee98a..a8585b01437a 100644
--- a/gcc/doc/invoke.texi
+++ b/
Andi Kleen writes:
>> Thanks both!
>
> For modules the Makefile needs to be adjusted to run final LTO before
> modpost etc. These were the respective hunks from the old patchkit
> (may need some tweaks)
Thanks Andi. This got me further:
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -
Andi Kleen writes:
> Sam James writes:
>
>> Michal Jires writes:
>>
>>> I did handle node->iterate_referring, but forgot cnode->callers.
>>>
>>> Only change are contents of the newly separated
>>> mark_symbol_referenced_from_
Richard Sandiford writes:
> In order to reduce time complexity, rtl-ssa groups consecutive
> clobbers together. Each group of clobbers has a splay tree for
> lookup and manipulation purposes.
>
> This arrangement means that we might need to split a group (when
> inserting a new non-clobber defin
Michal Jireš writes:
> On 9/4/25 8:53 PM, Sam James wrote:
>> Sam James writes:
>>
>>> Andi Kleen writes:
>>>
>>>> Sam James writes:
>>>>
>>>>> Michal Jires writes:
>>>>>
>>>>>> I did
Sam James writes:
> Andi Kleen writes:
>
>> Sam James writes:
>>
>>> Michal Jires writes:
>>>
>>>> I did handle node->iterate_referring, but forgot cnode->callers.
>>>>
>>>> Only change are contents of the newly s
Jakub Jelinek writes:
> On Thu, Sep 04, 2025 at 09:58:14AM +0200, Richard Biener wrote:
>> I'm in favor of disabling but I also fear the code will bitrot quickly if so?
>> We might also want to have a set of testcases for the -fcompare-debug
>> issues that are fixed by the change of defaults?
>>
Sam James writes:
> Michal Jires writes:
>
>> I did handle node->iterate_referring, but forgot cnode->callers.
>>
>> Only change are contents of the newly separated
>> mark_symbol_referenced_from_asm
>
> Thanks, I'll try the new patch now.
>
&g
Michal Jires writes:
> I did handle node->iterate_referring, but forgot cnode->callers.
>
> Only change are contents of the newly separated
> mark_symbol_referenced_from_asm
Thanks, I'll try the new patch now.
With the workaround I mentioned earlier, I managed to build but got this
when booting
Michal Jireš writes:
> On 9/3/25 7:58 PM, Sam James wrote:
>> Michal Jires writes:
>>
>>> Check that must_remain_in_tu is partitioned correctly, and that
>>> refereced_from_asm is not renamed.
>>>
>>> gcc/lto/ChangeLog:
>>>
>>
Sam James writes:
> Back in GCC 8, with r8-5241-g8697bf9f46f361 (-gstatement-frontiers),
> r8-6658-g58006663903200, r8-6657-gbd2b9f1e2d67ec (-gvariable-location-views),
> some advanced GNU extensions to DWARF were introduced and enabled by default
> with the aim of improving debuggi
Back in GCC 8, with r8-5241-g8697bf9f46f361 (-gstatement-frontiers),
r8-6658-g58006663903200, r8-6657-gbd2b9f1e2d67ec (-gvariable-location-views),
some advanced GNU extensions to DWARF were introduced and enabled by default
with the aim of improving debugging optimized code.
Unfortunately, as of y
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
Michal Jires writes:
> Check that must_remain_in_tu is partitioned correctly, and that
> refereced_from_asm is not renamed.
>
> gcc/lto/ChangeLog:
>
> * lto-partition.cc (lto_1_to_1_map): must_remain_in_tu check.
> (privatize_symbol_name_1): refereced_from_asm check.
I get this when
Tobias Burnus writes:
> Hi Andre, hi all,
>
> Andre Vehreschild wrote:
>
> I am experiencing a strange issue with gfortran. Compiling a simple program:
>
> $ cat end.f90
> end
> $ gfortran end.f90 -o end
> f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,'
> compilation terminated.
Andi Kleen writes:
> That said the automatic scanning of identifiers still seems like a
> useful option to have. I bet the kernel is not the only software
> with this issue.
Off the top of my head, there's PHP and Valgrind.. I'd have to go
looking for more (of course projects have added workarou
Andrew Pinski writes:
> On Tue, Sep 2, 2025 at 9:22 PM Sam James wrote:
>>
>> Andi Kleen writes:
>>
>> > That said the automatic scanning of identifiers still seems like a
>> > useful option to have. I bet the kernel is not the only software
>> &g
Nathanial Sloss writes:
> Hi
>
> There are issues with m68k softfloat (fpgnulib.c) not perserving NaNs and Inf
> when converting from (long) double and float types.
>
> This issue has been documented in a NetBSD PR:
>
> http://gnats.netbsd.org/59616
>
> Addressed by the attached patch which sets
Nathanial Sloss writes:
> Hi,
>
> The m68k m68lc040 (early revisions) have an issue after executing f-line (co
> processor mmu/fpu) instructions and executing a trap in the case of fpu
> emulation.
>
> Unfornately due to time passed the processor errata as to how to address the
> issue has bee
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:
>&
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:
&
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
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
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
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.
>> >
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
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
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
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
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
"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
"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
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/
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
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
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 (
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
> ---
>
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
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-
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".
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
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é
.. 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
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
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/
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
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
>
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
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
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
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
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.
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
"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
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.
>>
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
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
"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
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
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
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
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
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
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
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
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
>
>
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
>
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
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
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
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
>> >
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
1 - 100 of 545 matches
Mail list logo
