https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #7 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to David Malcolm from comment #1)
>
> > Perhaps we should try to capture both the untranslated text and the
> > translated text? SARIF has vario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #6 from David Malcolm ---
(In reply to David Malcolm from comment #5)
[...]
> (the SARIF spec's tutorial doesn't seem to cover translations yet)
FWIW I've requested this as
https://github.com/microsoft/sarif-tutorials/issues/40
[..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #5 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to David Malcolm from comment #1)
>
> > Perhaps we should try to capture both the untranslated text and the
> > translated text? SARIF has vario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116731
Bug ID: 116731
Summary: Incorrect behavior of -Wrange-loop-construct in GCC 14
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #262 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #261)
> I'm a little concerned because of PR 115949. It shows that there are some
> fundamental issues with move patterns like `movsi_ie`. It seems real-world
> code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #8 from Hime Haieto ---
I am aware of how checking generated files, particularly from autotools, is a
common practice employed for convenience. I am also aware of how easily it can
mask bugs that could otherwise go unnoticed. Thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #7 from Andrew Pinski ---
(In reply to Hime Haieto from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > > autoreconf2.69 -vfi
> >
> >
> > Don't do this.
>
> Where do you think babies...I mean configure comes from?
M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #6 from Hime Haieto ---
(In reply to Andrew Pinski from comment #4)
> > autoreconf2.69 -vfi
>
>
> Don't do this.
Where do you think babies...I mean configure comes from?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #5 from Hime Haieto ---
This is the same process I've used for every past version of gcc, every
autotools project that isn't completely broken by abusing the autotools
environment/standards, as well as most projects that don't use au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #4 from Andrew Pinski ---
> autoreconf2.69 -vfi
Don't do this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #3 from Hime Haieto ---
git clone 'git://gcc.gnu.org/git/gcc.git'
cd gcc
git worktree add worktrees/14.2.0 releases/gcc-14.2.0
cd worktrees/14.2.0
autoreconf2.69 -vfi
mkdir -p build/votocon
cd build/votocon
../../configure --prefix=/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #2 from Andrew Pinski ---
Also building in the source tree is not fully tested and is sometimes known to
be broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
Bug ID: 116730
Summary: `make install` fails when processing libbacktrace
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #1 from Hime Haieto ---
This may possibly have some connections to the behaviour seen in PR116726.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113299
Bug 113299 depends on bug 110512, which changed state.
Bug 110512 Summary: C++20 random access iterators run sequentially with PSTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #4 from Hans-Peter Nilsson ---
(In reply to David Malcolm from comment #1)
> Perhaps we should try to capture both the untranslated text and the
> translated text? SARIF has various abilities for handling translations.
Works for m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116729
Bug ID: 116729
Summary: [[maybe_unused]] doesn't prevent warning for unused
function declarations
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
Bug ID: 116728
Summary: c23 tag compatibility broken with pointers to
incomplete types
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
--- Comment #9 from GCC Commits ---
The releases/gcc-12 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:ebdc85b6ce4f2067431331a1a37440e952efd49b
commit r12-10710-gebdc85b6ce4f2067431331a1a37440e952efd49b
Author: H.J. Lu
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
--- Comment #8 from GCC Commits ---
The releases/gcc-13 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:64af1a600f6bd57d47a5926f2328682bba88be90
commit r13-9028-g64af1a600f6bd57d47a5926f2328682bba88be90
Author: H.J. Lu
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116621
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:3f3f546bf830d019224aaf6cd349a1b9b738de1a
commit r14-10672-g3f3f546bf830d019224aaf6cd349a1b9b738de1a
Author: H.J. Lu
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #4 from Martin Uecker ---
I will look at this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113563
Andrew Pinski changed:
What|Removed |Added
CC||janschultke at googlemail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116727
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Andrew Pinski changed:
What|Removed |Added
Summary|compiler segfault when |[14/15 Regression] compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116727
Bug ID: 116727
Summary: "this" is unusable in an explicit object member
function lambda capturing this
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #2 from Hime Haieto ---
Actually, I had also tried using the -freport-bug option like the ICE had
advised, but it failed with the message:
"The bug is not reproducible, so it is likely a hardware or OS problem."
It seems to fail fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Peter Damianov changed:
What|Removed |Added
CC||peter0x44 at disroot dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
Bug ID: 116726
Summary: compiler segfault when using certain struct
redefinitions
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116723
--- Comment #2 from Ye Xiong ---
(In reply to Andrew Pinski from comment #1)
> (p.f0 != (-18))
>
> For uint16_t, this is always true and is an always infinite loop. While for
> int16_t it is not and the loop is removed because you supplied -ffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116296
--- Comment #3 from Andrew Pinski ---
*** Bug 116721 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116721
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116721
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-15
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725
--- Comment #1 from Andrew Pinski ---
-masm=intel is definitely not well tested ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116723
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725
Bug ID: 116725
Summary: operand size mismatch for vfpclasssd and vfpcla
when using -masm=intel for AVX512 builtins
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
--- Comment #3 from Andreas Schwab ---
More likely a glibc bug that has since been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c5fd1a483858c0e85b40149aef88be00f94980a7
commit r15-3650-gc5fd1a483858c0e85b40149aef88be00f94980a7
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #3 from David Malcolm ---
Note to self:
499 diagnostic_set_info (diagnostic_info *diagnostic, const char *gmsgid,
500 va_list *args, rich_location *richloc,
501 diagnostic_t kind)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #2 from David Malcolm ---
See e.g. ยง3.19.4 "Translations"
https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os-complete.html#_Toc141790787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
--- Comment #1 from David Malcolm ---
I tried this for some examples; consider:
$ LANG=C ./xgcc -B. ../../src/gcc/testsuite/gcc.dg/format/sentinel-1.c
-fdiagnostics-format=text -Wall -S -fdiagnostics-format=text
../../src/gcc/testsuite/gcc.dg/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116724
Bug ID: 116724
Summary: RFE: can generated SARIF diagnostics contain
untranslated messages (plus translations?)
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
--- Comment #2 from Jonathan Wakely ---
Does this still fail? I don't see it failing in gcc-testresults
Running it under GDB should show where the fatal exception is thrown from.
I think the only places in this test that should throw system_err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116723
Bug ID: 116723
Summary: performance differs in -ffinite-loop with only type
changing
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89615
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #24 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108107
--- Comment #1 from Jonathan Wakely ---
The segfault seems to be calling rdbuf() from this Python code:
# Check if the stream was redirected. This is essentially:
# val['_M_streambuf'] != val['_M_stringbuf'].address
# Ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116722
Bug ID: 116722
Summary: Internal Compiler Error: when creating a class with
virtual inheritance, constexpr template constructor
and call it with floating point
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116721
Bug ID: 116721
Summary: [15 Regression] ICE: in merge, at
ipa-modref-tree.cc:176
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116720
Bug ID: 116720
Summary: [13/14/15 Regression] RISC-V: Unrecognizable insn with
xtheadmemidx on rv32
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718
--- Comment #2 from Jose E. Marchesi ---
As far as I can tell the feature requires no inlining to happen. From the llvm
patch:
After this patch-set verifier would rewrite the program below:
r2 = 1
*(u64 *)(r10 - 32) = r2
call %[bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116719
Bug ID: 116719
Summary: [SH] missed folding of fp factor constant
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718
--- Comment #1 from Andrew Pinski ---
Note gcc does ipa based register allocation. I wonder if most of these like
attributes are just to work around llvm not doing that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116718
Bug ID: 116718
Summary: bpf: support bpf_fastcall attributes
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #261 from Oleg Endo ---
I'm a little concerned because of PR 115949. It shows that there are some
fundamental issues with move patterns like `movsi_ie`. It seems real-world
code is very easy to hit that problem.
I'm thinking to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116717
Bug ID: 116717
Summary: bpf: fix built-in functions for memory model aware
atomic operations.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949
--- Comment #5 from Oleg Endo ---
This issue seems to be popping up quite often when the fsca insn is utilized
(via the sincos pattern). That's the only insn which uses a `v2sf` (
vec2 ) and I suspect that something's going wrong there when it
63 matches
Mail list logo
