Given this in tree.h:
struct int_n_trees_t {
tree signed_type;
tree unsigned_type;
};
extern struct int_n_trees_t int_n_trees[NUM_INT_N_ENTS];
And this in tree.c:
struct int_n_trees_t int_n_trees [NUM_INT_N_ENTS];
What is the right way to mark these for garbage collection?
I
We have open-sourced AutoFDO profile toolchain in:
https://github.com/google/autofdo
For GCC developers, the most important tool is create_gcov, which
converts sampling based profile to GCC-readable profile. Please refer
to the readme file
(https://raw.githubusercontent.com/google/autofdo/master/
Snapshot gcc-4.9-20140507 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140507/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi All ,
We are porting GCC 4.8.1 for the customized hardware, where the
current calling convention used as arguments are passed by stack and
return value by register.
But we do have some intrinsic functions(that are supplied by hardware
folks ) which has the calling convention like both argu
On Wed, May 7, 2014 at 3:36 PM, Prathamesh Kulkarni
wrote:
> Hi,
> I have few questions regarding genmatch:
>
> a) When simplification fails, we continue pattern matching with the next
> pattern
> in the order they appear in match.pd. Is that necessary ?
> Could we not simply return false fro
Hi,
I have few questions regarding genmatch:
a) When simplification fails, we continue pattern matching with the next pattern
in the order they appear in match.pd. Is that necessary ?
Could we not simply return false from gimple_match_and_simplify if
simplification fails ?
b) How do we handle
On Wed, May 7, 2014 at 2:28 PM, Florian Weimer wrote:
> On 05/07/2014 02:11 PM, Richard Biener wrote:
>
>>> Precisely. But optimizing this:
>>>
>>>
>>> int main()
>>> {
>>> if (0)
>>> foo ();
>>> else
>>> throw std::logic_error ("error");
>>> bar ();
>>> }
>>>
>>> to:
>>>
On 05/07/2014 02:11 PM, Richard Biener wrote:
Precisely. But optimizing this:
int main()
{
if (0)
foo ();
else
throw std::logic_error ("error");
bar ();
}
to:
int main()
{
throw std::logic_error ("error");
bar ();
}
would cause the code to issue such unwante
On Wed, May 7, 2014 at 2:07 PM, Florian Weimer wrote:
> On 05/07/2014 02:04 PM, Richard Biener wrote:
>
>> Depends on what "trivially" unreachable is. Yes,
>>
>> int main()
>> {
>>if (0)
>> foo ();
>> }
>>
>> will already be optimized. But I doubt you want to warn for that
>> given C++
On 05/07/2014 02:04 PM, Richard Biener wrote:
Depends on what "trivially" unreachable is. Yes,
int main()
{
if (0)
foo ();
}
will already be optimized. But I doubt you want to warn for that
given C++ and templates which often have this kind of specializations.
Precisely. But optim
On Wed, May 7, 2014 at 1:56 PM, Florian Weimer wrote:
> On 05/06/2014 04:30 PM, Richard Biener wrote:
>
>> Like I have suggested in the past a good point to do this kind of analysis
>> on the (mostly, as you say) unoptimized IL is right after going into SSA
>> form and implementing said analysis a
On 05/06/2014 04:30 PM, Richard Biener wrote:
Like I have suggested in the past a good point to do this kind of analysis
on the (mostly, as you say) unoptimized IL is right after going into SSA
form and implementing said analysis as an IPA pass (yeah, that somewhat
conflicts).
I don't think th
Jan-Benedict Glaw writes:
> On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
>> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
>> > please hold off on committing patches for the next couple of hours
>> > as we have a very large merge to do.
>> > thanks.
>>
>> All done… It is in.
>
> Jus
On Wed, 30 Apr 2014, Richard Biener wrote:
> On Tue, 29 Apr 2014, Jeff Law wrote:
>
> > On 04/29/14 05:21, Richard Biener wrote:
> > >
> > > The following patch forces the availability of a 64bit HWI
> > > (without applying the cleanups that result from this). I propose
> > > this exact patch f
On Tue, 2014-05-06 12:20:54 -0700, Mike Stump wrote:
> On May 6, 2014, at 8:19 AM, Kenneth Zadeck wrote:
> > please hold off on committing patches for the next couple of hours as we
> > have a very large merge to do.
> > thanks.
>
> All done… It is in.
Just found one more:
g++ -c -g -O2 -D
15 matches
Mail list logo
