Co-Authored-By: xujiahao
gcc/ChangeLog:
* config/loongarch/loongarch-def.c: Initial number of parallel prefetch.
* config/loongarch/loongarch-tune.h (struct loongarch_cache):
Define number of parallel prefetch.
* config/loongarch/loongarch.cc
Am Samstag, den 12.11.2022, 01:09 + schrieb Joseph Myers:
> On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
>
> > > Even a compiler extension requires the level of detail of specification
> > > that you get with a WG14 paper (and the level of work on finding bugs in
> > > that
在 2022/11/12 下午3:08, Xi Ruoyao 写道:
On Wed, 2022-11-09 at 21:53 +0800, Xi Ruoyao wrote:
These patches allow to expand the following builtins to floating point
instructions for LoongArch:
- __builtin_rint{,f}
- __builtin_{l,ll}rint{,f}
- __builtin_{l,ll}floor{,f}
- __builtin_{l,ll}ceil{,f}
-
On Fri, 11 Nov 2022 18:17:46 -0500
Andrew MacLeod wrote:
> On 11/11/22 16:56, Bernhard Reutner-Fischer wrote:
> > So of course it doesn't really matter what that stmt was, a non_debug
> > is as good as a debug one AFAIU, it's just a marker, as good as any SSA
> > version or id, i suppose. So
On Wed, 2022-11-09 at 21:53 +0800, Xi Ruoyao wrote:
> These patches allow to expand the following builtins to floating point
> instructions for LoongArch:
>
> - __builtin_rint{,f}
> - __builtin_{l,ll}rint{,f}
> - __builtin_{l,ll}floor{,f}
> - __builtin_{l,ll}ceil{,f}
> - __builtin_scalb{n,ln}{,f}
在 2022/11/12 下午12:40, Xi Ruoyao 写道:
On Sat, 2022-11-12 at 11:54 +0800, Lulu Cheng wrote:
在 2022/11/9 下午9:53, Xi Ruoyao 写道:
This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f}
with
-fno-math-errno.
IMODE is added because we can't hard code SI for operand 2:
fscaleb.d
LGTM!
Thanks.
在 2022/11/9 下午9:53, Xi Ruoyao 写道:
On LoongArch, flogb instructions extract the exponent of a non-negative
floating point value, but produces NaN for negative values. So we need
to add a fabs instruction when we expand logb.
gcc/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #3 from Tomoya Suzuki ---
Perhaps I should ask the question in libc instead of gcc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #2 from Tomoya Suzuki ---
I Sorry I didn't follow your bug report guidelines. After this, I investigated
the cause by myself, and it seems that there is a difference in the output of
the std::shuffle function. Even if the input and
This patch adds support for new instructions that may be added to the PowerPC
architecture in the future to enhance the load and store vector with length
instructions.
The current instructions (lxvl, lxvll, stxvl, and stxvll) are inconvient to use
since the count for the number of bytes must be
This patch adds support for a saturating subtract built-in function that may be
added to a future PowerPC processor. Note, if it is added, the name of the
built-in function may change before GCC 13 is released. If the name changes,
we will submit a patch changing the name.
I also added support
[Global / middle-end reviewers, note there is a dfp.cc change here
that needs review.]
Implement C2x constexpr (a feature based on the C++ one but much more
minimal, with only constexpr variables, not functions).
I believe this implementation is fully functional for use of this
feature.
On Sat, 2022-11-12 at 11:54 +0800, Lulu Cheng wrote:
>
> 在 2022/11/9 下午9:53, Xi Ruoyao 写道:
> > This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f}
> > with
> > -fno-math-errno.
> >
> > IMODE is added because we can't hard code SI for operand 2:
> > fscaleb.d
> > instruction
> On 12 Nov 2022, at 00:53, Paul Eggert wrote:
>
> On 2022-11-11 15:25, Sam James wrote:
>> That's not a judgement on whether the changes will ultimately remain in
>> autoconf, I'm just
>> hesitant to allow a discussion I've kicked off to derail something that we
>> were planning
>> on doing
在 2022/11/9 下午9:53, Xi Ruoyao 写道:
This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with
-fno-math-errno.
IMODE is added because we can't hard code SI for operand 2: fscaleb.d
instruction always take the high half of both source registers into
account. See my_ldexp_long in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-12
Ever confirmed|0
On Fri, 11 Nov 2022, Zack Weinberg via Gcc wrote:
> These are also a trip hazard for novices, and the only way to turn them
> off is with -std=cXX, which also turns another trip hazard (trigraphs)
> *on*… so yeah, anything you can do to help speed up their removal, I
> think it’d be worthwhile.
> On 12 Nov 2022, at 03:40, Zack Weinberg wrote:
>
> Florian Weimer writes:
>> based on a limited attempt to get this fixed about three years
>> ago, I expect that many of the problematic packages have not had their
>> configure scripts regenerated using autoconf for a decade or more. This
Florian Weimer writes:
> based on a limited attempt to get this fixed about three years
> ago, I expect that many of the problematic packages have not had their
> configure scripts regenerated using autoconf for a decade or more. This
> means that as an autoconf maintainer, you unfortunately
On Fri, 2022-11-11 at 22:23 -0500, David Malcolm wrote:
> Changes since v1: ported the doc changes from texinfo to sphinx
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> Are the C frontend parts OK for trunk? (I can self-approve the
> analyzer parts)
...and FWIW, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452
--- Comment #11 from David Ledger ---
This did not occur with GCC 10.2, it started in GCC 10.3:
10.3 (https://godbolt.org/z/jrdv31M17):
```
0x15d1ed3 A
0x15d1ed2 ~A
0x15d1ed3 ~A
```
10.2 (https://godbolt.org/z/rrvKh9h6K):
```
0x2322ed1 A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
Bug ID: 107660
Summary: Running binaries compiled with g++11 or later produces
different results than g++ version 10 or earlier
Product: gcc
Version: 12.2.0
Status:
Changed in v2: ported doc changes from texinfo to sphinx
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
I can self-approve this patch, but it depends on the named constants
patch here:
* [PATCH v2] c, analyzer: support named constants in analyzer [PR106302]
*
Rich Felker writes:
> On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote:
>> The biggest remaining (potential) problem, that I’m aware of, is that
>> AC_CHECK_FUNC unconditionally declares the function we’re probing for
>> as ‘char NAME (void)’, and asks the compiler to call it with no
Changes since v1: ported the doc changes from texinfo to sphinx
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Are the C frontend parts OK for trunk? (I can self-approve the
analyzer parts)
Thanks
Dave
The analyzer's file-descriptor state machine tracks the access mode of
Nick Bowler writes:
> My gut feeling is that Autoconf should just determine the necessary
> options to get compatible behaviour out of these modern compilers, at
> least for the purpose of running configure tests. For example, Autoconf
> should probably build the AC_CHECK_FUNC programs using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64234
--- Comment #8 from lo1ol ---
https://www.youtube.com/watch?v=Ua3TiOSwVTI
On Fri, 11 Nov 2022 at 21:00, Stephan Bergmann wrote:
>
> On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote:
> > As discussed in the PR, this makes it three times faster to construct
> > iostreams objects.
> >
> > Tested x86_64-linux. Pushed to trunk.
>
> I haven't yet tried to track down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
--- Comment #14 from Jonathan Wakely ---
Should be fixed now, I think
I have no more questions.
Thanks.
在 2022/11/11 下午1:29, Xi Ruoyao 写道:
Lulu:
So I think the code is correct:
+ (
+|| flag_fp_int_builtin_inexact
+|| !flag_trapping_math)"
is 1 for lrint, 0 for lceil and lfloor. As N3054
says:
The lrint and llrint functions provide
Hi,
the previous patch established a way to propagate information about
parameters from callers to callees (even though then the actual
splitting is done in the opposite direction), this patch adds to that
information about size of the parameters that is known to be safe to
dereference in the
Hi,
while modifying the code, I realized that we do look into statements
even when there are no replacements. This patch adds the necessary
early bail-outs to avoid that.
ipa_param_body_adjustments::modify_call_stmt cannot have the same at
the very beginning because calls can still contain
Hi,
I have noticed that scan_expr_access passes all the expressions it
gets to get_ref_base_and_extent even when we are really only
interested in memory accesses. So bail out when the expression is
something clearly uninteresting.
Bootstrapped and tested on x86_64-linux. OK for master?
Hi,
this patch does not do any functional changes, it merely moves
top-down propagation in the IPA-SRA WPA phase before bottom-up one.
This also meant moving some preliminary checks from the latter to the
former - where they need to be in their own loop over each SCC because
the subsequent one
Hi,
C++ and especially Fortran pass data by references which are not
pointers potentially pointing anywhere and so can be assumed to be
safely dereferencable. This patch teaches IPA-SRA to treat them as
such and avoid the dance we do to prove that we can move loads from
them to the caller.
When
Hi,
Fortran descriptors are structures which are often constructed just
for a particular argument of a particular call where it is passed by
reference. When the called function is under compiler's control, it
can be beneficial to split up the descriptor and pass it in individual
parameters.
Hi,
this should have been part of r12-578-g717d278af93a4a. Call edge
summaries provide information required for IPA-SRA transformations in
the callees but are generated when analyzing callers and thus also
callers which are not IPA-SRA candidates themselves. Therefore we
analyze them but don't
Hi,
looking at some benchmarks I have noticed many cases when IPA-CP
cloned a function for all contexts just because it knew that some
parameters were not used at all. Then IPA-SRA looked at the function
and cloned it again to split another parameter or two. The latter
pass is better equipped
Hi,
this is basically a better fix for PR 103227. The one currently in
use, rushed in late at stage3, which means that IPA-CP transformation
simply does a replacement of default-definition of IPA-SRA-created
scalar parameters with a constant, meant that IPA-SRA actually often
led to creation of
Hi,
IPA-CP transformation summary streaming code currently won't stream
out transformations necessary for clones which are only necessary for
materialization of other clones (such as an IPA-CP clone which is then
cloned again by IPA-SRA). However, a follow-up patch for bettor
reconciling IPA-SRA
Hi,
When building vectors of known aggregate values, there is no point in
including those for parameters which are not used in any way
whatsoever.
Bootstrapped and tested on x86_64-linux. OK for master?
Thanks,
Martin
gcc/ChangeLog:
2022-11-11 Martin Jambor
* ipa-cp.cc
I posted this at the start of the year while we were in stage 3.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This rewrites the stamp-debug and build-debug targets in src/Makefile so
that each generated Makefile in the debug/$(SUBDIRS) directories is a
make target, instead of being created by
Hi,
I have noticed that the flag m_split_modifications_p of
ipa_param_body_adjustments is not really necessary as it has to
correspond to whether m_replacements is non-empty so this patch
removes it. This also simplifies a bit some patches I work on.
Bootstrapped and tested on x86_64-linux. OK
This fixes a build failure on powerpc64le when using ieeelongdouble as
the default.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
compatibility-ldbl-alt128.cc re-includes locale-inst-numeric.h and
locale-inst-monetary.h but wasn't defining the macros added in
r13-3888-gb3ac43a3c05744.
Put
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a7f51059fb009dcd7d491d6b2164bce75dbd9975
commit r13-3917-ga7f51059fb009dcd7d491d6b2164bce75dbd9975
Author: Jonathan Wakely
On Fri, 11 Nov 2022, Martin Uecker via Gcc wrote:
> > Even a compiler extension requires the level of detail of specification
> > that you get with a WG14 paper (and the level of work on finding bugs in
> > that specification), to avoid the problem we've had before with too many
> > features
On 2022-11-11 15:25, Sam James wrote:
That's not a judgement on whether the changes will ultimately remain in
autoconf, I'm just
hesitant to allow a discussion I've kicked off to derail something that we were
planning
on doing anyway.
What do you think?
I'm hesitant to do that partly
Thanks for that. I'll keep your comments in mind for the future.
On Fri, Nov 11, 2022 at 05:59:33PM +, Jonathan Wakely wrote:
> On Fri, 11 Nov 2022 at 17:55, Patrick Palka wrote:
> >
> > On Fri, 11 Nov 2022, Jonathan Wakely via Libstdc++ wrote:
> >
> > > On Fri, 11 Nov 2022 at 11:23,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107659
Bug ID: 107659
Summary: C procedure with no global scope is seen as global
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> I thought it went one layer deap but nope it is kinda of random.
> For an example:
> Not split up:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653
--- Comment #1 from Andrew Pinski ---
I thought it went one layer deap but nope it is kinda of random.
For an example:
Not split up:
https://gcc.gnu.org/onlinedocs/gccint/target-macros/register-classes.html
Splitted up:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107658
Bug ID: 107658
Summary: TARGET_EXPAND_TO_RTL_HOOK, TARGET_INSTANTIATE_DECLS,
TARGET_MANGLE_TYPE don't really belong in the Storage
Layout target hook section
Product: gcc
On Fri, 11 Nov 2022, Tobias Burnus wrote:
> For /onlinedocs/, I concur that we want to have the old doc there as there are
> many
> deep links. Still, we should consider adding a disclaimer box to all former
> mainline
> documentation stating that this data is no longer updated + point to the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634
--- Comment #5 from Andrew Pinski ---
One of the biggest drawbacks of not having one file is when you need to add a
new section, you have to add a new file/directory rather than edditing one
file.
I also noticed the splitting up sections of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107634
--- Comment #4 from Andrew Pinski ---
I came across a related issue here:
Take:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/C_002b_002b-ABI.html
The original section name was just C++-ABI but had a heading of C++ ABI
parameters
Now post
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107652
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107657
Bug ID: 107657
Summary: PROMOTE_MODE, TARGET_PROMOTE_FUNCTION_MODE,
TARGET_FUNCTION_VALUE and TARGET_PROMOTE_FUNCTION_MODE
should describe better their interactions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656
--- Comment #1 from Andrew Pinski ---
.. c:macro:: PROMOTE_MODE (m, unsignedp, type)
.. function:: enum flt_eval_method TARGET_C_EXCESS_PRECISION (enum
excess_precision_type type)
It is really hard to tell the difference in the generated page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107656
Bug ID: 107656
Summary: post sphinx conversion, can't tell between a target
macro or a target hook
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords:
> On 11 Nov 2022, at 03:33, Zack Weinberg wrote:
>
> On Thu, Nov 10, 2022, at 10:08 PM, Sam James wrote:
>>> On 10 Nov 2022, at 21:10, Michael Orlitzky wrote:
>>> While everyone else is discussing big ideas, it would be helpful for me
>>> personally if autoconf just made a release with the
On Linux/x86_64,
81de4037454275f8ed6d858fbc129e832c6147ef is the first bad commit
commit 81de4037454275f8ed6d858fbc129e832c6147ef
Author: Richard Biener
Date: Fri Nov 11 14:28:52 2022 +0100
tree-optimization/107554 - fix ICE in stlen optimization
caused
FAIL: gcc.dg/pr107554.c (test for
On 11/11/22 16:56, Bernhard Reutner-Fischer wrote:
On Fri, 11 Nov 2022 11:17:17 -0500
Andrew MacLeod via Gcc-patches wrote:
diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc
index 3393c73a7db..a474d9d11e5 100644
--- a/gcc/tree-vrp.cc
+++ b/gcc/tree-vrp.cc
@@ -4485,6 +4486,7 @@ public:
On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
> Hello.
>
> Based on the very positive feedback I was given at the Cauldron
> Sphinx Documentation BoF,
> I'm planning migrating the documentation on 9th November. There are
> still some minor comments
> from Sandra when it comes to the PDF
On Mon, 2022-10-17 at 15:28 +0200, Martin Liška wrote:
> Hello.
>
> Based on the very positive feedback I was given at the Cauldron
> Sphinx Documentation BoF,
> I'm planning migrating the documentation on 9th November. There are
> still some minor comments
> from Sandra when it comes to the PDF
Richard Biener writes:
>> +M2_MAINTAINER = no
>> +
>> +CPP_GM2=-fpermissive -DIN_GCC -g
>
> Do we really need -fpermissive here?
no not needed (and now removed) - thanks for spotting it.
>> +GM2_1 = ./gm2 -B./stage1/m2 -g -fm2-g
>> +
>> +GM2_FOR_TARGET = $(STAGE_CC_WRAPPER) ./gm2 -B./
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107655
Bug ID: 107655
Summary: [meta-bug] tracker bug for issues encountered in the
texinfo-to-sphinx migration
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
Jonathan Wakely changed:
What|Removed |Added
CC|jwakely.gcc at gmail dot com |
--- Comment #12 from
Snapshot gcc-11-2022 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-2022/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Fri, 11 Nov 2022 at 17:44, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux and x86_64-w64-ming32 (via Wine).
Sigh, I did test on Wine, but then what I pushed didn't include the
fix that was found thanks to that testing.
This is needed to prevent runtime errors on Windows when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:8214ec0cf33482f60139ae18a40567317e63c1ff
commit r13-3915-g8214ec0cf33482f60139ae18a40567317e63c1ff
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #4 from anlauf at gcc dot gnu.org ---
Partial fix:
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index b95c5cf2f96..f09fad337bc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6193,6
On Fri, 11 Nov 2022 11:17:17 -0500
Andrew MacLeod via Gcc-patches wrote:
> diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc
> index 3393c73a7db..a474d9d11e5 100644
> --- a/gcc/tree-vrp.cc
> +++ b/gcc/tree-vrp.cc
> @@ -4485,6 +4486,7 @@ public:
> for (gphi_iterator gsi = gsi_start_phis (bb);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
--- Comment #11 from Jonathan Wakely ---
As I said in Bug 107632 comment 2:
I'm kinda tempted to just disable the new optimization on these targets, the
handling of compat facets for different float ABIs is impossible to get right.
gcc/analyzer/ChangeLog:
* sm-fd.dot: Fix typo in comment.
* sm-file.dot: New file.
* varargs.cc: Fix typo in comment.
* varargs.dot: New file.
Signed-off-by: David Malcolm
---
gcc/analyzer/sm-fd.dot | 2 +-
gcc/analyzer/sm-file.dot | 67
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
wrote:
>
> On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> wrote:
> >
> >
> >
> > On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> > >
> > >
> > > On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> > >> PR92999
> On 8 Nov 2022, at 07:14, Sam James wrote:
>
> 1. This should speed up decompression for folks, as parallel xz
> creates a different archive which can be decompressed in parallel.
>
> Note that this different method is enabled by default in a new
> xz release coming shortly anyway (>=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #3 from anlauf at gcc dot gnu.org ---
I am still wondering if this is really invalid code.
null(z) has the same characteristics as z, see F2018:16.9.144
So is there really a mismatch of arguments?
Second, just one observation:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654
--- Comment #1 from Andrew Pinski ---
cppdiropts.rst cppenv.rst cppopts.rst cppwarnopts.rst
Also maybe should not be in the toplevel directory.
Maybe place them in libcpp instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107654
Bug ID: 107654
Summary: [13 Regression] md.rst should be in gcc/doc and not in
doc
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
--- Comment #6 from David Malcolm ---
The above patch implements -Wanalyzer-infinite-recursion for GCC 13.
I also have the beginnings of an implementation of -Wanalyzer-infinite-loop,
but it won't be ready for the close of GCC 13 stage 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107653
Bug ID: 107653
Summary: how-to-use-inline-assembly-language-in-c-code page is
huge and should be split up
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3913-g65752c1f7c41c5.
gcc/analyzer/ChangeLog:
* checker-path.h: Split out checker_event and its subclasses to...
* checker-event.h: ...this new header.
Signed-off-by: David Malcolm
---
This patch adds a new -Wanalyzer-infinite-recursion warning to
-fanalyzer, which complains about certain cases of infinite recursion.
Specifically, when it detects recursion during its symbolic execution
of the user's code, it compares the state of memory to that at the
previous level of
On 11/11/22 13:52, Gerald Pfeifer wrote:
On Tue, 8 Nov 2022, Martin Liška wrote:
After the migration, people should be able to build (and install) GCC
even if they miss Sphinx (similar happens now if you miss makeinfo).
My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke
(from
On 11/11/22 13:52, Gerald Pfeifer wrote:
On Tue, 8 Nov 2022, Martin Liška wrote:
After the migration, people should be able to build (and install) GCC
even if they miss Sphinx (similar happens now if you miss makeinfo).
My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke
(from
On 11/9/22 8:44 PM, Michael Meissner via Gcc-patches wrote:
> + /* For now, make -mtune=future the same as -mtune=power10. */
> + if (rs6000_tune == PROCESSOR_FUTURE)
> +rs6000_tune = PROCESSOR_POWER10;
This comment matches the code...
> + /* Some future processor. For now, just use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651
--- Comment #1 from Andrew Pinski ---
For the install page, one index should be index of configure option and another
one will be of the env variables.
For the preprocessor has an index of env variables too.
Maybe even in the main document
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107652
Bug ID: 107652
Summary: c++20 gccchoses incorrect operator== overload
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:12c583a2a3da798e82737c2d0e11fd686636cfeb
commit r13-3912-g12c583a2a3da798e82737c2d0e11fd686636cfeb
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107651
Bug ID: 107651
Summary: Having two different kind of indexes is very useful
still
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation
On 11/11/22 06:30, Jonathan Wakely via Gcc-patches wrote:
As discussed in the PR, this makes it three times faster to construct
iostreams objects.
Tested x86_64-linux. Pushed to trunk.
I haven't yet tried to track down what's going on, but with various
versions of Clang (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650
--- Comment #1 from Andrew Pinski ---
The side bar has issues with the text being so much bigger and popping out
compared to the main text. Plus when I scroll it, the search and icon part just
takes up so much of it, the side bar becomes not
On Tue, 8 Nov 2022, Martin Liška wrote:
> After the migration, people should be able to build (and install) GCC
> even if they miss Sphinx (similar happens now if you miss makeinfo).
My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke
(from what I can tell due to this - it's
On Tue, 8 Nov 2022, Martin Liška wrote:
> After the migration, people should be able to build (and install) GCC
> even if they miss Sphinx (similar happens now if you miss makeinfo).
My nightly *install* (not build) on amd64-unknown-freebsd12.2 broke
(from what I can tell due to this - it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #2 from Jonathan Wakely ---
Although if the _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is not defined, it will
still be ambiguous, because we won't define these overloads:
#if _GLIBCXX_USE_C99_COMPLEX
#if defined(__STDCPP_FLOAT16_T__)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107650
Bug ID: 107650
Summary: Sphinx generated web pages don't have up (to the
section index)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Bug ID: 107649
Summary: New std::complex specializations are never used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
1 - 100 of 317 matches
Mail list logo
