Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
>> Isn't the actual invocation of the build-g++ also including
>> /sysroot_for_host/include
>> in that case? Why doesn't this cause problems then?
>
> Yes, and that causes failures too. BUILD_CPPFLAGS is
>
> Jakub Jelinek wrote:
>>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>>> Of course, IMO, the cleanest fix would be to use switchable targets
>>> for i386...
>>
>>We IMHO want that anyway, e.g. #pragma omp declare simd tests take eons
>>to
>>compile because even with just a
On Mon, 6 Jan 2014 19:16:57, Richard Saniford wrote:
>
> Bernd Edlinger writes:
>>>
>>> Jakub Jelinek wrote:
>>>>On Mon, Jan 06, 2014 at 10:27:06AM +, Richard Sandiford wrote:
>>>>> Of course, IMO, the cleanest fix would be to use switcha
can we proceed?
Regards
Bernd.
>>
>> On Thu, Dec 19, 2013 at 11:50:02AM +0100, Bernd Edlinger wrote:
>>> Isn't the actual invocation of the build-g++ also including
>>> /sysroot_for_host/include
>>> in that case? Why doesn't this cause probl
Hello,
Ping...
We still need a decision how to fix this.
There are two alternative patches:
1. My latest proposal: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01675.html
2. Eric's latest proposal:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01667.html
Thanks
Bernd.
Hi,
On Tue, 7 Jan 2014 15:10:20, Richard Biener wrote:
>
> On Tue, Jan 7, 2014 at 1:12 PM, Richard Sandiford
> wrote:
>> Bernd Edlinger writes:
>>>> How about this patch for the big comment?
>>>>
>>>
>>> The comment should say that ta
On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote:
>
> On Thu, Jan 09, 2014 at 09:02:28AM +, Richard Sandiford wrote:
>>> I think Jakub's patch will fix this case, but I did not try.
>>> However even if the i368 is now clean, there are
>>> still many targets that use target_reinit() in
>>> targe
Hello,
and Ping for this patch:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01552.html
note however, that cross-building is probably broken
anyway in the moment by r205690,
Thanks
Bernd.
> there is a small problem with SSIZE_MAX, because it is not always
> defined, especially not in gcc/gli
Hi Jakub,
The test cases gcc.dg/vect/vect-simd-clone-10.c and
gcc.dg/vect/vect-simd-clone-12.c keep failing on my i686-pc. I do not really
understand why. The problem seem to be the command line to xgcc has
-S and -o and two .c files, probably the test case is not supported at all
on this target,
On Sun, 12 Jan 2014 12:01:43, Jakub Jelinek wrote:
>
> On Sun, Jan 12, 2014 at 10:53:58AM +0100, Bernd Edlinger wrote:
>> The test cases gcc.dg/vect/vect-simd-clone-10.c and
>> gcc.dg/vect/vect-simd-clone-12.c keep failing on my i686-pc. I do not really
>> understand why
Hello,
there is another test case, that misses the necessary check_vect() runtime
check.
Tested on i686-pc-linux-gnu.
OK for trunk?
Regards
Bernd.
patch-vect-nop-move.diff
Description: Binary data
-64-linux-gnu.
OK for trunk?
Thanks
Bernd.
2015-07-22 Bernd Edlinger
* tree-pass.h (get_current_pass_name): Removed.
patch-tree-pass.diff
Description: Binary data
Hi,
On Thu, 17 Sep 2015 10:39:04, Jeff Law wrote:
>
> On 09/17/2015 09:00 AM, Marek Polacek wrote:
>> On Wed, Sep 09, 2015 at 07:48:15PM +0200, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> On Wed, 9 Sep 2015 09:31:33, Jeff Law wrote:
>>>> You co
regression-tested
on x86_64-pc-linux-gnu and arm-linux-gnueabihf.
OK for trunk?
Thanks
Bernd.
gcc:
2015-09-30 Bernd Edlinger
PR rtl-optimization/67037
* lra-constraints.c (process_addr_reg): Use copy_rtx when necessary.
testsuite:
2015-09-30
Hi,
actually I do not quite understand why we need a TYPE_ALIGN_OK flag that is
only used in Ada.
Somehow other languages seem to have no problem of that kind.
You remember, when I removed the TYPE_ALIGN_OK handing (initially it wasn't
clear to me that
it's entire use is only to make Ada happy)
/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 228444)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,7 @@
+2015-10-03 Bernd Edlinger
+
+ * gcc.target/arm/pr67756.c: Fixed warnings.
+
2015-10-02 Mar
Hi,
On Fri, 2 Oct 2015 23:31:09, Eric Botcazou wrote:
>
> It's related to a known difficulty with alignment and inheritance, and other
> languages are affected by variant of it, see e.g. PR c++/37798.
>
I doubt that this is still an issue with the current trunk.
I tried the test case from the pr
difference at
all.
So I would kindly ask, if you could give this patch a test on your SPARC
platforms?
Thanks
Bernd.
2015-10-05 Bernd Edlinger
Convert TYPE_ALIGN_OK to a TYPE_LANG_FLAG.
* tree.h (TYPE_ALIGN_OK): Remove
Hi,
I have boot-strapped & reg-tested this patch now
on arm-linux-gnueabihf with all languages enabled.
Is it OK for the gcc-5-branch?
Thanks
Bernd.gcc:
2015-11-26 Bernd Edlinger
Backport from mainline
2015-09-30 Bernd Edlinger
PR rtl-optimization/6
Hi,
On Tue, 17 Nov 2015 14:31:29, Jeff Law wrote:
> The benefit is traditional asms do the expected thing. With no way to
> describe dataflow, the only rational behaviour for a traditional asm is that
> it has to be considered a
use/clobber of memory and hard registers.
I'd like to mention he
on x86_64-pc-linux-gnu,
OK for trunk?
Thanks
Bernd.2015-12-06 Bernd Edlinger
* ipa-icf-gimple.c (func_checker::compare_gimple_asm): Fix check for
basic asm.
Index: gcc/ipa-icf-gimple.c
===
--- gcc/ipa-icf-gimple.c (revision 23
object to check is PATTERN (inner_insn).
Boot-strapped and reg-tested on x86_64-pc-linux-gnu,
OK for trunk?
Thanks
Bernd.2015-12-06 Bernd Edlinger
* final.c (shorten_branches): Fix check for basic asm.
Index: gcc/final.c
*&saved_cw));
}
return ret;
So this patch avoids the hidden data flow, and
adds "st" to the clobber list.
Boot-strapped and reg-tested on x86_64-pc-linux-gnu
OK for trunk?
Thanks
Bernd.2015-12-08 Bernd Edlinger
* gcc.target/i386/sse4_1-round.h: Fix inline asm statements.
*
Hi,
Am 08.12.2015 um 19:23 schrieb Uros Bizjak:
> On Tue, Dec 8, 2015 at 7:10 PM, Uros Bizjak wrote:
>> Hello!
>>
>>> this patch fixes the asm statements in the gcc.target/i386/sse4_1-round*
>>> test cases.
>>>
>>> They do lots of things that are just absolutely forbidden, like clobber
>>> regi
ng code.
It was boot-strapped and regression-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
... or should I wait for the next stage1?
Thanks
Bernd.gcc:
2015-12-09 Bernd Edlinger
PR c/24414
* cfgexpand.c (expand_asm_loc): Remove handling for ADDR_EXPR.
Implicitl
Hi,
On 09.12.2015 12:06 Bernd Schmidt wrote:
> On 12/09/2015 03:18 AM, Bernd Edlinger wrote:
>> Furthermore there is a documented use for asm(""): The empty
>> assembler string is used to make a function
>> volatile, thus calls can not be optimized away. But I t
Hi,
On 09.12.2015 16:48 Bernd Schmidt wrote:
> On 12/09/2015 04:09 PM, Bernd Edlinger wrote:
>
>> So would you agree on the general direction of the patch,
>> if I drop the hunk in sched-deps.c ?
>
> I'm not sure there was any consensus in that other thread, but I
.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk.
Thanks
Bernd.
From 0fc0c1453c59eb8709d56f7d817caa111eb6eeb7 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Fix -save-temp leaking files in /tmp
And avoid signal handler calling
dd98fe7c45c5096dfab9425dce6e0f88f5ccdcbe Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink
with uninitialized memory
2020-02-19 Bernd Edlinger
* collect2.c (tool_cleanup): Avoid calling not signal
On 2/19/20 6:36 PM, Bernhard Reutner-Fischer wrote:
> Bernd,
>
> On 18 February 2020 18:12:21 CET, Bernd Edlinger
> wrote:
>> Hi,
>
> +is not allocatted with calloc. */
>
> s/tt/t/
>
Thanks yes,
fixed as obvious:
commit fd136f018e6d64bff08b7
-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
From d6dc826c63dc881fe41dbf0c3a461008afdef8b3 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 17 Feb 2020 17:40:07 +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. They w
On 2/20/20 2:34 PM, Richard Biener wrote:
> On Thu, 20 Feb 2020, Bernd Edlinger wrote:
>
>> Hi,
>>
>> this is the remaining issue that happens when -flto and -save-temps
>> is used together, it leaks several files in /tmp.
>>
>> I try to give more backgro
me of those files are probably also from mkoffload etc.
> See below.
>
> On 2/20/20 4:33 PM, Bernd Edlinger wrote:
>
>> On 2/20/20 2:34 PM, Richard Biener wrote:
>>> I don't think this is an improvement. The files still
>>> will be (correctly) retained and now i
;
not debug = false, to match the different logic in maybe_unlink.
Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
Is it OK for the gcc-9 branch?
Thanks
Bernd.
From d52ac2c0394f0432e183511f8a6d4f96b49f88a5 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Mon, 17 Feb 2020 17:40:07 +0100
Hi,
I am pinging this because PR 91614 has been raised to P2 now:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
Thanks
Bernd.
On 9/6/19 2:12 PM, Bernd Edlinger wrote:
> On 9/5/19 5:55 PM, Richard Earnshaw (lists) wrote:
>> On 03/09/2019 21:45, Bernd Edlinger wrot
On 4/22/20 8:20 PM, Jeff Law wrote:
> On Thu, 2020-03-26 at 04:23 +0100, Bernd Edlinger wrote:
>> Hi,
>>
>> I am pinging this because PR 91614 has been raised to P2 now:
>> https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00370.html
> It's been nearly a
Hi Oleg,
I think both variants should fix the issues for us.
But I cannot tell if the bitfield access generates
more efficient code or identical code than the
original variant when no ms bitfields are used.
That needs closer inspection of the generated
assembler code, a simple bootstrap / regtest
Hi,
I am currently trying to implement -Wshadow=local, and
this patch triggers a build-failure with -Wshadow=local
since i is a parameter that is the regno.
But it is also used as loop variable,
so I think this introduces probably a bug:
> @@ -728,7 +731,11 @@ globalize_reg (tree decl, int i)
>
On 9/13/19 12:16 PM, Janne Blomqvist wrote:
> On Fri, Sep 13, 2019 at 1:07 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> this fixes a test case where a short string constant is put in a larger
>> memory object.
>>
>> The consistency check in va
Hi,
I've noticed that the documentation of -Wshadow=x has some
missing bits, and I want to add an negative example to
-Wshadow=compatble-local.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* doc/invoke.texi (-Ws
Hi,
this adds -Wshadow=local to the GCC build rules.
It is to be applied after all other patches in this series
including the trivial ones are applied.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* configure.ac
use templates instead. Since the 7-argument overload is not
used anywhere removed RTL_FLAG_CHECK7 for now.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* rtl.h (RTL_FLAG_CHECK): New variadic macro.
(RTL_FLAG_CHECK1-6
gimple_assign)
def -> _c%d (if gimple_call)
def_stmt -> _d%d
leaving res_ops, res_op, capture for later, since they are not likely to
be used in .md files.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* genmatch.c (
variable in ipa_write_summaries can simply be
removed sine the outer variable of the same name has the
same type and is not live here, this is a trivial change.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* passes.c
name.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* cgraph.h (FOR_EACH_ALIAS): Avoid shadowing the loop variable.
Index: gcc/cgraph.h
===
--- gcc/cgraph.h
and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* dumpfile.h (AUTO_DUMP_SCOPE): Use XCONCAT2 and __LINE__
to form a unique name for the scope variable.
Index: gcc/dumpfile.h
Bernd Edlinger
* hash-table.h (hash_table::empty_slow): Don't assign
size_t values to int variables.
Index: gcc/hash-table.h
===
--- gcc/hash-table.h (revision 276484)
+++ gcc/hash-table.h (working copy)
@@ -842,9 +
always have the same alignment
as the complex itself, but I have not checked that.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* expr.c (convert_mode_scalar): Remove shadowing local var.
(emit_block_move): Rename local vars
this on my behalf?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* gofrontend/ast-dump.cc
(Ast_dump_traverse_blocks_and_functions::function): Remove shadowing
local var.
* gofrontend/escape.cc (Escape_analysis_assign::expression): Likewise.
* gofrontend/expressions.cc
as obvious.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-03 Bernd Edlinger
* primary.c (match_real_constant): Remove shadowing local vars.
Rename local vars. Fix undefined behavior in loop termination.
(gfc_convert_to_structure_constructor)
On 10/3/19 5:25 PM, Jakub Jelinek wrote:
> On Thu, Oct 03, 2019 at 03:17:47PM +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros,
>> which happen when this macro is used recursively in a macro
>> argument.
On 10/4/19 12:43 PM, Richard Biener wrote:
> On Thu, Oct 3, 2019 at 5:17 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> this adds -Wshadow=local to the GCC build rules.
>>
>> It is to be applied after all other patches in this series
>> including the
On 10/4/19 12:54 PM, Richard Biener wrote:
> On Thu, Oct 3, 2019 at 5:18 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> this fixes -Wshadow=local warnings in genmatch.c itself and in generated
>> files as well.
>>
>> The non-trivial part of this patch
On 10/4/19 2:38 PM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> Hi,
>>
>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros,
>> which happen when this macro is used recursively in a macro
>> argument. The __typeof (RTX) const _rtx in the
On 10/4/19 2:16 PM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> Hi,
>>
>> this fixes a -Wshadow=local warning when using AUTO_DUMP_SCOPE in
>> nested blocks. Since NAME i a string I cannot use it to create
>> a unique name for the auto_dump_scope obje
On 10/4/19 7:09 PM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>>
>> Actually I wanted to do it with a template, and invoke it using
>> __typeof(RTX).
>>
>> BUT with that I ran into a lmitation of the template vs. block statements
>> See PR#91803:
Hi,
these macros don't use reserved names for local variables.
This caused -Wshadow=local warnings in varasm.c IIRC.
Fixed by using _lowercase reserved names for macro parameters.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-04
Hi,
this macro caused -Wshadow=local warnings in varasm.c with
the microblaze target.
Only built a bare metal cross compiler that was able to compile
libgcc for that target.
Is it OK for trunk?
Thanks
Bernd.
2019-10-04 Bernd Edlinger
* defaults.h (ASM_OUTPUT_ASCII): Rename local vars
OK for trunk?
Thanks
Bernd.
2019-10-04 Bernd Edlinger
* genautomata.c (REGEXP_UNIT, REGEXP_RESERV, REGEXP_SEQUENCE,
REGEXP_REPEAT, REGEXP_ALLOF, REGEXP_ONEOF): Rename local vars.
Index: gcc/genautomata.c
===
--- gcc
On 10/3/19 5:25 PM, Jakub Jelinek wrote:
> On Thu, Oct 03, 2019 at 03:17:47PM +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros,
>> which happen when this macro is used recursively in a macro
>> argument.
On 10/4/19 10:26 AM, Segher Boessenkool wrote:
> On Thu, Oct 03, 2019 at 05:25:55PM +0200, Jakub Jelinek wrote:
>> On Thu, Oct 03, 2019 at 03:17:47PM +0000, Bernd Edlinger wrote:
>>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros,
>>> which hap
On 10/4/19 10:23 PM, Jeff Law wrote:
> On 10/4/19 12:24 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> this macro caused -Wshadow=local warnings in varasm.c with
>> the microblaze target.
>>
>>
>> Only built a bare metal cross compiler that was able to compile
On 10/4/19 10:26 PM, Jeff Law wrote:
> On 10/4/19 12:24 PM, Bernd Edlinger wrote:
>> Hi,
>>
>> these macros don't use reserved names for local variables.
>> This caused -Wshadow=local warnings in varasm.c IIRC.
>>
>> Fixed by using _l
before monday,
to give you all a chance to look at the changes, and request
changes, if you like, for instance better variable names or so.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Thanks
Bernd.
2019-10-05 Bernd Edlinger
* asan.c (asan_emit_stack_protection,
asan_expand_check_ifn
.
Thanks
Bernd.
2019-10-05 Bernd Edlinger
* df-problems.c (df_rd_transfer_function): Remove shadowing local vars.
(df_word_lr_local_compute, df_md_local_compute): Rename local var.
* df-scan.c (df_insn_rescan): Remove shadowing local var.
* diagnostic-show-locus.c (layout::print_leading_fixits
On 10/5/19 9:26 AM, Segher Boessenkool wrote:
> On Fri, Oct 04, 2019 at 02:26:26PM -0600, Jeff Law wrote:
>> Same objections as before. As long as we're using macros like this,
>> we're going to have increased potential for shadowing problems and
>> macros which touch implementation details that j
Hi Segher,
On 10/5/19 10:08 AM, Segher Boessenkool wrote:
> Hi Bernd,
>
> I'll just review the combine part.
>
> On Sat, Oct 05, 2019 at 06:36:34AM +, Bernd Edlinger wrote:
>> --- gcc/combine.c(revision 276598)
>> +++ gcc/combine.c(wor
On 10/5/19 8:24 PM, Segher Boessenkool wrote:
>
> I am maintainer of combine, I know all about its many problems (it has much
> deeper problems than this unfortunately). Thanks for your help though, this
> is much appreciated, but I do think your current patch is not a step in the
> right directi
On 10/5/19 9:24 AM, Jakub Jelinek wrote:
> On Sat, Oct 05, 2019 at 06:12:37AM +0000, Bernd Edlinger wrote:
>> On 10/3/19 5:25 PM, Jakub Jelinek wrote:
>>> What effect does this have on the cc1/cc1plus .text sizes?
>>
>> r276457:
>>
>> with patch, --enab
Hi Sandra,
On 10/6/19 10:23 PM, Sandra Loosemore wrote:
> On 10/3/19 9:16 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> I've noticed that the documentation of -Wshadow=x has some
>> missing bits, and I want to add an negative example to
>> -Wshadow=compatble-local
On 10/7/19 8:56 AM, Richard Biener wrote:
> On Sun, Oct 6, 2019 at 1:24 PM Bernd Edlinger
> wrote:
>>
>> On 10/5/19 8:24 PM, Segher Boessenkool wrote:
>>>
>>> I am maintainer of combine, I know all about its many problems (it has much
>>> deeper p
On 10/7/19 9:20 AM, Eric Botcazou wrote:
>> If this ends up acked then please add this to ansidecl.h or
>> somewhere else global as template:
>>
>> template
>> struct push {
>> push (T &);
>> ~push ();
>> T *m_loc;
>> T m_val;
>> };
>>
>> because it would be a general solution for _all_ sh
Hi,
this fixes a crash when -Wshadow=compatible-local is
enabled in the testcase g++.dg/parse/crash68.C
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
patch-pr92024.diff
Description: patch-pr92024.diff
On 10/10/19 7:49 PM, Jason Merrill wrote:
> On 10/10/19 10:42 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes a crash when -Wshadow=compatible-local is
>> enabled in the testcase g++.dg/parse/crash68.C
>
> Why does that flag cause this crash?
>
gcc/cp/n
ed as a boolean, i.e. pointer is NULL or not.
This changes the parameter vec_stmt to vec_stmt_p, and propagates that
change to can_vectorize_live_stmts.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-11 Bernd Edlinger
* tree-vect-loop.c (vect_ana
On 10/11/19 6:31 PM, Jason Merrill wrote:
> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>> On 10/10/19 7:49 PM, Jason Merrill wrote:
>>> On 10/10/19 10:42 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this fixes a crash when -Wshadow=compati
Hi David,
I just wanted to say that this does not work right on ubuntu 14.04 at least:
g++ -Wshadow=local -Wno-shadow=compatible-local -S Wshadow-1.c
Wshadow-1.c: In function 'void foo(int*, int*)':
Wshadow-1.c:8:9: warning: declaration of 'int d' shadows a parameter
[]8;;https://gcc.gnu.org/o
On 10/12/19 4:21 PM, David Malcolm wrote:
> On Sat, 2019-10-12 at 07:00 +0000, Bernd Edlinger wrote:
>> Hi David,
>>
>> I just wanted to say that this does not work right on ubuntu 14.04 at
>> least:
>>
>> g++ -Wshadow=local -Wno-shadow=compatible-l
On 10/11/19 6:31 PM, Jason Merrill wrote:
> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>> On 10/10/19 7:49 PM, Jason Merrill wrote:
>>> On 10/10/19 10:42 AM, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> this fixes a crash when -Wshadow=compati
Ping...
for the c++ FE and testsuite changes in the updated patch
here: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00916.html
Thanks
Bernd.
On 10/12/19 8:10 PM, Bernd Edlinger wrote:
> On 10/11/19 6:31 PM, Jason Merrill wrote:
>> On 10/10/19 2:06 PM, Bernd Edlinger wrote:
>&g
while with -fno-common, those variables are placed
in the .bss segment.
I believe the description is describing the "flag_no_common",
but that is not what the user needs to know.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-10-20 Bernd
n any optimization mode, since there
was no breakpoint at line 11, now the breakpoint works, but the variable
value is wrong, but basically this was not working before.
I don't know how to make this test xfail when compiled with optimization,
but the do-skip-if is probably good en
On 10/5/19 9:24 AM, Jakub Jelinek wrote:
> On Sat, Oct 05, 2019 at 06:12:37AM +0000, Bernd Edlinger wrote:
>> On 10/3/19 5:25 PM, Jakub Jelinek wrote:
>>> Does this affect debuggability of --enable-checking=yes,rtl compilers?
>>> I mean, often when we replace some macr
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.
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
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
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
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
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/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/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 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
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
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
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)]
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,
>>
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
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
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
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
301 - 400 of 1395 matches
Mail list logo
