https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-04-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760
--- Comment #1 from Richard Biener ---
I think it's also a missed canonicalization for x << 1 vs. x + x (and 2*x).
unsigned a, b, c;
void foo (unsigned x)
{
a = x << 1;
b = x + x;
c = 2 * x;
}
x + x gets folded to 2 * x before gimplifica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
--- Comment #5 from rguenther at suse dot de ---
On Wed, 17 Apr 2024, juzhe.zhong at rivai dot ai wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
>
> --- Comment #4 from JuzheZhong ---
> Hi, Patrick.
>
> It seems that Richard di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
--- Comment #3 from Andrew Pinski ---
Is this based on real code or you just was looking at the differences between
gcc and clang here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #2 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762
Bug ID: 114762
Summary: wrong code with _BitInt() division by "BITINT_NN_MIN"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #6 from Andrew Pinski ---
Will submit both patches once GCC 15 opens up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #5 from Andrew Pinski ---
Created attachment 57979
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57979&action=edit
Patch 2/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #4 from Andrew Pinski ---
Created attachment 57978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57978&action=edit
Patch 1/2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #3 from Gejoe ---
Can I get a reply on what needs to be checked next ?
Thank you for the support team !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114761
Bug ID: 114761
Summary: Ignored [[likely]] attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114744
--- Comment #3 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:6e62ede7aaccc6ebe027c8e00224f65e226072e9
commit r14-10011-g6e62ede7aaccc6ebe027c8e00224f65e226072e9
Author: Kewen Lin
Date: Wed Apr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #5 from Peter Bergner ---
(In reply to Peter Bergner from comment #4)
> If instead we want to just silently ignore (or with a warning), we'd just
> need to modify the rs6000.cc hunk to disable rs6000_rop_protect instead of
> calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #4 from Peter Bergner ---
Created attachment 57977
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57977&action=edit
Patch that emits an error for invalid ROP option combinations.
Here's a patch that treats invalid ROP option c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #3 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #2)
>> 1. We always define the __ROP_PROTECT__ predefined macro [snip]
>
> No. Whenever the -mrop-protect option is in effect, we should do that
> predefine.
Wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #10 from Vineet Gupta ---
Debug update -fsched-verbose=99 dumps (they are reay verbose)
For the insn/regs under consideration, the canonical pre-scheduled sequence
with ideal live-range (but non-ideal load-to-use delay) is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Vincent Lefèvre changed:
What|Removed |Added
Summary|With FLT_EVAL_METHOD = 2, |With FLT_EVAL_METHOD = 2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre ---
There is the same issue with constant floating-point expressions.
Consider the following program given at
https://github.com/llvm/llvm-project/issues/89128
#include
#include
static double const_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #2 from Jonathan Wakely ---
It's just yet another occurrence of false positive -Wstringop-overflow
warnings, it has nothing to do with vector being special.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760
Bug ID: 114760
Summary: traling zero count detection failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #2 from Segher Boessenkool ---
> 1. We always define the __ROP_PROTECT__ predefined macro when using
> -mrop-protect, even when we've silently disabled ROP protection because of a
> too old -mcpu=CPU value. We should only emit __R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
--- Comment #4 from JuzheZhong ---
Hi, Patrick.
It seems that Richard didn't append the testcase in the patch.
Could you send a patch to add the testcase for RISC-V port ?
Thangks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #1 from Chris Lalancette ---
I should also mention that this doesn't happen with gcc 12.3 or earlier. It
seems to only have started happening with gcc 13.1 and 13.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Bug ID: 114759
Summary: Power: multiple issues with -mrop-protect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
Bug ID: 114758
Summary: The layout of a std::vector reports a warning
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #2 from Andrew Pinski ---
Note gimple_assign_nontemporal_move_p is just for non temporal stores. There is
no code handling non-temporal loads (which do exist on some targets, aarch64
for an example).
I will also add a comment to tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #4 from Sonia Zaldana Calles ---
Command to compile zMarkStack.cpp
( /usr/bin/rm -f
/home/szaldana/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/zMarkStack.o.log
&& /usr/bin/g++ -MMD -MF
/home/szaldana/jd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #3 from Sonia Zaldana Calles ---
Created attachment 57976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57976&action=edit
ZMarkStack.ii
Preprocessed file for ZMarkStack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #11 from Andrew Pinski ---
(In reply to Brecht Sanders from comment #10)
> What is the status of GCC support for aarch64-w64-mingw32 ?
>
> I just tried GCC 14 snapshot 20240414 and it looks like it's still not
> supported.
>
> Buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #10 from Brecht Sanders ---
What is the status of GCC support for aarch64-w64-mingw32 ?
I just tried GCC 14 snapshot 20240414 and it looks like it's still not
supported.
Build fails with:
*** Configuration aarch64-w64-mingw32 not s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Andrew Pinski changed:
What|Removed |Added
Component|other |tree-optimization
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #1 from Sonia Zaldana Calles ---
Created attachment 57975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57975&action=edit
debug log file
Contains a .txt file with the debug log.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Bug ID: 114757
Summary: [ASAN] ASAN miscalculates size of region when building
the JDK
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100604
--- Comment #8 from Andrew Pinski ---
Note this linker relaxation code could be more forgiving here and not producing
"wrong-code" but GCC should be fixed still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
--- Comment #3 from Andrew Pinski ---
Basically what is happening is the linker relaxation code is turning it into
something which is wrong. But GCC's invalid use of %lo(n+4)(a5) with a
(invalid) corresponding %hi(n) is confusing the relaxation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100604
Andrew Pinski changed:
What|Removed |Added
CC||patrick at rivosinc dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
--- Comment #1 from Andrew Pinski ---
lui a5,%hi(n)
lw a2,%lo(n)(a5)
lw a3,%lo(n+4)(a5)
vs:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
lw a2,0(a5)
lw a3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
--- Comment #5 from Michael Levine ---
I submitted a patch for this today, see either the gcc-patches or the libstdc++
mailing lists for the subject: [PATCH] libstdc++: Fix std::ranges::iota is not
included in numeric [PR108760]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
Bug ID: 114756
Summary: [14] RISC-V rv32imc miscompile with -fdata-sections
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114755
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-17
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #14 from Jakub Jelinek ---
(In reply to Andreas Krebbel from comment #13)
> We will go and fix PyTorch instead. Although it is not clearly documented,
> the way PyTorch uses the builtin right now is probably not what was
> intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
Bug 22348 depends on bug 23096, which changed state.
Bug 23096 Summary: Wrong folding for FLOOR_MOD_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #13 from Andreas Krebbel ---
We will go and fix PyTorch instead. Although it is not clearly documented, the
way PyTorch uses the builtin right now is probably not what was intended. It is
pretty clear that the element type pointer ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
--- Comment #4 from Segher Boessenkool ---
Well, I wanted to add Alex as well, but BZ does not allow that? Says he does
not exist?
Is there some other mail address than that mentioned in MAINTAINERS, the one he
usually uses, that works, maybe @
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240417 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Segher Boessenkool changed:
What|Removed |Added
CC||abel at ispras dot ru
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 69031, which changed state.
Bug 69031 Summary: ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC
-fselective-scheduling and __builtin_setjmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114509
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Known to fail||12.0, 13.0, 14.0
--- Comment #2 from Pet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> No, I think the issue is that ESRA leaves e.f0 alone:
>
> e$f3_7 = e.f3;
> e$f0$f4_8 = e.f0.f4;
> _1 = e$f0$f4_8;
> _2 = (unsigned char) _1;
> e$f3_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:57056146f4ffc5ea347c03e37e1e2c7cd99261d0
commit r14-10007-g57056146f4ffc5ea347c03e37e1e2c7cd99261d0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #9 from GCC Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:a9fefbf71726bb0ce89c79e547ab3319af3227a8
commit r14-10006-ga9fefbf71726bb0ce89c79e547ab3319af3227a8
Author: Christophe Lyon
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #11 from Jakub Kulik ---
> This is a bit of circular reasoning but, if the rule had been crystal clear,
> GCC would have implemented it at some point during the last quarter of
> century.
I see. I guess it's also not a common enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #10 from Jakub Kulik ---
Sorry for longer response.
I asked internally again and was told by a colleague who was in the room when
the spec was created, that: "the intent was (and is) that the individual
elements/atoms/fundamental ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #7 from Wilco ---
(In reply to Tamar Christina from comment #6)
> and the exact armv9-a cost model you quoted, also does the right codegen.
> https://godbolt.org/z/obafoT6cj
>
> There is just an inexplicable penalty being applied to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841
Haojian Wu changed:
What|Removed |Added
CC||hokein.wu at gmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114754
Bug ID: 114754
Summary: [OpenMP] Missing 'uses_allocators' diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic, openmp
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #5 from Jakub Jelinek ---
I wouldn't call it a hack, I'd say it is the right fix.
Though, we have tons of those in internal-fn.cc
ops.code = MULT_EXPR;
ops.code = MULT_EXPR;
ops.code = MULT_EXPR;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
--- Comment #3 from Stefan Schulze Frielinghaus
---
Created attachment 57971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57971&action=edit
dwarf2cfi dump for alog-active_logger.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
--- Comment #2 from Stefan Schulze Frielinghaus
---
Fails for function alog.active_logger.logging_taskT and trace 2 whose heads are
(gdb) call debug(ti->head)
(code_label 48 573 49 152 (nil) [2 uses])
(gdb) call debug(ti->eh_head)
(insn 57 76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #7 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #4)
> (In reply to Hongtao Liu from comment #3)
> > Looks like ix86_vect_estimate_reg_pressure doesn't work here, taking a look.
>
> Oh, ix86_vect_estimate_reg_pressure is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> With __val = 9223372036854775808LL __sign = -1LL
Oops, that should be __val = 9223372036854775808ULL and __sign = -1
i.e.
int main()
{
unsigned long lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #6 from Richard Biener ---
That's ix86_expand_vector_init_interleave which for QI inner_mode extends
to SImode, likely because it tries to work with just SSE2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Bug ID: 114753
Summary: from_chars aborts with -m32 -ftrapv when passed
-9223372036854775808
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #2 from Gejoe ---
For me, it is like this (just keeping the sample filenames as such but the
values are real ones shown while checking with gcov-dump) :
$gcov-dump ./obj-dir-path/src-file.gcda
./obj-dir-path/src-file.gcda:data:magi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #5 from Richard Biener ---
We do not BB vectorize gathers I think (ISTR some "loop" uses in the
infrastructure, not too difficult to fix I guess).
In the end the problem is RTL expansion of the CTOR and then lack of
combine?
Look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
Summary|[14] RISC-V rv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #4 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #3)
> Looks like ix86_vect_estimate_reg_pressure doesn't work here, taking a look.
Oh, ix86_vect_estimate_reg_pressure is only for loop, BB vectorizer only use
ix86_builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bf2b5231312e1cea45732cb8df6ffa2b2c9115b6
commit r14-10005-gbf2b5231312e1cea45732cb8df6ffa2b2c9115b6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
--- Comment #2 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:ca7d454804045a39d10a9b1f691a940aeacdf25b
commit r13-8616-gca7d454804045a39d10a9b1f691a940aeacdf25b
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #1 from Richard Biener ---
>From reading what the gcov code does it somehow means that the gcda and gcno
files were not created consistently.
You can use gcov-dump to check the stamp, for an example pair I have around
I see consiste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #1 fr
1 - 100 of 117 matches
Mail list logo
