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 ja...@redhat.com wrote:
On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
GET_MODE_BITSIZE (lmode)« (8 bits).
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, 09 May 2012 10:01:55 +0800, I wrote:
On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com 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«
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 figure out that
Hi!
On Wed, 25 Apr 2012 13:51:16 +0200, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Apr 25, 2012 at 1:27 PM, Thomas Schwinge
tho...@codesourcery.com 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:
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;
};
void
On Wed, Apr 25, 2012 at 1:27 PM, Thomas Schwinge
tho...@codesourcery.com 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,
};
-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-volatile-bitfields fixes
Hi!
On Wed, 18 Apr 2012 18:16:32 +0200, Bernd Schmidt ber...@codesourcery.com
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.
*
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
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, 21 Feb
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.
None
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;
volatile unsigned
On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
tho...@codesourcery.com wrote:
Hi!
How do we move this issue forward?
On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
On 11/29/2011 05:35 PM, Mitchell, Mark wrote:
So, I still think this patch is the best
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
tho...@codesourcery.com wrote:
Hi!
How do we move this issue forward?
On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
Hi!
How do we move this issue forward?
On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt ber...@codesourcery.com
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
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. The part in
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 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
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-linux and
On Wed, Dec 21, 2011 at 12:46 AM, Bernd Schmidt ber...@codesourcery.com 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
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 bernds_...@t-online.de
gcc/
* expr.c (store_field): Avoid a direct store if the mode is larger
than the
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.
But it
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
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 code in some
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 humble
28 matches
Mail list logo
