[Moving to gcc@ from gcc-patches@]
Community,
We've got 11 student proposals (good job, students!), and only the N top-rated
ones will be accepted into the program. Therefore, we as a community need to
make sure that the ratings are representative of our goals -- making GCC the
best compiler
On Tue, 25 Mar 2014, Matthew Fortune wrote:
> Can you envisage any way of us raising a warning/error if INVALID
> exceptions get enabled in this hybrid NaN world? I believe that is the
> only major problem area with mixing NaNs. I.e. It should be possible to
> introduce a magic symbol if LD mer
Matthew Fortune writes:
> Joseph Myers writes:
>> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>>
>> > Hi Richard, we talked about (a.) originally - it was the design of the
>> > libraries. Joseph, as I recollect, you raised language issues with
>> > requirements for compile-time constant values for
Joseph Myers writes:
> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>
> > Hi Richard, we talked about (a.) originally - it was the design of the
> > libraries. Joseph, as I recollect, you raised language issues with
> > requirements for compile-time constant values for NaNs. Would you
> > accept a non
On Tue, 25 Mar 2014, Rich Fuhler wrote:
> Hi Richard, we talked about (a.) originally - it was the design of the
> libraries. Joseph, as I recollect, you raised language issues with
> requirements for compile-time constant values for NaNs. Would you accept
> a non-constant NaN implementation in
> Hello,
>I've been compiling Chromium with LTO and I noticed that WPA
> stream_out forks and do parallel:
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html.
>
> I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about
> 6GB. When WPA start to fork, memory consumption increa
> The easiest way to do that is to add a flag that either (a) stops the
> compiler emitting a .nan at all or (b) gets it to emit ".nan legacy"
> regardless of the actual encoding used. It's really just a slight
> variation on (2), the difference being that we might be using 2008
> under the covers
> You can certainly nest them, no?
>
> ANNOTATE_EXPR , unroll, 2>
Yes, that works, thanks.
--
Eric Botcazou
On Tue, Mar 25, 2014 at 3:26 AM, Martin Liška wrote:
> The code resides in Chromium project, please see full source code:
> https://github.com/scheib/chromium/blob/master/sandbox/linux/seccomp-bpf/syscall.cc
The easy workaround is to make SyscallAsm global. And frankly I would
put it in a .S fil
Hi,
CppCon is the annual, week-long face-to-face gathering for the entire
C++ community. The conference is organized by the C++ community for the
community and so we invite you to present.
Have you learned something interesting about C++, maybe a new technique
possible in C++11? Or perhaps you ha
On 03/25/14 06:23, Umesh Kalappa wrote:
Dear All,
The GCC source reference 4.8.1 will synthesized some of the double
word operations(SI mode) like add /sub in the below case from the word
size (HI) patterns,
(code snippet)
expand_binop_directly function in the optabs.c.
/* These can be done a
Dear All,
The GCC source reference 4.8.1 will synthesized some of the double
word operations(SI mode) like add /sub in the below case from the word
size (HI) patterns,
(code snippet)
expand_binop_directly function in the optabs.c.
/* These can be done a word at a time by propagating carries. */
dw writes:
>>asm ("" : "=m" (*x), "=r" (y));
>>
>> you have to assume that the address in %0 might use the same register as %1
>
> Ok, now I'm getting there. It helps that I've compiled some examples
> and can see what is happening. This one is subtle. I'm going to have
> to go back and r
The code resides in Chromium project, please see full source code:
https://github.com/scheib/chromium/blob/master/sandbox/linux/seccomp-bpf/syscall.cc
Martin
On 03/24/2014 06:34 PM, Ian Lance Taylor wrote:
On Mon, Mar 24, 2014 at 6:26 AM, Martin Liška wrote:
I've been solving undefined sy
On Mon, Mar 24, 2014 at 10:11 PM, Eric Botcazou wrote:
>> Look at how we implement #pragma ivdep (see replace_loop_annotate ()
>> and fortran/trans-stmt.c where it builds ANNOTATE_EXPR).
>
> Note that the C and C++ front-ends also support it.
>
> We are planning to submit a patch to add more loop
Matthew Fortune writes:
> Richard Sandiford writes:
>> Matthew Fortune writes:
>> > Maciej W. Rozycki writes:
>> >> On Sat, 22 Mar 2014, Richard Sandiford wrote:
>> >>
>> >> > > Thanks Joseph. I guess I'm not really pushing to have don't-care
>> >> > > supported as it would take a lot of effort
"Maciej W. Rozycki" writes:
> What I'm concerned the most about is the matter is so obscure to people
> outside a narrow group of hardware/kernel/toolchain/library experts (that
> regrettably does not include distribution packagers) that once that "don't
> care" approach is set in the environm
17 matches
Mail list logo
