On Thu, Jul 24, 2025 at 4:23 AM Jeff Law via Gcc wrote:
>
>
>
> On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote:
> > Hi all,
> >When I improved DSE to remove stores where the rhs is known 100% to be
> > an uninitialized variables (ssa_undefined_value_p), I get a few regressions
> > due to an
On Thu, Jul 24, 2025 at 2:39 AM magic0826gc via Gcc wrote:
>
> Dear GCC Developers,
> I'm writing to report an observation regarding loop unswitching behavior when
> compiling the attached code with GCC 15 using -O2 -funswitch-loops
> optimization flags. Here's a detailed analysis of the issue:
Hello GNU GCC Developers,
My name is Evan Cooney and I'm a student at the University of Missouri. I
was reading the documentation for the #ifdef preprocessor macro and I think
I found a slight typo. It is in section 4.2.1 "Ifdef", paragraph 5 (the one
that starts with "The comment following the '#
On 7/23/25 5:45 PM, Andrew Pinski via Gcc wrote:
Hi all,
When I improved DSE to remove stores where the rhs is known 100% to be an
uninitialized variables (ssa_undefined_value_p), I get a few regressions due to
an uninitialized warning does not happen:
gcc.dg/uninit-40.c for an example. (
Dear GCC Developers,
I'm writing to report an observation regarding loop unswitching behavior when
compiling the attached code with GCC 15 using -O2 -funswitch-loops optimization
flags. Here's a detailed analysis of the issue:
Code Overview:
int
foo(double *a, double *b, double *c, double *d, dou
> -Original Message-
> From: Andrew Pinski
> Sent: Wednesday, July 23, 2025 4:45 PM
> To: gcc@gcc.gnu.org
> Subject: RFC/RFH: uninit warning vs DSE of store from a
> known uninitialized variable
>
> Hi all,
> When I improved DSE to remove stores where the rhs is
> known 100% to be an un
Hi all,
When I improved DSE to remove stores where the rhs is known 100% to be an
uninitialized variables (ssa_undefined_value_p), I get a few regressions due to
an uninitialized warning does not happen:
gcc.dg/uninit-40.c for an example. (gcc.dg/analyzer/torture/boxed-int-1.c fails
also for a
On 23/07/2025 17:29, Alexander Monakov wrote:
On Wed, 23 Jul 2025, Jan Hubicka via Gcc wrote:
Thank you for the careful explanation. It seems like all the "innermost" blocks
would need to be instrumented, and in most cases the rest can be assumed. Unfortunately,
that probably means instrument
On 23/07/2025 17:05, Jan Hubicka wrote:
Am 23.07.2025 um 16:42 schrieb Andrew Stubbs :
On 23/07/2025 15:22, Michael Matz wrote:
Hello,
On Tue, 22 Jul 2025, Andrew Stubbs wrote:
Don’t you need to instrument more (or at least different) edges when
only having visited bits ? With counters yo
On Wed, 23 Jul 2025, Jan Hubicka via Gcc wrote:
> > > Thank you for the careful explanation. It seems like all the "innermost"
> > > blocks would need to be instrumented, and in most cases the rest can be
> > > assumed. Unfortunately, that probably means instrumenting the hottest
> > > blocks,
>
>
> > Am 23.07.2025 um 16:42 schrieb Andrew Stubbs :
> >
> > On 23/07/2025 15:22, Michael Matz wrote:
> >> Hello,
> >> On Tue, 22 Jul 2025, Andrew Stubbs wrote:
> Don’t you need to instrument more (or at least different) edges when
> only having visited bits ? With counters you can
> Am 23.07.2025 um 16:42 schrieb Andrew Stubbs :
>
> On 23/07/2025 15:22, Michael Matz wrote:
>> Hello,
>> On Tue, 22 Jul 2025, Andrew Stubbs wrote:
Don’t you need to instrument more (or at least different) edges when
only having visited bits ? With counters you can derive coverage
On 23/07/2025 15:22, Michael Matz wrote:
Hello,
On Tue, 22 Jul 2025, Andrew Stubbs wrote:
Don’t you need to instrument more (or at least different) edges when
only having visited bits ? With counters you can derive coverage of
related edges by diffing counters (consider a simple diamond).
I
Hello,
On Tue, 22 Jul 2025, Andrew Stubbs wrote:
> > Don’t you need to instrument more (or at least different) edges when
> > only having visited bits ? With counters you can derive coverage of
> > related edges by diffing counters (consider a simple diamond).
>
> I have not yet got this deep
14 matches
Mail list logo
