On Thu, 6 May 2021 at 17:01, Richard Biener wrote:
>
> On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
>
> > On Thu, 6 May 2021 at 15:43, Richard Biener wrote:
> > >
> > > On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> > >
> > > > Hi Richard,
> > > > I was just wondering if second (and higher) o
>> To simplify explanation of this memory gathering optimization, pseudo
>> code on original nested loops is given as:
>>
>> outer-loop ( ) { /* data in inner loop are also invariant in outer loop.
>> */
>> ...
>> inner-loop (iter, iter_count) { /* inner loop to apply MGO */
>>
>>
Building the last several gcc releases I get the warning:
warning: gcc/cc1obj-checksum.o differs
This seems harmless but I am curious what causes it.
--Sidney Marshall
Snapshot gcc-9-20210506 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210506/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
> "Ulrich" == Ulrich Weigand via Gcc writes:
Ulrich> If we do want to byte-swap pointer types, then I guess we need
Ulrich> to still fix the debug info problem, which I guess would at a
Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an
Ulrich> attribute to DW_TAG_pointer_
Back in February I wrote an article about GCC 11 features designed
to help detect common dynamic memory management bugs. The article
just published in two parts in the Red Hat Developer Blog:
https://developers.redhat.com/blog/2021/04/30/detecting-memory-management-bugs-with-gcc-11-part-1-unders
> I'm not really sure where exactly the bug is, because I'm not
> quite sure if pointer types actually *should* be byte swapped.
>
> On the one hand, the typical use case of scalar_storage_order
> is to simplify accessing binary data (read from a file or the
> network) that was generated on a "for
Hello,
On Thu, 6 May 2021, Prathamesh Kulkarni via Gcc wrote:
> Well, I was thinking of this test-case:
>
> int f(int cond1, int cond2, int cond3, int x, int y)
> {
> void f1();
> void f2(int);
> void f3();
>
> if (cond1)
> f1 ();
> else
> {
> if (cond2)
> f2 (x
Hello,
for a few years now, GCC has supported the scalar_storage_order
attribute (and pragma) that allows specifying the storage order
(endianness) of structures. This affects both the code GCC
generates to access variables declared using the attribute,
and also the debug info: GCC emits the DW_A
On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> On Thu, 6 May 2021 at 15:43, Richard Biener wrote:
> >
> > On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> >
> > > Hi Richard,
> > > I was just wondering if second (and higher) order hoistings may defeat
> > > the "AVAIL_OUT in at least one succes
On Thu, 6 May 2021 at 15:43, Richard Biener wrote:
>
> On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
>
> > Hi Richard,
> > I was just wondering if second (and higher) order hoistings may defeat
> > the "AVAIL_OUT in at least one successor heuristic" ?
> >
> > For eg:
> > bb2:
> > if (cond1) goto
unsubscribe
On Friday, April 30, 2021, Xun Li via llvm-dev
wrote:
> Hi,
>
> I noticed that when compiling lambda functions, the generated function
> names use different conventions than GCC.
> Example: https://godbolt.org/z/5qvqKqEe6
> The lambda in Clang is named "_Z3barIZ3foovE3$_0EvT_", while
On Thu, 6 May 2021, Prathamesh Kulkarni wrote:
> Hi Richard,
> I was just wondering if second (and higher) order hoistings may defeat
> the "AVAIL_OUT in at least one successor heuristic" ?
>
> For eg:
> bb2:
> if (cond1) goto bb3 else goto bb4;
>
> bb3:
> if (cond2) goto bb5 else goto bb6;
>
>
Hi Richard,
I was just wondering if second (and higher) order hoistings may defeat
the "AVAIL_OUT in at least one successor heuristic" ?
For eg:
bb2:
if (cond1) goto bb3 else goto bb4;
bb3:
if (cond2) goto bb5 else goto bb6;
bb5:
return x + y;
bb6:
return x + y;
bb4:
if (cond3) goto bb7 else g
15 matches
Mail list logo
