The gcov_profile_merge() already had code to deal with profile information
which had no counterpart to merge with. For profile information from files
with no associated counterpart, the profile information is simply used as is
with the weighting transformation applied. Make sure that
This patch set is a proof of concept.
The aim is to better support gcov in free-standing environments. For example,
you can run a test executable which dumps all gcov info objects in a serial
data stream using __gcov_info_to_gcda() and the new __gcov_filename_to_gcfn().
It could be encoded as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #11 from Martin Liška ---
(In reply to vit9696 from comment #10)
> I believe this is possible. Since we use both clang and gcc, I filed an
> issue in llvm first to make sure both compilers can be updated in a similar
> way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #10 from vit9696 ---
I believe this is possible. Since we use both clang and gcc, I filed an issue
in llvm first to make sure both compilers can be updated in a similar way
(https://github.com/llvm/llvm-project/issues/54670).
Alexandre Oliva via Gcc-patches writes:
> These tests require a target that supports arm soft-float. The
> problem is that the test checks for compile-time soft-float support,
> but they may hit a problem when the linker complains that it can't
> combine the testcase's object file with
On Thu, Mar 31, 2022 at 7:51 AM liuhongt wrote:
>
> Since cfg is freed before machine_reorg, just do a rough calculation
> of the window according to the layout.
> Also according to an experiment on CLX, set window size to 64.
>
> Currently only handle V2DFmode load since it doesn't need any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #7 from Jakub Jelinek ---
There can be security concerns with that though if just print variable
in a debugger lets you format your disk etc. though, while DWARF expressions
can do a lot, they can't modify registers or memory of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #6 from Jakub Jelinek ---
Note, for computations expressible in DWARF expressions DWARF already has
DW_OP_call* which doesn't actually mean a call in the inferior call sense, but
a call in the DWARF expression evaluation sense, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Yeah, there is nothing we can do in the debug info about this.
> We really can't inline just for the purposes of debug stmts or something
> similar.
> Another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #3 from Jakub Jelinek ---
And I certainly can't reproduce the wrong-debug issue you're talking about.
If I change it to char l_144 = 8;
then optimized dump has:
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG l_144 => 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Hi,
The dg-options line in gcc.target/nvptx/march.c:
...
/* { dg-options "-march=sm_30"} */
...
currently doesn't have any effect because it's missing a space between '"' and
'}'.
Fix this by adding the missing space.
Tested on nvptx.
Committed to trunk.
Thanks,
- Tom
[nvptx, testsuite] Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89583
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63675
Arnaud Charlet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97ad0b831386e56ecb125a25fff00b2cb0b1a2b9
commit r12-7934-g97ad0b831386e56ecb125a25fff00b2cb0b1a2b9
Author: Richard Biener
Date:
When update_address_taken rewrites a _Complex into SSA it changes
stores to real/imaginary parts to loads of the other component and
a COMPLEX_EXPR. That matches what gimplification does but it misses
suppression of diagnostics for the load of the other component.
The following patch adds that,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #8 from vit9696 ---
> Sure, well, I can imagine introducing something similar to what we have for
> gcov:
>
> $ gcov --help | grep hash
> -x, --hash-filenamesHash long pathnames
Yes, that would likely solve the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
--- Comment #7 from Martin Liška ---
(In reply to Jakub Jelinek from comment #6)
> While changing mdiv= from accepting a string to Enum(something) might be
> worth it, wouldn't that be GCC 13 material? I think right now -mdiv=
> accepts random
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #7 from Martin Liška ---
(In reply to vit9696 from comment #6)
> While true, this scenario is simply inconvenient in many cases.
>
> (1) When filesystem path limitations exist, they will unavoidably lead to
> being unable to save
Hi,
Newer versions of CUDA no longer support sm_30, and nvptx-tools as
currently doesn't handle that gracefully when verifying
( https://github.com/MentorEmbedded/nvptx-tools/issues/30 ).
There's a --no-verify work-around in place in ASM_SPEC, but that one doesn't
work when using -Wa,--verify on
g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant. ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE. It's not clear to me which way the
clash between AAPCS and C++ Modules design should be resolved, but
currently it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b75f996e846d079251f3a6134617f0405c3ed535
commit r12-7932-gb75f996e846d079251f3a6134617f0405c3ed535
Author: Richard Biener
Date:
When expanding an aggregate copy into a memcpy call RTL expansion
uses mark_addressable to ensure the base object is addressable but
that function doesn't handle TARGET_MEM_REF bases. Fixed as follows.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-03-31 Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #6 from vit9696 ---
While true, this scenario is simply inconvenient in many cases.
(1) When filesystem path limitations exist, they will unavoidably lead to being
unable to save data due to extra large resulting paths. To remind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #5 from Martin Liška ---
(In reply to vit9696 from comment #4)
> Path length limitation in the current case is 200 bytes, but in general the
> issue is that we would like _to be able to properly set the gcda path for
> the
@Jakub: May I install it once stage1 opens?
Cheers,
Martin
On 1/3/22 12:43, Martin Liška wrote:
PING: Jakub?
On 12/15/21 10:57, Martin Liška wrote:
On 12/14/21 17:12, Jakub Jelinek wrote:
I'd use INT_TYPE_SIZE - 1 instead of 31. Otherwise LGTM.
Installed with that change, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
--- Comment #2 from Richard Biener ---
There isn't really a good way (w/o further analysis) to improve what
update_address_taken does. While it probably could use a BIT_INSERT_EXPR
instead of reading the other component and using a
On 3/30/22 16:48, Sebastian Huber wrote:
On 30/03/2022 15:30, Sebastian Huber wrote:
On 30/03/2022 13:56, Martin Liška wrote:
Example:
base64 -d log.txt | gcov-tool merge-stream
The gcov-tool uses a new tag which contains the filename of the associated gcov
info file:
gcov-dump
On 3/31/22 08:55, Sebastian Huber wrote:
gcc/
* gcov-io.cc (gcov_read_string): Reword documentation comment.
---
gcc/gcov-io.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-io.cc b/gcc/gcov-io.cc
index c2e9e2b6d64..72c40f8eaa0 100644
---
Hi.
Before the patch we have:
$ gcc-11 --help | grep target-help
--target-helpDisplay target specific command line options.
$ gcc-11 --help=common | grep target-help
--target-help Alias for --help=target.
and --target-help prints undocumented options (that was
gcc/
* gcov-io.cc (gcov_read_string): Reword documentation comment.
---
gcc/gcov-io.cc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/gcov-io.cc b/gcc/gcov-io.cc
index c2e9e2b6d64..72c40f8eaa0 100644
--- a/gcc/gcov-io.cc
+++ b/gcc/gcov-io.cc
@@ -473,9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107
--- Comment #3 from Martin Liška ---
You'll see it with:
gcc-11 pr105107.c -fsanitize=address -g -O2 &&
ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out
addr of e=0x739f4020
write to 0x739f4020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #14 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #13)
...
> Does the following fix the runtime error? The RTL after DSE seems to be OK.
>
> diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
> index
101 - 146 of 146 matches
Mail list logo
