https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #20 from Jonathan Wakely ---
Strange, maybe something different about my newlib build. Anyway, what matters
is that you can build it. I only need to be able to verify my changes compile!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Bug ID: 108398
Summary: tree-object-size trips up with pointer arithmetic if
an intermediate result is an invalid pointer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #2 from Siddhesh Poyarekar ---
Yeah, I've been ping-ponging about the validity too, which is why I filed a bug
to get some consensus position. I suppose if we don't treat it as a bug, should
we try and support it in cases we can by a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108399
Bug ID: 108399
Summary: wrong locations generated for OMP_FOR
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #3 from Siddhesh Poyarekar ---
Oops, sorry I messed up the reproducer, here's the correct one. The principles
don't really change though:
unsigned steps[2];
int main(void) {
unsigned n_steps = sizeof (steps) / sizeof (unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
--- Comment #8 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:733a1b777f16cd397b43a242d9c31761f66d3da8
commit r13-5154-g733a1b777f16cd397b43a242d9c31761f66d3da8
Author: Alexander Monakov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108117
--- Comment #17 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:733a1b777f16cd397b43a242d9c31761f66d3da8
commit r13-5154-g733a1b777f16cd397b43a242d9c31761f66d3da8
Author: Alexander Monakov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108400
Bug ID: 108400
Summary: false positive: null dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
Andrew Pinski changed:
What|Removed |Added
Keywords||rejects-valid
Summary|PPCLE:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108397
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #5 from Siddhesh Poyarekar ---
Ack, I had a thinko with
unsigned steps[] = {1, 1};
because in that case too n_steps doesn't get decremented, resulting in OOB
access. I'm going to look at the original report[1] to see if the test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #7 from Siddhesh Poyarekar ---
Thanks, is that from the code in prima[1] or the Red Hat bugzilla report? The
latter is undefined as per the above discussion.
[1] https://github.com/dk/Prima/issues/78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
--- Comment #8 from Jakub Jelinek ---
-fsanitize=undefined with no diagnostics doesn't mean code is UB free.
This testcase is still invalid.
Before the first g--;, g == &e, so g-- will set g to g - sizeof (int). That is
UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #14 from Jerry DeLisle ---
the '-x f77' id documented here:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#Overall-Options
All it does is tell the compiler the source is fixed form or free-form.
Admittedly that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108398
Siddhesh Poyarekar changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108395
Andrew Pinski changed:
What|Removed |Added
Blocks||89180
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #7 from Andrew Macleod ---
Created attachment 54269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54269&action=edit
patch in testing
Patch is in testing.
We added relation processing to GORI during stage 1, but its very ligh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368
--- Comment #2 from Andrew Macleod ---
Not sure why it looks expensive, it is a lot cheaper than the original cache
propagation was, but still gets all the cases.
Regardless, the upcoming fix for 108356 fixes this PR as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
--- Comment #4 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:4fa6845b4b29f33cc7ea3d8ff49b61bb1f460561
commit r13-5157-g4fa6845b4b29f33cc7ea3d8ff49b61bb1f460561
Author: Eric Botcazou
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105546
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #4 from Andrew Macleod ---
Created attachment 54270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54270&action=edit
possible patch
When the on-entry cache is updated for a block, all incoming ranges are unioned
together and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107467
--- Comment #9 from Jan Hubicka ---
>
> so it's ICFed compare_pairs having modref TBAA info that makes the
> stores dead. I suppose ICF needs to reset / alter the modref summaries?
Well, matching that ICF does should be enough to verify that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108356
--- Comment #5 from Andrew Macleod ---
The full comment is the test case is:
/* Verify offsets in an anti-range. */
<...>
/* The initial source range is valid but the final range after the access
has complete cannot be. The value menti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108395
--- Comment #2 from Andrew Pinski ---
This is will most likely fix it, but I am not 100% sure it fixes all of the
constexpr cases though:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index e06f052eb46..3a169eceece 100644
--- a/gcc/c/c-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:ccd4df81aa6537c3c935b026905f6e2fd839654e
commit r13-5159-gccd4df81aa6537c3c935b026905f6e2fd839654e
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105273
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #6 from Kees Cook ---
Sorry, I forgot to include those details fully! Here's how I'm seeing it:
$ gcc --version
gcc (GCC) 13.0.0 20230105 (experimental)
...
$ gcc -O2 -fno-strict-overflow -fsanitize=shift -Warray-bounds -c -o /dev/n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #7 from Kees Cook ---
(In reply to Kees Cook from comment #6)
> Sorry, I forgot to include those details fully! Here's how I'm seeing it:
>
> $ gcc --version
> gcc (GCC) 13.0.0 20230105 (experimental)
> ...
> $ gcc -O2 -fno-strict-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40457
--- Comment #15 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:acddf6665f067bc98a2529a699b1d4509a7387cb
commit r13-5160-gacddf6665f067bc98a2529a699b1d4509a7387cb
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
--- Comment #9 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:31aaa6ef5a952d4f64fb04010459f28e0e793702
commit r13-5161-g31aaa6ef5a952d4f64fb04010459f28e0e793702
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108401
Bug ID: 108401
Summary: gcc defeats vector constant generation with intrinsics
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
--- Comment #5 from Ed Catmur ---
PR: https://github.com/ecatmur/gcc/pull/5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
--- Comment #7 from Jerry DeLisle ---
I biffed the PR number on this commit. It should have been here. I will have
to look into amending the ChangeLog correctly.
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:cdc6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #16 from Alexandre Oliva ---
Sorry it took me so long to react, I'd missed the question.
IIRC the scheduler was the hardest part of GCC to make work with debug insns.
The general strategy is that nondebug insns never depend on debu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
Bug ID: 108402
Summary: False positive Wuninitialized with
ftrivial-auto-var-init=pattern
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
--- Comment #1 from Andrew Pinski ---
This has nothing to do with ftrivial-auto-var-init=pattern . But rather you are
passing an uninitiated struct to a function that takes a pointer to a const
type. That causes the warning.
Can you attach the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108402
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108403
Bug ID: 108403
Summary: -Wanalyzer-null-dereference false negative with *q ==
0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
101 - 144 of 144 matches
Mail list logo
