https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68
Bug ID: 68
Summary: a[0,1]|b[0,-1] == 0 is not reduced to a ==0 & b ==0 if
a and b are defined by comparisons
Product: gcc
Version: 14.0
Status: UNCONFIRMED
David Edelsohn via Gcc writes:
> n Fri, Aug 25, 2023 at 4:16 PM Michael Welsh Duggan via Gcc <
> gcc@gcc.gnu.org> wrote:
>
>> I am attempting to debug an issue in gcc (PR 110827, if curious). In
>> order to do this I have built a stage 1 compiler with debugging and
>> without optimization as
On Sat, 2023-08-26 at 14:22 +0200, priour...@gmail.com wrote:
> From: benjamin priour
>
> Hi,
>
> Updated version of the patch, regstrapping the changes described in
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628455.html.
>
> Regstrapped off trunk
Snapshot gcc-13-20230826 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230826/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #7 from Thorsten Glaser ---
(but with this, I think it’s neither the GCC builtins, nor a change thereof,
nor anything about dietlibc that is at fault; feel free to adjust the title
accordingly)
Surrounding code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #6 from Thorsten Glaser ---
dietlibc’s strlen is a horrid SSE nightmare that doesn’t call (f)emms, but it
has a switch global variable __valgrind, if setting that to 1 it uses a very
traditional loop instead, and the registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #5 from Thorsten Glaser ---
I managed to isolate one specific strchr call changing which causes the
breakage to go away:
asm volatile("nop"); //401
sp = cstrchr(sp, '\0') + 1;
asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #4 from Thorsten Glaser ---
Its {,sig}{set,long}jmp for x32 look good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
--- Comment #1 from Andrew Pinski ---
In this case the problem seems to be jump threading related.
If we did:
```
void f(int);
void lookup_attribute1(const char *attr_ns, int list, int t) {
short t1;
if (attr_ns) { if (list) {t1 = 0; goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67
Bug ID: 67
Summary: swapping around duplicated conditionals can produce
better code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #3 from Thorsten Glaser ---
Not yet, given it’s been relatively clearly tracked down to a change in GCC.
I’ll have at its setjmp/longjmp myself now, will report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).
Sorry, missed the -std=f95 flag.
Confirmed on recent master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66
Bug ID: 66
Summary: gcc unnecessarily creates vector operations for
packing 32 bit integers into struct (x86_64)
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
--- Comment #1 from Andrew Pinski ---
> (which makes me think of register corruption occurring here)
>The codepath is a bit convoluted, setjmp/longjmp are involved.
Which could mean it is a bug in dietlibc's setjmp/longjmp since you said it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65
Bug ID: 65
Summary: [13 regression] builtin strchr miscompiles on
Debian/x32 with dietlibc
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #7 from Paul Eggert ---
(In reply to Alexander Monakov from comment #6)
> Are you binding the benchmark to some core in particular?
I did the benchmark on performance cores, which was my original use case. On
efficiency cores,
Add a flag to turn tag compatibility rules on or off
independent from the language version.
gcc/c-family:
* c.opt (flag_tag_compat): New flag.
gcc/c:
* c-decl.cc (diagnose_mismatched_decls, start_struct,
finish_struct, start_enum, finish_enum): Support flag.
*
Support for constructing composite type for structs and unions
in C23.
gcc/c:
* c-typeck.cc (composite_type_internal): Adapted from
composite_type to support structs and unions.
(composite_type): New wrapper function.
(build_conditional_operator): Return
Tell the backend which types are equivalent by setting
TYPE_CANONICAL to one struct in the set of equivalent
structs. Structs are considered equivalent by ignoring
all sizes of arrays nested in types below field level.
gcc/c:
* c-decl.cc (c_struct_hasher): Hash stable for struct
Allow redefinition of enum types and enumerators.
gcc/c:
* c-decl.cc (start_num): Allow redefinition.
(finish_enum): Diagnose conflicts.
(build_enumerator): Set context.
(diagnose_mismatched_decls): Diagnose conflicting enumerators.
(push_decl): Preserve
Implement redeclaration and compatibility rules for
structures and unions in C23.
gcc/c/:
* c-decl.cc (previous_tag): New function.
(get_parm_info): Turn off warning for C2X.
(start_struct): Allow redefinitons.
(finish_struct): Diagnose conflicts.
*
Adapt the old and unused code for type checking for C23.
gcc/c/:
* c-typeck.c (struct comptypes_data): Add anon_field flag.
(comptypes, comptypes_check_unum_int,
comptypes_check_different_types): Remove old cache.
(tagged_tu_types_compatible_p): Rewrite.
---
Reorganize recursive type checking to use a structure to
store information collected during the recursion and
returned to the caller (warning_needed, enum_and_init_p,
different_types_p).
gcc/c:
* c-typeck.cc (struct comptypes_data): Add structure.
This is a revised series for the C23 rules for type
compatibility.
1/6 c: reorganize recursive type checking
2/6 c23: recursive type checking of tagged type
3/6 c23: tag compatibility rules for struct and unions
4/6 c23: tag compatibility rules for enums
5/6 c23: aliasing of compatible tagged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #3 from Jonathan Wakely ---
We could also just have a "can_hh_mm_ss" check, as I think we use hh_mm_ss in
most places where we do these conversations. Then we would just check once, not
on every cast. I don't think we want to change
Hi David,
Sorry I missed out on your answer about the operator new patch on the IRC.
Should I submit the first bit of the operator new patch ? Putting aside for
now fixing the
"uninitialized value" that accompanies "null deref" of nothrow new variants
?
About generalizing tests to C++, I'll soon
Committed as 'obvious'. 13-branch to follow.
commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas
Date: Sat Aug 26 14:37:49 2023 +0100
Fortran: Supply a missing dereference [PR92586]
2023-08-26 Paul Thomas
gcc/fortran
PR fortran/92586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #2 from Paul Dreik ---
The fmt lib had the same problem. I wrote a safe duration cast which eventually
morphed into this:
https://github.com/fmtlib/fmt/blob/9b74160817f2bc63288d2111e823a35dd3dbf234/include/fmt/chrono.h#L57-L68
Hi,
If you further have issues with loading required libraries,
you could try running a test intended for g++ (make check-c++ from under
BUILDDIR/gcc/)
You may find examples at
https://gcc-newbies-guide.readthedocs.io/en/latest/working-with-the-testsuite.html#running-just-one-test-or-just-a-few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
--- Comment #1 from Jonathan Wakely ---
This doesn't seem much different to:
std::chrono::seconds s = std::chrono::duration{2314885530818453536};
Which we can't really do much about.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
--- Comment #13 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160
Author: Paul Thomas
Date: Sat
From: Pan Li
Update in v2:
* Remove control flow check in BB_END.
* Passed x86 bootstrap and regression test.
Original log:
We have EMIT hook in mode switching already, which will insert the
insn before in most cases. However, in some arch like RISC-V, it
requires the additional insn to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64
Bug ID: 64
Summary: The error message for a literal operator accepting an
argument of the wrong type is confusing
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63
Bug ID: 63
Summary: signed integer overflow in
std::format("{:%S}",std::chrono::duration)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62
Bug ID: 62
Summary: signed integer overflow triggered by
std::chrono::parse
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57
--- Comment #4 from Jan Hubicka ---
So here ipa-modref declares the field dead, while ipa-prop determines its value
even if it is unused and makes it used later?
I think dead argument is probably better than optimizing out one store, so I
Hi!
The following incremental patch to the PR110341 posted patch uses
a special conversion callback instead of conversion from host charset
(UTF-8/UTF-EBCDIC) to UTF-32, and also ignores all diagnostics from the
second cpp_interpret_string which should just count chars. The UTF-EBCDIC
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85097
--- Comment #5 from Michał Staromiejski ---
In clang 16.0.0 it compiles w/o errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85097
Michał Staromiejski changed:
What|Removed |Added
CC||michal.staromiejski+gnu@gma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61
Bug ID: 61
Summary: [13 Regression] ICE: RTL check: expected code
'const_int', have 'reg' in riscv_print_operand, at
config/riscv/riscv.cc:4394 during build
Product:
On Thu, Aug 24, 2023 at 09:19:51PM -0500, Peter Bergner wrote:
> On 8/24/23 12:35 PM, Michael Meissner wrote:
> > On Thu, Jul 20, 2023 at 10:05:28AM +0530, jeevitha wrote:
> >> gcc/
> >>PR target/110411
> >>* config/rs6000/rs6000.h (enum rs6000_builtin_type_index): Add fields
> >>to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43
--- Comment #6 from Alexander Monakov ---
Thanks.
i5-1335U has two "performance cores" (with HT, four logical CPUs) and eight
"efficiency cores". They have different micro-architecture. Are you binding the
benchmark to some core in particular?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102793
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> basically ccmp expension is just ifcombine really.
> That is:
> cc = bar cmp 0
> cc = cc.eq ? ne : d1 cmp d2
> cset cc.ne
> So this is why doing a late pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
---
57 matches
Mail list logo
