From: Pan Li
This patch depends on below ICE fix.
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647915.html
The function target attribute should be on a per-function basis.
For example, we have 3 function as below:
void test_1 () {}
void __attribute__((target("arch=+v"))) test_2 () {}
Thanks to you doc:
libstdc++: [_GLIBCXX_DEBUG] Define __[glibcxx,cpp_lib]_null_iterators
_GLIBCXX_DEBUG has now fully N3344 compliant iterator checks, we
can define
__glibcxx_null_iterators and __cpp_lib_null_iterators macros like
the normal
mode.
libstdc++-v3/ChangeLog:
This patch adds some simple tests for -mcpu=power11 support. In order to run
these tests, you need an assembler that supports the appropriate option for
supporting the Power11 processor (-mpower11 under Linux or -mpwr11 under AIX).
I have tested this patch on a little endian power10 system and a
This patch adds the power11 option to the -mcpu= and -mtune= switches.
This patch treats the power11 like a power10 in terms of costs and reassociation
width.
This patch issues a ".machine power11" to the assembly file if you use
-mcpu=power11.
This patch defines _ARCH_PWR11 if the user uses -mc
This patch makes -mtune=power11 use the same tuning decisions as
-mtune=power10.
I have tested this patch on a little endian power10 system and a big endian
power9 system. There were no regressions. Can I check this into GCC 15 when
it is open for general patches?
2024-03-18 Michael Meissner
These three patches add support for -mcpu=power11 to the PowerPC GCC compiler.
There are 3 patches in the set. I would like to check these patches into GCC
15 ASAP, and back port the patches into GCC 14 after GCC 14.1 ships. I hope to
also back port these patches to other active branches after t
Pushed to r14-9562...r14-9564.
在 2024/3/15 上午9:30, Chenghui Pan 写道:
Changes from v1: Some correction about ChangeLog format.
There's some unused/redundant definitions inside LoongArch target support
codes, these patches make a simple cleanup. Regression test passed.
Chenghui Pan (3):
LoongA
gcc/ChangeLog:
* doc/invoke.texi: Document -fexcess-precision=16.
---
gcc/doc/invoke.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 85c938d4a14..6bc1ebf9721 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -14930,6
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
This test fails in C++11 due to:
linkage-1.C:3:8: error: 'f' function uses 'auto' type specifier without
trailing return type
3 | inline auto f() {
|^~~~
linkage-1.C:3:8: note: deduced return type only available with '-std
On Tue, 19 Mar 2024 13:05:54 PDT (-0700), Vineet Gupta wrote:
On 3/19/24 06:10, Jeff Law wrote:
On 3/19/24 12:48 AM, Andrew Waterman wrote:
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99829
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and aarch64.
commit 9c91f8a88b2db50c8faf70786d3cef27b39ac9fc
Author: Vladimir N. Makarov
Date: Tue Mar 19 16:57:11 2024 -0400
[PR99829][L
On Tue, Mar 19, 2024 at 1:05 PM Vineet Gupta wrote:
>
>
>
> On 3/19/24 06:10, Jeff Law wrote:
> > On 3/19/24 12:48 AM, Andrew Waterman wrote:
> >> On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
> >>> On 3/16/24 13:21, Jeff Law wrote:
> | 59944:add s0,sp,2047 <
> |
On Tue, 19 Mar 2024 12:58:41 PDT (-0700), Andrew Waterman wrote:
On Tue, Mar 19, 2024 at 9:23 AM Palmer Dabbelt wrote:
On Mon, 18 Mar 2024 20:50:14 PDT (-0700), jeffreya...@gmail.com wrote:
>
>
> On 3/18/24 3:09 AM, Jivan Hakobyan wrote:
>> As RV has round instructions it is reasonable to use
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-14.1-b20240218.de.po',
From: Jakub Jelinek
Jakub wrote this patch for PR analyzer/113505.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9555-gc87f1f3d660f41.
gcc/analyzer/ChangeLog
PR analyzer/113505
On 3/19/24 06:10, Jeff Law wrote:
> On 3/19/24 12:48 AM, Andrew Waterman wrote:
>> On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
>>> On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2,a0
| 5994c:mv a3,a1
| 59
On Tue, Mar 19, 2024 at 9:23 AM Palmer Dabbelt wrote:
> On Mon, 18 Mar 2024 20:50:14 PDT (-0700), jeffreya...@gmail.com wrote:
> >
> >
> > On 3/18/24 3:09 AM, Jivan Hakobyan wrote:
> >> As RV has round instructions it is reasonable to use them instead of
> >> calling the library functions.
> >>
>
On Tue, 19 Mar 2024, Hongtao Liu wrote:
> On Tue, Mar 19, 2024 at 12:16 AM Joseph Myers wrote:
> >
> > On Mon, 18 Mar 2024, liuhongt wrote:
> >
> > > +If @option{-fexcess-precision=16} is specified, casts and assignments of
> > > +@code{_Float16} and @code{bfloat16_t} cause value to be rounded to
Ping. Though I reckon it may be better to defer this to 15.
On Fri, Mar 01, 2024 at 07:58:51PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't
> claim that this has to go to 14 though.
>
> -- >8 --
> ...from another array in a mem-initializer s
On Thu, Mar 14, 2024 at 05:26:59PM -0400, Marek Polacek wrote:
> @@ -1441,11 +1406,13 @@ static tree
> replace_placeholders_for_class_temp_r (tree *tp, int *, void *data)
> {
>tree t = *tp;
> - tree full_expr = *static_cast(data);
> + auto pset = static_cast *>(data);
>
>/* We're look
On Mon, Mar 18, 2024 at 09:10:27PM -0400, Jason Merrill wrote:
> On 3/15/24 13:48, Marek Polacek wrote:
> > On Thu, Mar 14, 2024 at 03:39:04PM -0400, Jason Merrill wrote:
> > > On 3/8/24 12:02, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > > >
> > >
Various values of -fdiagnostics-format= request machine-readable output
on stderr, using JSON, but in various places we use fnotice to write
free-form text to stderr, such as "compilation terminated", leading to
corrupt JSON.
Fix by having fnotice skip the output for such cases.
Successfully boot
On Tue, 2024-03-19 at 09:03 -0400, Lewis Hyatt wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
Sorry about the delay.
The patch looks good for trunk, assuming it's passed the usual
bootstrap and regression testing.
Thanks
Dave
>
> Thanks!
>
> On Fri, Feb 16, 2024
Hi Mikael,
This is very good. I am pleased to see global variables disappear and I
like the new helper functions.
As before, OK for mainline and, if you wish, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> This fixes a spurious invalid variable in specification e
Hi Mikael,
Sorry, I am replying to these in the order that they appear in my intray :-)
OK for mainline and, if you wish, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> Hello,
>
> these patches correct diagnostics dealing with variables in specification
> express
On 2024-03-18 00:30, Jonathan Wakely wrote:
> I don't have an opinion on the implementation, or the proposal itself,
> except that the implementation seems susprisingly simple, which is
> nice.
Hi Jonathan,
Here is an updated patch.
It rebased cleanly over more than newer 16000 commits, suggesti
Hi Mikael,
This looks completely "obvious" to me. OK for mainline and, I would
suggest, 13-branch.
Thanks
Paul
On Tue, 19 Mar 2024 at 15:49, Mikael Morin wrote:
> This fixes invalid undeclared fortran array bound variables
> in the testsuite.
>
> gcc/testsuite/ChangeLog:
>
> * gfort
On 3/13/24 07:24, Cupertino Miranda wrote:
> Any unnamed structure field if not a member of the BTF_KIND_STRUCT.
typo: if -> is
I'd suggest to clarify that "any unnamed structure field" is really
any unnamed non-struct-or-union field, since anonymous inner structs
and unions certainly are prese
On 3/18/2024 8:14 PM, Jeff Law wrote:
On 3/12/24 3:56 PM, Edwin Lu wrote:
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
gcc/testsuite/ChangeLog:
On 3/18/2024 8:07 PM, Jeff Law wrote:
On 3/18/24 12:54 PM, Edwin Lu wrote:
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and
there is nothing to advance, but that is not the case for (...)
functions
returning by hidden reference which have one such artificial ar
On 3/13/24 07:24, Cupertino Miranda wrote:
> Although part of all CO-RE relocation data, type based relocations do
> not require an access string.
> Initial implementation defined it as an empty string.
> On the other hand, libbpf when parsing the CO-RE relocations verifies
> that those strings
On Tue, Mar 19, 2024 at 04:17:32PM +0100, FX Coudert wrote:
>
> These two (independent) patches add two tiny Fortran 2023 features: new
> ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu.
> Please review, and let me know i
On Tue, 2024-03-19 at 16:10 +0100, Stefan Schulze Frielinghaus wrote:
> On s390 pr94688.c is failing due to excess error
>
> pr94688.c:6:5: warning: allocated buffer size is not a multiple of
> the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
>
> This is because on s390 functions are by
On Mon, 18 Mar 2024 20:50:14 PDT (-0700), jeffreya...@gmail.com wrote:
On 3/18/24 3:09 AM, Jivan Hakobyan wrote:
As RV has round instructions it is reasonable to use them instead of
calling the library functions.
With my patch for the following C code:
double foo(double a) {
return ceil(
Tested x86_64-linux. Pushed to trunk.
Not a regression, but worth backporting.
-- >8 --
The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiply
This fixes the problem in the PR, which is revealed by the new
concept-based constraints on std::pair constructors in C++20 mode. That
makes this a C++20 regression, as the PR's example compiles with C++17.
We need something similar for std::basic_string too, which I'll do
later.
Any comments?
T
Does anybody see any issues with making this change?
The __cpp_constexpr_dynamic_alloc macro is defined with -std=c++2a
since Clang 10.0.0 so this won't result in std::construct_at
disappearing by anybody using libstdc++ with Clang.
Tested x86_64-linux and aarch64-linux. Basic smoke tests checked
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likew
Hello,
these patches correct diagnostics dealing with variables in specification
expressions.
The first patch is a testsuite change, which fixes invalid specification
expressions that the second patch would diagnose.
The second patch removes a spurious diagnostic when a dummy procedure is
involved
On Tue, 19 Mar 2024 at 09:31, Jonathan Wakely wrote:
>
> On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
> >
> > Both committed now.
> >
> > Just to confirm, those 2 last patches should be backported to gcc-13
> > branch, right ?
>
> Yes please.
>
> >
> > I might have a try to update version.h
Tested x86_64-linux. Pushed to trunk.
I've taken the liberty of assuming that the change to
gcc/doc/install.texi is sufficiently "obviously true" to not require
separate approval.
-- >8 --
This is a generated header but regenerating it requires the manual step
of running 'make -C include update-
Pushed to trunk.
-- >8 --
There are several more sub-directories below 'src' now, with lots more
conveience libraries. Document them all as of GCC 14.
Also document how to regenerate the generated headers under include/bits
and how to update the tzdata.zi file.
libstdc++-v3/ChangeLog:
Tested x86_64-linux. Pushed to trunk.
-- >8 --
These scripts both print "generated by $file, do not edit" header but
one of them prints the wrong filename. Use the built-in __file__
attribute to ensure it's correct.
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Fix header
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This has been reported upstream.
libstdc++-v3/ChangeLog:
* testsuite/util/pstl/test_utils.h: Fix typos in comments.
---
libstdc++-v3/testsuite/util/pstl/test_utils.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
dif
Hi,
These two (independent) patches add two tiny Fortran 2023 features: new
ISO_FORTRAN_ENV named constants and SELECTED_LOGICAL_KIND intrinsic.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
Please review, and let me know if it’s okay to push once we’re back in stage 1.
(I know it’s not par
Tested x86_64-linux. Pushed to trunk. Backport to gcc-13 to follow.
-- >8 --
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's cons
On s390 pr94688.c is failing due to excess error
pr94688.c:6:5: warning: allocated buffer size is not a multiple of the
pointee's size [CWE-131] [-Wanalyzer-allocation-size]
This is because on s390 functions are by default aligned to an 8-byte
boundary and during function type construction size
On Tue, Mar 19, 2024 at 03:47:37PM +0100, Richard Biener wrote:
> The following fixes bogus truncation of a value-range for an int128
> array index when computing the maximum extent for a variable array
> reference. Instead of possibly slowing things down by using
> widest_int the following makes
The following fixes bogus truncation of a value-range for an int128
array index when computing the maximum extent for a variable array
reference. Instead of possibly slowing things down by using
widest_int the following makes sure the range bounds fit within
the constraints offset_int were designe
On Mar 19, 2024, at 09:46, Jakub Jelinek wrote:
On Tue, Mar 19, 2024 at 01:14:51PM +, Qing Zhao wrote:
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
Can you explain why do you
When SRA analyzes BIT_FIELD_REFs it handles writes and not byte
aligned reads differently from byte aligned reads. Instead of
trying to create replacements for the loaded portion the former
cases try to replace the base object while keeping the wrapping
BIT_FIELD_REFs. This breaks when we have bo
On Tue, Mar 19, 2024 at 01:14:51PM +, Qing Zhao wrote:
> Currently, the OST_DYNAMIC information is not passed to
> early_object_sizes phase. Pass this information to it, and adjust the code
> and testing case accordingly.
Can you explain why do you think this is desirable?
Having both passe
On Mon, 18 Mar 2024 at 22:35, Evgeny Karpov wrote:
>
> Monday, March 18, 2024 2:27 PM
> Christophe Lyon wrote:
>
> > > +/* Disable SEH and declare the required SEH-related macros that are
> > > +still needed for compilation. */ #undef TARGET_SEH #define
> > > +TARGET_SEH 0
> > > +
> > > +#define
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
bootstrapped and regress tested on both x86 and aarch64. no issue.
Okay for trunk?
thanks.
Qing
gcc/ChangeLog:
* tree-obj
On 3/19/24 12:48 AM, Andrew Waterman wrote:
On Mon, Mar 18, 2024 at 5:28 PM Vineet Gupta wrote:
On 3/16/24 13:21, Jeff Law wrote:
| 59944:add s0,sp,2047 <
| 59948:mv a2,a0
| 5994c:mv a3,a1
| 59950:mv a0,sp
| 59954:li a4,1
| 599
In r14-1497-gef768035ae8090 I added some support to the analyzer for
__atomic_ builtins (enough to fix false positives I was seeing in
my integration tests).
Unfortunately I messed up the implementation of
__atomic_{exchange,load,store}, leading to ICEs seen in
PR analyzer/114286.
Fixed thusly, f
Tested on x86_64-darwin21, a cross to powerpc-darwin9 and on
x86_64-linux-gnu, pushed to trunk (will backport to branches soon).
thanks,
Iain
--- 8< ---
The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
Thanks!
On Fri, Feb 16, 2024 at 7:02 PM Lewis Hyatt wrote:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
>
> On Thu, Jan 25, 2024 at 4:57 PM Lewis Hyatt wrote:
> >
> > May I please ask again about this o
This was pre-approved on irc by Jonathan, tested on x86_64-linux,Darwin,
pushed to trunk, thanks,
Iain
--- 8< ---
For Darwin, in order to allow uninstalled testing, we need to provide
a '-B' option pointing to each path containing an uninstalled library
that we are using (these get appended to th
> -原始邮件-
> 发件人: "Jeff Law"
> 发送时间: 2024-03-19 10:54:09 (星期二)
> 收件人: Jiawei , gcc-patches@gcc.gnu.org
> 抄送: kito.ch...@sifive.com, pal...@dabbelt.com,
christoph.muell...@vrull.eu, wuwei2...@iscas.ac.cn, shi...@iscas.ac.cn,
shiyul...@iscas.ac.cn, chenyix...@iscas.ac.cn
> 主题: Re: [PATCH]
On Tue, Mar 19, 2024 at 01:06:50PM +0100, Richard Biener wrote:
> The following reverts the chrec_fold_multiply fix and only keeps
> handling of constant overflow which keeps the original testcase
> fixed. A better solution might involve ranger improvements or
> tracking of assumptions during SCEV
The following reverts the chrec_fold_multiply fix and only keeps
handling of constant overflow which keeps the original testcase
fixed. A better solution might involve ranger improvements or
tracking of assumptions during SCEV analysis similar to what niter
analysis does.
Bootstrapped and tested
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> > Works for me, but would
> >
> > #undef vec_step
> >
> > work or is it really a keyword in the clang side?
>
> No, it is really keyword.
> #undef vec_step
> int
> main ()
> {
> int ve
On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> Works for me, but would
>
> #undef vec_step
>
> work or is it really a keyword in the clang side?
No, it is really keyword.
#undef vec_step
int
main ()
{
int vec_step = 0;
return vec_step;
}
clang --target=powerpc64le-linux -o
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
> > Gerald Pfeifer writes:
> > > I have seen an increasing number of reports of GCC failing to
> > > build with clang on powerpc (on FreeBSD, though that's probably
> > > immaterial).
>
Hi,
On 3/5/24 16:09, David Malcolm wrote:
On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:
Hi.
See answers below.
On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
Hi.
This patch adds support for getting the CPU features
On Tue, 19 Mar 2024 at 10:55, Iain Sandoe wrote:
>
> Note that Windows-based platforms do something quite similar, but always
> use the same (x.exe) filename. I wonder, in passing, if that makes a
> vulnerability in parallel testing (I chose to avoid the possibility for
> Darwin).
Parallel testin
On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
> Gerald Pfeifer writes:
> > I have seen an increasing number of reports of GCC failing to
> > build with clang on powerpc (on FreeBSD, though that's probably
> > immaterial).
> >
> > Turns out that clang has vec_step as a reserved
Note that Windows-based platforms do something quite similar, but always
use the same (x.exe) filename. I wonder, in passing, if that makes a
vulnerability in parallel testing (I chose to avoid the possibility for
Darwin).
Tested on x86_64-darwin21, x86_64-linux-gnu,
OK for trunk?
back-ports wher
On Mon, 18 Mar 2024 at 21:38, François Dumont wrote:
>
> Both committed now.
>
> Just to confirm, those 2 last patches should be backported to gcc-13
> branch, right ?
Yes please.
>
> I might have a try to update version.h but if you want to do it before
> don't hesitate.
You'll need to have 'au
Hi!
Like for x86-64, alpha or rs6000, arc seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-19 Jakub Jelinek
PR target/114175
* config/arc/arc.cc (arc_setup_incoming_varargs):
On Tue, 2024-03-19 at 11:19 +0800, chenglulu wrote:
>
> 在 2024/3/18 下午5:34, Xi Ruoyao 写道:
> > We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
> > arguments and there is nothing to advance, but that is not the case
> > for (...) functions returning by hidden reference which have o
Hi!
c_omp_check_loop_binding_exprs with check_loop_binding_expr was composing
diagnostics from a format string with %s that provided additional words (but not
keywords). That is a big no no for translations, both because the translator
can't choose a different word order and because the %s part w
On Mon, 18 Mar 2024, Fangrui Song wrote:
LLVM has had an aarch64 mingw ABI support for a long time. Does this
patch series introduce a different ABI?
If yes, do you have a summary?
This patchset in itself does not reach ABI compatibility with the
preexisting aarch64 mingw ecosystem - but this
Hi Jakub,
on 2024/3/19 01:21, Jakub Jelinek wrote:
> Hi!
>
> The c23-stdarg-8.c test (as well as the new test below added to cover even
> more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
> as well.
> Like in the r14-9503-g218d174961 change on x86-64 we need to advance
>
76 matches
Mail list logo
