This new test was reported to be still failing on sparc targets.
Here the number of DW_AT_ranges dropped to zero.
The test should pass on this architecture with -Os, -O2 and -O3.
I tried to improve also different known problematic targets,
where only one subroutine had DW_AT_ranges:
Those are armhf
On 8/26/24 10:31, Richard Biener wrote:
> On Mon, 26 Aug 2024, Bernd Edlinger wrote:
>
>> This recent change triggered various bootsteap-errors, mostly on
>> x86 targets because line info advance address entries were output
>> in the wrong section table.
>> The
This recent change triggered various bootsteap-errors, mostly on
x86 targets because line info advance address entries were output
in the wrong section table.
The switch to the wrong line table happened in dwarfout_set_ignored_loc.
It must use the same section as the earlier called
dwarf2out_switch
Apparently due to slightly different optimization levels
not always both subroutines have multiple subranges,
but having at least one such, and no lexical blocks
is sufficient to prove that the fix worked. Q.E.D.
So reduce the test expectations to only at least one
inlined subroutine with multiple
This affects only the RISC-V targets, where the compiler options
-gvariable-location-views and consequently also -ginline-points
are disabled by default, which is unexpected and disables some
useful features of the generated debug info.
Due to a bug in the gas assembler the .loc statement
is not u
On 8/22/24 09:11, Richard Biener wrote:
> On Thu, 22 Aug 2024, Bernd Edlinger wrote:
>> --- a/gcc/dwarf2out.cc
>> +++ b/gcc/dwarf2out.cc
>> @@ -10374,7 +10374,7 @@ dwarf2out_maybe_output_loclist_view_pair
>> (dw_loc_list_ref curr)
>> #ifdef DW_LLE_view_
This affects only the RISC-V targets, where the compiler options
-gvariable-location-views and consequently also -ginline-points
are disabled by default, which is unexpected and disables some
useful features of the generated debug info.
Due to a bug in the gas assembler the .loc statement
is not u
to make a small fixup to the test cases, as the linaro folks
indicated
that my test cases should not include the comment sign in "# DW_AT_entry_pc",
as that is target dependent.
Thanks
Bernd.
> On Aug 21, 2024, Bernd Edlinger wrote:
>
>> gcc/Chan
While this already works correctly for the case when an inlined
subroutine contains only one subrange, a redundant DW_TAG_lexical_block
is still emitted when the subroutine has multiple blocks.
Fixes: ac02e5b75451 ("re PR debug/37801 (DWARF output for inlined functions
doesn'
On 8/21/24 10:45, Richard Biener wrote:
> On Wed, 21 Aug 2024, Richard Biener wrote:
>
>> On Tue, 20 Aug 2024, Bernd Edlinger wrote:
>>
>>> On 8/20/24 13:00, Richard Biener wrote:
>>>> On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger
>>>> wrote:
This affects only the RISC-V targets, where the compiler options
-gvariable-location-views and consequently also -ginline-points
are disabled by default, which is unexpected and disables some
useful features of the generated debug info.
Due to a bug in the gas assembler the .loc statement
is not u
On 8/20/24 13:00, Richard Biener wrote:
> On Fri, Aug 16, 2024 at 12:49 PM Bernd Edlinger
> wrote:
>>
>> While this already works correctly for the case when an inlined
>> subroutine contains only one subrange, a redundant DW_TAG_lexical_block
>> is still emitted wh
This affects only the RISC-V targets, where the compiler options
-gvariable-location-views and consequently also -ginline-points
are disabled by default, which is unexpected and disables some
useful features of the generated debug info.
Due to a bug in the gas assembler the .loc statement
is not u
This affects only the RISC-V targets, where the compiler options
-gvariable-location-views and consequently also -ginline-points
are disabled by default, which is unexpected and disables some
useful features of the generated debug info.
Due to a bug in the gas assembler the .loc statement
is not u
While this already works correctly for the case when an inlined
subroutine contains only one subrange, a redundant DW_TAG_lexical_block
is still emitted when the subroutine has multiple blocks.
Fixes: ac02e5b75451 ("re PR debug/37801 (DWARF output for inlined functions
doesn'
On 4/11/24 05:03, Li, Pan2 wrote:
> Committed, thanks Juzhe and Kito.
>
> Pan
Hi Pan,
this commit caused a regression:
FAIL: gcc.c-torture/compile/930623-1.c -O0 (test for excess errors)
FAIL: gcc.c-torture/compile/930623-1.c -O1 (internal compiler error: in
emit_vec_extract, at config/
On 8/10/21 10:56 PM, Eric Botcazou wrote:
>> Ah, thanks, I tried it but the defs__struct1IP function has
>> DECL_IGNORED_P = false when I build it with -gnatD.
>>
>> So that would not be affected by setting DECL_SOURCE_LOCATION to
>> UNKNOWN_LOCATION as done in the proposed patch, because that is o
On 8/9/21 4:37 PM, Eric Botcazou wrote:
>> But it is okay that we can set a breakpoint on defs__struct1IP,
>> in the test case of PR 101598.
>> And the debugger shall only show assembler here.
>> Right?
>
> The defs__struct1IP procedure should be totally transparent for the user, so
> setting a b
On 8/4/21 4:33 PM, Eric Botcazou wrote:
>> The location of these ignored Ada decls looks completely sane to me.
>> However, it was an unintentional side effect of the patch to allow
>> minimal debugging of ignored decls. This means we can now step into
>> those functions or set line breakpoints th
cls with
>> DECL_IGNORED_P to UNKNOWN_LOCATION.
>>
>> 2021-07-24 Bernd Edlinger
>>
>> PR debug/101598
>> * gcc-interface/trans.c (Subprogram_Body_to_gnu): Set the
>> DECL_SOURCE_LOCATION of DECL_IGNORED_P gnu_subprog_decl to
>>
On 7/29/21 9:23 AM, Richard Biener wrote:
> On Wed, 28 Jul 2021, Bernd Edlinger wrote:
>
>> On 7/28/21 2:51 PM, Richard Biener wrote:
>>> On Mon, 26 Jul 2021, Bernd Edlinger wrote:
>>>
>>>> Ignored functions decls that are compiled at the start of
>&
On 7/28/21 2:51 PM, Richard Biener wrote:
> On Mon, 26 Jul 2021, Bernd Edlinger wrote:
>
>> Ignored functions decls that are compiled at the start of
>> the assembly have bogus line numbers until the first .file
>> directive, as reported in PR101575.
>>
>>
It was pointed out in PR101598 to be inappropriate, that
ignored Ada decls receive the source line number which was
recorded in the function decl's DECL_SOURCE_LOCATION.
Therefore set all front-end-generated Ada decls with
DECL_IGNORED_P to UNKNOWN_LOCATION.
2021-07-24 Bernd Edl
, mostly for -fdwarf-4.
2021-07-24 Bernd Edlinger
PR ada/101575
* dwarf2out.c (dwarf2out_begin_prologue): Move init
of fde->ignored_debug to dwarf2out_set_ignored_loc.
(dwarf2out_set_ignored_loc): This is now also called
when no .loc statement is to
rapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks,
Bernd Edlinger (2):
Fix debug info for ignored decls at start of assembly
Ada: Remove debug line number for DECL_IGNORED_P functions
gcc/ada/gcc-interface/trans.c | 4 +++-
gcc/dwarf2out.c
On 7/14/21 2:47 PM, Tamar Christina wrote:
> Hi,
>
> Ever since this commit
>
> commit c9114f2804b91690e030383de15a24e0b738e856
> Author: Bernd Edlinger
> Date: Fri May 28 06:27:27 2021 +0200
>
> Various tools have been having trouble with cross compilation result
c:
2021-06-08 Bernd Edlinger
* Make-lang.in (cc1-obj-checksum.c): Check previous
stage checksum exists.
gcc/objcp:
2021-06-08 Bernd Edlinger
* Make-lang.in (cc1objplus-checksum.c): Check previous
stage checksum exists.
---
gcc/objc/Make-lang.in | 3 ++-
gcc/ob
Ping...
On 5/28/21 9:47 AM, Bernd Edlinger wrote:
> Hi Richard,
>
> I've replicated your PR to make the objective-c checksum compare equal
>
> commit fb2647aaf55b453b37badfd40c14c59486a74584
> Author: Richard Biener
> Date: Tue May 3 08:14:27 2016 +
>
>
On 5/29/21 9:31 PM, Jeff Law wrote:
>
>
> On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> it turns out to be reproducible this way:
>>
>> COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
>>
>> Running
.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix
caret_max_with.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_
stage.
From-SVN: r235804
This silences the stage compare.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
objc/
* Make-lang.in (cc1obj-checksum.c): For stage-final re-use
the checksum from the previous
On 5/28/21 9:26 AM, Andrew Pinski wrote:
> On Thu, May 27, 2021 at 10:10 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> I was wondering, why gimple-match.c and generic-match.c
>> are not built early but always last, which slows down parallel
>> makes signif
On 5/28/21 8:41 AM, Richard Biener wrote:
> On Fri, 28 May 2021, Bernd Edlinger wrote:
>
>>
>>
>> On 5/28/21 6:42 AM, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> I was wondering, why gimple-match.c and generic-match.c
>>> are not buil
On 5/28/21 6:42 AM, Bernd Edlinger wrote:
> Hi,
>
> I was wondering, why gimple-match.c and generic-match.c
> are not built early but always last, which slows down parallel
> makes significantly.
>
> The reason seems to be that generated_files does not
> mention gi
:
$(ALL_HOST_OBJS) : | $(generated_files)
So this patch adds gimple-match.c generic-match.c to generated_files.
Tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
* Makefile.in (generated_files): Add gimple-match.c and
generic-match.c
From
On 5/19/21 3:37 PM, Bernd Edlinger wrote:
> On 5/19/21 3:27 PM, Jonathan Wakely wrote:
>> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote
On 5/26/21 7:03 PM, Bernd Edlinger wrote:
> On 5/26/21 2:05 PM, Richard Biener wrote:
>> On Wed, May 26, 2021 at 1:37 PM Andrew Pinski wrote:
>>>
>>> On Wed, May 26, 2021 at 4:28 AM Richard Biener
>>> wrote:
>>>>
>>>> On Wed, May 26, 2
t;>> On Wed, May 26, 2021 at 2:01 AM Andrew Pinski wrote:
>>>>>
>>>>> On Wed, May 26, 2021 at 1:43 AM Bernd Edlinger
>>>>> wrote:
>>>>>>
>>>>>> On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
>>>>>
On 5/25/21 4:22 PM, Richard Biener via Gcc-patches wrote:
> On Sun, May 23, 2021 at 12:03 PM apinski--- via Gcc-patches
> wrote:
>>
>> From: Andrew Pinski
>>
>> Instead of some of the more manual optimizations inside phi-opt,
>> it would be good idea to do a lot of the heavy lifting inside match
On 5/21/21 8:57 AM, Richard Biener wrote:
> On Thu, May 20, 2021 at 4:04 PM H.J. Lu wrote:
>>
>> On Thu, May 20, 2021 at 12:51 AM Richard Biener
>> wrote:
>>>
>>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu wrote:
On Wed, May 19, 2021 at 2:33 AM Richard Biener
wrote:
>
> O
On 5/20/21 10:49 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 5:55 AM H.J. Lu wrote:
>>
>> On Wed, May 19, 2021 at 2:25 AM Richard Biener
>> wrote:
>>>
>>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
target ins
On 5/20/21 4:03 PM, H.J. Lu wrote:
> On Thu, May 20, 2021 at 12:51 AM Richard Biener
> wrote:
>>
>> On Wed, May 19, 2021 at 3:22 PM H.J. Lu wrote:
>>>
>>> On Wed, May 19, 2021 at 2:33 AM Richard Biener
>>> wrote:
On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
>
> When expandin
IL: g++.dg/modules/omp-1_c.C -std=c++2a (test for excess errors)
FAIL: g++.dg/modules/omp-1_c.C -std=c++2b dg-regexp 6 not found: "In module
imported at [^\\n]*omp-1_c.C:3:1:\\nfoo: error: module contains OpenMP, use
'-fopenmp' to enable\\n"
FAIL: g++.dg/modules/omp-1_c.C -std=c++
On 5/19/21 3:27 PM, Jonathan Wakely wrote:
> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>>>> libstdc++-v3/ChangeLog:
>>>>
>>>>
On 5/19/21 3:22 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 2:33 AM Richard Biener
> wrote:
>>
>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
>>>
>>> When expanding a constant constructor, don't call expand_constructor if
>>> it is more efficient to load the data from the memory via move by p
to bb 90
>> + Sinking _321 = (unsigned long) ip_229;
>> + from bb 31 to bb 90
>> + Sinking len_158 = _322 + 4294967295;
>> +from bb 31 to bb 33" */
>>
>> - /* { dg-final { scan-tree-dump-times "Sunk statements: 4" 1 "sink2" } }
On 5/18/21 1:55 PM, Bernd Edlinger wrote:
> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/thread (jthread::_S_create): Fix static assert
>> message.
>> * testsuite/30_threads
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/thread (jthread::_S_create): Fix static assert
> message.
> * testsuite/30_threads/jthread/95989.cc: Re-enable test.
> * testsuite/30_threads/jthread/jthread.cc: Do not re
On 5/18/21 1:00 PM, Segher Boessenkool wrote:> On Tue, May 18, 2021 at
08:36:34AM +0200, Bernd Edlinger wrote:
>> On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
>>> Bootstrap and regtest pass on ppc64le. Is this ok for trunk?
>
>> I've tried this patch and
On 5/17/21 3:15 PM, H.J. Lu via Gcc-patches wrote:
> Changes in the v3 patches:
>
> 1. Split the TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE changes
> into the generic part and the x86 part.
>
>
> 1. Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
> target instructio
On 5/17/21 4:01 AM, Jiufu Guo via Gcc-patches wrote:
> When there is the possibility that overflow/wrap may happen on the loop index,
> a few optimizations would not happen. For example code:
>
> foo (int *a, int *b, unsigned k, unsigned n)
> {
> while (++k != n)
> a[k] = b[k] + 1;
> }
>
>
On 5/16/21 10:36 PM, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski
>
> Instead of some of the more manual optimizations inside phi-opt,
> it would be good idea to do a lot of the heavy lifting inside match
> and simplify instead. In the process, this moves the three simple
> A?CST1:CST2
On 5/14/21 11:26 PM, Julian Brown wrote:
> This patch reworks indirect struct handling in gimplify.c (i.e. for struct
> components mapped with "mystruct->a[0:n]", "mystruct->b", etc.), for
> both OpenACC and OpenMP. The key observation leading to these changes
> was that component mappings of refe
On 5/13/21 5:17 PM, Jeff Law via Gcc-patches wrote:
>
> On 5/13/2021 6:23 AM, Martin Jambor wrote:
>> Hi,
>>
>> When SRA transforms an assignment where the RHS is an aggregate decl
>> that it creates replacements for, the (least efficient) fallback
>> method of dealing with them is to store all th
've pushed now:
commit cb787efa45782adab764575a2efc356e082828b6
Author: Bernd Edlinger
Date: Fri May 14 07:10:59 2021 +0200
Cleanup temp files in libphobos unittest at src/std/process.d
2021-05-14 Bernd Edlinger
* src/std/process.d (unittest): Remove tmpname on exit.
* src/
Hi Iain,
On 5/14/21 11:55 AM, Iain Buclaw wrote:
> Excerpts from Bernd Edlinger's message of May 14, 2021 7:19 am:
>> Hi,
>>
>> I've noticed that a couple temp files are leaked after each full
>> gcc test-suite run.
>>
>> I'd like to fix that by the following patch.
>>
>>
>> Bootstrapped and reg-t
00:00 2001
From: Bernd Edlinger
Date: Fri, 14 May 2021 07:10:59 +0200
Subject: [PATCH] Cleanup temp files in libphobos unittest at src/std/process.d
2021-05-14 Bernd Edlinger
* src/std/process.d (unittest): Remove tmpname on exit.
---
libphobos/src/std/process.d | 1 +
1 file changed, 1
On 5/14/21 12:35 AM, Martin Sebor wrote:
> On 5/13/21 11:36 AM, Martin Sebor wrote:
>> On 5/13/21 11:20 AM, Bernd Edlinger wrote:
>>> On 5/13/21 3:55 AM, Martin Sebor via Gcc-patches wrote:
>>>> A logic bug in the handling of PHI arguments in compute_objsize
>>&
On 5/13/21 3:55 AM, Martin Sebor via Gcc-patches wrote:
> A logic bug in the handling of PHI arguments in compute_objsize
> that are all null pointers lets an incompletely populated struct
> be used in a way that triggers an assertion causing an ICE.
>
> The attached patch corrects that by having
On 5/13/21 3:37 PM, H.J. Lu via Gcc-patches wrote:
> Warn for excessive argument alignment in main instead of ICE.
>
> gcc/
>
> PR c/100575
> * cfgexpand.c (expand_stack_alignment): Add a bool argument for
> expanding main. Warn for excessive argument alignment in main.
>
Hi,
this fixes another regression from my previous patch.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
From 62da66525c4b7ac1cfd5cad5b8e690ce928802e5 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Tue, 11 May 2021 17:55:18 +0200
Subject: [PATCH
Hi Eric,
I have a slightly different issue, last week it was still okay,
but now I get (using gcc-4.8 as bootstrap compiler):
gcc -std=gnu99 -c -g -gnatpg -gnatwns -gnata -W -Wall -nostdinc -I- -I.
-Iada/generated -Iada -Iada/gcc-interface -I../../gcc-trunk/gcc/ada
-I../../gcc-trunk/gcc/ada/gc
Hi,
this fixes a fallout from my previous patch to improve
debug info of virtual thunks.
Tested on x86_64-pc-linux-gnu with --target_board=unix/-m32
Is it OK for trunk?
Thanks
Bernd.
From 7bea6a83f4daf97ac1cfeb6c2e10fb7ae742340f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sat, 8 May
urrent one.
So, since we are again in stage 1:
Is it OK for trunk?
Thanks
Bernd.
On 1/13/21 3:59 PM, Bernd Edlinger wrote:
> Hi,
>
> this is a new improved version of my patch.
> The previous patch had two defects:
> It failed with -ffunction-section. Although
> the line in
Aehm,
forgot to mention,
tested on arm-none-eabi (arm-sim target)
is it OK for trunk?
Thanks
Bernd.
On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> As the test case shows, the outer mode may have a higher alignment
> requirement than the inner mode here.
>
> 2021-04-22 Be
As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.
2021-04-22 Bernd Edlinger
PR target/100106
* gimplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.
* gcc.c
Oops,
thanks for fixing this problem.
To my excuse I would like to note,
that the script error does not happen on x86_64-pc-linux-gnu,
probably it would only happen when a file is left over.
Since usually this is never executed because $outs is empty:
foreach f $outs {
file delete $
Ping?
The patch was posted before Stage 4 started:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563391.html
Thanks
Bernd.
On 1/13/21 3:59 PM, Bernd Edlinger wrote:
> Hi,
>
> this is a new improved version of my patch.
> The previous patch had two defects:
> It failed
x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
From feffb6731523e3a77566c2a5f541c6b90e1ffb19 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Tue, 12 Jan 2021 16:27:53 +0100
Subject: [PATCH] Add line debug info for virtual thunks
There is no debug info when the DECL_IGNORED_P flag
is
K to push?
Thanks
Bernd.
> Thanks, David
>
> On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger
> wrote:
>>
>> On 1/8/21 3:23 PM, David Edelsohn wrote:
>>> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
>>> wrote:
>>>>
>>>> Hi,
>>
On 1/8/21 3:23 PM, David Edelsohn wrote:
> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>> The unsetenv needs to be wrapped in
>>>
>>> if [info exists env(MAKEFLAGS)]
we would have a couple of other files created
as well IMHO.
If there are still misssing files in some cases,
I'd prefer to track these per test case, instead of globally.
Therefore I propose to remove that exception for now.
Is it OK for trunk?
Thanks
Bernd.
From 9e0fc10b1c655320ccb63c17981
Hi,
this should fix the test failures in this test case.
Is it OK for trunk?
Thanks
Bernd.
From a8008af3db94a9dff7ae243ebfb40f45c54b3a81 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Thu, 7 Jan 2021 09:37:32 +0100
Subject: [PATCH] Fix test failures from outputs.exp
The .ld1_args file
On 1/6/21 12:49 PM, Eric Botcazou wrote:
>> currently there is a problem when debugging a virtual thunk. That is
>> a decl with DECL_IGNORED_P. Currently the line information displayed
>> in gdb is completely bogus, thus the last line of whatever function
>> is immediately before the PC of the th
On 1/4/21 10:45 PM, Jeff Law wrote:
>
>
> On 1/4/21 1:06 PM, Bernd Edlinger wrote:
>> --- a/gcc/final.c
>> +++ b/gcc/final.c
>> @@ -1735,7 +1735,12 @@ final_start_function_1 (rtx_insn **firstp, FILE
>> *file, int *seen,
>>
On 1/6/21 8:01 AM, Alexandre Oliva wrote:
> On Jan 5, 2021, Richard Biener wrote:
>
>> But isn't this a consumer issue then? If there is no line info for
>> a PC range then gdb shouldn't display any.
>
> No, there *is* line info there, carried over from an earlier .loc
> directive, as there is
On 1/5/21 5:51 PM, Jeff Law wrote:
>
>
> On 1/5/21 1:05 AM, Richard Biener wrote:
>> On Tue, 5 Jan 2021, Bernd Edlinger wrote:
>>
>>>
>>> On 1/4/21 10:23 PM, Jeff Law wrote:
>>>>
>>>> On 1/4/21 1:12 PM, Bernd Edlinger wrote:
On 1/4/21 10:23 PM, Jeff Law wrote:
>
>
> On 1/4/21 1:12 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> I spotted a place where input_location is clobbered accidentally.
>>
>> That is in a recursive call to expand_call_inline. The input_location
>> is usu
good idea.
Although this causes no problems ATM, I wanted to fix it anyway.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
From 88b963bba7b32972abf0ea44a01c03d643d7c6ca Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 4 Jan 2021 11:35:31 +0100
0a44bb870e90623689cae484f8a8899706480876 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 3 Jan 2021 11:18:39 +0100
Subject: [PATCH] Add line debug info for virtual thunks
There is no full debug info since the DECL_IGNORED_P
flag is set on virtual thunks.
But instead of no line info at all, emit at least
the
Hi,
I'd like to ping for this patch below:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561811.html
Thanks
Bernd.
On 12/14/20 4:31 PM, Bernd Edlinger wrote:
> Hi,
>
> On 2/21/20 8:35 AM, Richard Biener wrote:
>>
>> IIRC this definitely clashes with Alex w
or trunk?
Thanks
Bernd.
From 5e07f814f102d6dabebcb6652a40f5a1b9716479 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 13 Dec 2020 08:24:57 +0100
Subject: [PATCH] Fix -save-temp leaking lto files in /tmp
When linking with -flto and -save-temps, various
temporary files are created in /tmp.
On 12/8/20 7:57 PM, Bernd Edlinger wrote:
> On 12/8/20 11:35 AM, Richard Biener wrote:
>>
>> + {
>> + /* Remove a nonbind marker when the outer scope of the
>> + inline function is completely removed. */
>> + if (gi
On 12/8/20 11:35 AM, Richard Biener wrote:
>
> + {
> + /* Remove a nonbind marker when the outer scope of the
> + inline function is completely removed. */
> + if (gimple_debug_nonbind_marker_p (stmt)
> + && BLOCK_ABSTRACT_ORIGIN (b))
> +
22b2 Mon Sep 17 00:00:00 2001
> From: Bernd Edlinger
> Date: Wed, 2 Dec 2020 12:32:02 +0100
> Subject: [PATCH] Remove misleading debug line entries
>
> This removes gimple_debug_begin_stmts without block info which remain
> after a gimple block originating from an inline functio
On 12/7/20 4:04 PM, Jason Merrill wrote:
> On 12/5/20 7:37 AM, Bernd Edlinger wrote:
>> On 12/2/20 7:57 PM, Jason Merrill wrote:
>>> On 12/1/20 1:28 PM, Bernd Edlinger wrote:>>>> + tree type =
>>> targetm.cxx.guard_mask_bit ()
>>>&
On 12/7/20 11:50 AM, Richard Biener wrote:
>
> The ipa-param-manipulation.c hunk is OK, please commit separately.
>
Okay, this is the part I just committed.
commit 92e563d91b012f09da8fd152e934f6b964ae49cb
Author: Bernd Edlinger
Date: Mon Dec 7 16:00:00 2020 +0100
Fix locatio
On 12/2/20 7:57 PM, Jason Merrill wrote:
> On 12/1/20 1:28 PM, Bernd Edlinger wrote:
>> On 11/24/20 11:10 PM, Jason Merrill wrote:
>>> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this avoids the need to use -fno-threadsaf
On 12/3/20 9:30 AM, Richard Biener wrote:
> On Wed, 2 Dec 2020, Bernd Edlinger wrote:
>
>> On 12/2/20 8:50 AM, Richard Biener wrote:
>>> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>>>
>>>> Hi!
>>>>
>>>>
>>>> Thi
On 12/2/20 8:50 AM, Richard Biener wrote:
> On Tue, 1 Dec 2020, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This removes gimple_debug stmts without block info after a
>> NULL INLINE_ENTRY.
>>
>> The line numbers from these stmts are from the inli
this point, and therefore those
line table entries are not helpful to the user.
2020-11-20 Bernd Edlinger
* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
following a removed debug_inline_entry.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK
On 11/24/20 11:10 PM, Jason Merrill wrote:
> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this avoids the need to use -fno-threadsafe-statics on
>> arm-none-eabi or working around that problem by supplying
>> a dummy __sync_synchronize function which
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559882.html
Thanks
Bernd.
On 11/22/20 9:05 AM, Bernd Edlinger wrote:
> Hi,
>
> this avoids the need to use -fno-threadsafe-statics on
> arm-none-eabi or working around that problem
target,
that is, previously the wrong bit was checked.
Regression tested successfully on arm-none-eabi with newlib-3.3.0.
Is it OK for trunk?
Thanks
Bernd.
From 9fd070407408cf10789f5e9eb5ddda2fb3798e6f Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Sun, 22 Nov 2020 08:11:14 +0100
Subject
On 11/17/20 4:41 PM, Richard Earnshaw (lists) wrote:
>
> libgcc is *still* the wrong place for this. It belongs in the system
> library (eg newlib, or glibc, or whatever), which knows about the system
> it's running on. (Sorry, I should have said this before, but I've
> context-switched this out
On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote:
> On 03/11/2020 15:08, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes a problem with a missing symbol __sync_synchronize
>> which happens when newlib is used together with libstdc++ for
>> the non-thread
Ping...
I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557886.html
Thanks
Bernd.
On 11/3/20 4:08 PM, Bernd Edlinger wrote:
> Hi,
>
> this fixes a problem with a missing symbol __sync_synchronize
> which happens when newlib is used toge
17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 2 Nov 2020 11:43:44 +0100
Subject: [PATCH] libgcc: Add a weak stub for __sync_synchronize
This patch adds a default implementation for __sync_synchronize,
which prevents many unresolved symbol errors on arm-none-eabi.
This happens often in C
= array_size;
This happened due to a merge conflict a long time ago.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
I think this qualifies as obvious, so I will commit it now.
Thanks
Bernd.
From 48a85b06992e4d915f29998f8db96ec2a019ea16 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Dat
On 11/3/20 11:16 AM, Richard Biener wrote:
> On Tue, 3 Nov 2020, Bernd Edlinger wrote:
>
>>
>>
>> On 11/3/20 10:34 AM, Richard Biener wrote:
>>> On Mon, 2 Nov 2020, Bernd Edlinger wrote:
>>>
>>>> On 11/2/20 3:07 PM, Richard Biener
1 - 100 of 1395 matches
Mail list logo
