Hello,
Should I be concerned about using a vec<> inside a GTYed struct. Something like:
typedef loop_info * LOOP_INFO;
struct GTY(()) LOOP_INFO
{
...
vec infos;
};
is causing me some pain due to invalid free() / delete / delete[] / realloc()
(as reported by valgrind) after a segfault).
Ar
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc to
work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
generates
My mistake here.
I have not used the section attribute myself much and was looking at gcc
code
just passed the right handside of the .section to the attribute string.
# Stub function for foovf (float)
.section.mips16.fn.foovf,"ax",@progbits
.align2
.setnomips16
On 2013-04-19 10:21 , Paulo Matos wrote:
struct GTY(()) LOOP_INFO
{
...
vec infos;
You are declaring a heap vector here. Since your structure is in GC
memory, the vector must also be in GC memory. Add 'va_gc' to the
arguments; and make infos a pointer (a sad side-effect of using GC):
Good Day to all.
I'm an aspirant for GSOC 2013.
Currently I'm studying in Jaypee University of Information and
Technology, HP, India.
I'm interested in GCC that's why I'm looking forward to doing one of
your projects titled as : Improvements to GCC on windows.
After reading the resources availab
On 13-04-17 11:11 PM, Shiva Chen wrote:
Hi, Vladimir
Overlapped live range RTL is from line 7577 to 7597 in test2.c.209r.reload
Previous patch probably not completed.
The new patch will record lra_reg_info[i].offset as the offset from
eliminate register to the pseudo i
and keep updating when th
The GCC port I am using has some 'hack', that shares some data structs
interfaces (not the data itself) between front- and backend.
Therefore, I have the very ugly situation to have the definition of
these data structures both in the .h as well as in .c
(for GTY). Is there a more elegant way to ma
On Thu, Apr 18, 2013 at 6:22 AM, Jeff Law wrote:
> On 04/17/2013 03:52 PM, Steven Bosscher wrote:
>>
>> First of all: What is still important to handle?
>>
>> It's clear that the expectations in reorg.c are "anything goes" but
>> modern RISCs (everything since the PA-8000, say) probably have some
>
On Thu, Apr 18, 2013 at 12:58 PM, Bernd Schmidt wrote:
> In general I think if a new target wants more than one delay slot, it
> should try to use the C6X method instead of reorg.c. It would be nice
> for someone to try it on a target like mips or PA as well;
Agreed on both points. I actually cons
