Hi,
On 2022-11-16 03:11, Hans-Peter Nilsson wrote:
How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested? I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*. I think it was only tested for
the special-case of an installed
On Wed, 16 Nov 2022, Hongyu Wang wrote:
> > When emitting a compare-and-swap loop for @ref{__sync Builtins}
> > and @ref{__atomic Builtins} lacking a native instruction, optimize
> > for the highly contended case by issuing an atomic load before the
> > @code{CMPXCHG} instruction, and using the
Hi,
As Robin spotted, my recent commit r13-3716 caused an ICE
on s390 if vector access with length is enabled there (his
patch for the enablement hasn't been committed yet). The
failure is caused by one stupid typo, the bias on s390 is
-1, so the assertion should use tree_fits_shwi_p rather
than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
--- Comment #1 from Jinyang He ---
Created attachment 53906
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53906=edit
a simple test
Hi,
The current handlings in rs6000_emit_vector_compare is a bit
complicated to me, especially after we emit vector float
comparison insn with the given code directly. This patch is
to refine the handlings for vector integer comparison operators,
it becomes not recursive, and we don't need the
Hi,
All kinds of vector float comparison operators have been
supported in one rtl comparison pattern as vector.md, we can
just emit an rtx comparison insn with the given comparison
operator in function rs6000_emit_vector_compare instead of
checking and handling the reverse condition cases.
This
Hi!
The following testcase ICEs, because when !HONOR_NANS but
HONOR_SIGNED_ZEROS, if we see
lhs = op1 * op2;
and know that lhs is [-0.0, 0.0] and op2 is [0.0, 0.0], the
division of these two yields UNDEFINED and clear_nan () on it
fails an assert. With HONOR_NANS it would actually result in
a
On Mon, Nov 14, 2022 at 10:14 AM Hongtao Liu wrote:
>
> On Fri, Nov 11, 2022 at 10:47 PM Tamar Christina via Gcc-patches
> wrote:
> >
> > Hi All,
> >
> > The current i386 implementation of the TARGET_CAN_CHANGE_MODE_CLASS is
> > currently
> > not useful before re-alloc.
> >
> > In particular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe
commit r13-4081-g7c6cd9c05efca29a1a9635b81c86cbad25bbdbbe
Author: Jakub Jelinek
Date:
On Wed, Nov 16, 2022 at 12:27:02AM +, Jonathan Wakely wrote:
> On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
> >
> > On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > > Here is an updated patch that passed bootstrap/regtest, the only
> > > > change is another testcase
On 15/11/22 17:17, Jonathan Wakely wrote:
On 06/10/22 19:38 +0200, François Dumont wrote:
Hi
Looks like the previous patch was not enough. When using it in the
context of a build without dual abi and versioned namespace I started
having failures again. I guess I hadn't rebuild everything
Hi David,
I found definition of the operands in 'cbranch'. The argumnets matters.
I will create a new expand pattern for cbranchcc4. Thanks a lot for your
comments.
'cbranchmode4’
Conditional branch instruction combined with a compare instruction.
Operand 0 is a comparison operator. Operand 1
> When emitting a compare-and-swap loop for @ref{__sync Builtins}
> and @ref{__atomic Builtins} lacking a native instruction, optimize
> for the highly contended case by issuing an atomic load before the
> @code{CMPXCHG} instruction, and using the @code{PAUSE} instruction
> to save CPU power when
On Tue, 15 Nov 2022, Patrick Palka wrote:
> When linking with a static library, the linker seems to exclude a
> constituent .o object (including its global initializers) if nothing
> from it is referenced by the program (unless e.g. --whole-archive is
> used). This behavior breaks iostream when
On 11/10/22 12:05, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and
On 10/28/22 10:55, David Abdurachmanov via Gcc-patches wrote:
On Fri, Sep 2, 2022 at 1:09 PM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
LGTM with minor comments, it's time to move forward, thanks Patrick and
Palmer.
Ping.
Any plans to finally land this one for GCC 13?
On 11/3/22 07:29, Rasmus Villemoes wrote:
On 02/11/2022 16.45, Jeff Law wrote:
On 11/2/22 06:35, Rasmus Villemoes wrote:
However, when I try to push the new master branch I get
$ git push origin master
fatal: remote error: service not enabled: /git/gcc.git
I do gcc patches sufficiently
On 11/10/22 14:35, Philipp Tomsich wrote:
Sequences of the form "a ^ C" with C being the positive half of a
signed immediate's range with one extra bit set in addtion are mapped
to xori and one binvi to avoid using a temporary (and a multi-insn
sequence to load C into that temporary).
On 11/10/22 14:34, Philipp Tomsich wrote:
Sequences of the form "a | C" with C being the positive half of a
signed immediate's range with one extra bit set in addtion are mapped
to ori and one binvi to avoid using a temporary (and a multi-insn
sequence to load C into that temporary).
On 11/11/22 09:22, Richard Sandiford via Gcc-patches wrote:
Epilogues for sibling calls are generated using the
sibcall_epilogue pattern. One disadvantage of this approach
is that the target doesn't know which call the epilogue is for,
even though the code that generates the pattern has the
On 11/12/22 20:47, Max Filippov wrote:
On Sat, Nov 12, 2022 at 11:42 AM Jeff Law wrote:
ISTM that we'd need to strip the unspec and process its argument
instead.
I tried that first, the result was more ICEs because that pattern
wasn't recognized at later stages. Then I read the change to
On 11/15/22 16:08, Christoph Muellner wrote:
From: Christoph Müllner
This patch fixes a wrong placed closing bracket in the RISC-V option
list and an unneeded @gol in the PRU option list in invoke.texi.
gcc/ChangeLog:
* doc/invoke.texi: Fix PRU/RISC-V option list formatting.
OK.
在 2022/11/16 上午11:06, WANG Xuerui 写道:
On 2022/11/16 10:10, Lulu Cheng wrote:
v2 -> v3:
1. Remove preldx support.
---
Enable sw prefetching at -O3 and higher.
Co-Authored-By: xujiahao
gcc/ChangeLog:
* config/loongarch/constraints.md (ZD): New
Failed to deliver to 'enqu...@technochemicals.com.tn'
Message detected as SPAM
Reporting-MTA: dns; mx01.ingw.orange.tn
Original-Recipient: rfc822;
Final-Recipient: system;
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;Message detected as SPAM
Received: by mx01.ingw.orange.tn (CommuniGate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
Bug ID: 107713
Summary: Wrong implementation atomic_exchange on
LoongArch
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority:
On 2022/11/16 10:10, Lulu Cheng wrote:
v2 -> v3:
1. Remove preldx support.
---
Enable sw prefetching at -O3 and higher.
Co-Authored-By: xujiahao
gcc/ChangeLog:
* config/loongarch/constraints.md (ZD): New constraint.
*
On Tue, Nov 15, 2022 at 9:32 PM HAO CHEN GUI wrote:
> Hi,
> The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
> indicate if branch by CC bits is invalid or not. As rs6000 already has
> "*cbranch" insn which does branching according to CC bits, the flag
> should be enabled and
When linking with a static library, the linker seems to exclude a
constituent .o object (including its global initializers) if nothing
from it is referenced by the program (unless e.g. --whole-archive is
used). This behavior breaks iostream when linking with static libstdc++.a
(on systems that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Haochen Jiang changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
on 2022/11/10 11:30, Kewen.Lin wrote:
> on 2022/11/9 15:56, Eric Botcazou wrote:
>>> The previous testings on powerpc64{,le}-linux-gnu covered language Go, but
>>> not Ada. I re-tested it with languages c,c++,fortran,objc,obj-c++,go,ada
>>> on powerpc64le-linux-gnu, the result looked good. Both
Hi,
The patch enables have_cbrnachcc4 which is a flag in ifcvt.cc to
indicate if branch by CC bits is invalid or not. As rs6000 already has
"*cbranch" insn which does branching according to CC bits, the flag
should be enabled and relevant branches can be optimized out. The test
case illustrates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90259
--- Comment #8 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:63e1b2e767a3f4695373c2406ff719c0a60c1858
commit r13-4079-g63e1b2e767a3f4695373c2406ff719c0a60c1858
Author: Kewen Lin
Date: Tue Nov
v2 -> v3:
1. Remove preldx support.
---
Enable sw prefetching at -O3 and higher.
Co-Authored-By: xujiahao
gcc/ChangeLog:
* config/loongarch/constraints.md (ZD): New constraint.
* config/loongarch/loongarch-def.c: Initial number of parallel
On 2022/11/15 下午10:21, Xi Ruoyao wrote:
On Tue, 2022-11-15 at 21:03 +0800, Jinyang He wrote:
gcc/ChangeLog:
* config/loongarch/sync.md:
Add atomic_cas_value_exchange_and_7 and fix atomic_exchange.
nit:
* config/loongarch/sync.md (atomic_cas_value_exchange_and_7):
New
How was r13-2619-g34b9a03353d3fd "gcov: Respect triplet when looking
for gcov" tested? I'm having a hard time believing it was tested with
a *cross-compiler* *in-build-tree*. I think it was only tested for
the special-case of an installed cross-compiler; not even with a
native build exercising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107701
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #9 from Tomoya Suzuki ---
Thanks for clarifying the cause. I don't think you need to add the macro just
for me, gcc11 behavior is not critical for me.
Hi Gerald,
I will remove "to GCC" here if there is no more comment from others on Thursday.
For me it is reasonable.
Thx,
Haochen
> -Original Message-
> From: Gerald Pfeifer
> Sent: Monday, November 14, 2022 9:56 PM
> To: Jiang, Haochen
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107712
Bug ID: 107712
Summary: std::format does not work for clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
On Tue, 15 Nov 2022 at 22:14, Philipp Tomsich wrote:
>
> Jeff,
>
> On Tue, 15 Nov 2022 at 17:37, Jeff Law wrote:
> >
> >
> > On 11/13/22 13:41, Philipp Tomsich wrote:
> >
> > RISC-V's .p2align (currently) ignores the max-skip argument. As we
> > have experimental patches underway to address
On Tue, Nov 15, 2022 at 06:58:39PM -0500, Jason Merrill wrote:
> On 11/12/22 06:53, Marek Polacek wrote:
> > In this PR, we are crashing because we've encountered a UDL where a
> > string-literal is expected. This patch makes the parser reject string
> > and character UDLs in all places where the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
Bug ID: 107711
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Mon, Nov 14, 2022 at 06:00:58PM -0500, Jason Merrill wrote:
> On 11/9/22 10:53, Marek Polacek wrote:
> > This patch implements C++23 P2448, which lifts more restrictions on the
> > constexpr keyword. It's effectively going the way of being just a hint
> > (hello, inline!).
> >
> > This gist
On Tue, 15 Nov 2022 at 23:50, Jakub Jelinek wrote:
>
> On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > > Here is an updated patch that passed bootstrap/regtest, the only
> > > change is another testcase tweak.
> > >
> > > 2022-11-13 Jakub Jelinek
> > >
> > > gcc/c-family/
>
On Tue, 15 Nov 2022 at 23:36, Jason Merrill wrote:
>
> On 11/13/22 01:45, Jakub Jelinek wrote:
> > On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
> >> The following patch on top of Marek's P2448 PR106649 patch
> >> (mainly because that patch implements the previous __cpp_constexpr
On Tue, 15 Nov 2022 at 01:46, Kito Cheng wrote:
>
> Hi Christoph:
>
> > This patch implements expansions for the cmpstrsi and the cmpstrnsi
> > builtins using Zbb instructions (if available).
> > This allows to inline calls to strcmp() and strncmp().
> >
> > The expansion basically emits a peeled
On Tue, 15 Nov 2022, Sam James wrote:
On 13 Nov 2022, at 00:43, Paul Eggert wrote:
On 2022-11-11 07:11, Aaron Ballman wrote:
We believe the runtime behavior is sufficiently dangerous to
warrant a conservative view that any call to a function will be a call
that gets executed at runtime,
On 11/8/22 16:10, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such
On 11/8/22 16:10, Ben Boeckel wrote:
Unicode does not support such values because they are unrepresentable in
UTF-16.
libcpp/
* charset.cc: Reject encodings of codepoints above 0x10.
UTF-16 does not support such codepoints and therefore all
Unicode rejects such
On 11/8/22 16:10, Ben Boeckel wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
libcpp/
* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
*
On 11/8/22 16:10, Ben Boeckel wrote:
This simplifies the interface for other UTF-8 validity detections when a
simple "yes" or "no" answer is sufficient.
libcpp/
* charset.cc: Add `_cpp_valid_utf8_str` which determines whether
a C string is valid UTF-8 or not.
*
On 11/12/22 06:53, Marek Polacek wrote:
In this PR, we are crashing because we've encountered a UDL where a
string-literal is expected. This patch makes the parser reject string
and character UDLs in all places where the grammar requires a
string-literal and not a user-defined-string-literal.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #2 from joseph at codesourcery dot com ---
(Where "check for any high bits being set" needs appropriate adjustment in
the case of negative values for conversion from signed __int128, e.g. "the
high 64 bits aren't the
On 11/12/22 13:45, Bernhard Reutner-Fischer wrote:
gcc/cp/ChangeLog:
* decl.cc (start_function): Set the result decl source location to
the location of the typespec.
---
Bootstrapped and regtested on x86_86-unknown-linux with no regressions.
Ok for trunk?
Cc: Nathan Sidwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107702
--- Comment #1 from joseph at codesourcery dot com ---
On Tue, 15 Nov 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote:
> _Float16 f9 (__int128 x) { return x; }
> _Float16 f10 (__int128 x) { return x; }
I suppose one of those is meant to be
On Tue, Nov 15, 2022 at 06:36:38PM -0500, Jason Merrill wrote:
> > Here is an updated patch that passed bootstrap/regtest, the only
> > change is another testcase tweak.
> >
> > 2022-11-13 Jakub Jelinek
> >
> > gcc/c-family/
> > * c-cppbuiltin.cc (c_cpp_builtins): Bump __cpp_constexpr
> >
On Tue, Nov 15, 2022 at 15:09:19 -0800, Paul Eggert wrote:
> This may be a hack, but it's a *good* hack. It's likely to fix
> real-world bugs that would be caused if Clang becomes overly pedantic by
> default here. And the probability of introducing real-world bugs is
> essentially zero.
FWIW,
On 11/13/22 01:45, Jakub Jelinek wrote:
On Fri, Nov 11, 2022 at 06:07:04PM +0100, Jakub Jelinek wrote:
The following patch on top of Marek's P2448 PR106649 patch
(mainly because that patch implements the previous __cpp_constexpr
feature test macro bump so this can't go in earlier; OT,
P2280R4
On 11/13/22 01:43, Jakub Jelinek wrote:
On Fri, Nov 11, 2022 at 08:43:04AM +0100, Jakub Jelinek wrote:
Again, because stage1 close is near, posting the following patch
to implement CWG 2654.
Ok for trunk if it passes bootstrap/regtest and is voted into C++23
and C++20 as a DR?
Here is an
On 11/13/22 01:50, Jakub Jelinek wrote:
On Sat, Nov 12, 2022 at 12:23:56PM +0100, Jakub Jelinek wrote:
The following patch implements CWG2635.
So far tested on
GXX_TESTSUITE_STDS=98,11,14,17,20,2b make check-g++
RUNTESTFLAGS="dg.exp=decomp*"
ok for trunk if it passes full bootstrap/regtest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #7 from Sergei Trofimovich ---
Looking -fdump-ipa-cp-all I see the following clone
```
IPA decision stage:
Evaluating opportunities for static void function_ref::callback_fn(void*) [with
Callable =
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is the wrong
prototype? Is it plausible that any such security flaw exists?
CVE-2006-1174 is a possibly reasonable example.
CVE-2006-1174 is not an example, because no
From: Christoph Müllner
This patch fixes a wrong placed closing bracket in the RISC-V option
list and an unneeded @gol in the PRU option list in invoke.texi.
gcc/ChangeLog:
* doc/invoke.texi: Fix PRU/RISC-V option list formatting.
Signed-off-by: Christoph Müllner
---
On Tue, Nov 15, 2022 at 11:54 PM Andreas Schwab
wrote:
> On Nov 15 2022, Christoph Muellner wrote:
>
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index 057439a004c..dfac7c85844 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -1220,8 +1220,8 @@ See
On 11/14/22 01:28, Jakub Jelinek wrote:
Hi!
Working virtually out of Baker Island.
When trying to figure out what to do about alignment,
layout_compatible_type_p returns false if TYPE_ALIGN on
ENUMERAL_TYPE/CLASS_TYPE_P (but not scalar types?) differ, or if members
don't have the same
On Nov 15 2022, Christoph Muellner wrote:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 057439a004c..dfac7c85844 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -1220,8 +1220,8 @@ See RS/6000 and PowerPC Options.
> -malign-data=@var{type} @gol
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492
--- Comment #7 from Jonathan Wakely ---
I think clang warns there too, but we could.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107492
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ed1797ddf8285f59a50d9c883beb97705279d980
commit r13-4077-ged1797ddf8285f59a50d9c883beb97705279d980
Author: Marek Polacek
Date:
From: Christoph Müllner
This patch fixes a wrong placed closing bracket in the RISC-V section of
invoke.texi.
gcc/ChangeLog:
* doc/invoke.texi: Fix closing block bracket
Signed-off-by: Christoph Müllner
---
gcc/doc/invoke.texi | 4 ++--
1 file changed, 2 insertions(+), 2
On Tue, Nov 15, 2022 at 1:46 AM Kito Cheng wrote:
> Hi Christoph:
>
> > This patch implements expansions for the cmpstrsi and the cmpstrnsi
> > builtins using Zbb instructions (if available).
> > This allows to inline calls to strcmp() and strncmp().
> >
> > The expansion basically emits a
On Tue, 15 Nov 2022 at 17:40, Jeff Law wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
> > The Zihintpause extension uses an opcode from the 'fence' opcode range
> > to add a true hint instruction (i.e. if it is not supported on any
> > given platform, the 'fence' that is encoded will not
On 11/14/22 14:33, Marek Polacek wrote:
On Thu, Nov 03, 2022 at 03:22:12PM -0400, Jason Merrill wrote:
On 11/1/22 13:01, Marek Polacek wrote:
It seems wrong to issue a -Wignored-qualifiers warning for code like:
static_assert(!is_same_v);
because there the qualifier matters. Likewise in
On 11/14/22 22:54, Jakub Jelinek wrote:
On Tue, Nov 15, 2022 at 09:54:00AM +0100, Jakub Jelinek via Gcc-patches wrote:
On Mon, Nov 14, 2022 at 07:00:54PM -0500, Jason Merrill wrote:
The following patch adds parsing of attributes to concept definition,
allows deprecated attribute to be
On 11/15/22 02:28, Jakub Jelinek wrote:
Hi!
On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
Indeed. The code in build_new_method_call for this case has the comment
/* In an expression of the form `a->f()' where `f' turns
out to be a static
This Friday, 18 November, at 16:00 UTC (11:00am Eastern, 17:00 Central
European Time) the FSF will host a session on their BBB server about
the current sourceware infrastructure and future plans.
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a
This Friday, 18 November, at 16:00 UTC (11:00am Eastern, 17:00 Central
European Time) the FSF will host a session on their BBB server about
the current sourceware infrastructure and future plans.
https://www.fsf.org/events/sourceware-infrastructure-a-presentation-and-community-q-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #9 from anlauf at gcc dot gnu.org ---
Something like the following rejects NULL when there is no interface:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 49dbd1d886c..62b325b726d 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107243
--- Comment #2 from David Binderman ---
Nothing has happened on this for over a month.
The bug still exists in current sources.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107710
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Andrew Pinski changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107710
Bug ID: 107710
Summary: error: ‘constinit’ on function return type is not
allowed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Jeff,
On Tue, 15 Nov 2022 at 17:37, Jeff Law wrote:
>
>
> On 11/13/22 13:41, Philipp Tomsich wrote:
>
> RISC-V's .p2align (currently) ignores the max-skip argument. As we
> have experimental patches underway to address this in a
> backwards-compatible manner, let's prepare GCC for the day when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107709
Bug ID: 107709
Summary: IVOPTs is introducing a non-zero assumption
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638
John David Anglin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072
--- Comment #3 from Rainer Orth ---
At least when building the devel/rust/master branch as of 2022, the warning
doesn't occur any longer. I haven't investigated why, though.
On Tue, Nov 15, 2022 at 3:27 PM Paul Eggert wrote:
>
> On 2022-11-15 11:27, Jonathan Wakely wrote:
> > Another perspective is that autoconf shouldn't get in the way of
> > making the C and C++ toolchain more secure by default.
>
> Can you cite any examples of a real-world security flaw what would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107695
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
Dear all,
when constant expressions involve parentheses, array constructors,
typespecs, and the power operator (**), we could fail with an ICE
during simplification in arith_power.
Debugging of the testcase showed we call the proper type conversions
needed for the arithmetic operation, but under
Mark Wielaard writes:
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old
> if someone wants to push that, to merge for a v4.
Sorry, missed that part, taking care of merging it right now :)
https://github.com/Rust-GCC/gccrs/pull/1649
Thanks,
Marc
Mark Wielaard writes:
> https://code.wildebeest.org/git/user/mjw/gccrs/commit/?h=no-Rust-old
> if someone wants to push that, to merge for a v4.
Sorry, missed that part, taking care of merging it right now :)
https://github.com/Rust-GCC/gccrs/pull/1649
Thanks,
Marc
--
Gcc-rust mailing list
On Tue, Nov 15, 2022 at 2:08 PM Paul Eggert wrote:
>
> On 2022-11-15 06:50, Jonathan Wakely wrote:
> > Could you clarify what you mean, with a concrete example? Surely as
> > long as errors are reported on stderr and the compiler exits with
> > non-zero status, that's an acceptable way to report
On 2022-11-15 11:27, Jonathan Wakely wrote:
Another perspective is that autoconf shouldn't get in the way of
making the C and C++ toolchain more secure by default.
Can you cite any examples of a real-world security flaw what would be
found by Clang erroring out because 'char foo(void);' is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106765
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107708
--- Comment #2 from Christoph Steefel ---
Ok. If passing arguments to a constructor function is explicitly undefined, and
gcc is willing to optimize based on that, should it be documented in the
constructor attribute docs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100532
Andrew Pinski changed:
What|Removed |Added
Target Milestone|12.3|---
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100525
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057
Bug 101057 depends on bug 100525, which changed state.
Bug 100525 Summary: ICE: tree check: expected class ‘type’, have ‘exceptional’
(error_mark) in useless_type_conversion_p, at gimple-expr.c:87
1 - 100 of 280 matches
Mail list logo
