Pushed r13-5319.
在 2023/1/18 下午5:14, Richard Sandiford 写道:
Lulu Cheng writes:
Co-authored-by: Yang Yujie
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_classify_address):
Add precessint for CONST_INT.
(loongarch_print_operand_reloc): Operand modifier 'c'
Register-register move instructions that can be easily seen as
unnecessary by the human eye may remain in the compiled result.
For example:
/* example */
double test(double a, double b) {
return __builtin_copysign(a, b);
}
test:
add.n a3, a3, a3
extui a5, a5, 31, 1
In the case of the CALL0 ABI, values that must be retained before and
after function calls are placed in the callee-saved registers (A12
through A15) and referenced later. However, it is often the case that
the save and the reference are each only once and a simple register-
register move (with
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-2978 I tried to eliminate TARGET_EXPR around TARGET_EXPR by
discarding the outer one, but as in this testcase that breaks if the
TARGET_EXPR_SLOT of the outer one is used elsewhere. But it should always
be safe to strip the inner
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
With -ffold-simple-inlines, we turn calls to std::move into the static_cast
equivalent. In this testcase, this exposes the FindResult temporary to copy
elision which is not specified by the standard, through an optimization in
get_shift_range was incorrectly communicating that it couldn't calculate
a range when the shift value was out of range.
Fix this and always return a range of [0, 0] instead of varying when the
shift value is out of range.
Bootstraps with no regressions on x86_64-pc-linux-gnu. OK for trunk?
On Fri, Jan 20, 2023 at 2:56 AM Björn Schäpers wrote:
>
> From: Björn Schäpers
>
> This is actually needed so that libstdc++'s implementation
> to be able to work on windows.
>
> Tested on x86_64-linux and i686-w64-mingw32.
>
> -- >8 --
>
> * configure.ac: Add a check for windows.h.
>
On Mon, Jan 23, 2023 at 10:23:54PM +0100, Harald Anlauf via Fortran wrote:
>
> the code in the PR demonstrates that dependency checking in the
> frontend optimization was not recovering well from invalid code,
> leading to a NULL pointer dereference. An easy and really obvious
> fix.
>
>
Hi Harald,
the code in the PR demonstrates that dependency checking in the
frontend optimization was not recovering well from invalid code,
leading to a NULL pointer dereference. An easy and really obvious
fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Yes indeed (and I would not
On 1/23/23 16:28, Marek Polacek wrote:
On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote:
On 1/19/23 21:03, Marek Polacek wrote:
We shouldn't emit "right operand of comma operator has no effect"
when that comma operator was created by the compiler for "new int{}".
On Fri, Jan 20, 2023 at 02:37:19PM -0500, Jason Merrill wrote:
> On 1/19/23 21:03, Marek Polacek wrote:
> > We shouldn't emit "right operand of comma operator has no effect"
> > when that comma operator was created by the compiler for "new int{}".
> > convert_to_void/COMPOUND_EXPR already checks
Dear all,
the code in the PR demonstrates that dependency checking in the
frontend optimization was not recovering well from invalid code,
leading to a NULL pointer dereference. An easy and really obvious
fix.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The transformation done by r13-4564 to use the iterator constructor instead
of the initializer-list constructor breaks if the iterator pointers are
themselves treated as elements of an initializer-list, so check for that.
PR
On Mon, Jan 23, 2023 at 09:34:59PM +0100, Harald Anlauf via Fortran wrote:
>
> we did not check array element triplets for validity strictly enough
> (i.e. defensively in the case of invalid code), so we could encounter
> non-integer constant expressions that were passed to mpz_get_si.
>
> The
Dear all,
we did not check array element triplets for validity strictly enough
(i.e. defensively in the case of invalid code), so we could encounter
non-integer constant expressions that were passed to mpz_get_si.
The attached obvious patch tries to fix all such potential issues
in
Am 20.01.2023 um 23:25 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:54 AM Björn Schäpers wrote:
From: Björn Schäpers
It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a following
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
In r13-4469 we started to build the RESULT_DECL in grokdeclarator, while we
still know the location of the return type. But in this testcase, we hit
that code again when parsing the explicit instantiation, and clobber the
DECL_RESULT that
On Mon, Jan 23, 2023 at 02:21:46PM +0100, Iain Buclaw wrote:
> Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar
> 13, 2023 6:54 pm:
> > In the context of D the interpretation of S390, S390X, and SystemZ is a
> > bit fuzzy. The wording S390X was wrongly deprecated in
remove remnant of Cygwin options from x86 Windows options summary
in doc/invoke.texi
Cygwin objects, functions, and options details were removed in 2010-10-07
commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=3edeb30d044a4852881c34229e618b34f95b0d9e#patch8
leaving only this remnant
---
On Mon, 23 Jan 2023 at 18:15, François Dumont wrote:
>
> On 23/01/23 10:22, Jonathan Wakely wrote:
> > On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++
> > wrote:
> >> libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
> >>
> >> Creating a safe iterator from a
On 23/01/23 10:22, Jonathan Wakely wrote:
On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++
wrote:
libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
Creating a safe iterator from a normal iterator is done within the
library where we
already know that it
Sorry should have mention the PR
On 1/23/23 12:44, Andrew MacLeod wrote:
This patch adds VREL_OTHER to represent another relation we do not
understand. It is used to represent the class fo relations arising
from floating point that are currently not represented. IN GCC 14 we
will determine
This patch adds VREL_OTHER to represent another relation we do not
understand. It is used to represent the class fo relations arising from
floating point that are currently not represented. IN GCC 14 we will
determine exactly how to represent them, but for this release, this
should prevent us
In order to fix 108447, this patch changes the calls to relation_union
and relation_intersection to instead utilize the value_relation class,
and make the calls through that instead.
value_relation manages the operands of a relation, and thus understands
whether this is a floating point
Prathamesh Kulkarni writes:
> On Wed, 18 Jan 2023 at 19:59, Richard Sandiford
> wrote:
>>
>> Prathamesh Kulkarni writes:
>> > On Tue, 17 Jan 2023 at 18:29, Richard Sandiford
>> > wrote:
>> >>
>> >> Prathamesh Kulkarni writes:
>> >> > Hi Richard,
>> >> > For the following (contrived) test:
>>
On Fri, Jan 20, 2023 at 04:05:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I'm attaching 3 so far just compile tested patches.
So far successfully bootstrapped/regtested the first and third patches,
both on x86_64-linux and i686-linux.
Jakub
Iain Sandoe writes:
> Given that, currently, this value is not configurable per target the
> short-term solution is to avoid a bad request.
>
> Tested on x86_64-darwin21, OK for trunk?
> thanks
> Iain
Hi Iain,
yes this is fine. LGTM - thanks
regards,
Gaius
On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> On Mon, Jan 23, 2023 at 12:37:59PM +, Richard Biener wrote:
> > Guess it should work. Do we (accidentially?) do anything special
> > to static var initializers in nested functions?
>
> I don't think we touch those, we walk the bodies of functions,
Iain Sandoe writes:
> Tested on x86_64-linux-gnu (with a 32b multilib), powerpc, i686 and
> x86_64-darwin. OK for trunk?
> thanks,
> Iain
>
> --- 8< ---
>
> The adds the includes in the FE as done in other GCC languages.
> It also revises the library handling to avoid additional -L options
>
On Mon, Jan 23, 2023 at 12:37:59PM +, Richard Biener wrote:
> Guess it should work. Do we (accidentially?) do anything special
> to static var initializers in nested functions?
I don't think we touch those, we walk the bodies of functions, I don't
think we traverse static var DECL_INITIALs.
Excerpts from Lorenzo Salvadore's message of Januar 10, 2023 5:10 pm:
> Hello,
>
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605685.html
>
> I would like to remind that Gerald Pfeifer already volunteered to commit this
> patch
> when it is approved. However the patch has not
Hello,
This patch fixes the documentation for -mbranch-protection command line option.
Committed this patch to trunk as obvious fix.
Regards,
Srinath.
gcc/ChangeLog:
2023-01-23 Srinath Parvathaneni
* doc/invoke.texi (-mbranch-protection): Update documentation.
###
Excerpts from Stefan Schulze Frielinghaus via Gcc-patches's message of Januar
13, 2023 6:54 pm:
> In the context of D the interpretation of S390, S390X, and SystemZ is a
> bit fuzzy. The wording S390X was wrongly deprecated in favour of
> SystemZ by commit
>
libstdc++-v3/ChangeLog:
* doc/xml/manual/using.xml: Document newly-freestanding
headers and the effect of the -ffreestanding flag.
* doc/xml/manual/status_cxx2023.xml: Document P1642R11 as
completed.
* doc/xml/manual/configure.xml: Document that hosted
On Mon, Jan 23, 2023 at 11:44 AM Rainer Orth
wrote:
>
> The gcc.dg/vect/vect-bitfield-write-[23].c tests FAIL on 32 and 64-bit
> SPARC:
>
> FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects
> scan-tree-dump-times vect "vectorized 1 loops" 1
> FAIL:
On Mon, Jan 23, 2023 at 11:39 AM Rainer Orth
wrote:
>
> The gcc.dg/vect/vect-fmax-?.c etc. tests FAIL on 32 and 64-bit SPARC:
>
> FAIL: gcc.dg/vect/vect-fmax-1.c -flto -ffat-lto-objects scan-tree-dump vect
> "Detected reduction"
> FAIL: gcc.dg/vect/vect-fmax-1.c scan-tree-dump vect "Detected
On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> On Mon, Jan 23, 2023 at 09:25:50AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> > > > I was just trying to be careful, because unfortunately this spot
> > > > doesn't mean it really is
On Mon, 23 Jan 2023, Tobias Burnus wrote:
> In any case, I concur that it would be nice to unify .texi/.xml and
> diagnostic
> output (twice in config/or1k/elf.opt) - and likewise the wwwdocs pages.
:
> ->adds this to the to-do list.
Let me help a litte and take care of wwwdocs. Pushed. :)
Hi Richard,
thanks for reviewing and approving this series, this is now in.
BR
Andrea
On Mon, Jan 23, 2023 at 09:25:50AM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> > > I was just trying to be careful, because unfortunately this spot
> > > doesn't mean it really is only expanded in static var DECL_INITIAL,
> > > it
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
>
> PR target/55522
> * config/sparc/freebsd.h (ENDFILE_SPEC): Don't add crtfastmath.o
> for -shared.
> * config/sparc/linux.h (ENDFILE_SPEC): Likewise.
> *
The gcc.dg/vect/vect-fmax-?.c etc. tests FAIL on 32 and 64-bit SPARC:
FAIL: gcc.dg/vect/vect-fmax-1.c -flto -ffat-lto-objects scan-tree-dump vect
"Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-1.c scan-tree-dump vect "Detected reduction"
FAIL: gcc.dg/vect/vect-fmax-2.c -flto -ffat-lto-objects
The gcc.dg/vect/vect-bitfield-write-[23].c tests FAIL on 32 and 64-bit
SPARC:
FAIL: gcc.dg/vect/vect-bitfield-write-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/vect-bitfield-write-2.c scan-tree-dump-times vect "vectorized
1 loops" 1
FAIL:
On Mon, Jan 23, 2023 at 10:28:01AM +, Richard Biener wrote:
> On Mon, 23 Jan 2023, Jakub Jelinek wrote:
>
> > On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> > > The following deals with .LOOP_DIST_ALIAS surviving vectorization
> > > because any of the loops involved were
On 1/20/23 18:33, Jason Merrill wrote:
> Martin, I wonder about having the hooks reject out-of-order CommitDate
> in future?
Yes, I would do that. Looking at the last 30K commmits I see just a few
violations
of the order:
UNIXTS hash
1668298622 30d77d49628
1630019619 5889e842ae4
1626967834
The following addresses the fact that libgm2 installs static libraries
into two places, one performed by
toolexeclib_LTLIBRARIES = libm2cor.la
and one performed as part of the install-data-local rule to a
m2/m2cor subdirectory alongside Modula-2 .def and .mod files.
This patch opts to keep the
Ping
Richard Sandiford writes:
> Various parts of the omp code checked whether the size of a decl
> was an INTEGER_CST in order to determine whether the decl was
> variable-sized or not. If it was variable-sized, it was expected
> to have a DECL_VALUE_EXPR replacement, as for VLAs.
>
> This
On Mon, 23 Jan 2023, Jakub Jelinek wrote:
> On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> > The following deals with .LOOP_DIST_ALIAS surviving vectorization
> > because any of the loops involved were elided between loop distribution
> > and vectorization. As opposed to
The following deals with .LOOP_DIST_ALIAS surviving vectorization
because any of the loops involved were elided between loop distribution
and vectorization. As opposed to .LOOP_VECTORIZED which exists only
between if-conversion and vectorization with no intermediate passes
this is more difficult
On Mon, Jan 23, 2023 at 11:09:43AM +0100, Richard Biener wrote:
> The following deals with .LOOP_DIST_ALIAS surviving vectorization
> because any of the loops involved were elided between loop distribution
> and vectorization. As opposed to .LOOP_VECTORIZED which exists only
> between
The previous change to avoid a duplicate multi directory
caused the m2/m2{cor,iso,log,min,pim} installs to happen
relative to the main library directory when not using
--enable-version-specific-runtime-libs which doesn't match
the drivers expectation where to find them. The following
fixes the
On Fri, Jan 13, 2023 at 7:49 PM Martin Jambor wrote:
>
> Hello,
>
> sorry for getting to this quite late. I have only had a quick glance at
> ipa-cp.cc hunks so far.
>
Hi Martin,
Thanks for taking the time to review these.
> On Fri, Dec 16 2022, Manolis Tsamis wrote:
> > The IPA CP pass
On 22.01.23 02:45, Gerald Pfeifer wrote:
Maybe, but the question is what to use? The project's webpage has on the
first page: "patch submissions to Newlib" and "automate the testing of
newlib".
I also dug into the newlib web page and other sources and - while my
personal preference slightly
On Mon, 23 Jan 2023 at 06:02, François Dumont via Libstdc++
wrote:
>
> libstdc++: [_GLIBCXX_DEBUG] Remove useless constructor checks
>
> Creating a safe iterator from a normal iterator is done within the
> library where we
> already know that it is done correctly. The rare
On Mon, 23 Jan 2023, Tobias Burnus wrote:
> Now committed with the suggestions taken into account.
Nice - this feels rather clear to me (as a non-expert) now. :-)
Thanks,
Gerald
Now committed with the suggestions taken into account.
That is: for non-rect loop-nest support, add 'some' / set back to
partial. I also changed the already-in-GCC-11 wording as it was a bit
unclear to which word/topic the "which" in the original patch referred
to - and the "some" made it even
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/loongarch/gnu-user.h (GNU_USER_TARGET_MATHFILE_SPEC):
> Don't add crtfastmath.o for
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/sparc/freebsd.h (ENDFILE_SPEC): Don't add crtfastmath.o
> for -shared.
> *
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/mips/gnu-user.h (GNU_USER_TARGET_MATHFILE_SPEC):
> Don't add crtfastmath.o for -shared.
>
On Fri, 13 Jan 2023, Richard Biener wrote:
> Don't add crtfastmath.o for -shared to avoid altering the FP
> environment when loading a shared library.
Ping.
> PR target/55522
> * config/alpha/linux.h (ENDFILE_SPEC): Don't add
> crtfastmath.o for -shared.
> ---
>
As discussed in the thread
Re: [wwwdocs] gcc-13/changes.html + projects/gomp/: OpenMP update
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610324.html
in https://gcc.gnu.org/PR107424 and the thread starting at
OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]
On Sun, Jan 22, 2023 at 07:19:07PM -0500, Jason Merrill wrote:
> > I was just trying to be careful, because unfortunately this spot
> > doesn't mean it really is only expanded in static var DECL_INITIAL,
> > it can make it into dynamic initializers, and most of DECL_VALUE_EXPRs
> > appear only in
62 matches
Mail list logo
