This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.
This problem only manifested when
This commit adds a new option to the driver that truncates one file after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o -truncate
gcc: error: missing filename after
Just fixes the link to the manual for the new -nostdlib++ option.
Signed-off-by: Andrew Pinski
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 6930bd58..4384c329 100644
---
Hi,
on 2024/4/18 10:01, HAO CHEN GUI wrote:
> Hi,
> This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
> bcdadd on two same numbers might cause overflow which also set
> overflow/invalid bit so that we can't distinguish it's invalid or overflow.
> The bcdsub doesn't have
On 2024-04-17 17:56, Peter Damianov wrote:
This commit adds a new option to the driver that truncates one file
after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o
Hi,
This patch replace bcdadd. with bcdsub. for bcd invalid number checking.
bcdadd on two same numbers might cause overflow which also set
overflow/invalid bit so that we can't distinguish it's invalid or overflow.
The bcdsub doesn't have the problem as subtracting on two same number never
Kindly ping^ for this ice fix.
Pan
-Original Message-
From: Li, Pan2
Sent: Saturday, April 6, 2024 8:02 PM
To: Li, Pan2 ; Jeff Law ; Robin Dapp
; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; richard.guent...@gmail.com;
Wang, Yanzhang ; Liu, Hongtao
Subject:
On Wed, Apr 17, 2024 at 5:57 PM Peter Damianov wrote:
>
> This commit adds a new option to the driver that truncates one file after
> linking.
>
> Tested likeso:
>
> $ gcc hello.c -c
> $ du -h hello.o
> 4.0K hello.o
> $ gcc hello.o -truncate hello
> $ ./a.out
> Hello world
> $ du -h hello.o
> $
This commit changes the Makefiles generated by lto-wrapper to no longer use
the "mv" and "touch" shell commands. These don't exist on Windows, so when the
Makefile attempts to call them, it results in errors like:
The system cannot find the file specified.
This problem only manifested when
This commit adds a new option to the driver that truncates one file after
linking.
Tested likeso:
$ gcc hello.c -c
$ du -h hello.o
4.0K hello.o
$ gcc hello.o -truncate hello
$ ./a.out
Hello world
$ du -h hello.o
$ 0 hello.o
$ gcc hello.o -truncate
gcc: error: missing filename after
On 4/17/24 11:44, Cupertino Miranda wrote:
> The BPF backend was allocating an unnecessarily large string when
> constructing CO-RE relocations for enum types.
>
> gcc/ChangeLog:
> * config/bpf/core-builtins.cc (process_enum_value): Correct
> string allocation.
> ---
>
The BPF backend was allocating an unnecessarily large string when
constructing CO-RE relocations for enum types.
gcc/ChangeLog:
* config/bpf/core-builtins.cc (process_enum_value): Correct
string allocation.
---
gcc/config/bpf/core-builtins.cc | 10 ++
1 file changed, 6
On Tue, Apr 16, 2024 at 5:52 AM Alexandre Oliva wrote:
>
>
> Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
> because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
> declared.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-13 on arm-,
> aarch64-, x86-
On Tue, Apr 16, 2024 at 5:51 AM Alexandre Oliva wrote:
>
>
> A few x86 tests get unexpected insn counts if the toolchain is
> configured with --enable-frame-pointer. Add explicit
> -fomit-frame-pointer so that the expected insn sequences are output.
>
> Regstrapped on x86_64-linux-gnu. Also
This patch fixes GCC Bug 108760:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
Before this patch, using std::ranges::iota required including when
it should have been sufficient to only include .
When the patch is applied, the following code will compile:
On Mon, 15 Apr 2024, Nathaniel Shead wrote:
> I'm not a huge fan of always streaming 'imported_temploid_friends' for
> all decls, but I don't think it adds much performance cost over adding a
> new flag to categorise decls that might be marked as such.
IIUC this value is going to be almost
>> Jose E. Marchesi writes:
>>
>>> Hi Cuper.
>>> Thanks for the patch.
>>>
This patch adds line_info debug information support to .BTF.ext
sections.
Line info information is used by the BPF verifier to improve error
reporting and give more precise source core referenced
> Jose E. Marchesi writes:
>
>> Hi Cuper.
>> Thanks for the patch.
>>
>>> This patch adds line_info debug information support to .BTF.ext
>>> sections.
>>> Line info information is used by the BPF verifier to improve error
>>> reporting and give more precise source core referenced errors.
>>>
On Wed, Apr 17, 2024 at 01:16:43PM -0400, Eric Gallager wrote:
> > --- a/libcpp/configure
> > +++ b/libcpp/configure
> > @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
> >
> >
> >
> > +
> > +
> > +
>
> So, this is kind of a minor style nitpick, but personally, it kind of
> bothers me
On Wed, Apr 17, 2024 at 10:03 AM Christophe Lyon
wrote:
>
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
>
> 2024-04-17 Christophe Lyon
>
> PR preprocessor/114748
> libcpp/
> * aclocal.m4: Regenerate.
> *
This ICE was caused by my patch r14-9489-g3fd46d859cda10. However, the ICE
hid a wrong error going back to at least 6.4.1 20180703. The patch fixes
both and exposed incorrect error messages in existing tests in gfortran.dg.
The fix for these was to add 'IMPLICIT NONE' in call cases so that there
Tested x86_64-linux and x86_64-freebsd. Pushed to trunk.
-- >8 --
This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature.
Jose E. Marchesi writes:
> Hi Cuper.
> Thanks for the patch.
>
>> This patch adds line_info debug information support to .BTF.ext
>> sections.
>> Line info information is used by the BPF verifier to improve error
>> reporting and give more precise source core referenced errors.
>>
>>
On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> On 04/04/2024 11:00, Alex Coplan wrote:
> > Hi,
> >
> > This adds a note to the GCC 14 release notes mentioning support for
> > __has_{feature,extension} (PR60512).
> >
> > OK to commit?
>
> Ping. Is this changes.html patch OK? I
Hi Cuper.
Thanks for the patch.
> This patch adds line_info debug information support to .BTF.ext
> sections.
> Line info information is used by the BPF verifier to improve error
> reporting and give more precise source core referenced errors.
>
> gcc/Changelog:
> *
On Mon, 15 Apr 2024, Nathaniel Shead wrote:
> I took another look at this patch and have split it into two, one (this
> one) to standardise the error messages used and prepare
> 'module_may_redeclare' for use with temploid friends, and another
> followup patch to actually handle them correctly.
>
Hi Cupertino.
OK for master.
Thanks!
> BPF supports multiple instructions to be CO-RE relocatable regardless of
> the position of the immediate field in the encoding.
> In particular, not only the MOV instruction allows a CO-RE
> relocation of its immediate operand, but the LD and ST
Hi Rainer!
On 4/17/24 10:13, Rainer Orth wrote:
Andrew Pinski writes:
On Mon, Apr 8, 2024 at 9:39 AM wrote:
From: Pierre-Emmanuel Patry
Hello,
The rust frontend requires cargo to build some of it's components,
it's presence was not checked during configuration.
WHY did this go in
On Wed, Apr 17, 2024 at 04:34:07PM +0200, Jan Hubicka wrote:
> I think for most scenarios this is OK, but I am not sure about
> incremental linking (both LTO and non-LTO). What seems wrong is that we
> produce C5 comdat that is not exporting what it should and thus breaking
> the invariant that in
>
> Ah, you're right.
> If I compile (the one line modified) pr113208_0.C with
> -O -fno-early-inlining -fdisable-ipa-inline -std=c++20
> it does have just _ZN6vectorI12QualityValueEC2ERKS1_ in
> _ZN6vectorI12QualityValueEC2ERKS1_
> comdat and no _ZN6vectorI12QualityValueEC1ERKS1_
> and
Hi Andrew,
> On 17 Apr 2024, at 14:59, Rainer Orth wrote:
>> The driver currently will remove "/lib" and "/usr/lib" from the library
>> path that gets passed to the linker because it considers them as paths that
>> the linker will already known to search. But this is not true for newer
>>
On Wed, Apr 17, 2024 at 03:26:53PM +0200, Jan Hubicka wrote:
> >
> > I've tried to see what actually happens during linking without LTO, so
> > compiled
> > pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> > (so it has those 2 separate comdats, one for C2 and one for
On Wed, Apr 17, 2024 at 02:01:55PM +, Christophe Lyon wrote:
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
>
> 2024-04-17 Christophe Lyon
>
> PR preprocessor/114748
> libcpp/
> * aclocal.m4: Regenerate.
> *
As discussed in the PR, aclocal.m4 and configure were incorrectly
regenerated at some point.
2024-04-17 Christophe Lyon
PR preprocessor/114748
libcpp/
* aclocal.m4: Regenerate.
* configure: Regenerate.
---
libcpp/aclocal.m4 | 1 +
libcpp/configure | 3 +++
2
Hi Andrew,
> The driver currently will remove "/lib" and "/usr/lib" from the library
> path that gets passed to the linker because it considers them as paths that
> the linker will already known to search. But this is not true for newer
> linkers, mold and lld for an example don't have a
>
> I've tried to see what actually happens during linking without LTO, so
> compiled
> pr113208_0.C with -O1 -fkeep-inline-functions -std=c++20 with vanilla trunk
> (so it has those 2 separate comdats, one for C2 and one for C1), though I've
> changed the
> void m(k);
> line to
>
On Wed, Apr 17, 2024 at 1:17 PM Jakub Jelinek wrote:
>
> Hi!
>
> Starting with GCC 14 we have the nice URLification of the options printed
> in diagnostics, say for in
> test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but
> argument 2 has type ‘long int’ [-Wformat=]
> the
On Wed, Apr 17, 2024 at 11:04:26AM +0200, Jan Hubicka wrote:
> > The reason the optimization doesn't trigger when the constructor is
> > constexpr is that expand_or_defer_fn is called in that case much earlier
> > than when it is not constexpr; in the former case it is called when we
> > try to
The following adds support for the various division and modulo operators
to the GIMPLE frontend via __{CEIL,FLOOR,ROUND}_{DIV,MOD} and
__EXACT_DIV operators.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.
Richard.
gcc/c/
* gimple-parser.cc
Hi!
Starting with GCC 14 we have the nice URLification of the options printed
in diagnostics, say for in
test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but argument
2 has type ‘long int’ [-Wformat=]
the -Wformat= is underlined in some terminals and hovering on it shows
Hi,
Test case builtins-6-p9-runnable.c doesn't work well on BE
due to two problems:
- When applying vec_xl_len onto data_128 and data_u128
with length 8, it expects to load 128[01] from
the memory, but unfortunately assigning 128[01] to
a {vector} {u,}int128 type variable,
Hi,
on 2024/4/17 17:05, jeevitha wrote:
> Hi,
>
> On 18/03/24 7:00 am, Kewen.Lin wrote:
>
>>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we
>>> should backport this fix. Segher and Ke Wen, can we get an approval
>>> to backport this to all the open release branches (GCC 13,
The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P
to its default of false when re-trying without SLP as otherwise
analysis may run into bogus asserts.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PR tree-optimization/114749
*
Ping!
please review.
Thanks & Regards
Jeevitha
On 26/03/24 10:23 am, jeevitha wrote:
> Ping!
>
> please review.
>
> Thanks & Regards
> Jeevitha
>
>
> On 26/02/24 11:13 am, jeevitha wrote:
>> Hi All,
>>
>> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>>
>>
Ping!
I've incorporated all the suggested changes. Please review.
Thanks & Regards
Jeevitha
On 21/03/24 6:21 pm, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> PTImode assists in generating even/odd register pairs on 128 bits.
Hi,
On 18/03/24 7:00 am, Kewen.Lin wrote:
>> The bogus vsx_splat_ code goes all the way back to GCC 8, so we
>> should backport this fix. Segher and Ke Wen, can we get an approval
>> to backport this to all the open release branches (GCC 13, 12, 11)?
>> Thanks.
>
> Sure, okay for backporting
> Hi!
Hello,
> The reason the optimization doesn't trigger when the constructor is
> constexpr is that expand_or_defer_fn is called in that case much earlier
> than when it is not constexpr; in the former case it is called when we
> try to constant evaluate that constructor. But
Applied as obvious
Johann
--
AVR: target/114752 - Fix ICE on inline asm const 64-bit float operand
gcc/
PR target/114752
* config/avr/avr.cc (avr_print_operand) [CONST_DOUBLE_P]:
Handle DFmode.
diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index
On Wed, 17 Apr 2024 at 09:17, Matthias Kretz wrote:
>
> This never showed up as an issue because it's an internal header and
> implicitly guarded by bits/simd.h.
>
> OK for trunk? Any reason to backport?
OK for trunk, I think it's worth backporting too.
>
> - 8<
On Wed, 17 Apr 2024 at 08:58, Matthias Kretz wrote:
>
> Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
>
> OK for trunk and backports?
OK, thanks.
>
> - 8< --
>
> This resolves failing tests in check-simd.
>
>
On 16/04/2024 20:01, Thomas Schwinge wrote:
Hi!
OK to push the attached "GCN: Enable effective-target 'vect_long_long'"?
(Or is that not what you'd expect to see for GCN? I haven't checked the
actual back end code...)
I think if there are still missing int64 vector operations then they're
This never showed up as an issue because it's an internal header and
implicitly guarded by bits/simd.h.
OK for trunk? Any reason to backport?
- 8< --
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
*
Andrew Pinski writes:
> On Mon, Apr 8, 2024 at 9:39 AM wrote:
>>
>> From: Pierre-Emmanuel Patry
>>
>> Hello,
>>
>> The rust frontend requires cargo to build some of it's components,
>> it's presence was not checked during configuration.
>
> WHY did this go in right before the release of GCC
Tested on arm-linux-gnueabihf, powerpc64le-linux-gnu, and aarch64-linux-gnu.
OK for trunk and backports?
- 8< --
This resolves failing tests in check-simd.
Signed-off-by: Matthias Kretz
libstdc++-v3/ChangeLog:
PR libstdc++/114750
Hi,
on 2024/4/17 13:12, HAO CHEN GUI wrote:
> Hi,
> This patch fixes loss of return statement in maxbcd of bcd-4.c. Without
> return statement, it returns an invalid bcd number and make the test
> noneffective. The patch also enables test to run on Power9 and Big Endian,
> as all bcd
Hi!
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that
On Wed, 17 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> .ABNORMAL_DISPATCHER is currently the only internal function with
> ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding
> some builtin call before them, which breaks the .ABNORMAL_DISPATCHER
> discovery added in gsi_safe_*.
Hi!
.ABNORMAL_DISPATCHER is currently the only internal function with
ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding
some builtin call before them, which breaks the .ABNORMAL_DISPATCHER
discovery added in gsi_safe_*.
The following patch fixes asan not to instrument
On 4/17/24 03:52, Jiufu Guo wrote:
>
> Hi,
>
> I would like to ping this patch.
>
>
> Jeff (Jiufu Guo)
>
> Jiufu Guo writes:
>
>> Hi,
>>
>> Same like PR101168, this patch is need for s390 to
>> avoid peeking eof after vector keyword.
>> And similar test case is also ok for s390.
>>
>> Is
59 matches
Mail list logo
