This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: HAVE_ATTR_enabled mishandling?
- From: Chung-Ju Wu <jasonwucj at gmail dot com>
- To: David Given <dg at cowlark dot com>
- Cc: gcc at gcc dot gnu dot org, Vladimir Makarov <vmakarov at redhat dot com>
- Date: Fri, 12 Jul 2013 02:35:53 +0800
- Subject: Re: HAVE_ATTR_enabled mishandling?
- References: <51DC85D4 dot 10206 at cowlark dot com>
On 7/10/13 5:51 AM, David Given wrote:
I think I have found a bug. This is in stock gcc 4.8.1...
My backend does not use the 'enabled' attribute; therefore the following
code in insn-attr.h kicks in:
#ifndef HAVE_ATTR_enabled
#define HAVE_ATTR_enabled 0
#endif
Therefore the following code in gcc/lra-constraints.c is enabled:
#ifdef HAVE_ATTR_enabled
if (curr_id->alternative_enabled_p != NULL
&& ! curr_id->alternative_enabled_p[nalt])
continue;
#endif
->alternative_enabled_p is bogus; therefore segfault.
Elsewhere I see structures of the form:
#if HAVE_ATTR_enabled
...
#endif
So I think that #ifdef above is a straight typo. Certainly, changing it
to a #if makes the crash go away...
I faced exactly the same problem as yours.
When I was trying to enable LRA on my target, I got segfault as well
because I did not have 'enabled' attribute in my target.md file.
I was told it was due to my faulty md design. The simplest workaround
is to define 'enabled' attribute so I took it. But I suspected that
may be a latent issue.
It's so happy to see others have the same question and provide a solution.
Certainly, whether your solution is correct should be reviewed by LRA
maintainer, Vladmir Makarov, so I cc him in the list.
Best regards,
jasonwucj