On Wed, 31 Mar 2021, Jakub Jelinek wrote:
> Hi!
>
> In GCC8/9 we used to optimize this into a bswap, but we no longer do.
> Handling byteswapping of pointers is easy, all we need is to allow them,
> for the __builtin_bswap* we already use TYPE_PRECISION to determine
> the precision and we cast th
On Wed, 31 Mar 2021, Martin Jambor wrote:
> Hi,
>
> SRA represents parts of aggregates which are arrays accessed with
> unknown index as "unscalarizable regions." When there are two such
> regions one within another and the outer is only read whereas the
> inner is written to, SRA fails to propa
On Thu, 1 Apr 2021, Jakub Jelinek wrote:
> On Thu, Apr 01, 2021 at 12:52:20AM -0400, Jason Merrill wrote:
> > On 1/8/21 2:29 PM, Jakub Jelinek wrote:
> > > On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> > > > I like the idea to use *walk_subtrees to distinguish between walking
>
On Wed, Mar 31, 2021 at 10:51 PM Iain Sandoe wrote:
>
> Hi,
>
> This fixes a stage 1 bootstrap fail on some Darwin versions when the
> bootstrap compiler is clang / libc++ from Xcode.
>
> bootstrapped on x86_64-darwin16, x86_64-linux-gnu
> OK for master?
LGTM.
Thanks,
Richard.
> thanks
> Iain
>
This fixes an omission of promoting a bit-precision required precision
to a vector element precision.
Bootstrapped & tested on x86_64-unknown-linux-gnu, pushed.
2021-04-01 Richard Biener
PR tree-optimization/99856
* tree-vect-patterns.c (vect_recog_over_widening_pattern): Prom
Hi,
On Wed, 31 Mar 2021 at 11:38, Jan Hubicka wrote:
>
> Hi,
> in the dicussion on PR 99447 there was some confusion about release_body
> being used in context where call edges/references survive. This is not
> a valid use because it would leave stale pointers to ggc_freed memory
> location. By a
Hi!
When looking at the symver documentation, I've noticed a couple of
syntax errors in it.
Committed to trunk as obvious.
But looking more at it, the
r11-2859-g363080bb8bd2cca81dd9e2e774910a8c8226f430
change that introduced this has another problem - the documentation
still talks about foo_v1 b
> This patch is causing ICEs on arm and aarch64, and others according to
> gcc-testresults:
> on aarch64:
> g++.dg/ipa/devirt-7.C -std=gnu++14 (internal compiler error)
> g++.dg/ipa/devirt-7.C -std=gnu++17 (internal compiler error)
> g++.dg/ipa/devirt-7.C -std=gnu++2a (internal compi
On 3/31/21 4:50 PM, Iain Sandoe wrote:
Hi,
This fixes a stage 1 bootstrap fail on some Darwin versions when the
bootstrap compiler is clang / libc++ from Xcode.
bootstrapped on x86_64-darwin16, x86_64-linux-gnu
OK for master?
thanks
Iain
ok, thanks for tracking this down!
--
Nathan Sidwell
The GCC 10 branch is now frozen in preparation for the GCC 10.3 release
which will see a first release candidate built soon.
All changes from now on require release manager approval.
Status
==
The GCC 10 branch is frozen for the release of GCC 10.3 with
a first release candidate published. All changes require
release manager approval.
Quality Data
Priority # Change from last report
--- ---
P1
I finally managed to reduce the testcase without hitting other bugs.
This problem is caused by discovering a duplicate in the middle of
reading in the entity in question. I had thougt the import seeding at
the beginning of a cluster prevented that, but it is insufficient.
Specifically an ear
Hi Jakub,
On 31/03/2021 21:30, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> In GCC8/9 we used to optimize this into a bswap, but we no longer do.
> Handling byteswapping of pointers is easy, all we need is to allow them,
> for the __builtin_bswap* we already use TYPE_PRECISION to determine
> th
Hey.
I've returned to the David's project and I'm willing to finish his transition
effort.
I believe using Sphinx documentation can rapidly improve readability, both HTML
and PDF version,
of various GCC manuals ([1]). I've spent some time working on the David's
texi2rsf conversion tool ([2])
an
Can it provide EPUB or MOBI output? Some of the documentation systems used in
various open source products have that capability, and that is very nice to
have. I have seen this from the one used by the Python project, for example.
Converting other formats to EPUB sometimes works tolerably we
This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch now produces the correct error.
Regtests OK on FC33/x86_64 - OK for the affected branches?
Paul
Fortran: Fix ICE on wrong code [PR99818].
2021-04-01 Paul Thomas
gcc/fortran/ChangeLog
On 4/1/21 3:42 PM, Koning, Paul wrote:
> Can it provide EPUB or MOBI output?
Yes, [1] lists 'epub' as one of the possible "buildername" options.
Btw. what Python project do you speak about?
Cheers,
Martin
[1]
https://www.sphinx-doc.org/en/master/man/sphinx-build.html#cmdoption-sphinx-build-b
On Apr 1, 2021, at 9:51 AM, Martin Liška
mailto:mli...@suse.cz>> wrote:
[EXTERNAL EMAIL]
On 4/1/21 3:42 PM, Koning, Paul wrote:
Can it provide EPUB or MOBI output?
Yes, [1] lists 'epub' as one of the possible "buildername" options.
Btw. what Python project do you speak about?
Cheers,
Marti
On 29/03/21 22:25 +0200, François Dumont wrote:
On 25/03/21 4:29 pm, Jonathan Wakely wrote:
Oh, it's the same generate(sz) bug as you already found. But I've
found other bugs, e.g. with GLIBCXX_SEED_TEST_RNG=1908970375).
I think we should also add a check for non-empty containers to those
test
On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use thi
On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::find): Define.
(split_view::_OuterIter::operator++): Apply proposed resolution
of LWG 3505.
* testsuite/std/ranges/adaptors/split.cc (test10): New t
> Oops, and I also forgot to update the other headers that were using
> those autoconf-generated macros!
>
> Fixed by this patch. Tested on mingw-w64, pushed to trunk.
The original patch was apparently backported onto the gcc-10 branch, but not
this follow-up fix, so Windows builds are now broke
On 29/03/21 14:49 -0400, Patrick Palka via Libstdc++ wrote:
The header currently copies some simple algorithms from
, which was originally done in order to avoid a
circular dependency with the header. This is no longer an issue since
the latter header now includes instead of all of
.
This mea
On Thu, Apr 01, 2021 at 03:30:10PM +0200, Martin Liška wrote:
> Hey.
>
> I've returned to the David's project and I'm willing to finish his transition
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both
> HTML and PDF version,
> of various GCC manuals ([1]). I'
On 01/04/21 16:04 +0200, Eric Botcazou wrote:
Oops, and I also forgot to update the other headers that were using
those autoconf-generated macros!
Fixed by this patch. Tested on mingw-w64, pushed to trunk.
The original patch was apparently backported onto the gcc-10 branch, but not
this follow
On Thu, Apr 01, 2021 at 03:25:56PM +0100, Jonathan Wakely via Gcc-patches wrote:
> On 01/04/21 16:04 +0200, Eric Botcazou wrote:
> > > Oops, and I also forgot to update the other headers that were using
> > > those autoconf-generated macros!
> > >
> > > Fixed by this patch. Tested on mingw-w64, pu
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD case, so we don't
need to look deeply to find
On Thu, 2021-04-01 at 15:30 +0200, Martin Liška wrote:
> Hey.
>
> I've returned to the David's project and I'm willing to finish his
> transition effort.
For reference, the original thread about this is in the archives here:
https://gcc.gnu.org/pipermail/gcc-patches/2015-November/434055.html
>
> On Apr 1, 2021, at 9:30 AM, Martin Liška wrote:
>
> Hey.
>
> I've returned to the David's project and I'm willing to finish his transition
> effort.
> I believe using Sphinx documentation can rapidly improve readability, both
> HTML and PDF version,
> of various GCC manuals ([1]). I've spe
On Thu, Apr 1, 2021 at 12:45 AM Martin Liška wrote:
>
> On 3/31/21 8:45 PM, David Edelsohn via Gcc-patches wrote:
> > This patch is causing new crashes in the testsuite.
> >
> > ICE in release_body, at graph.c:1863
> > ranges offset out of range
>
> Hello.
>
> Should be fixed with 23ce9945d5efa77c
produce the problem on the gcc-10 branch or with the
gcc-10.3.0-RC-20210401.tar.xz release candidate. That's because I
didn't backport r11-6226-gf5feee6adc8350a292c235eb21e31a5082350d94
either. The follow-up fix referred to above was only needed because
r11-6226 regenerated libstdc++-v3/con
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the same way.
For the testcase in the PR, here is the code we gener
ping
> [Changes from V4:
> - Rebased to latest master.
> - Support for DATASEC in BTF.
> - Bug fixes in the CTF support.
> - Be more silent: do not inform() the user anymore if -gctf is used
> along with a frontend for which there is no CTF support. Ignore
> the request instead.
> - Got rid
> Thanks, pushed.
I can confirm that the build failure we had is now gone, thanks!
> Eric, are you building the RC with --enable-maintainer-mode maybe? Or
> regenerating the autoconf files yourself?
The latter, we have local configure changes so we regenerate the script.
--
Eric Botcazou
Since uiret should be used only for user interrupt handler return, don't
generate uiret in interrupt handler return with -mcmodel=kernel even if
UINTR is enabled.
gcc/
PR target/99870
* config/i386/i386.md (interrupt_return): Don't generate uiret
for -mcmodel=kernel.
gcc/
On 4/1/21 10:30 AM, Patrick Palka wrote:
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD ca
On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the sam
On 01/04/21 18:47 +0200, Eric Botcazou wrote:
Thanks, pushed.
I can confirm that the build failure we had is now gone, thanks!
Eric, are you building the RC with --enable-maintainer-mode maybe? Or
regenerating the autoconf files yourself?
The latter, we have local configure changes so we re
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the definition
qualifies. Otherwise we ca
On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
wrote:
>Since uiret should be used only for user interrupt handler return,
>don't
>generate uiret in interrupt handler return with -mcmodel=kernel even if
>UINTR is enabled.
>
>gcc/
>
> PR target/99870
> * config/i386/i386.md (i
Change the preprocessor logic so RTEMS uses utime().
gcc/ada/
* adaint.c (__gnat_copy_attribs): RTEMS should use utime().
---
gcc/ada/adaint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 0a90c92402c..d3b83f61076 100644
-
On 1 April 2021 20:31:13 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
> wrote:
>>Since uiret should be used only for user interrupt handler return,
>>don't
>>generate uiret in interrupt handler return with -mcmodel=kernel even
>if
>>UINTR is enab
On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>Change the preprocessor logic so RTEMS uses utime().
>gcc/ada/
> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
RTEMS probably doesn't care alot about accurate time, from the looks. Otherwise
it would not mandate use of
On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
>>Change the preprocessor logic so RTEMS uses utime().
>>gcc/ada/
>> * adaint.c (__gnat_copy_attribs): RTEMS should use utime().
>
>RTEMS probably doesn't care alot about
On 4/1/21 2:15 PM, Marek Polacek wrote:
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the de
L
On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer
wrote:
> On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer <
> rep.dot@gmail.com> wrote:
> >On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote:
> >>Change the preprocessor logic so RTEMS uses utime().
> >>gcc/ada/
> >> *
The tree-walk looking for parameter packs didn't find this one because we
weren't stepping into TYPE_RAISES_EXCEPTIONS.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/99583
PR c++/99584
* tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into
On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
>
> Since uiret should be used only for user interrupt handler return, don't
> generate uiret in interrupt handler return with -mcmodel=kernel even if
> UINTR is enabled.
NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off SSE.
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.
We could sa
> On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> >
> > Since uiret should be used only for user interrupt handler return, don't
> > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > UINTR is enabled.
>
> NAK, -mcmodel should not affect ISAs, in the same way it doesn't s
On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote:
>
> > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> > >
> > > Since uiret should be used only for user interrupt handler return, don't
> > > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > > UINTR is enabled.
> >
> >
On Thu, Apr 1, 2021 at 10:47 PM H.J. Lu wrote:
>
> On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote:
> >
> > > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> > > >
> > > > Since uiret should be used only for user interrupt handler return, don't
> > > > generate uiret in interrupt handler return
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
> On 4/1/21 2:15 PM, Marek Polacek wrote:
> > Here we crash in reshape_init because we're accessing ggc_freed
> > & poisoned data: since r277865 in defaulted_late_check we call
> > synthesize_method here:
> >
> >if (kind == sfk_com
On 4/1/21 5:12 PM, Marek Polacek wrote:
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
On 4/1/21 2:15 PM, Marek Polacek wrote:
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
On 4/1/21 4:09 PM, Patrick Palka wrote:
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in
I would very much like to get all the details right on my next submission.
I'm submitting this query for feedback before I do the full submission.
Most changes requested require obvious fixes. One has me confused about
the best action to take.
- - - -
On the issue of alloca vs XALLOCAVEC, I dis
Various places iterate through all of the saved_diagnostics to find
just the ones that are at a given enode. This patch adds a per-enode
record of the diagnostics that are at each node, to save iterating
through all of the diagnostics each time.
Successfully bootstrapped & regrtested on x86_64-pc
Paul,
This looks OK to me for Trunk. I believe 10 is in freeze so it may have
to wait or get release manager approval.
Jerry
On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote:
This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch
58 matches
Mail list logo
