https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #11 from Richard Biener ---
Yes, they should compare equal. Integer constant ranges do not need a type.
Not even FP constant ranges. Symbolic ranges need a type, but then the
endpoints in their symbolic form have one (and those
On Thu, 2 Feb 2023, Qing Zhao wrote:
>
>
> > On Feb 2, 2023, at 8:54 AM, Richard Biener wrote:
> >
> > On Thu, 2 Feb 2023, Qing Zhao wrote:
> >
> >>
> >>
[...]
> >> + return flexible_size_type_p (TREE_TYPE (last));
> >
> > For types with many members this can become
On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches
wrote:
>
> I'm reposting these two patches that allow GCC to build on Fedora 36 just to
> be
> clear which patches I'm talking about. The issue is that if GCC is configured
> with long double using the IEEE 128-bit representation,
On Fri, Feb 3, 2023 at 12:39 AM Vineet Gupta wrote:
>
> Hi,
>
> I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
> This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
> Problem also happens with -O3 -ffast-math (and goes away with fast-math
> removed)
>
> I've bisected it to
On Thu, Feb 2, 2023 at 6:39 PM Michael Meissner via Gcc-patches
wrote:
>
> The new __dmr type that is being added as a possible future PowerPC
> instruction
"is being added" means this feature is already in GCC 13?
> set bumps into a structure field size issue. The size of the __dmr type is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote:
>
> Hi,
>
> when the compiled program contains type mismatches between callers and
> callees when it comes to a parameter, IPA-CP can try to propagate one
> constant from callers while IPA-SRA may try to split a parameter
> expecting a value of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108650
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
Hi Richard,
While digging thru aarch64_expand_vector_init, I noticed it gives
priority to loading a constant first:
/* Initialise a vector which is part-variable. We want to first try
to build those lanes which are constant in the most efficient way we
can. */
which results in
committed, thanks!
On Wed, Feb 1, 2023 at 6:15 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/shift_vx_constraint-1.c: New test.
>
> ---
> .../riscv/rvv/base/shift_vx_constraint-1.c| 133 ++
> 1 file changed, 133
committed, thanks!
On Wed, Feb 1, 2023 at 6:08 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/predicates.md (pmode_reg_or_uimm5_operand): New
> predicate.
> * config/riscv/riscv-vector-builtins-bases.cc: New class.
> *
committed, thanks!
On Wed, Feb 1, 2023 at 9:48 AM wrote:
>
> From: Ju-Zhe Zhong
>
> Current constraint configuration will generate:
> vadd.vv v0,v24,v25,v0.t
> vsll.vx v0,v24,a5,v0.t
>
> They are incorrect according to RVV ISA.
> This patch fix this obvious issue.
>
> gcc/ChangeLog:
>
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:20 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/riscv/rvv/base/vsra_vx-1.C: New test.
> * g++.target/riscv/rvv/base/vsra_vx-2.C: New test.
> * g++.target/riscv/rvv/base/vsra_vx-3.C: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:18 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * g++.target/riscv/rvv/base/vsrl_vx-1.C: New test.
> * g++.target/riscv/rvv/base/vsrl_vx-2.C: New test.
> * g++.target/riscv/rvv/base/vsrl_vx-3.C: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:10 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vsrl_vx-1.c: New test.
> * gcc.target/riscv/rvv/base/vsrl_vx-2.c: New test.
> * gcc.target/riscv/rvv/base/vsrl_vx-3.c: New test.
>
committed, thanks!
On Wed, Feb 1, 2023 at 6:11 AM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/vsra_vx-1.c: New test.
> * gcc.target/riscv/rvv/base/vsra_vx-2.c: New test.
> * gcc.target/riscv/rvv/base/vsra_vx-3.c: New test.
>
committed, also updated mask for ALL_REGS, thanks.
On Fri, Feb 3, 2023 at 12:59 PM Monk Chiang wrote:
>
> Avoid VL_REGS, VTYPE_REGS join register allocation.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class.
> * config/riscv/riscv.cc: Ditto.
> ---
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #18 from Richard Biener ---
OK, thanks for the info. These kind of testcases are quite useful in that they
are not done for the purpose of breaking the compiler and they show algorithmic
deficiencies in GCC. GCC aims to be able to
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/constraints.md (Wdm): Adjust constraint.
(Wbr): New constraint.
* config/riscv/predicates.md (reg_or_int_operand): New predicate.
* config/riscv/riscv-protos.h (emit_pred_op): Remove function.
This patch reworks how the complex multiply and divide built-in functions are
done. Previously we created built-in declarations for doing long double complex
multiply and divide when long double is IEEE 128-bit. The old code also did not
support __ibm128 complex multiply and divide if long
This patch is a repost of a patch:
| Date: Thu, 19 Jan 2023 11:37:27 -0500
| Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE
128-bit
| Message-ID:
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE
I'm reposting these two patches that allow GCC to build on Fedora 36 just to be
clear which patches I'm talking about. The issue is that if GCC is configured
with long double using the IEEE 128-bit representation, it currently cannot
build _mulkc3 and _divkc3 in libgcc.
Note, these patches do
Avoid VL_REGS, VTYPE_REGS join register allocation.
gcc/ChangeLog:
* config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class.
* config/riscv/riscv.cc: Ditto.
---
gcc/config/riscv/riscv.cc | 8 +---
gcc/config/riscv/riscv.h | 6 --
2 files changed, 1 insertion(+), 13
On 2023-02-02 03:33, Richard Biener wrote:
looking at PR77650 what seems missing there is the semantics of this
extension as expected/required by the glibc use. comment#5 seems
to suggest that for my example above its expected that
Y.x.data[0] aliases Y.end?! There must be a better way to
On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not
On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not
On Thu, Feb 02, 2023 at 21:24:12 +0100, Harald Anlauf wrote:
> Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisions based on
> > the source
On Thu, Feb 02, 2023 at 21:24:12 +0100, Harald Anlauf wrote:
> Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisions based on
> > the source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #4 from Jerry DeLisle ---
Well folks, I like to document my thought process.
>From the 2022 draft standard we have:
R781 ac-value is expr or ac-implied-do
R782 ac-implied-do is ( ac-value-list , ac-implied-do-control )
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
--- Comment #5 from JuzheZhong ---
Revise the testcase, it has a bug here:
void foo5_3 (int32_t * restrict in, int32_t * restrict out, size_t n, int cond)
{
vint8m1_t v = *(vint8m1_t*)in;
*(vint8m1_t*)out = v;
vbool8_t v3 =
On Fri, 3 Feb 2023 at 07:10, Prathamesh Kulkarni
wrote:
>
> On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
> wrote:
> >
> > Prathamesh Kulkarni writes:
> > >> >> > I have attached a patch that extends the transform if one half is
> > >> >> > dup
> > >> >> > and other is set of constants.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #3 from Jerry DeLisle ---
I have a copy of the standard so I will answer my own question. This is a
comment:
In a situation like this:
print *, [integer :: ([1.0])] ** 2
My brain wants to say reject it because 1.0 is not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108641
--- Comment #2 from weilomg ---
(In reply to Andrew Pinski from comment #1)
> >Fatal Error: Wrong module version '6' (expected '5') for file 'sizes.mod'
> >opened at (1)
>
>
> This means the modules you are using was compiled with a newer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
--- Comment #19 from Rama Malladi ---
Thanks @Sebastian and @Martin J. I will get another bisect between GCC 7-and-8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
On Thu, 2 Feb 2023 at 20:50, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> >> >> > I have attached a patch that extends the transform if one half is dup
> >> >> > and other is set of constants.
> >> >> > For eg:
> >> >> > int8x16_t f(int8_t x)
> >> >> > {
> >> >> > return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #2 from Andrew Pinski ---
>Tested with both clang and gcc trunk, so it seems to be a library level issue.
I tested clang with -stdlib=libc++ and it produces the same results as without
that option (which is it uses gcc's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #24 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #23)
> I also suspect many of these new warnings we are doing in recent years
> really should not be part of -Wall because of how many false positives we
> have.
That might be sufficient for this case, but temploid friends violate an
assumption of the implementation -- namely that module A cannot create an entity
that belongs in module B's symbol table. This causes a bunch of excitement,
particularly around handling (well formed) duplicatd instantions.
Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't
been completed yet, but that doesn't work:
/* We can't lower this until the class is complete. */
if (!COMPLETE_TYPE_P (DECL_CONTEXT (member)))
return cst;
and then this unlowered PTRMEM_CST is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #5 from Scott Boyce ---
Comment on attachment 54395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54395
Source Part 1
This is a part 1 of a 3 part zip file created with 7zip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108652
Bug ID: 108652
Summary: type-bound procedure that returns integer used to
allocate character on stack
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
Bug ID: 108651
Summary: Array Constructor with [type-spec:: fails to apply to
all values, eg x = [integer(int64):: 1,2,3,4]
Product: gcc
Version: 11.3.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108650
Bug ID: 108650
Summary: Error: IMPORT statement only permitted in an INTERFACE
body | but it should be allowed in any contained
routine to control scope
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #4 from Scott Boyce ---
Created attachment 54397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54397=edit
Source Part 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #3 from Scott Boyce ---
Created attachment 54396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54396=edit
Source Part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #2 from Scott Boyce ---
Created attachment 54395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54395=edit
Source Part 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #1 from Scott Boyce ---
Missing attachment in first post
I was unable to compress the source code to 1MB.
So I will make it into a mutlipart zip over the next three posts.
If you want to download a single zip file, it is located
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
Bug ID: 108649
Summary: allocation segmentation fault for pointer derive type
and ICE for final-binding
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
On 2/2/23 15:38, Vineet Gupta wrote:
Hi,
I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with
fast-math removed)
I've bisected it to b7fd7fb50111 ("frange:
Hi,
I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with fast-math
removed)
I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max
representable
WG14 has agreed to allow equality comparisons between pointers and
nullptr_t values that are not null pointer constants (this was
previously an exceptional case where such nullptr_t values were
handled differently from null pointer constants; other places in the
standard allowed nullptr_t values,
A restored build has been detected on builder gccrust-rawhide-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/132/builds/406
Build state: build successful
Revision: a26b897b44732a5ec024008e05a6cc0a06bfabdd
Worker: bb1-1
Build
A restored build has been detected on builder gccrust-fedora-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/16/builds/615
Build state: build successful
Revision: a75f038c069cc3a23b214854bedf04321fe88bc5
Worker: bb2-1
Build
A retry build has been detected on builder gccrust-rawhide-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/132/builds/382
Build state: worker not available
Revision: (unknown)
Worker: bbo1-1
Build Reason: (unknown)
Blamelist:
On 1/30/23 14:10, Patrick Palka wrote:
In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members. In the testcase below this manifests as an
unstable satisfaction error because the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #23 from Andrew Pinski ---
The patch which would have "fixed" this was reverted as there was too many
false positives and that happens when you do optimization based warnings ...
I don't know if we want to keep this open or close
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 95515, which changed state.
Bug 95515 Summary: missing --Wnonnull on a straightforward call with a null
pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
--- Comment #22 from Andrew Pinski ---
*** Bug 95515 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
Snapshot gcc-10-20230202 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20230202/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108648
Bug ID: 108648
Summary: -Wanalyzer-fd-leak false positives seen on haproxy's
proto_tcp.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
On 1/30/23 16:36, Patrick Palka wrote:
Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous.
This patch fixes this by
On 1/30/23 21:35, Marek Polacek wrote:
In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)]
in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':
new_ctx.object = t; //
A new failure has been detected on builder gccrust-fedora-x86_64 while building
gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/16/builds/573
Build state: failed configure (failure)
Revision: 4b8f3005af0ddfd409f43e671b817f846e3c47e4
Worker: bb1-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95515
Andrew Pinski changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Li Shaohua changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
--- Comment #2 from Li Shaohua ---
(In reply to Andrew Pinski from comment #1)
> PRE removes the load/stores from/to *f .
> Basically the compiler is able to remove the use-after-scope usage with -O2
> and above.
Well, this makes sense to me
Pushed.
Gerald
---
htdocs/gcc-11/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 4787fc26..cc0fdc19 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -807,7 +807,7 @@ You may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment
On 2/2/23 13:09, Patrick Palka wrote:
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose pruned callee is wrapped in
an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Bug ID: 108647
Summary: [13 Regression] ICE in upper_bound, at
value-range.h:950 with -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Hi!
On 2023-02-01T16:12:07+0100, Martin Jambor wrote:
> On Thu, Oct 20 2022, Richard Biener via Gcc-patches wrote:
>>> Am 20.10.2022 um 14:41 schrieb Jakub Jelinek via Gcc-patches
>>> :
>>> On Thu, Oct 20, 2022 at 12:33:28PM +, Michael Matz wrote:
> On Thu, 20 Oct 2022, Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #1 from Evan Teran ---
To further experiment, i factored out `std::accumulate`:
```
#include
#include
#include
#include
void print_v(const char *rem, const std::vector ) {
std::cout << rem;
for (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #6)
> IMHO these tests and AFAICT the underlying issue has seen no attention for
> months and should be xfailed. On it...
Tested cris-elf, native x86_64-pc-linux-gnu.
Ok to commit?
--- 8< ---
These appear as regressions from a baseline before
r13-3761-ga239a63f868e29. See the PR trail.
Note that the warning for g++.dg/pr71488.C is for a *header*
file, thus we can't match the line number (sanely).
gcc/testsuite:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108453
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:936fdf056944989c49dc4fff399ca5dc0d0213ee
commit r12-9101-g936fdf056944989c49dc4fff399ca5dc0d0213ee
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
Bug ID: 108646
Summary: nonnull attribute does not detect variables that are
NULL being passed
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
Bug ID: 108645
Summary: Change in behavior, std::accumulate doesn't always
work as expected in C++20 builds
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #2 from Mikael Pettersson ---
Happens with 11.3.0, 10.4.0, and 9.5.0 too, so shouldn't be related to the CC0
conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #2 from Andrew Pinski ---
h8300.cc should be using HOST_WIDE_INT_PRINT_DEC instead.
Can you file that issue seperately?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #1 from Andrew Pinski ---
The lto-plugin warnings are not a GCC issue really.
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with '%x'
gnu_printf format [-Wformat=]
Those are done correctly and using the right
Hi Ben,
Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not
Hi Ben,
Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
Scott Boyce changed:
What|Removed |Added
CC||Boyce at engineer dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
Bug ID: 108644
Summary: Format string warnings related to longs under
MigW-W64/MSYS2 on Windows 10
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
WG14 has agreed some changes (detailed at the end of N3082) to the
rules on constexpr initializers for floating types. Update GCC's
implementation to match: binary initializers are now allowed for
decimal types, and real initializers for complex types, but signaling
NaN initializers can't be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #10 from Jakub Jelinek ---
Ok then.
I won't test my patch then, the testcases from it were:
--- gcc/testsuite/gcc.c-torture/compile/pr108638.c.jj 2022-11-21
10:04:00.210677046 +0100
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #5 from Andrew Pinski ---
The difference between the two front-ends is at the original.
The C++ front-end adds a BLOCK around the loop while the C front-end does not.
This difference changes where the ASAN_MARK is placed with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #1 from Mikael Pettersson ---
I can reproduce. Doesn't happen with the m68k-linux-gnu target though.
> cross-m68k-uclinux/bin/m68k-unknown-uclinux-uclibc-gcc -Os -c /tmp/ls.i
during RTL pass: final
coreutils/ls.c: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #4 from Andrew Pinski ---
Hmm, using the C++ front-end, the use-after-scope still happens at -O3 but not
with the C front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
1 - 100 of 247 matches
Mail list logo
