Could someone please approve this patch too? The base conversion patch
(https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568658.html) was
approved and committed, and fixing peepholes addresses a bunch of code
size regressions introduced by the base patch.
No regressions on all 4 devices, as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #4 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #3)
> Confirmed.
Merci, Dominique. Would you actually advise to compile without bootstrap and
start using gcc, or wait until the reason for the bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94136
palmer at gcc dot gnu.org changed:
What|Removed |Added
CC||palmer at gcc dot gnu.org
We have had an implementation of __builtin__clear_cache since the
beginning, but didn't have the cooresponding __clear_cache library
routine implemented. This directly conflicts the GCC manual in a
handful of places, which indicates that __clear_cache should work and
that __builtin_clear_cache
Hi:
For v{,p}expand* When mask is 0, -1, or has all all one bits in its
lower part, it can be optimized to simple mov or mask mov.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,} and
x86_64-linux-gnu{m32\ -march=cascadelake,-m64\ -march=cascadelake},
gcc/ChangeLog:
*
Hi:
This patch is to fix ice which was introduced by my
r11-5696-g35c4c67e6c534ef3d6ba7a7752ab7e0fbc91755b.
Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk and backport to GCC11?
gcc/ChangeLog
PR target/100310
* config/i386/i386-expand.c
>> This patch implements a new loop optimization according to the proposal
>> in RFC given at
>> https://gcc.gnu.org/pipermail/gcc/2021-January/234682.html.
>> So do not repeat the idea in this mail. Hope your comments on it.
>
> With the caveat that I'm not an optimization expert (but no one
On Wed, Apr 28, 2021 at 1:30 AM Geng Qi via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> gcc/ChangeLog:
> * config/riscv/riscv.opt (march=,mabi=): Negative itself.
>
Thanks. I committed this.
Do we need to backport to release branches? This looks like an uncommon
problem, or we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #16 from luoxhu at gcc dot gnu.org ---
> +2016-11-09 Segher Boessenkool
> +
> + * simplify-rtx.c (simplify_binary_operation_1): Simplify
> + (xor (and (xor A B) C) B) to (ior (and A C) (and B ~C)) and
> + (xor
On Wed, Apr 28, 2021 at 1:11 PM Joseph Myers
wrote:
> Could you please explain the bug at the *user-visible* level? That is,
> the particular options passed to the compiler, how those options behave,
> and how you think they should behave instead.
I added this to the riscv.opt file to create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100305
--- Comment #13 from Gilles Gouaillardet
---
Thanks Richard for the quick fix.
I am happy to confirm that the latest trunk passes the three reproducers
included in this ticket.
However, the latest gcc-11 branch only passes the mini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
--- Comment #4 from W E Brown ---
I won't comment on any compiler's behavior, but do want to thank you for
reminding me of [namespace.udecl]/14:
"When a using-declarator brings declarations from a base class into a derived
class, member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100267
--- Comment #5 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > After support v{,p}expand* thats w/o mask operands, codegen seems to be
> > optimal
> >
>
> I was wrong, without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
On Wed, Apr 28, 2021 at 10:43 PM Levy Hsu wrote:
> From: LevyHsu
>
> Added implementation for builtin overflow detection, new patterns are
> listed below.
>
This looks OK. You are missing a ChangeLog entry. I added one. I had to
fix some whitespace and formatting issues. Open parens should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
--- Comment #4 from Andrew Pinski ---
You are going to have to provide the whole build log to figure out why this is
happening.
Are you using a network mounted drive? If so do they have the time syncronized
between them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
Andrew Pinski changed:
What|Removed |Added
Component|other |bootstrap
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2019-02-03 00:00:00 |2021-4-29
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100348
Bug ID: 100348
Summary: RISC-V extra pointer adjustments for memcpy() from
glibc
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #1 from Erik Schnetter ---
Forgot to add: When I explicitly use "-march=skylake", everything works as
expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
Bug ID: 100347
Summary: GCC 11 does not recognize skylake; translates
"march=native" to "x86_64"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity:
On Thu, Apr 29, 2021 at 07:23:03PM -0400, Michael Meissner wrote:
> On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote:
> > On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> > > This patch defines the constants needed for libgcc for the PowerPC
> > > specific IEEE
On Thu, Apr 29, 2021 at 05:50:03PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> > This patch defines the constants needed for libgcc for the PowerPC
> > specific IEEE 128-bit floating point types (KFmode).
>
> It doesn't do that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
--- Comment #2 from Mark Hittinger ---
../gcc-11.1.0/configure \
--prefix=/usr/local/gcc1110 \
--disable-multilib \
--enable-languages=c,c++,fortran
x64 fedora using binutils-2.36 and gcc 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100346
Bug ID: 100346
Summary: [11 regression] printf tests fail after r11-6755
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi!
On Thu, Apr 29, 2021 at 05:48:53PM -0400, Michael Meissner wrote:
> This patch defines the constants needed for libgcc for the PowerPC
> specific IEEE 128-bit floating point types (KFmode).
It doesn't do that though?
> The 4/28 changes to libgcc need these constants defined.
I wondered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344
--- Comment #4 from cqwrteur ---
Created attachment 50713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50713=edit
Preprocess
sorry. the file was too large.
It looks like it is an issue related to constexpr evaluation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344
--- Comment #3 from cqwrteur ---
(In reply to Marek Polacek from comment #2)
> Testcase?
i can only provide preprocess file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
Snapshot gcc-9-20210429 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210429/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100345
Bug ID: 100345
Summary: gcc 11.1 build "make -n install" fails linking gcov
undefined reference to
std::__throw_bad_array_new_length()
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #5 from m.cencora at gmail dot com ---
Actually standard seems to require it - at least to my understanding of wait()
description in in chapter 31.8.1: it explicitly states that waiting is
performed in a loop, and loop is exited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344
--- Comment #1 from cqwrteur ---
D:\hg\fast_io\.tmp\dragonboxtest>g++ -o a a.cc -Ofast -std=c++20 -s -flto
-march=native -Wall -Wextra
In file included from ../../include/fast_io_core_impl/codecvt/impl.h:7,
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100344
Bug ID: 100344
Summary: compiler ICE internal compiler error: in build_call_a,
at cp/call.c:38
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100330
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100343
Bug ID: 100343
Summary: add -Wundefined-inline for inline function is used but
not defined
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
On 4/29/21 1:02 PM, Indu Bhagat wrote:
+{
+ dw_die_ref c;
+
+ if (!ctf_do_die (die))
+ return;
+
+ FOR_EACH_CHILD (die, c, ctf_do_die (c));
+}
+
/* Perform any cleanups needed after the early debug generation pass
has run. */
@@ -32471,6 +32491,16 @@ dwarf2out_early_finish (const
On Wed, Apr 28, 2021 at 4:04 PM Andrew Waterman wrote:
> > This is a good suggestion, but in the interests of making forward
> progress here, I'd like to accept the patch and then file these as
> bugzillas as ways to further improve the patch.
>
> Agreed, these potential improvements are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
--- Comment #3 from Jonathan Wakely ---
I don't know if that rule applies here. If it did, this would be invalid too
(by [over.load]/2.1), but all compilers agree that this is OK:
struct Base {
int method() {}
};
struct Derived : Base {
[PATCH, V2] Define KFmode constants for libgcc.
This patch defines the constants needed for libgcc for the PowerPC
specific IEEE 128-bit floating point types (KFmode). The 4/28 changes to
libgcc need these constants defined.
We only define the KFmode constants if IEEE 128-bit floating point is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
--- Comment #2 from Daniel ---
As an extra Info: the other compilers I tested (e.g. clang) accept the code
example as is.
But after reading the cited pet of the standard It seems that GCC is right in
rejecting this and the other compilers have
On Thu, Apr 29, 2021 at 04:48:07PM +, Joseph Myers wrote:
> On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
>
> > On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> > > On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> > >
> > > > Fix PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
--- Comment #6 from Iain Sandoe ---
(In reply to anlauf from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > gcc304 is the Apple M1 machine. The GCC support there is highly
> > experimental and not in master -- please note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #2 from Jürgen Reuter ---
I just check, with --disable-bootstrap, gcc compiles to the end. Just the
checksums of the object files for bootstrap between stage 2 and 3 don't agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100335
W E Brown changed:
What|Removed |Added
CC||webrown.cpp at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100275
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100341
cqwrteur changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100341
--- Comment #1 from cqwrteur ---
it looks we need to rebuild cross compiler before Canadian cross-compile
because the cross compiler itself might not provide the macros we need.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100338
--- Comment #2 from seurer at gcc dot gnu.org ---
On a system where things fail (Ubuntu 20.04.1):
Python 2.7.18
GNU gdb (GDB) 11.0.50.20201107-git
On a working system (Ubuntu 18.04.5):
Python 2.7.17
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
On 29/04/21 11:04 -0400, Patrick Palka via Libstdc++ wrote:
This implements the wording changes of P2367R0 "Remove misuses of
list-initialization from Clause 24", modulo the parts that depend
on P1739R4 which we don't yet implement (due to LWG 3407).
Tested on x86_64-pc-linux-gnu, does this
On 29/04/21 16:06 -0400, David Edelsohn wrote:
On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely wrote:
On 06/01/21 19:41 -0500, David Edelsohn wrote:
>Thanks for clarifying the issue.
>
>As you implicitly point out, GCC knows the type of INT64 and defines
>the macro __INT64_TYPE__ . The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100342
Bug ID: 100342
Summary: [10/11 Regression] wrong code with -O2 -fno-dse
-fno-forward-propagate -mno-sse2
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
On Fri, Jan 8, 2021 at 1:37 PM Jonathan Wakely wrote:
>
> On 06/01/21 19:41 -0500, David Edelsohn wrote:
> >Thanks for clarifying the issue.
> >
> >As you implicitly point out, GCC knows the type of INT64 and defines
> >the macro __INT64_TYPE__ . The revised code can use that directly,
> >such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82359
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
In ix86_int_compare, opportunistically swap operands of GTU and LEU comparisons
to emit carry flag comparison, with the expectation that the comparison will
combine to *add3_carry_0 or *sub3_carry_0 insn pattern.
Do not use ix86_expand_carry_flag_compare because this function prefers
carry flag
Hello,
On 4/29/21 5:10 AM, Richard Biener wrote:
On Thu, 29 Apr 2021, Jose E. Marchesi wrote:
This commit introduces support for generating CTF debugging
information and BTF debugging information from GCC.
Comments inline.
Thanks for your reviews.
My responses and questions inline at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100341
Bug ID: 100341
Summary: build fails of error: '__LIBGCC_DF_EPSILON__'
undeclared (first use in this function) for mingw-w64
Product: gcc
Version: 12.0
Status:
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 Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-11.1.0.sv.po', has
I've now committed this patch as preparation for further digit separator
fixes and enabling digit separators for C2x, but would still welcome any
C++ maintainer comments.
--
Joseph S. Myers
jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82359
--- Comment #4 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:b24d8acbfffe30f40e280f11f23adac81b1e7f0c
commit r12-302-gb24d8acbfffe30f40e280f11f23adac81b1e7f0c
Author: Joseph Myers
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #1 from Jürgen Reuter ---
After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang
clang-1205.0.22.9, bootstrap doesn't work any more:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
Bug ID: 100340
Summary: Bootstrap fails with Clang 12.0.5 (XCode 12.5)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100339
Marek Polacek changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100339
Bug ID: 100339
Summary: Bogus "should have been declared inside" error with
friend
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
-fdata-sections places data symbols into their own, unique, named sections.
-fsection-anchors create an anchor to access neighboring symbols
within a section.
When both are enabled, a separate section anchor is created for each
symbol, which provides no benefit.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100338
--- Comment #1 from Jonathan Wakely ---
Some of these tests are sensitive to GDB and Python versions. Do they differ
between machines?
I'll take a look at this tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100338
Bug ID: 100338
Summary: [11 regression] Python error running test case after
r11-2720
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51344
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a0fdff3cf33f72848d3f894272431a5d49fe6a16
commit r12-299-ga0fdff3cf33f72848d3f894272431a5d49fe6a16
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:58a92b789a77cdade1f41800efebf6e0686f9982
commit r12-298-g58a92b789a77cdade1f41800efebf6e0686f9982
Author: Jason Merrill
Date:
In discussion of PR98463, Jakub noted that cxx_fold_indirect_ref_1 was
bailing out early for empty bases even when we do have fields for them (in
C++17 mode or later). This corrects that.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* constexpr.c
51344 was a problem with calling save_template_attributes twice for the same
friend function: once from do_friend and once from grokmethod. The 2012
patch for the bug avoided creating an infinite loop when this happens, but
it's better to avoid the duplication in the first place. This also
While working on the GCC 11 patch, it occurred to me that we could move
the errors about invalid members from finish_struct_anon_r to here, so we
properly get a diagnostic in g++.law/union4.C.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/97974
*
My GCC 11 patch for PR93314 turned off cp_unevaluated_operand while
processing an id-expression that names a non-static data member, but the
broader issue is that in general, a constant-expression is evaluated even in
an unevaluated operand.
Tested x86_64-pc-linux-gnu, applying to trunk.
On Thu, Apr 29, 2021 at 11:54:27AM -0600, Martin Sebor via Gcc wrote:
> On 4/29/21 11:32 AM, Jakub Jelinek wrote:
> > On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote:
> > > The C front end (and perhaps others as well) creates internal
> > > variables in a few places, such as
Once a CONSTRUCTOR has been digested and used as an initializer, it no
longer represents a compound literal by itself, so we can clear the flag,
letting us use it consistently to distinguish between digested and
undigested initializer-lists.
Tested x86_64-pc-linux-gnu, applying to trunk.
On 4/29/21 11:18 AM, David Malcolm wrote:
I've been going through old Linux kernel CVEs, trying to prototype some
possible new warnings for -fanalyzer in GCC 12 (and, alas, finding
places where the analyzer internals need work...)
I think I want a way for the user to be able to mark security
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100304
--- Comment #3 from Zdenek Sojka ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this one.
Were you testing with a clean build, or did you have PR100303 fix applied?
On master, it stopped failing for me between r12-285 (BAD)
On Thu, Apr 29, 2021 at 8:52 AM Jeff Law wrote:
>
> This change:
>
> 985b3a6837dee7001e6b618f073ed74f0edf5787 is the first bad commit
> commit 985b3a6837dee7001e6b618f073ed74f0edf5787
> Author: H.J. Lu
> Date: Mon Jun 10 09:57:15 2019 -0700
>
> Generate offset adjusted operation for
On 4/29/21 11:32 AM, Jakub Jelinek wrote:
On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote:
The C front end (and perhaps others as well) creates internal
variables in a few places, such as in convert_lvalue_to_rvalue
like so:
/* Remove the qualifiers for the rest of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100331
Michael Benfield changed:
What|Removed |Added
CC||mbenfield at google dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:efeca0ac4155b76ce713155f190422aac20537c5
commit r12-295-gefeca0ac4155b76ce713155f190422aac20537c5
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589
--- Comment #17 from Jakub Jelinek ---
Created attachment 50710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50710=edit
gcc12-pr94589-wip.patch
WIP patch that just matches those spaceship comparisons followed by single use
comparison of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
We correctly accept this testcase since r11-1571.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
PR c++/94102
* g++.dg/cpp1z/class-deduction87.C: New test.
---
gcc/testsuite/g++.dg/cpp1z/class-deduction87.C | 15 +++
1 file changed, 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94102
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:f24702258fc78ac37b3e8154d76239cccd30c422
commit r12-294-gf24702258fc78ac37b3e8154d76239cccd30c422
Author: Marek Polacek
Date:
On Thu, Apr 29, 2021 at 11:22:15AM -0600, Martin Sebor via Gcc wrote:
> The C front end (and perhaps others as well) creates internal
> variables in a few places, such as in convert_lvalue_to_rvalue
> like so:
>
> /* Remove the qualifiers for the rest of the expressions and
>create
The C front end (and perhaps others as well) creates internal
variables in a few places, such as in convert_lvalue_to_rvalue
like so:
/* Remove the qualifiers for the rest of the expressions and
create the VAL temp variable to hold the RHS. */
nonatomic_type =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Brecht Sanders changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
I've been going through old Linux kernel CVEs, trying to prototype some
possible new warnings for -fanalyzer in GCC 12 (and, alas, finding
places where the analyzer internals need work...)
I think I want a way for the user to be able to mark security
boundaries in their code: for example:
* in
On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> > On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> >
> > > Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
> > >
> > > This patch fixes the PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337
Bug ID: 100337
Summary: Should be able to pass non-present optional arguments
to CO_BROADCAST
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46250
Zdenek Sojka changed:
What|Removed |Added
Known to work||5.5.0, 6.5.0, 7.5.0
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067
Zdenek Sojka changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #13
On Thu, Apr 29, 2021 at 04:31:50PM +, Joseph Myers wrote:
> On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
>
> > Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
> >
> > This patch fixes the PowerPC _divkf3.c module to use the appropriate
> > FLT128 constants if long double is
On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote:
> Fix PR bootstrap/100327 (_divkf3.c) on PowerPC.
>
> This patch fixes the PowerPC _divkf3.c module to use the appropriate
> FLT128 constants if long double is not IEEE 128-bit.
>
> I have tested this patch by doing a bootstrap on a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #4 from Thomas Rodgers ---
This analysis is likely correct, except for -
"- protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value has changed from old, if not then wait again"
An earlier version of
1 - 100 of 281 matches
Mail list logo
