Hello, Richard,
Thanks for the review!
On Mar 31, 2022, Richard Sandiford wrote:
>> +/* If the natural mode doesn't work, try some wider mode. */
>> +if (!targetm.hard_regno_mode_ok (regno, mode))
>> + {
>> +for (int nregs = 2;
>> + regno + nregs <=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment
Update my email address in the MAINTAINERS file.
2022-04-01 Qian Jianhua
ChangeLog:
* MAINTAINERS: Update my email address.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f388bdaf4f1..30f81b3dd52 100644
---
On Tue, 29 Mar 2022 07:08:35 PDT (-0700), lewis.rev...@embecosm.com wrote:
Currently the existing libcalls for restoring registers have the
requirement that they must be tail called by the parent function, so
that they can safely return through the restored return address
register. This does
On machines that support fixed-point and the test runs, it's failing
because of warnings issued by -Warray-parameter=[12], enabled by
-Wall.
The warnings state "mismatch in bound 1 of argument 1 declared as...",
referring to the redeclaration of f2_##NAME. The purpose of the
redeclaration is
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
--- Comment #5 from John Eivind Helset ---
Created attachment 52729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52729=edit
Patch with testcase.
Tried adding a testcase to the g++.dg/coroutines testsuite. Used dg-ice, but it
seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
Snapshot gcc-9-20220331 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20220331/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Wed, Mar 30, 2022 at 06:07:26PM -0500, Segher Boessenkool wrote:
> On Tue, Mar 15, 2022 at 02:18:00PM +0100, Jakub Jelinek wrote:
> > On Fri, Jan 28, 2022 at 11:50:26AM -0600, Bill Schmidt via Gcc-patches
> > wrote:
> > > PR104004 caught some misses on my part in converting to the new built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
--- Comment #3 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:aaf3a5993ae49f1ae6792800e5161a1d51436ed3
commit r12-7945-gaaf3a5993ae49f1ae6792800e5161a1d51436ed3
Author: Bill Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
--- Comment #4 from John Eivind Helset ---
It seems a non-void return-type from await-resume of a final awaitable,
combined with at least -O1 causes a segfault: https://godbolt.org/z/rzq8dM7Pr
Not sure if it's the same as the one I initially
On Thu, Mar 31, 2022 at 9:41 AM Sören Tempel wrote:
>
> Ping.
>
> Would be nice to get this integrated since this one of the changes needed to
> make gccgo work with musl libc. Let me know if the patch needs to be revised
> further.
I went with a simpler solution, more verbose but easier to
On Mon, Mar 21, 2022 at 10:28 PM Qing Zhao via Gcc-patches
wrote:
>
> Hi,
>
> Per our discussion on:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html
>
> I come up with the following patch to:
>
> 1. Update the documentation for TARGET_ZERO_CALL_USED_REGS hook;
> 2. Add an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #17 from Ian Lance Taylor ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> There seems to be a threshold at -fmax-stack-var-size=64.
The threshold is 64 for -m64, and 36 for -m32.
Could it be that the limit applies to the array
On Thu, 31 Mar 2022, Jonathan Wakely wrote:
On Thu, 31 Mar 2022 at 17:03, Marc Glisse via Libstdc++
wrote:
On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
I like it. But I'd like it even more if we could have
#elif defined _UBSAN
__ubsan_invoke_ub("reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104949
--- Comment #1 from Tobias Burnus ---
The following addition to testcase is needed.
! ---
!$omp parallel default(A)
!$omp master
if (any (A /= [1,2,3,4,5])) error stop
A(:) = [99,88,77,66,55]
!$omp end master
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105119
Bug ID: 105119
Summary: the division in x / (1 << y) is optimized away when x
has unsigned type, but not when it's signed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118
Bug ID: 105118
Summary: Why is unexpected::value() named error() in libstdc++?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:562d014efadfef6628ae670049c2d92ff6b166f0
commit r12-7941-g562d014efadfef6628ae670049c2d92ff6b166f0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Wed, 30 Mar 2022, Thomas Schwinge wrote:
> > I don't think we want to support different help strings for
> > different languages; if an option is supported for multiple languages, we
> > should have a generic description of that option that is correct for all
> > of them.
>
> To not just bury
On Wed, 30 Mar 2022, Thomas Schwinge wrote:
> > --- gcc/optc-gen.awk (revision 187427)
> > +++ gcc/optc-gen.awk (working copy)
>
> > else if (help[i] != "" && help[i + 1] != help[i])
> > - print "warning: multiple different help strings for "
> > \
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #9 from joseph at codesourcery dot com ---
The dependencies in gcc_update refer to
gcc/config/loongarch/genopts/loongarch-string which doesn't exist (should
be loongarch-strings not loongarch-string, I suppose). Maybe that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #9 from Cristian Assaiante ---
Created attachment 52728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52728=edit
Executable file at -Og with l_144 = 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #8 from Cristian Assaiante ---
(In reply to Jakub Jelinek from comment #3)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
Ping.
Would be nice to get this integrated since this one of the changes needed to
make gccgo work with musl libc. Let me know if the patch needs to be revised
further.
Sören Tempel wrote:
> The .regs member is primarily intended to be used in conjunction with
> ptrace. Since this code is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
Martin Jambor changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Part 2/2 of PR 102024 fix for MIPS.
The ABI says:
"Regardless of the struct field structure, it is treated as a sequence
of 64-bit chunks. If a chunk consists solely of a double float field
(but not a double, which is part of a union), it is passed in a floating
point register. Any other chunk
Hi,
This is a backport of the fix for PR99977 to the GCC 9 branch. The only
case where the GCC 10 patch did not apply cleanly was on sync.md, where
some of the context has changed, but the substance of the patch has not
changed, it simply required applying by hand.
Tested as follows:
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #14 from vit9696 ---
I have just tested this patch after rebasing it on 10.3.x branch, and can
confirm it works as intended. Thank you!
On 28/03/2022 15:59, Richard Sandiford wrote:
"Andre Vieira (lists)" writes:
Hi,
Addressed all of your comments bar the pred ops one.
Is this OK?
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_vector_costs): Define
determine_suggested_unroll_factor and m_nosve_pattern.
Part 1/2 of PR 102024 fix for MIPS.
No change for code generation. It only adds a -Wpsabi inform for return
values affected by the change in C++ FE.
The ABI is clear that any zero-width bit-field in a return value will
disallow using FPRs for it, so the behavior of GCC trunk is correct
(it's
On Thu, 31 Mar 2022 at 17:03, Marc Glisse via Libstdc++
wrote:
>
> On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
>
> > I like it. But I'd like it even more if we could have
> >
> > #elif defined _UBSAN
> >__ubsan_invoke_ub("reached std::unreachable()");
> >
> > But to my
On Thu, 31 Mar 2022 at 16:51, Matthias Kretz via Libstdc++
wrote:
>
> I like it. But I'd like it even more if we could have
>
> #elif defined _UBSAN
> __ubsan_invoke_ub("reached std::unreachable()");
>
> But to my knowledge UBSAN has no hooks for the library like this (yet).
As far as I
On Thu, 31 Mar 2022, Matthias Kretz via Gcc-patches wrote:
I like it. But I'd like it even more if we could have
#elif defined _UBSAN
__ubsan_invoke_ub("reached std::unreachable()");
But to my knowledge UBSAN has no hooks for the library like this (yet).
-fsanitize=undefined already
On Thu, 2022-03-31 at 17:50 +0200, Matthias Kretz via Gcc-patches wrote:
> I like it. But I'd like it even more if we could have
>
> #elif defined _UBSAN
> __ubsan_invoke_ub("reached std::unreachable()");
>
> But to my knowledge UBSAN has no hooks for the library like this
> (yet).
UBSAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
I like it. But I'd like it even more if we could have
#elif defined _UBSAN
__ubsan_invoke_ub("reached std::unreachable()");
But to my knowledge UBSAN has no hooks for the library like this (yet).
and...
On Thursday, 31 March 2022 17:30:29 CEST Jonathan Wakely via Gcc-patches
wrote:
> diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #43 from Jakub Jelinek ---
Created attachment 52727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52727=edit
gcc12-pr102772.patch
Another patch. This one changes (for now on 32-bit x86 solaris only)
malloc_alignment ()
This is a tiny C++23 feature that I plan to add for GCC 12. Does anybody
have any comments on the choices below in terms of when to make reaching
std::unreachable do an assert/trap/unreachable?
My thoughts on avoiding the overhead in the _GLIBCXX_ASSERTIONS case is
that this differs from e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:7ea3a73c195a79e6740ae594ee1a14c8bf7a938d
commit r12-7939-g7ea3a73c195a79e6740ae594ee1a14c8bf7a938d
Author: Martin Jambor
Date:
Pushed to trunk.
-- >8 --
The memalign man page on Solaris and QNX lists an additional requirement
for the alignment value that is not present in all implementation of
that non-standard function. For both those targets we should actually be
using posix_memalign anyway, so it doesn't matter. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:cf68f5a6d20db2aee2f3e674ad3f10e1c458edf9
commit r12-7937-gcf68f5a6d20db2aee2f3e674ad3f10e1c458edf9
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #42 from Jonathan Wakely ---
It should really depend on -faligned-new which can be set for C++14 and C++11
too (and I guess C++98 in theory, but that would break when you include
because you can't have 'enum class align_val_t' in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #34 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #33)
> > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR
>
> GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width
> bit-fields are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #33 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #31)
> Well, what do other compilers do? It's not such a good idea to break ABI
> compatibility with the 1990's compilers ;-)
Does someone have access to a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
--- Comment #3 from David Malcolm ---
Possible simplification: don't try to model floating-point operations e.g. any
binop on a floating point value has unknown_svalue as the result, so that
complicated floating-point computations can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e
commit r12-7936-gf6d65e803623c7ba6c8eb92ce5975fc1b90cd91e
Author: Martin Jambor
Date:
Hello,
gcov supports currently branch coverage. Some projects require modified
condition/decision coverage (MC/DC):
https://en.wikipedia.org/wiki/Modified_condition/decision_coverage
In general, 100% branch coverage does not imply 100% MC/DC coverage:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #41 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #39)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #37)
> > AFAICS, alignof is C++ >= 11 only. I've used the attached patch to
> > use __alignof__
Require effective target fpic for newly added test.
gcc/testsuite/
* g++.dg/ext/visibility/visibility-local-extern1.C: Add missing
dg-require-effective-target fpic.
Tested on x86_64-linux. Ok for master?
---
gcc/testsuite/g++.dg/ext/visibility/visibility-local-extern1.C | 1 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #8 from Jakub Jelinek ---
One possibility would be 32-bit make binary using 32-bit stat syscalls and the
new files having non-representable ino_t values, so stat on those would appear
to fail. But that is just a wild guess...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #40 from Jonathan Wakely ---
N.B. I don't think we want to replace alignof with __alignof__ because they're
not identical. For x86 alignof(long long) != __alignof__(long long).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #39 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #37)
> AFAICS, alignof is C++ >= 11 only. I've used the attached patch to
> use __alignof__ instead, although I don't know if that's the best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #7 from Andreas Schwab ---
contrib/gcc_update is supposed to work with any make, even non-GNU ones,
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Hi, Richard,
Thanks a lot for your reviewing on the non-x86 part.
Uros, could you please review the x86 part of the change?
thanks.
Qing
> On Mar 31, 2022, at 8:10 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi,
>>
>> Per our discussion on:
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #5 from seurer at gcc dot gnu.org ---
The makefiles between systems were the same.
One thing that is different is make itself. On another system where this was
working make was a later release. So I grabbed the latest release of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #38 from Rainer Orth ---
Created attachment 52726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52726=edit
Use __alignof__ in several allocator headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #36 from Jakub Jelinek ---
> Created attachment 52719
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719=edit
> gcc12-pr102772.patch
>
> So like this?
Mostly.
On Thu, 31 Mar 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > The following makes sure that when we build the versioning condition
> > for vectorization including the cost model check, we check for the
> > cost model and branch over other versioning checks. That is what
> > the
Hi!
On 2020-11-18T10:36:35+0100, Jakub Jelinek via Gcc-patches
wrote:
> Honza mentioned that especially for the new param machinery, most of
> streamed values are probably going to be the default values. Perhaps
> somehow we could stream them more effectively.
>
> This patch implements it and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #4 from Jan Hubicka ---
What happens to the by-value parameter should get merged from
concat5_pkg2.compare (s);
I will take a look now - sorry for not handling this bug earlier.
Honza
Qing Zhao writes:
> Hi,
>
> Per our discussion on:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html
>
> I come up with the following patch to:
>
> 1. Update the documentation for TARGET_ZERO_CALL_USED_REGS hook;
> 2. Add an assertion in function.cc to make sure the actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645
--- Comment #4 from Jakub Jelinek ---
The first GCC 13 should have been GCC 12 of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645
--- Comment #3 from Jakub Jelinek ---
Created attachment 52725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52725=edit
gcc12-pr104645.patch
I wonder if at least for GCC 13 we just can't treat even that cast stmt as a
preparation
Richard Biener writes:
> The following makes sure that when we build the versioning condition
> for vectorization including the cost model check, we check for the
> cost model and branch over other versioning checks. That is what
> the cost modeling assumes, since the cost model check is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #4 from Jakub Jelinek ---
Mar 30 15:14 is certainly much newer than Mar 30 10:16.
Perhaps try make -d -f Makefile.28475 all
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #3 from Richard Biener ---
The store
D.5010.P_BOUNDS =
is
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 9 canonical-type
0x7653bf18 fields Ada size
pointer_to_this chain
On Wed, 30 Mar 2022, Jason Merrill via Gcc-patches wrote:
> The recent change to reject __is_constructible for nested classes with DMI
> is breaking some code loudly that was previously only silently broken.
> Let's allow simple cases by immediately parsing DMI that do no name lookup;
> then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #32 from Jakub Jelinek ---
One of the reasons we changed the ABI on various arches one way or another is
that we had this ABI incompatibility between C and C++, that just can't be
right.
At that time we can and should decide if we
> Hi,
>
> PR 102513 shows we emit bogus array access warnings when IPA-CP
> creates clones specialized for values which it deduces from arithmetic
> jump functions describing self-recursive calls. Those can however be
> avoided if we consult the IPA-VR information that the same pass also
> has.
> Hi,
>
> in r12-2523-g13586172d0b70c ipa-prop tracking of jump functions during
> inlining got the ability to remove ADDR references when inlining
> discovered that they were not necessary or turn them into LOAD
> references when we know that what was a function call argument passed
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #31 from Segher Boessenkool ---
Well, what do other compilers do? It's not such a good idea to break ABI
compatibility with the 1990's compilers ;-)
> IPA_JF_ANCESTOR jump functions are constructed also when the formal
> parameter of the caller is first checked whether it is NULL and left
> as it is if it is NULL, to accommodate C++ casts to an ancestor class.
>
> The jump function type was invented for devirtualization and IPA-CP
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #3 from seurer at gcc dot gnu.org ---
I did look at the Makefile and didn't see anything that jumped out as weird. I
will try comparing it to one that works.
Those files all exist.
-rwxr-xr-x 1 seurer users 2954 Mar 30 10:16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #13 from Martin Liška ---
Created attachment 52724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52724=edit
Tentative patch
Can you please experiment with the following patch?
Alexandre Oliva via Gcc-patches writes:
> When the mode of regno_reg_rtx is not hard_regno_mode_ok for the
> target, try grouping the register with subsequent ones. This enables
> s16 to s31 and their hidden pairs to be zeroed with the default logic
> on some arm variants.
>
> Regstrapped on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #12 from vit9696 ---
It is an in-house airborne RTOS we develop in ISP RAS. There is a legacy paper
in English telling a bit more about the project
(https://www.ispras.ru/proceedings/docs/2016/28/2/isp_28_2016_2_181.pdf).
libgcc/
* libgcov-util.c (ftw_read_file): Use size_t for strlen() variables.
---
libgcc/libgcov-util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgcc/libgcov-util.c b/libgcc/libgcov-util.c
index 03902ed10b1..622d5a9dc71 100644
--- a/libgcc/libgcov-util.c
gcc/
* gcov-tool.cc (gcov_profile_merge_stream): Declare.
(print_merge_stream_usage_message): New.
(merge_stream_usage): Likewise.
(do_merge_stream): Likewise.
(print_usage): Call print_merge_stream_usage_message().
(main): Call do_merge_stream() to
Use an enum for file error codes.
gcc/
* gcov-io.cc (gcov_file_error): New enum.
(gcov_var): Use gcov_file_error enum for the error member.
(gcov_open): Use GCOV_FILE_NO_ERROR.
(gcov_close): Use GCOV_FILE_WRITE_ERROR.
(gcov_write): Likewise.
gcc/
* gcov-io.h (GCOV_FILENAME_MAGIC): Define and document.
libgcc/
* gcov.h (__gcov_info_to_gcda): Mention __gcov_filename_to_gcfn().
(__gcov_filename_to_gcfn): Declare and document.
* libgcov-driver.c (dump_string): New.
(__gcov_filename_to_gcfn):
This allows to reuse read_gcda_file() to read multiple objects from a single
file.
libgcc/
* libgcov-util.c (read_gcda_file): Do not open file.
(ftw_read_file): Open file here.
---
libgcc/libgcov-util.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff
This helps to reuse read_gcda_file().
libgcc/
* libgcov-util.c (read_gcda_file): Prepend new info object to global
list.
(ftw_read_file): Remove list append here.
---
libgcc/libgcov-util.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
Move duplication of filename to caller and use xstrdup() instead of custom
code. This helps to reuse read_gcda_file() for other purposes.
libgcc/
* libgcov-util.c (read_gcda_file): Do not duplicate filename.
(ftw_read_file): Duplicate filename for read_gcda_file().
---
This function is only used by gcov_write_length() in the gcov-io.cc file.
gcc/
* gcov-io.cc (gcov_seek): Make it static.
* gcov-io.h (struct gcov_summary): Do not mention gcov_seek().
libgcc/
* libgcov.h (gcov_seek): Remove define and declaration.
---
gcc/gcov-io.cc
gcc/
* gcov-io.cc (GCOV_MODE_STDIN): Define.
(gcov_position): For gcov-tool, return calculated position if file is
stdin.
(gcov_open): For gcov-tool, use stdin if filename is NULL.
(gcov_close): For gcov-tool, do not close stdin.
(gcov_read_bytes):
gcc/
* gcov-tool.cc (gcov_do_dump): Add mode parameter.
(gcov_output_files): Open files for reading and writing.
libgcc/
* libgcov-driver-system.c (gcov_exit_open_gcda_file): Add mode
parameter. Pass mode to gcov_open() calls.
* libgcov-driver.c
gcc/
* gcov-io.cc (gcov_open): Always use the mode parameter.
* gcov-io.h (gcov_open): Declare it unconditionally.
libgcc/
* libgcov-driver-system.c (gcov_exit_open_gcda_file): Open file for
reading and writing.
* libgcov-util.c (read_gcda_file): Open
1 - 100 of 146 matches
Mail list logo
