Hello, Christophe,
On Feb 10, 2024, Christophe Lyon wrote:
> gcc/
> * Makefile.in: Add no-info dependency.
> * configure.ac: Set BUILD_INFO=no-info if makeinfo is not
> available.
> * configure: Regenerate.
Thank you, this is ok.
Now, this doesn't fix a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
--- Comment #2 from Andrew Pinski ---
Note `PERM<{0},a,{1,2,3,4}>` should be handled too, that means defining
`vec_shl_` patterns too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113872
Bug ID: 113872
Summary: PERM<{0},a,{3,4,5,6}> is not producing SHL (for
little-endian) and USHR for big-endian
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
Bug ID: 113871
Summary: psrlq is not used for PERM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
On Sat, Feb 10, 2024 at 08:01:46PM -0800, Andrew Pinski wrote:
> On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
> wrote:
> >
> > Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> > x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
> >
> > (Also I noticed I forgot to
On Sat, Feb 10, 2024 at 7:55 PM Nathaniel Shead
wrote:
>
> Bootstrapped and regtested (so far just modules.exp and dg.exp) on
> x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
>
> (Also I noticed I forgot to add the PR to the changelog in my last
> patch, I've fixed that locally.)
>
>
Bootstrapped and regtested (so far just modules.exp and dg.exp) on
x86_64-pc-linux-gnu, OK for trunk if full regtest succeeds?
(Also I noticed I forgot to add the PR to the changelog in my last
patch, I've fixed that locally.)
-- >8 --
After fixing PR111710, I noticed that we currently ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113870
Andrew Pinski changed:
What|Removed |Added
Depends on||113869
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113870
Bug ID: 113870
Summary: Add V2HF support
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113869
Bug ID: 113869
Summary: V4HF->V4SF pattern seems to be missing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
On 2/2/24 23:55, Jonathan Yong wrote:
Attached patch OK? Fixes the following warnings:
coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in
function ‘memcpy’; expected ‘void *(void *, const void *, long long
unsigned int)’ [-Wbuiltin-declaration-mismatch]
17 |
Problem solved.
I didn't have this:
#define SIZE_TYPE (TARGET_64BIT ? "long unsigned int" : "unsigned int")
because I wasn't including x86_64.h.
This is the first time I have attempted to go to 64-bit pointers
so I wasn't aware this even existed.
So here it is doing Win64 ABI:
Hello,
I have implemented a patch that fixes compile time errors for valid PDT
type-bound procedures. I wrote 4 new tests that address the test-cases in
PR 82943, PR 86148, and PR 86268, since the patch fixes all three of them.
All regression tests pass, including the new ones. This was tested
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should I re-introduce the tree checking and just add checks for the
new kinds of declarations that could be have keyed decls?
-- >8 --
The fix for PR107398 weakened the restrictions that lambdas must belong
to namespace scope.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Jason, this is the patch you proposed for PR113545. It looks very safe
so I'm posting it here so that it's not forgotten.
PR c++/113545
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_switch_expr): If the
Snapshot gcc-13-20240210 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20240210/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi!
On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote:
>
> Hello, Christophe,
>
> Thanks for the patch.
>
> On Feb 5, 2024, Christophe Lyon wrote:
>
> > In order to save build time, our CI overrides BUILD_INFO="", which
> > works when invoking 'make all' but not for 'make install' in case
> "Andrew" == Andrew Burgess writes:
Andrew> Tom Tromey writes:
>> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
>>
>> This patch caused problems for some users when building gdb, because
>> it would cause 'guild' to be invoked with the wrong versin of guile.
>> On the
I managed to try this patch on aarch64-linux-gnu:
This is the test run without your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html
And this is the "result" with your patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html
For me, as for
On 2023-08-28 10:09, Kaz Kylheku wrote:
> On 2022-06-13 16:13, Kaz Kylheku wrote:
>> Pinging this item:
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593473.html
>>
>> Thanks.
Again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
Probably stage1 material but it should be safe...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
On the heels of r14-8903, this patch adds further complain parameters
so that we don't emit "invalid use of incomplete type" from inside
a concept.
PR c++/112436
(replying to Joe Monk)
> It appears that this is not an issue that this version of GCC is
> architected to be able to solve.
> The first 64-bit PC processor, the AMD opteron series, was launched on
> April 22, 2003.
> GCC 3.2.3 was released on April 25, 2003.
Jakub has already shown correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113868
Bug ID: 113868
Summary: error: expression function must be enclosed in
parentheses.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Hello,
I have added myself to write after approval.
Thanks,
Alexander Westbrooks
>From 564b307970d3be7a02e827420f0fad87bd335d9b Mon Sep 17 00:00:00 2001
From: Alexander Westbrooks
Date: Sat, 10 Feb 2024 12:20:00 -0600
Subject: [PATCH] Add Myself to Write After Approval and DCO List
On Sat, Feb 10, 2024 at 07:35:22PM +0100, Marc Glisse wrote:
> On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
>
> > So, how does one biulding all parts of gcc with "-O -g"?
> >
> > In my shell script, I have
> >
> > CFLAGS="-O -g"
> > export CFLAGS
> >
> > CXXFLAGS="-O -g"
> > export CXXFLAGS
On Sat, 10 Feb 2024, Jason Merrill wrote:
> On 2/9/24 17:11, Patrick Palka wrote:
> > On Fri, 9 Feb 2024, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > I'll try to reduce and add testcases overnight for these
On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work
So, how does one biulding all parts of gcc with "-O -g"?
In my shell script, I have
CFLAGS="-O -g"
export CFLAGS
CXXFLAGS="-O -g"
export CXXFLAGS
BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS
../gcc/configure --prefix=$HOME/work --enable-languages=c,c++,fortran \
--enable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111342
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #5 from Tobias Burnus ---
The runtime issue is now PR113867.
The new testcase gcc.target/i386/asm-raw-symbol.c fails on darwin. This is
partly because symbols are prefixed with underscore, and also because the order
of operands in the addition is reversed (but I think it’s valid still). The
code generated is this:
_func:
LFB0:
pushq %rbp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #1 from Tobias Burnus ---
Created attachment 57382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57382=edit
Fortran testcase, kind of, as pointer + pointee mapping cannot be split
(working)
For completeness, a Fortran
On Sat, Feb 10, 2024 at 9:46 AM Jakub Jelinek wrote:
>
> On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
> > PR target/113855
> >
> > gcc/ChangeLog:
> >
> > * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
> > available to all sub-targets.
> > *
> On 10 Feb 2024, at 17:46, Jakub Jelinek wrote:
>
> On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
>> PR target/113855
>>
>> gcc/ChangeLog:
>>
>> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
>> available to all sub-targets.
>> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
Bug ID: 113867
Summary: [14 Regression][OpenMP] Wrong code with mapping
pointers in structs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2024-02-10
Ever
Three new tests using -mcmodel=large, which darwin does not support. Skipping
them.
Pushed as obvious.
FX
0001-Darwin-testsuite-skip-some-mcmodel-large-tests.patch
Description: Binary data
On Sat, Feb 10, 2024 at 05:14:44PM +, Iain Sandoe wrote:
> PR target/113855
>
> gcc/ChangeLog:
>
> * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
> available to all sub-targets.
> * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
> *
It appears that this is not an issue that this version of GCC is
architected to be able to solve.
The first 64-bit PC processor, the AMD opteron series, was launched on
April 22, 2003.
GCC 3.2.3 was released on April 25, 2003.
"*Opteron* is AMD
rom the flang testsuite at
https://github.com/llvm/llvm-project/tree/main/flang/test
when compiled by recent gfortran, does this:
est $ ~/gcc/results.20240210.asan.ubsan/bin/gfortran -c -w
./Lower/HLFIR/bindc-assumed-length.f90
./Lower/HLFIR/bindc-assumed-length.f90:39:29:
39 | c
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and have
tracked done some of the unexpected behaviour
GDB makes use of the libiberty function buildargv for splitting the
inferior (program being debugged) argument string in the case where
the inferior is not being started under a shell.
I have recently been working to improve this area of GDB, and noticed
some unexpected behaviour to the libiberty
I realise that these patches are not going to get merged until GCC is
back in stage 1, but thought I'd post my latest set of changes for the
libiberty buildargv function.
Patch #1 is unchanged from V1.
Patch #2 is new in V2.
Thanks,
Andrew
---
Andrew Burgess (2):
libiberty/buildargv: POSIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113846
--- Comment #2 from David Binderman ---
>From the same flang test suite, the following files seem to crash in the
same routine:
./Lower/HLFIR/structure-constructor.f90
./Lower/HLFIR/convert-mbox-to-value.f90
./Lower/polymorphic-temp.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113865
Bug ID: 113865
Summary: FAIL: rust/execute/torture/issue-2187.rs -O0 output
pattern test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113865
Bug ID: 113865
Summary: FAIL: rust/execute/torture/issue-2187.rs -O0 output
pattern test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113864
Bug ID: 113864
Summary: FAIL: rust/debug/chartype.rs scan-assembler 0x10[
\t][^\n\r]* DW_AT_encoding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113864
Bug ID: 113864
Summary: FAIL: rust/debug/chartype.rs scan-assembler 0x10[
\t][^\n\r]* DW_AT_encoding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
I have so far tested this on i686-darwin17 and on x86_64-linux (with 32b
multilib )with the following permutations:
C (dg.exp=*nest*), Ada :
\{-m64,-m32\}\{,-ftrampoline-impl=heap\}\{,-shared-libgcc\}
Fortran \{-m64,-m32\}\{,-ftrampoline-impl=heap\}
The only fails [gnat] are expected (scanning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113473
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113473
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113472
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113472
John David Anglin changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
Filip Kastl changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107700
--- Comment #2 from John David Anglin ---
Regarding const-issue1440.rs and issue-1432.rs, here are the errors
on hppa64-hp-hpux11.11:
FAIL: rust/compile/const-issue1440.rs (test for excess errors)
Excess errors:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107700
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113792
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112436
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #5 from Iain Sandoe ---
AFAICT, this was fixed on trunk by r14-6721-gd31c54c7da7661 (which seems to
have a reference to the PR so not sure why it did not show up here).
I think we need this on any open branch which we want to work
On 2024-02-10 6:52 a.m., Iain Sandoe wrote:
On 10 Feb 2024, at 11:33, FX Coudert via Gcc wrote:
I’m seeing the following analyzer test failures on darwin. They were introduced
in December, when the tests were moved around:
FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
--- Comment #7 from Marek Polacek ---
The ICE was fixed by r14-8903-g3a3e0f1b46a3ad. But I'm not done here yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112864
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many libphobos tests FAIL
I have confirmed that this updated pr97969.c file still hangs with
gcc-arm-none-eabi-9-2020-q2-update as mentioned in comment 2 of PR97969.
Ok for trunk?
--
The test case for PR97969 needs updates in order to comply with recent
changes in GCC14. Without these changes, failures like this can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Many|Many obj-c++ tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] gfortran.dg |gfortran.dg coarray tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
Iain Sandoe changed:
What|Removed |Added
Summary|[14 regression] Most gdc|Most gdc tests FAIL on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113853
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
> On 10 Feb 2024, at 14:54, FX Coudert wrote:
>
> With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is
> obsolete
>
> The patches ignores the warning when present.
> OK to push?
yes, thanks.
Iain
… although part of me is curious about whether we still have any
With Xcode 15, gcc.dg/ssp-2.c fails due to a warning: -multiply_defined is
obsolete
The patches ignores the warning when present.
OK to push?
FX
0001-Darwin-testsuite-multiply_defined-is-obsolete.patch
Description: Binary data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #12 from Sam James ---
Created attachment 57379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57379=edit
test.c
Here's an initial stab at a standalone testcase. I'm going to try reduce it
now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #5)
> I'm wondering if we need to worry about other actual
> arguments. I note
>
> subroutine test_adjustl(x)
> character(*) :: x(100)
>x =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #13 from Дилян Палаузов ---
For clang being buggy from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679#c11 I filled
https://github.com/llvm/llvm-project/issues/81358 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854
--- Comment #3 from Jonathan Wakely ---
*unintended symptom deep inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854
--- Comment #2 from Jonathan Wakely ---
And those are not library internals, they're the public concepts defined in the
standard. You can look them up to see what they mean, but the problem boils
down to what's shown at the end: your predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113854
--- Comment #1 from Jonathan Wakely ---
Anybody who promised concepts will always result in better errors was lying or
misinformed. They have the potential to help, but it takes real effort to make
it happen.
ranges::find_if is constrained to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #5 from Jakub Jelinek ---
Comment on attachment 57378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378
patch under test
s/jumpl/jmpl/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855
--- Comment #4 from Iain Sandoe ---
Created attachment 57378
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=edit
patch under test
This implements the common case for an i386 trampoline (and, in this respect,
matches the
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html
May I please ping this one? Thanks!
On Sat, Jan 13, 2024 at 5:12 PM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704
>
> The below patch fixes the issue noted in the PR that extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455
--- Comment #7 from newbie-02 ---
> (and GCC doesn't implement the FENV_DEC_ROUND pragma to set a constant
> rounding mode in a particular scope)
here we are leaving my level of knowledge about internals.
Let me formulate from a user /
I have it down to a deliberate conversion from signed
to unsigned:
temp.txt: bbb piss ccc 32 32
temp.txt: bbb piss ccc2 0 1
temp.txt: bbb piss ddd -2
temp.txt: bbb - in convert
temp.txt: bbb - converting to integer
temp.txt: bbb y stage1
temp.txt: bbb y stage2
temp.txt: bbb y outprec thing,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:cff174fabd6c980c09aee95db1d9d5c22421761f
commit r14-8915-gcff174fabd6c980c09aee95db1d9d5c22421761f
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:cff174fabd6c980c09aee95db1d9d5c22421761f
commit r14-8915-gcff174fabd6c980c09aee95db1d9d5c22421761f
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113863
Bug ID: 113863
Summary: [14 Regression] ICE verify_ssa failed with -O3
-msse4.1 since r14-8768
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
[Public]
Hi all,
PFA, the patch that enables support for the next generation AMD Zen5 CPU via
-march=znver5 with basic znver5 scheduler Model.
We may update the scheduler model going forward.
Good for trunk?
Thanks and Regards
Karthiban
Resending the patch, as unable to inline the
> On 10 Feb 2024, at 12:07, Jason Merrill wrote:
>
> On 2/10/24 05:46, Iain Sandoe wrote:
>>> On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
>>>
>>>
>>>
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
> On 8 Feb 2024, at 21:44, Jason Merrill wrote:
>
> On 2/8/24 12:55, Paolo
On 2/9/24 17:11, Patrick Palka wrote:
On Fri, 9 Feb 2024, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
I'll try to reduce and add testcases overnight for these separate bugs
before pushing.
-- >8 --
Building modular fmtlib triggered
On 2/9/24 16:50, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk
-- >8 --
It turns out that with modules we can call mangle_decl recursively,
which is a problem because the global mangling state isn't recursion
aware. The recursion happens
On 2/10/24 05:46, Iain Sandoe wrote:
On 9 Feb 2024, at 23:21, Iain Sandoe wrote:
On 9 Feb 2024, at 10:56, Iain Sandoe wrote:
On 8 Feb 2024, at 21:44, Jason Merrill wrote:
On 2/8/24 12:55, Paolo Bonzini wrote:
On 2/8/24 18:16, Jason Merrill wrote:
Hmm. In stage 1, when we build
Hi FX,
> On 10 Feb 2024, at 11:58, FX Coudert wrote:
>
> With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning:
> ld: warning: -bind_at_load is deprecated on macOS
>
> The patches ignores the warning when present.
> OK to push?
Yes, thanks.
Iain
I guess for GCC-15 we might need to see
With Xcode 15, gcc.dg/darwin-ld-2.c fails due to a warning:
ld: warning: -bind_at_load is deprecated on macOS
The patches ignores the warning when present.
OK to push?
FX
0001-Darwin-testsuite-bind_at_load-is-deprecated.patch
Description: Binary data
> On 10 Feb 2024, at 11:33, FX Coudert via Gcc wrote:
> I’m seeing the following analyzer test failures on darwin. They were
> introduced in December, when the tests were moved around:
>
> FAIL: c-c++-common/analyzer/fd-glibc-byte-stream-socket.c
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #4 from Tobias Burnus ---
Created attachment 57377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57377=edit
Fixes the ICE – might paper over a real issue; doesn't fix the run-time issue →
TODO + 'data'-issue in PR comment 4
> Am 10.02.2024 um 11:03 schrieb Jakub Jelinek :
>
> Hi!
>
> torture/bitint-37.c test FAILed on i686-linux e.g. on
> signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
> __builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
> the IL, 2 in a loop (which handles
> Am 10.02.2024 um 10:56 schrieb Jakub Jelinek :
>
> Hi!
>
> The ia32 _BitInt support revealed a bug in floatbitint?d.c.
> As can be even guessed from how the code is written in the loop,
> the intention was to set inexact to non-zero whenever the remainder
> after division wasn't zero, but
1 - 100 of 121 matches
Mail list logo
