On Thu, May 24, 2012 at 02:29:18PM +0200, Thomas Schwinge wrote:
> Hi!
>
> Ping.
Ok.
> > > * fold-const.c (optimize_bit_field_compare): Abort early in the strict
> > > volatile bitfields case.
> > >
> > > Index: fold-const.c
> > >
Hi!
Ping.
On Wed, 16 May 2012 19:14:45 +0200, I wrote:
> Ping.
>
> On Wed, 09 May 2012 10:01:55 +0800, I wrote:
> > On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek wrote:
> > > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > > > > GET_MODE_BITSIZE (lmode)« (8 bits). (W
Hi!
Ping.
On Wed, 09 May 2012 10:01:55 +0800, I wrote:
> On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek wrote:
> > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode
> > > > > is
> > > > > VOIDmode.
Hi!
On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek wrote:
> On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode is
> > > > VOIDmode.)
> > > >
> > > > Is emmitting »BIT_FIELD_REF <*common, 32, 0> & 255« w
On Fri, Apr 27, 2012 at 11:00:19AM +0200, Richard Guenther wrote:
> But won't it re-introduce bugs like PR52080, 52097 or 48124? Also the
No. All those are about bitfield stores, not reads. All extract_bit*
functions currently pass 0, 0 as bitrange_{start,end}.
> proper place for this optimiza
On Fri, Apr 27, 2012 at 10:29 AM, Jakub Jelinek wrote:
> On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
>> > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode is
>> > > VOIDmode.)
>> > >
>> > > Is emmitting »BIT_FIELD_REF <*common, 32, 0> & 255« wrong in thi
On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode is
> > > VOIDmode.)
> > >
> > > Is emmitting »BIT_FIELD_REF <*common, 32, 0> & 255« wrong in this case,
> > > or should a later optimization pass be able to f
Hi!
On Wed, 25 Apr 2012 13:51:16 +0200, Richard Guenther
wrote:
> On Wed, Apr 25, 2012 at 1:27 PM, Thomas Schwinge
> wrote:
> > On Thu, 19 Apr 2012 19:46:17 +0200, I wrote:
> >> Here is my current test case, reduced from gcc.dg/tree-ssa/20030922-1.c:
> >>
> >> extern void abort (void);
> >>
On Wed, Apr 25, 2012 at 1:27 PM, Thomas Schwinge
wrote:
> Hi!
>
> On Thu, 19 Apr 2012 19:46:17 +0200, I wrote:
>> Here is my current test case, reduced from gcc.dg/tree-ssa/20030922-1.c:
>>
>> extern void abort (void);
>>
>> enum tree_code
>> {
>> BIND_EXPR,
>> };
>> stru
Hi!
On Thu, 19 Apr 2012 19:46:17 +0200, I wrote:
> Here is my current test case, reduced from gcc.dg/tree-ssa/20030922-1.c:
>
> extern void abort (void);
>
> enum tree_code
> {
> BIND_EXPR,
> };
> struct tree_common
> {
> enum tree_code code:8;
> };
>
> -Original Message-
> From: Thomas Schwinge [mailto:tho...@codesourcery.com]
> Sent: Friday, April 20, 2012 01:46
> To: Bernd Schmidt; Richard Earnshaw
> Cc: Richard Guenther; Joey Ye; d...@redhat.com; GCC Patches; Mitchell,
> Mark
> Subject: Re: Continue strict-vol
Hi!
On Wed, 18 Apr 2012 18:16:32 +0200, Bernd Schmidt
wrote:
> On 04/18/2012 06:14 PM, Richard Earnshaw wrote:
> > On 18/04/12 16:37, Thomas Schwinge wrote:
> >> gcc/testsuite/
> >>* gcc.dg/tree-ssa/20030922-1.c: Compile with
> >>-fno-strict-volatile-bitfields.
> >>* gcc.dg/tree-ssa/
On 04/18/2012 06:14 PM, Richard Earnshaw wrote:
> On 18/04/12 16:37, Thomas Schwinge wrote:
>> gcc/testsuite/
>> * gcc.dg/tree-ssa/20030922-1.c: Compile with
>> -fno-strict-volatile-bitfields.
>> * gcc.dg/tree-ssa/foldconst-3.c: Likewise.
>> * gcc.dg/tree-ssa/vrp15.c: Likewise.
On 18/04/12 16:37, Thomas Schwinge wrote:
> Hi!
>
> As it's been some time: this was the discussion about
> -fstrict-volatile-bitfields (as enabled by default on SH, for example)
> breaking some testsuite bits due to missed optimizations (even for
> bitfields that are not volatile).
>
> On Tue, 2
Hi!
As it's been some time: this was the discussion about
-fstrict-volatile-bitfields (as enabled by default on SH, for example)
breaking some testsuite bits due to missed optimizations (even for
bitfields that are not volatile).
On Tue, 21 Feb 2012 09:40:07 +, Richard Earnshaw wrote:
> On 2
On 20/02/12 17:51, Bernd Schmidt wrote:
> On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
>> I'm not sure why it should be. Can't a user write
>>
>> #ifdef __cplusplus
>> #define BOOL bool
>> #else
>> #define bool _Bool
>> #endif
>>
>> struct x {
>> volatile BOOL a : 1;
>> volatile BOOL b : 1;
On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
> I'm not sure why it should be. Can't a user write
>
> #ifdef __cplusplus
> #define BOOL bool
> #else
> #define bool _Bool
> #endif
>
> struct x {
> volatile BOOL a : 1;
> volatile BOOL b : 1;
> volatile unsigned char c : 6;
> volatile BOO
On 20/02/12 17:28, Bernd Schmidt wrote:
> On 02/20/2012 12:14 PM, Richard Guenther wrote:
>> On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
>> wrote:
>>> Hi!
>>>
>>> How do we move this issue forward?
>>>
>>> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt
>>> wrote:
That was committed
On 02/20/2012 12:14 PM, Richard Guenther wrote:
> On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
> wrote:
>> Hi!
>>
>> How do we move this issue forward?
>>
>> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt
>> wrote:
>>> That was committed a while ago. The part in stor-layout.c that stops u
On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
wrote:
> Hi!
>
> How do we move this issue forward?
>
> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt
> wrote:
>> On 11/29/2011 05:35 PM, Mitchell, Mark wrote:
>> >>> So, I still think this patch is the best way to go forward, and it
>> >> doe
Hi!
How do we move this issue forward?
On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt
wrote:
> On 11/29/2011 05:35 PM, Mitchell, Mark wrote:
> >>> So, I still think this patch is the best way to go forward, and it
> >> does
> >>> fix incorrect code generation. Would appreciate an OK.
> >>
>
On 01/23/2012 08:51 PM, DJ Delorie wrote:
>
>> and I think applying strict-volatile-bitfields to enums is probably
>> meaningless.
>
> MCU vendors would disagree. If a location is volatile, it's most
> likely hardware, and must be accessed in the user-specified way.
> Randomly accessing adjacent
> and I think applying strict-volatile-bitfields to enums is probably
> meaningless.
MCU vendors would disagree. If a location is volatile, it's most
likely hardware, and must be accessed in the user-specified way.
Randomly accessing adjacent locations could cause system failure.
On 11/29/2011 05:35 PM, Mitchell, Mark wrote:
>>> So, I still think this patch is the best way to go forward, and it
>> does
>>> fix incorrect code generation. Would appreciate an OK.
>>
>> Ping.
>
> If you don't hear any objections within a week, please proceed.
That was committed a while ago. T
This should be in 4.6 too
- Joey
On Wed, Dec 21, 2011 at 12:46 AM, Bernd Schmidt wrote:
> On 11/29/11 17:35, Mitchell, Mark wrote:
So, I still think this patch is the best way to go forward, and it
>>> does
fix incorrect code generation. Would appreciate an OK.
>>>
>>> Ping.
>>
>> If y
On Wed, Dec 21, 2011 at 12:46 AM, Bernd Schmidt wrote:
> On 11/29/11 17:35, Mitchell, Mark wrote:
So, I still think this patch is the best way to go forward, and it
>>> does
fix incorrect code generation. Would appreciate an OK.
>>>
>>> Ping.
>>
>> If you don't hear any objections within
On 11/29/11 17:35, Mitchell, Mark wrote:
>>> So, I still think this patch is the best way to go forward, and it
>> does
>>> fix incorrect code generation. Would appreciate an OK.
>>
>> Ping.
>
> If you don't hear any objections within a week, please proceed.
Committed now after bootstrapping i686
Ping, PR middle-end/51200
Tailored from Bernd's, and added target independent test case. Now it
is a pure middle-end fix.
OK for trunk and 4.6?
Bernd Schmidt
gcc/
* expr.c (store_field): Avoid a direct store if the mode is larger
than the size of the bit field.
> > So, I still think this patch is the best way to go forward, and it
> does
> > fix incorrect code generation. Would appreciate an OK.
>
> Ping.
If you don't hear any objections within a week, please proceed.
Thank you,
Mark
On 11/11/11 17:22, Bernd Schmidt wrote:
> On 11/11/11 16:30, Joey Ye wrote:
>> -fstrict-volatile-bitfields doesn't work incorrectly in some cases
>> when storing into a volatile bit-field.
>>
>> Bernd provided a fix here about 1 year ago:
>> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html
To raise awareness, a track at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200
- Joey
> > Bernd provided a fix here about 1 year ago:
> > http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
> > But it is pending to trunk. Here are my humble opinions and hopefully
> > we can revive it:
> Yeah. At the time I thought the objections were a bit pointless. At
> worst, the added cod
On 11/11/11 16:30, Joey Ye wrote:
> -fstrict-volatile-bitfields doesn't work incorrectly in some cases
> when storing into a volatile bit-field.
>
> Bernd provided a fix here about 1 year ago:
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
> But it is pending to trunk. Here are my hu
33 matches
Mail list logo
