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
>&
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
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
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 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
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.
>
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/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
>>&
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
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
'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/
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
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/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/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/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/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 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: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
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 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/
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'
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
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
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:
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'
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
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
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 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
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 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 i686-pc-linux-gnu.
Regards
Bernd Edlinger2013-08-20 Bernd Edlinger
PR tree-optimization/58137
Fixed vectorized pointer arithmentic in constant folding at forwprop.
Improved checks in verify_gimple_in_cfg: MINUS_EXPR with pointer vect
PING!
This issue is really important. It does not only affect bitfields but all kinds
of packed structures.
Starting from gcc 4.6.0 there is not a single released version that handles the
packed structures
correctly.
So could some one please approve Sandra's patch now?
Thanks
Bernd.
by
adding -fno-strict-overflow. The test case looks pretty constructed anyway.
The patch was boot-strapped and regression tested on i686-pc-linux-gnu and
X86_64-linux-gnu
OK for trunk?
Regards
Bernd Edlinger2013-08-28 Bernd Edlinger
PR tree-op
On Thu, 29 Aug 2013 11:54:22, Richard Biener wrote:
> On Wed, Aug 28, 2013 at 11:24 PM, Bernd Edlinger
> wrote:
>> The lim pass (aka loop invariant motion) can move conditional expressions
>> with
>> possible undefined behavior out of the if statement inside a loop
Index: ChangeLog
===
--- ChangeLog (revision 202117)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2013-08-30 Bernd Edlinger
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
2013-08-27 David Malcolm
On Fri, 30 Aug 2013 11:47:21, Richard Biener wrote:
> On Tue, Jul 2, 2013 at 7:33 PM, DJ Delorie wrote:
>>
>>> The choice appears to be to continue to have broken volatile bitfields
>>> on ARM with no way for users to make them conform to the ABI, or to
>>> change things so that they conform to th
On Fri, 30 Aug 2013 12:34:51 Richard Biener wrote:
> On Tue, Aug 20, 2013 at 1:01 PM, Bernd Edlinger
> wrote:
>> This patch fixes a bug in the vectorized pointer arithmetic in the forwprop
>> optimization pass.
>>
>> Although it seems to be impossible to create
ependent of the target platform.
Regards
Bernd Edlinger 2013-09-03 Bernd Edlinger
Implement -Wportable-volatility warning to warn about
code which accesses volatile structure members for
which different ABI specifications exist.
On Mon, 2 Sep 2013 12:56:22 Sandra Loosemore wrote:
>
> On 09/02/2013 03:10 AM, Richard Biener wrote:
>> Can someone, in a new thread, ping the patches that are still in
>> flight? ISTR having approved bits of some patches before my leave.
>
> Here's the current state of the patch set I put togethe
On Tue, 3 Sep 2013 10:30:22, Richard Biener wrote:
> On Mon, Sep 2, 2013 at 6:05 PM, Joseph S. Myers
> wrote:
>> On Mon, 2 Sep 2013, Richard Earnshaw wrote:
>>
>>> On 01/09/13 14:10, Bernd Edlinger wrote:
>>>> IMHO the AAPCS forbids packed structures. Th
On Tue, 3 Sep 2013 10:53:10, Richard Biener wrote:
> On Tue, Sep 3, 2013 at 2:05 AM, Bernd Edlinger
> wrote:
>> This is a follow-up patch for Sandra Loosemore's patch in this
>> thread: "reimplement -fstrict-volatile-bitfields, v3".
>> It was already p
On Tue, 3 Sep 2013 21:20:04, Joseph S. Myers wrote:
> On Tue, 3 Sep 2013, Bernd Edlinger wrote:
>
>>>> The trouble is that AAPCS semantics are incompatible with the default GNU
>>>> semantics for non-packed structures as well - AAPCS
>>>> strict-volatile
On Wed, 4 Sep 2013 09:29:02, DJ Delorie wrote:
>
>> I fully agree with you, the current default state of
>> -fstrict-volatile-bitfields should be disabled for all targets.
>
> Please don't do that until gcc produces code that does the same
> things. Most of my targets rely on gcc not doing the old
On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
> On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
> wrote:
>> Now I think this is good opportunity for a simple heuristic:
>>
>> If a statement is at loop level 1 we can move it out of the loop,
>> regardless o
assocate_pointerplus.
This way we get exactly the same code as before. It may be even possible
that this constant folding can improve something with scalars.
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
OK for trunk?
Bernd.2013-09-05 Ber
On Thu, 5 Sep 2013 12:25:08, Richard Biener wrote:
> On Thu, Sep 5, 2013 at 11:43 AM, Bernd Edlinger
> wrote:
>>
>> this would cause an ICE in test case 2629-1.c...
>
> Well, that's easily fixable.
>
>> So removing the pointer of vectors is not an op
On Wed, 4 Sep 2013 19:48:13, Hans-Peter Nilsson wrote:
> On Tue, 3 Sep 2013, Richard Biener wrote:
>> I think the warning can be completely implemented inside struct-layout.c
>> for example in finish_bitfield_representative (if you pass that the first
>> field
>> in the group, too). Of course that
4.8 / 4.7 branch?
Regards
Bernd Edlinger2013-09-06 Bernd Edlinger
PR middle-end/57748
* expr.c (expand_assignment): Check for out of bounds
access to structures.
testsuite:
* gcc.dg/torture/pr57748-1.c: New test
Just for completeness, these were the test examples on
this private communication:
On Fri, 6 Sep 2013 11:19:18, Richard Biener wrote:
> On Fri, Sep 6, 2013 at 10:35 AM, Bernd Edlinger
> wrote:
>> Richard,
>>
>>> But the movmisalign path skips all this code and with
arget-dependent, if there will be a movmisalign optab at all.
And the original test case will no longer reproduce on trunk because of this
change:
2013-08-08 Bernd Edlinger
PR target/58065
* config/arm/arm.h (MALLOC_ABI_ALIGNMENT): Define.
maybe we should first backport this one.
Yeste
On Tue, 10 Sep 2013 21:32:29, Martin Jambor wrote:
> Hi,
>
> On Fri, Sep 06, 2013 at 11:19:18AM +0200, Richard Biener wrote:
>> On Fri, Sep 6, 2013 at 10:35 AM, Bernd Edlinger
>> wrote:
>>> Richard,
>>>
>>>> But the movmisalign path skips all
On Wed, 11 Sep 2013 15:43:53, Richard Biener wrote:
> On Wed, Sep 11, 2013 at 3:41 PM, Bernd Edlinger
> wrote:
>> On Tue, 10 Sep 2013 21:32:29, Martin Jambor wrote:
>>> The misalignp path was added by you during the 4.7 development to fix
>>> PR 50444 which was i
>> While it is straight forward to remove the movmisalign path in 4.9 and 4.8,
>> this is not so simple in the 4.7 branch. The reason is that 4.7 uses
>> "to_rtx = expand_normal (tem);" while 4.8 and 4.9 use
>> "to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);"
>> which does almost the
, but there were none.
OK for trunk?
Regards
Bernd.2013-09-15 Bernd Edlinger
PR middle-end/57748
* expr.c (expand_assignment): Remove misalignp code path.
Check for bitregion in offset arithmetic.
(expand_expr_real_1): Use
ping...
On Wed, 4 Sep 2013 18:45:39, Bernd Edlinger wrote:
>
> On Tue, 3 Sep 2013 12:31:50, Richard Biener wrote:
>> On Fri, Aug 30, 2013 at 6:43 PM, Bernd Edlinger
>> wrote:
>>> Now I think this is good opportunity for a simple heuristic:
>>>
>>> If
-tested without any problems
on x86_64-unknown-linux-gnu.
OK for trunk?
Regards,
Bernd Edlinger2013-09-17 Bernd Edlinger
PR ipa/58398
* cgraph.c (cgraph_function_body_availability): Check for ifunc
attribute, and don't inline the res
Hi Martin,
On Tue, 17 Sep 2013 01:09:45, Martin Jambor wrote:
> Hi,
>
> On Sun, Sep 15, 2013 at 06:55:17PM +0200, Bernd Edlinger wrote:
>> Hello Richard,
>>
>> attached is my second attempt at fixing PR 57748. This time the
>> movmisalign path is completely remo
On Tue, 17 Sep 2013 12:45:40, Richard Biener wrote:
>
> On Tue, Sep 17, 2013 at 12:00 PM, Richard Biener
> wrote:
>> On Sun, Sep 15, 2013 at 6:55 PM, Bernd Edlinger
>> wrote:
>>> Hello Richard,
>>>
>>> attached is my second attempt at fixing
Bernd.2013-09-24 Bernd Edlinger
PR middle-end/57748
* expr.c (expand_expr_real_1): Use EXAND_MEMORY on base object.
testsuite/
PR middle-end/57748
* gcc.dg/torture/pr57748-3.c: New test.
patch-pr57748-2.diff
Description: B
d I apply this one after regression testing?
>
> It seems you already have...?
>
> Richard.
>
yes, did I misunderstand this message?
--- Comment #40 from rguenther at suse dot de ---
On Wed, 18 Sep 2013, bernd.edlinger at hotmail dot de wrote:
> http://gcc.gnu.org/bugzilla/
Hmm.,
On Tue, 24 Sep 2013 20:06:51, Martin Jambor wrote:
> Hi,
>
> On Tue, Sep 24, 2013 at 12:02:17PM +0200, Richard Biener wrote:
>> On Tue, Sep 24, 2013 at 4:52 AM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
>>> with the attached patch the read-s
Hi Sandra,
thanks a lot, your comments are very welcome, especially as I am
not a native english speaker...
On Tue, 24 Sep 2013 15:46:22, Sandra Loosemore wrote:
>
> I have some nit-picky documentation suggestions about this patch
>
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00100.html
>
case usually
fails it still tests something with this patch.
Ok for trunk?
Regards
Bernd Edlinger2013-09-25 Bernd Edlinger
PR fortran/58113
* gfortran.dg/round_4.f90: Check for rounding support.
--- gcc/testsuite/gfortran.dg/round_4.f90
ener wrote:
>>>> On Tue, Sep 24, 2013 at 4:52 AM, Bernd Edlinger
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> with the attached patch the read-side of the out of bounds accesses are
>>>>> fixed.
>>>>> There
On Wed, 25 Sep 2013 21:00:33, Tobias Burnus wrote:
>
> Bernd Edlinger wrote:
>> this test case fails very often, and the reason is not in GCC but
>> in a missing glibc rounding support for strtod.
>>
>> This patch fixes the test case, to first determine if the
&g
Hi,
On Thu, 26 Sep 2013 11:34:02, Eric Botcazou wrote:
>
>> So I still think my patch does the right thing.
>>
>> The rationale is:
>>
>> = expand_expr (tem,
>> (TREE_CODE (TREE_TYPE (tem)) == UNION_TYPE
>> && COMPLETE_TYPE_P (TREE_TYPE (tem))
>> && (TREE_CODE (TYPE_SIZE (TREE_TYPE (tem)))
>> != I
REF and VIEW_CONVERT_EXPR know how to handle
EXPAND_REFERENCE, anything else handles it like EXPAND_NORMAL.
OK, what do you think of it now?
Thanks
Bernd.2013-10-03 Bernd Edlinger
PR middle-end/57748
* expr.h (expand_modifier): New en
Ping!
How I should proceed with this patch, is it OK?
The latest version was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html
Thanks,
Bernd.
>
> ping...
>
> On Wed, 4 Sep 2013 18:45:39, Bernd Edlinger wrote:
>>
>> On Tue, 3 Sep 2013 12:31:50, Rich
Hi,
On Tue, 8 Oct 2013 10:01:37, Eric Botcazou wrote:
>
>> OK, what do you think of it now?
>
> My take on this is that the Proper Fix(tm) has been posted by Martin:
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00082.html
> IMO it's a no-brainer, modulo the ABI concern. Everything else is more o
Hi,
On Tue, 8 Oct 2013 22:50:21, Eric Botcazou wrote:
>
>> I agree, that assigning a non-BLKmode to structures with zero-sized arrays
>> should be considered a bug.
>
> Fine, then let's apply Martin's patch, on mainline at least.
>
That would definitely be a good move. Maybe someone should approv
Hi,
On Mon, 30 Sep 2013 16:18:30, DJ Delorie wrote:
>
> As per my previous comments on this patch, I will not approve the
> changes to the m32c backend, as they will cause real bugs in real
> hardware, and violate the hardware's ABI. The user may use
> -fno-strict-volatile-bitfields if they do not
Hi,
>> That would definitely be a good move. Maybe someone should approve it?
>
> Yes, but I agree that we ought to restrict it to trailing zero-sized arrays.
> That would help to allay Jakub's concerns about possible ABI fallouts.
>
> --
> Eric Botcazou
Other uses of zero-sized arrays in structu
Hi Eric,
>> Would you agree that this "error: flexible array member"
>> should also be emitted for a zero-sized array member,
>> maybe as "error: zero-sized array member not at end of struct"?
>
> I would have answered yes when zero-sized arrays where introduced, but it's
> far less clear a couple
Hi,
On Tue, 15 Oct 2013 15:57:16, Richard Biener wrote:
>
> This is an alternate fix (see
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html for the other
> one) for the various PRs that show that LIM exposes undefined
> signed overflow on paths where it wasn't executed before LIM
> ultimat
X x;
> x.x = 1;
>
> a volatile bitifled access?
>
> I think the warning can be completely implemented inside struct-layout.c
> for example in finish_bitfield_representative (if you pass that the first
> field
> in the group, too). Of course that is at the expense of warning
On Wed, 16 Oct 2013 22:50:20, DJ Delorie wrote:
> Not all of them can work, because they describe something that can't
> be done in hardware. For example, the first test has an incomplete
> bitfield - the fields do not completely describe an "int" so the
> structure is smaller (one byte, according
Hello,
this is a simple test that makes the follwing test cases pass:
because the messages are translated to german,
which the test scripts compare against english messages.
Tested on german ubuntu 12.04.
OK for trunk?
Regards
Bernd.2013-10-17 Bernd
Hi,
On Thu, 17 Oct 2013 16:41:13, DJ Delorie wrote:
> I'm starting from an MCU that doesn't work right if GCC doesn't do
> what the user tells GCC to do. I added -fstrict-volatile-bitfields to
> tell gcc that it needs to be more strict than the standard allows for
> bitfield access, because withou
2013-10-18 Bernd Edlinger
Fix volatile issues in optimize_bit_field_compare.
* fold-const.c (optimize_bit_field_compare): Bail out if
lvolatilep or rvolatilep.
patch-bitfield-compare.diff
Description: Binary data
Hi,
On Fri, 18 Oct 2013 14:06:57, Richard Biener wrote:
>
> On Fri, Oct 18, 2013 at 1:56 PM, Bernd Edlinger
> wrote:
>> Hello Richard,
>>
>> I see it the same way.
>>
>> The existing code in optimize_bit_field_compare looks wrong. It is very
>&
Hi,
>> What I would suggest is to have a -fgnu-strict-volatile-bit-fields
>
> Why a new option? The -fstrict-volatile-bitfields option is already
> GCC-specific, and I think it can do what you want anyway.
As I understand Richard's comment, he proposes to
have an option for true AAPCS compliance,
Hello,
this patch removes the dependency of DECL_BIT_FIELD on the
flag_strict_volatile_bitfields,
and makes get_inner_reference not returning a different mode for non-volatile
members
if flag_strict-volatile_bitfields is used.
This fixes the regression on the SH-target, due to the patch "Fix as
nd regression-tested on x86_64-linux-gnu.
>
> Ok for trunk?
>
> Bernd. 2013-10-21 Bernd Edlinger
Fix DECL_BIT_FIELD depencency on flag_strict_volatile_bitfields
and get_inner_reference returning different pmode for non-volatile
Hi,
On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
> Hr. After some further testing, I'm afraid this patch is still
> buggy. :-(
>
> I tried a backport to GCC 4.8 and tested on arm-none-eabi. On the new
> pr56997-1.c testcase, it got stuck in infinite recursion between
> store_split_bit
>
>> have an option for true AAPCS compliance, which will
>> be allowed to break the C++11 memory model and
>
>> And an option that addresses your requirements,
>> which will _not_ break the C++11 memory model
>
> So the problem isn't that what *I* need conflicts with C++11, it's
> that what AAPCS
Well,
one more point where the current patch is probably wrong:
the AAPCS states that for volatile bit-field access:
"For a write operation the read must always occur even if the entire contents
of the container will be replaced"
that means
struct s
{
volatile int a:32;
} ss;
ss.a=1; //nee
executes this code path.
Therefore I updated Martin's previous patch, to meet Eric's request:
That is to only handle zero-sized arrays at the end of the structure.
Boot-strapped and regression-tested on x86_64-linux-gnu.
Ok for trunk?
Regards
Bernd. 201
Hi,
On Tue, 17 Sep 2013 01:09:45, Martin Jambor wrote:
>> @@ -4773,6 +4738,8 @@ expand_assignment (tree to, tree from, b
>> if (MEM_P (to_rtx)
>> && GET_MODE (to_rtx) == BLKmode
>> && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode
>> + && bitregion_start == 0
>> +
Hi Richard/Joseph,
I noticed, this test case crashes on arm-eabi already witout the patch.
extern void abort (void);
#define test_type unsigned short
#define MAGIC (unsigned short)0x102u
typedef struct s{
unsigned char Prefix[1];
test_type Type;
}__attribute((__packed__,__aligned__(4))) ss;
Hi,
On Wed, 23 Oct 2013 14:37:43, Richard Biener wrote:
> The C++ memory model says that you may not introduce a data-race
> and thus you have to access Type without touching Prefix.
Thanks.
Right now I see the following priorities:
1. make -fno-strict-volatile-bitfields respect the C++ memory
On, Wed, 23 Oct 2013 17:36:41Richard Biener wrote:
>
> if bitregion_start/end are used after the adjust_address call then they have
> to be adjusted (or bitpos left in place). In fact why we apply byte-parts of
> bitpos here only if offset != 0 is weird. OTOH this code is _very_ old...
> what happe
Hi Martin,
On Wed, 23 Oct 2013 19:11:06, Martin Jambor wrote:
> On Wed, Oct 23, 2013 at 06:00:43PM +0200, Richard Biener wrote:
>>
>
> ...
>
>> ? And why should the same issue not exist for
>>
>> struct { V a[1]; }
>>
>
> indeed, it does and it's simple to trigger (on x86_64):
>
>
>> I think that is common practice to write array[1]; at the end of the
>> structure, and use it as a flexible array. The compute_record_mode has no
>> way to decide if that is going to be a flexible array or not.
>>
>> Sorry Eric, but now I have no other choice than to go back to my previous
>> ve
Hi,
On Thu, 24 Oct 2013 11:56:52, Richard Biener wrote:
>
> On Thu, Oct 24, 2013 at 10:37 AM, Eric Botcazou wrote:
>>> if bitregion_start/end are used after the adjust_address call then they have
>>> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
>>> of bitpos here only
101 - 200 of 1395 matches
Mail list logo
