On Fri, Dec 20, 2019 at 08:09:26AM +0100, Richard Biener wrote:
> >That (of course) only writes 80 bits of data because of XFmode, leaving
> >48 bits uninitialized. We then read those bits, or-ing the
> >uninitialized data into ored_words and all hell breaks loose later.
> >
> >Am I losing my mind
On Mon, 16 Dec 2019 at 11:49, lindorx wrote:> I want
to know how to cpmpile the specified executable format with GCC. I
use GCC on the Windows platform.But I want to compile the ELF format
file.
You need a cross compiler.
But this is the wrong mailing list for your question. Please use the
gcc-
On December 20, 2019 8:25:18 AM GMT+01:00, Jeff Law wrote:
>On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
>> On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law
>wrote:
>> > I need a sanity check here.
>> >
>> > Given this code:
>> >
>> > > typedef union { long double value; unsigned
On December 20, 2019 1:41:19 AM GMT+01:00, Jeff Law wrote:
>On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
>> Hi, Dmitry,
>>
>> Thanks for the responds.
>>
>> Yes, routine size only cannot determine the complexity of the
>routine. Different compiler analysis might have different formula wi
Hi There,
Email: g...@gnu.org
Our international company consists of around 25 Internet projects related
to crypto currencies and ICO. Now we recruit staff from around the world.
CHECK IT OUT HERE
Primary salary $448k yearly e-workers needed!
- No Special Skills Required
- No Previous Job Exper
Hi, I just saw this:
FAIL: gfortran.dg/goacc/finalize-1.f -O scan-tree-dump-times gimple
"(?n)#pragma omp target oacc_enter_exit_data
map\\(delete:MEM\\[\\(c_char \\*\\)[^\\]]+\\] \\[len: [^\\]]+\\]\\)
map\\(to:del_f_p \\[pointer set, len: [0-9]+\\]\\)
map\\(alloc:del_f_p\\.data \\[pointe
Thanks a lot for all these help.
So, currently, if GCC compilation aborts due to this reason, what’s the best
way for the user to resolve it?
I added “#pragma GCC optimize (“O1”) to the large routine in order to
workaround this issue.
Is there other better way to do it?
Is GCC planning to re
On Fri, 20 Dec 2019 at 16:05, Qing Zhao wrote:
>
> Thanks a lot for all these help.
>
> So, currently, if GCC compilation aborts due to this reason, what’s the best
> way for the user to resolve it?
> I added “#pragma GCC optimize (“O1”) to the large routine in order to
> workaround this issue.
>
Hi!
On Wed, Dec 18, 2019 at 01:43:19PM -0700, Jeff Law wrote:
> On Wed, 2019-12-18 at 13:50 -0600, Segher Boessenkool wrote:
> > On Wed, Dec 18, 2019 at 11:07:11AM -0700, Jeff Law wrote:
> > > > That isn't what I said. I said that freshly constructed complex
> > > > software
> > > > will have mo
On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
> * J. Decker:
>
> > Here's the gist of what I would propose...
> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
> >
> > In C, there are two operators . and -> used to access members of struct
> and
> > union types. These ope
On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>
> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer wrote:
>
>> * J. Decker:
>>
>> > Here's the gist of what I would propose...
>> > https://gist.github.com/d3x0r/f496d0032476ed8b6f980f7ed31280da
>> >
>> > In C, there are two operators . and -> u
On Fri, Dec 20, 2019 at 12:03 PM J Decker wrote:
>
>
> On Fri, Dec 20, 2019 at 11:59 AM J Decker wrote:
>
>>
>>
>> On Tue, Dec 17, 2019 at 2:53 AM Florian Weimer
>> wrote:
>>
>>> * J. Decker:
>>>
>>> > Here's the gist of what I would propose...
>>> > https://gist.github.com/d3x0r/f496d0032476ed
On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> I've attached an updated list to this mail, which removes the items
> we've analysed. There are 531 remaining.
With the current version of the script (including the various whitelisted
component pairs discussed) and with data freshly downloaded from
On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > I've attached an updated list to this mail, which removes the items
> > we've analysed. There are 531 remaining.
>
> With the current version of the script (including the various whitelisted
> c
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> >
> > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've attached an updated list to this mail, which removes the items
> > > we've analysed. There are 531 remaining.
> >
> > With the current
On Fri, 20 Dec 2019 at 21:41, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > On Fri, 20 Dec 2019 at 20:30, Joseph Myers wrote:
> > >
> > > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> > >
> > > > I've attached an updated list to this mail, which removes the items
> > >
Snapshot gcc-8-20191220 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20191220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, Dec 20, 2019 at 02:57:57AM +0100, Dmitry Mikushin wrote:
> Trying to plan memory consumption ahead-of-work contradicts with the nature
> of the graph traversal. Estimation may work very well for something simple
> like linear or log-linear behavior.
Almost everything we do is (almost) line
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> I've sent another pull request fixing another 20. Here is the list
> with those 20 removed (and this still includes the libcpp vs
> preprocessor ones that will be handled by the new alias).
Thanks, merged.
--
Joseph S. Myers
jos...@codesourcery.com
Yes, much more. When you traverse a CFG, the analysis develops into a tree
(for example a tree of uses). That is, every basic block could be
*recursively* a root of an individual linear iteration for up to all basic
blocks. Sum them up, and you will get a polynomial expression. I don't
insist that
On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > I've sent another pull request fixing another 20. Here is the list
> > with those 20 removed (and this still includes the libcpp vs
> > preprocessor ones that will be handled by the new alias).
On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> On Fri, 20 Dec 2019 at 22:58, Joseph Myers wrote:
> >
> > On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've sent another pull request fixing another 20. Here is the list
> > > with those 20 removed (and this still includes the libcpp vs
> > >
22 matches
Mail list logo
