Hi
In function arm_load_pic_register in file arm.c there are following code:
if (TARGET_ARM)
{
...
}
else if (TARGET_THUMB2)
{
/* Thumb-2 only allows very limited access to the PC. Calculate the
address in a temporary reg
I installed gcc-4.5-20091224 snapshot and noticed that for simple
variable declaration
I get two DW_TAG_variable dies in the object file. For example, the
following
code
int x;
main()
{x=1;}
generates (with -g -gdwarf2 -O0 switches):
<1><54>: Abbrev Number: 4 (DW_TAG_variable)
<55>
On 01/05/2010 07:12 AM, Matt wrote:
Hi,
I'm fixing some compiler errors when configuring with
--enable-build-with-cxx, and ran into a curious line of code that may
indicate a bug:
static unsigned int
rest_of_handle_combine (void)
{
int rebuild_jump_labels_after_combine;
df_set_flags (DF_LR_RUN
Erik Trulsson student.uu.se> writes:
> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
> > The text you quoted does not contain any "shall not" language about
> > dereferencing, so this conclusion does not follow.
>
> It doesn't have to use any "shall not" language. If the standa
On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
> Andrew Haley redhat.com> writes:
> > On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> > > Andrew Haley redhat.com> writes:
> > "6.3.2.3
> >
> > "A pointer to an object or incomplete type may be converted to a
> > pointer to a diff
Hi,
I'm trying to fix some errors/warnings to make sure that gcc-as-cxx
doesn't bitrot too much. I ran into this issue, and an unsure how to fix
it without really ugly casting:
enum df_changeable_flags
df_set_flags (enum df_changeable_flags changeable_flags)
{
enum df_changeable_flags old_f
Hi,
I'm fixing some compiler errors when configuring with
--enable-build-with-cxx, and ran into a curious line of code that may
indicate a bug:
static unsigned int
rest_of_handle_combine (void)
{
int rebuild_jump_labels_after_combine;
df_set_flags (DF_LR_RUN_DCE + DF_DEFER_INSN_RESCAN);
Andrew Haley redhat.com> writes:
> On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> > Andrew Haley redhat.com> writes:
> "6.3.2.3
>
> "A pointer to an object or incomplete type may be converted to a
> pointer to a different object or incomplete type. If the resulting
> pointer is not correctly al
Hi,
I have been trying to understand the gcc source code and am interested
in customizing gcc to support speculative parallelization of
conditional branching and loop instructions instructions.I am
considering gimple as input.
I want to know what is the entry point to the gimplification pass? and
On 01/04/2010 04:17 PM, Nathan Froyd wrote:
> On Mon, Jan 04, 2010 at 04:08:17PM +, Andrew Haley wrote:
>> On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
>>> IMHO we really should have some late tree pass that converts adjacent
>>> bitfield operations into integral operations on non-bitfields (li
On Mon, Jan 04, 2010 at 04:08:17PM +, Andrew Haley wrote:
> On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
> > IMHO we really should have some late tree pass that converts adjacent
> > bitfield operations into integral operations on non-bitfields (likely with
> > alias set of the whole containing
I can confirm that our target also generate GOOD code for this case.
Maybe this is a EABI or target-specific thing, where Struct/union is
forced to memory.
Bingfeng
Broadcom Uk
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Andrew Haley
On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
> On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote:
>>On Mon, Jan 4, 2010 at 12:02 PM, Andrew Haley wrote:
>>> This optimization is done by the first RTL cse pass. I can't understand
>>> why it's not being done for your target. I guess
Apologies if you receive multiple copies of this call.
CALL FOR PARTICIPATION
2nd Workshop on
GCC Research Opportunities
Happy New Year!
I was hoping for some kind of response to this, but maybe I didn't give
enough info? I'd appreciate some pointers on what I could do to prompt
some discussion because I have some promising new ideas that lead on
from what I've described below.
Cheers,
Ian
> -Original Message
On Mon, Jan 4, 2010 at 8:04 PM, Bernd Roesch wrote:
> Hi,
>
> Because of this regression,
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
>
> Problem is in m68k-elf too, but happen not with any older GCC as 4.5.0
>
> i want try out if the first GCC 4.5.0 snapshot
> have this Problem or not.
Hi,
Because of this regression,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
Problem is in m68k-elf too, but happen not with any older GCC as 4.5.0
i want try out if the first GCC 4.5.0 snapshot
have this Problem or not.
The first GCC 4.5.0 i compile was in month 08.this have the Bug.
B
> On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote:
> > > This optimization is done by the first RTL cse pass. I can't
> understand
> > > why it's not being done for your target. I guess this will need a
> > > powerpc expert.
> >
> > Known bug, see http://gcc.gnu.org/PR22141
>
> T
On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote:
> > This optimization is done by the first RTL cse pass. I can't understand
> > why it's not being done for your target. I guess this will need a
> > powerpc expert.
>
> Known bug, see http://gcc.gnu.org/PR22141
That's unrelated.
> >> Is there any way to improve this behaviour? I have been using 2.9.5
> very
> >> successfully for years and am now looking at 4.4.2, but have many
> such
> >> examples in my code (for clarity of commenting and maintainability).
> >
> > This is very strange. On x86_64, gcc 4.4.1 generates
> >
>
On Mon, Jan 4, 2010 at 12:02 PM, Andrew Haley wrote:
> On 01/04/2010 10:51 AM, Mark Colby wrote:
>> This sounds like a dumb question I know. However the following code
>> snippet results in many more machine instructions under 4.4.2 than under
>> 2.9.5 (I am running a cygwin->PowerPC cross):
>>
>>
On 01/04/2010 10:51 AM, Mark Colby wrote:
> This sounds like a dumb question I know. However the following code
> snippet results in many more machine instructions under 4.4.2 than under
> 2.9.5 (I am running a cygwin->PowerPC cross):
>
> typedef unsigned int U32;
> typedef union
> {
> U
This sounds like a dumb question I know. However the following code
snippet results in many more machine instructions under 4.4.2 than under
2.9.5 (I am running a cygwin->PowerPC cross):
typedef unsigned int U32;
typedef union
{
U32 R;
struct
{
U32 BF1:2;
U32 :8;
On 01/03/2010 11:25 PM, Richard Guenther wrote:
>char charray[sizeof(long)] = {...};
>long l = *(long*)charray; // ok
not correct;) (the lvalue has to be of character type, yours is of
type 'long' - the type of the actual object does not matter)
What would be correct instead is
On 01/03/2010 10:14 PM, Joshua Haberman wrote:
> Andrew Haley redhat.com> writes:
>> On 01/03/2010 10:53 AM, Richard Guenther wrote:
>>> GCC follows its own documentation here, not some random
>>> websites and maybe not the strict reading of the standard.
>>
>> GCC is compatible with C99 in this r
25 matches
Mail list logo
