NUMA support did strike me as a possible cause.
I thought that L2 caches on the Opteron communicated by I assume by your
response the Opteron memory controller doesn't allow cache propagation,
instead invalidates the cache entries read (assuming again the write
entries are handled differently
at. however I don't cecall if
there was a discussion on allowing C++ STL 11 library features in gcc.
At least it was not a definite yes on allowing STL libraries,
Nick
7;re already serial, the trycommit better work.
assert (ok);
}
--
2.17.1
It seems to be failing in Running
/home/nick/obdjir/../gcc/libatomic/testsuite/libatomic.c/c.exp ...
as this is the last thing I see but it could be a mistake in my code or
something else. It does
build gcc find through
send a patch if that's the case,
Nick
send a patch if that's the case,
Nick
On 2018-11-06 2:05 p.m., nick wrote:
> Greetings all,
> I am wondering why this bug is only for the function reported:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074
> Seems there are lots of other functions in that file that could
> use the exact same optimization, would
edocs/gccint/index.html#SEC_Contents
Thanks,
Nick
operators? Seems the spec is only mentioned a few functions
but noexpect on move is normally a good idea unless the C++
standard or the C++ library needs it for other template parsing
reasons.
Regards,
Nick
r details, and let me know if
> you have any questions about that.
>
Jonathan,
My only question remains is for copyright is it per patch or just one time.
My other question is related to the noexcept parts and that either I or
you should move and CC the other involed list i.e. the llibstdc++ list.
Cheers,
Nick
On 2018-12-02 11:53 a.m., David Edelsohn wrote:
> On Sat, Dec 1, 2018 at 11:46 PM nick wrote:
>>
>> On 2018-12-01 10:32 a.m., Jonathan Wakely wrote:
>>> On Fri, 30 Nov 2018 at 20:54, Nicholas Krause wrote:
>>>>
>>>> This adds the remainging noex
On 2018-12-11 8:37 a.m., Jonathan Wakely wrote:
> On 10/12/18 16:09 -0500, nick wrote:
>> Greetings All,
>>
>> Sorry I was busy last week but did get my forms signed off for the
>> required copyright assignment. Anyhow seems that the tuple and other
>> class
On 2018-12-12 10:24 a.m., Jonathan Wakely wrote:
> On 12/12/18 17:17 +0200, Ville Voutilainen wrote:
>> On Wed, 12 Dec 2018 at 17:14, nick wrote:
>>
>>> > I think there's an attempt to ascertain that mostly constructors and
>>> > assignment opera
vec_prefix::calculate_allocation call do:
if (v == NULL)
return
Thanks,
Nick
so it
should be fixed.
Let me known if I am missing something,
Nick
:1446
versus without:
#30 0x008f55f2 in (anonymous namespace)::tsubst_compound_requirement
(in_decl=0x0, complain=0, args=0x770bfde8, t=0x770bf528) at
../../gcc/gcc/tree.h:3658
Don't know why this would cause issues:
#define OMP_CLAUSE_PRIVATE_DEBUG(NODE) \
(OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_PRIVATE)->base.public_flag)
in gcc/tree.h on line 1448. Any ideas?
Nick
On 2018-12-17 11:12 a.m., nick wrote:
>
>
> On 2018-12-17 10:23 a.m., Nathan Sidwell wrote:
>> On 12/17/18 10:11 AM, Jonathan Wakely wrote:
>>
>>> The second snippet is his suggested fix for the caller of tsubst_expr
>>> in expand_concept. That would
Greetings All,
I was wondering as I sent a patch before the holidays if I should resend it
as I did not get any replies.
Thanks,
Nick
On 2019-01-07 10:44 a.m., Jonathan Wakely wrote:
> On Mon, 7 Jan 2019 at 15:42, nick wrote:
>>
>> Greetings All,
>>
>> I was wondering as I sent a patch before the holidays if I should resend it
>> as I did not get any replies.
>
> Which patch? I don&#
Greetings All,
I was interested in the following two projects from the wiki for this summer if
possible,
Parallelize compilation using threads and Make C/C++ not automatically promote
memory_order_consume to memory_order_acquire.
Thanks,
Nick
27;t known if that's normal. Here is
what I'm
running the program with and I've enabled --enable-checking:
gdb --args ./bin/g++ -v -da -Q -fconcepts test.cpp
Cheers,
Nick
On 2019-03-17 6:50 a.m., Jonathan Wakely wrote:
> On Sun, 17 Mar 2019, 00:21 nick, wrote:
>
>> Greetings,
>>
>> I've been busy so this probably has been fixed in since I last worked on
>> it:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
>&g
eems to be a mislabel to me but I'm new to the
code base so just thought
I would ask.
Cheers,
Nick
some
cases. This is for tsubst_constraint_variables in gcc/cp/constraint.cc
from the root source directory.
If that is correct. I was wondering what of the PARM_X marcos is the one
used to fix up and wrap the tree t correctly.
Cheers,
Nick
s required please
>> let me know. I am just sending it to the development list
>> for review to make sure it's OK in terms of my understanding
>> the code.
>
> That's what the gcc-patches list is for.
>
Sorry it was sent there too. Didn't know which list was the correct one for
reviewing RFC patches.
Nick
On 2019-03-25 9:29 a.m., Jonathan Wakely wrote:
> On Mon, 25 Mar 2019 at 13:26, nick wrote:
>>
>>
>>
>> On 2019-03-25 9:25 a.m., Jonathan Wakely wrote:
>>> On Mon, 25 Mar 2019 at 12:39, Nicholas Krause wrote:
>>>>
>>>> Not sure
On 2019-03-25 3:45 p.m., Jeff Law wrote:
> On 3/25/19 10:39 AM, Martin Sebor wrote:
>> On 3/23/19 9:49 PM, nick wrote:
>>> Greetings all,
>>> I just got this in my build output:
>>> ar: `u' modifier ignored since `D' is the default (see `U'
uired that's in mainline gcc I sent out a trial patch
for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
Cheers,
Nick
On 2019-03-26 9:41 a.m., Richard Biener wrote:
> On Tue, 26 Mar 2019, David Malcolm wrote:
>
>> On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
>>> Greetings All,
>>>
>>> I would like to take up parallelize compilation using threads or make
>>> c+
On 2019-03-27 9:55 a.m., Giuliano Belinassi wrote:
> Hi,
>
> On 03/26, Richard Biener wrote:
>> On Tue, 26 Mar 2019, David Malcolm wrote:
>>
>>> On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
>>>> Greetings All,
>>>>
>>>> I w
roadmap is detailed enough or can I just
write out a few
paragraphs discussing it in the Projects Section.
Any other comments are welcome as well as I write it there,
Nick
some changes including from Richard.
Thanks,
Nick
On 2019-03-28 4:59 a.m., Richard Biener wrote:
> On Wed, Mar 27, 2019 at 6:31 PM nick wrote:
>>
>> Greetings All,
>>
>> I've already done most of the work required for signing up for GSoC
>> as of last year i.e. reading getting started, being signed up
On 2019-03-29 5:08 a.m., Richard Biener wrote:
> On Thu, 28 Mar 2019, nick wrote:
>
>>
>>
>> On 2019-03-28 4:59 a.m., Richard Biener wrote:
>>> On Wed, Mar 27, 2019 at 6:31 PM nick wrote:
>>>>
>>>> Greetings All,
>>>>
>
On 2019-03-29 10:28 a.m., nick wrote:
>
>
> On 2019-03-29 5:08 a.m., Richard Biener wrote:
>> On Thu, 28 Mar 2019, nick wrote:
>>
>>>
>>>
>>> On 2019-03-28 4:59 a.m., Richard Biener wrote:
>>>> On Wed, Mar 27, 2019 at 6:31 PM nick
7;s
indirectly including
that way so this header inclusion should now be removed. Unless I'm missing
something else
which is fine.
If not just let me known and I will just send a patch for it,
Nick
On 2019-04-01 5:56 a.m., Richard Biener wrote:
> On Fri, 29 Mar 2019, nick wrote:
>
>>
>>
>> On 2019-03-29 10:28 a.m., nick wrote:
>>>
>>>
>>> On 2019-03-29 5:08 a.m., Richard Biener wrote:
>>>> On Thu, 28 Mar 2019, nick wrote:
On 2019-04-01 9:47 a.m., Richard Biener wrote:
> On Mon, 1 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-01 5:56 a.m., Richard Biener wrote:
>>> On Fri, 29 Mar 2019, nick wrote:
>>>
>>>>
>>>>
>>>> On 2019-03-29 10:
On 2019-04-01 4:21 a.m., Martin Liška wrote:
> On 3/29/19 11:29 PM, nick wrote:
>> Greetings all,
>>
>> Not sure why this exists still as tree-eh.h is including in tree-eh.c which
>> defines this header
>> as used for this FIXME:
>> #include &q
On 2019-04-01 1:54 p.m., Andrew MacLeod wrote:
> On 4/1/19 12:49 PM, nick wrote:
>>
>> On 2019-04-01 4:21 a.m., Martin Liška wrote:
>>> On 3/29/19 11:29 PM, nick wrote:
>>>> Greetings all,
>>>>
>>>> Not sure why this exists still as
On 2019-04-03 7:30 a.m., Richard Biener wrote:
> On Mon, 1 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-01 9:47 a.m., Richard Biener wrote:
>>> On Mon, 1 Apr 2019, nick wrote:
>>>
>>>> Well I'm talking about the shared roots of this
LE and RTA. We would be bottle necked here and that seems to
be a issue after reading the code.
Let me know if this makes more sense to you as a proposal and feel free to
ask questions if something doesn't make sense,
Nick
On 2019-04-05 6:25 a.m., Richard Biener wrote:
> On Wed, 3 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-03 7:30 a.m., Richard Biener wrote:
>>> On Mon, 1 Apr 2019, nick wrote:
>>>
>>>>
>>>>
>>>> On 20
On 2019-04-07 5:31 a.m., Richard Biener wrote:
> On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote:
>>
>>
>> On 2019-04-05 6:25 a.m., Richard Biener wrote:
>>> On Wed, 3 Apr 2019, nick wrote:
>>>
>>>>
>>>>
>>>> On 2019-
On 2019-04-08 3:29 a.m., Richard Biener wrote:
> On Sun, 7 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-07 5:31 a.m., Richard Biener wrote:
>>> On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote:
>>>>
>>>>
>>>> On 2019-04-05
On 2019-04-08 9:42 a.m., Richard Biener wrote:
> On Mon, 8 Apr 2019, nick wrote:
>
>>
>>
>> On 2019-04-08 3:29 a.m., Richard Biener wrote:
>>> On Sun, 7 Apr 2019, nick wrote:
>>>
>>>>
>>>>
>>>> On 2019-04-07 5:31
xcept for the move constructor and assignment operator.
Thanks if possible,
Nick
Andrew,
I read through your notes briefly on this issue and if you want help I'm game
for it.
I assuming it's fixed not through as the gcc projects pages tend to me out of
date in
my experience.
Nick
On 2019-05-07 5:04 p.m., Andrew MacLeod wrote:
> On 5/7/19 2:40 PM, nick wrote:
>> Andrew,
>>
>> I read through your notes briefly on this issue and if you want help I'm
>> game for it.
>> I assuming it's fixed not through as the gcc project
Greetings All,
I was unable to find in the official gcc internals manual but what layers have
threaded support in terms
of functions to use them. I'm not asking about implemented but at least a start
to being implemented.
Thanks,
Nick
he current expand_all_functions work are the GENERIC
reading
of files up to the RTL layer including certain passes. RTL may not need it due
to
most shared state being at the GENERIC and GIMPLE/pre RTL layers.
Regards,
Nick
e GIMPLE passes?
Just curious as I've not a RTL or backend expert,
Nick
fixing the code comments is fine and I don't mind but the
manual itself also requires
changes so making sure that gets changed as well.
Thanks,
Nick
On 2019-06-07 10:36 p.m., nick wrote:
> Greetings,
>
> In both the manual and general other places it seems that the old
> walk_dominator_tree is used instead
> of the current walk name. Trevor has been CCed as this change occurred it
> seems in 2013 but some of
> the
of the project.
Again that's just off the top of my head so it may be a really bad idea,
Nick
P.S. Good luck through.
On 2019-06-25 9:40 a.m., Giuliano Belinassi wrote:
> Hi
>
> On 06/24, nick wrote:
>>
>>
>> On 2019-06-24 8:59 a.m., Giuliano Belinassi wrote:
>>> Hi,
>>>
>>> Parallelize GCC with Threads -- First Evaluation
>>>
>>> Hi ev
pure-const, -fguess-branch-probability or
>> any other option alone does not produce the optimized code that breaks the
>> dependency. But applying -O1, i.e., allowing all the optimizations does so.
>> As passes are applied in a certain order, we need to figure out upto what
>> passes, the code remains same and after what pass the dependency does not
>> holds. So, we need to check the translated code after every pass.
>>
>> Does this sounds like a workable plan for ? Let me know your thoughts. If
>> this sounds good then, we can do this for all the optimizations that may
>> kill the dependencies at somepoint.
>
> I don't know of a better plan.
>
> My usual question... Is there some way to script the checking of the
> translated code at the end of each pass?
>
> Thanx, Paul
>
I don't off the top of my head where the documentation is but writing a gcc
tool to inspect passes if one doesn't exist is the best way forward. A gcc
tool would be exposed to those internals but not sure if it's easy to do
that in the time frame due to the effort required by you or Akshat.
Cheers,
Nick
less than those.
Again I understand if's out of scope but it would be great if you have a current
profile graph that I can see. It would give me an idea of where to start working
outside of the core GIMPLE optimizations passes your working on.
Huge thanks and again good luck,
Nick
P.S. D
Jeff,
Who is the best person to contact for SSA expertise in GCC as I've started
trying to figure
out if it's possible to multi-thread and parallel the SSA dominator trees
including insertion,
walking and pushing to hardware registers during RTL allocation.
Huge thanks,
Nick
currently working on that seems some help
either testing or otherwise?
Thanks for any answers,
Nick
Greetings All,
I am wondering if this is a warning worth looking into or is it just another
false postive:
/home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
if ((next = try_combine (insn, prev, NULL, NULL,
Maybe
On 2017-09-23 12:05 PM, Jeff Law wrote:
> On 09/22/2017 08:25 PM, nick wrote:
>> Greetings All,
>>
>> I am wondering if this is a warning worth looking into or is it just another
>> false postive:
>>
>> /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev
On 2017-09-24 10:10 AM, Eric Gallager wrote:
> On Sat, Sep 23, 2017 at 12:34 PM, nick wrote:
>> If your able to just tell me where the functions are located or how do you
>> enable ctags for all of
>> gcc? That would just save me asking stupid questions. Is there a global
with current or something?
Cheers,
Nick
P.S. I already sent this but this should be in around thread. Sorry for
polluting the ML.
y
helpful before I sent in a patch to the patches list to get merged for the fix.
Take care,
Nick
rts it.
What do you mean by nested functions actually as that means a lot
of things in compiler or language development.
Cheers,
Nick
yntactic
> sugar syntax.
>
> Austin
>
That's the same thing actually if your going to name your lambda. What are the
advantages
of this newer syntax or feature. Do you have any examples?
Nick
> On Jan 3, 2018 2:44 PM, "nick" <mailto:xerofo...@gmail.com>> wrot
seful in helping me figure out the
problem.
So this e-mail is Kudos to the project's developers & contributors for a
rockin' product! Keep up the good work!
Nick
ot; << f2 << ": " << (f1 < f2) << endl;
cout << "5) " << f2 << " < " << f1 << ": " << (f2 < f1) << endl;
cout << "6) " << f2 << " < " << (f3 + f4) <
On Sat, 2014-01-11 at 16:24 +0100, Marc Glisse wrote:
> First, this is not an appropriate list for this question. gcc-help would
> be better.
Sorry about that--my e-mail auto completed the address and I wasn't
paying enough attention.
> Second, there are hundreds of places on the internet answer
On Sat, 2014-01-11 at 15:24 +, Rob wrote:
> On Sat, 11 Jan 2014, Nick wrote:
> > I'm very surprised by the result in #6. #7 seems to be doing the same
> > thing, except that it uses a local variable to hold the sum.
>
> Sounds to me like it could be related to e
u'll have to give me another day to look
at the problem.
Cheers
Nick
gcc and binutils sources for this...)
Cheers
Nick
ection of the most effective
optimization options to compile any given particular application.
For switches which are not binary in nature, the current state of
the switch would be displayed.
What do you think ?
Cheers
Nick
sumption is correct means that the linker is right.
uriMovieEditing does contain an unresolved reference to an
outputFrame_ symbol. You will need to add whichever library or object
file contains that symbol to the linker command line, and if it is a
library that contains it, then it must come *after* -luriVision on the
command line.
Cheers
Nick
rrect in
complaining that it cannot resolve the reference and hence you do need
to tell the linker where to find this symbol.
Where do you think the ...getFrame_(bool.uriBase::RasterImage*) symbol
is defined ?
Cheers
Nick
or a socket ?
Thanks in advance for your answers,
Nick Rolins
arm-elf-ld: warning: cannot find entry symbol _start; not setting start address
how do i type the correct command line option for this
Try using gcc to control the entire process from compilation to final
link, like this:
arm-elf-gcc new.c
Cheers
Nick
hts before I go barking up the wrong tree ?
Regards,
Nick.
diff -x '*.orig' -x '*.rej' -uprN
/home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads
gcc-4.0/gcc/ada/s-auxdec.ads
--- /home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads
2004-06-16 14:50:06.0 +01
Geert Bosch wrote:
On Mar 21, 2005, at 02:54, Nick Burrett wrote:
This seems to be a reoccurance of PR5677.
I'm sorry, but I can't see any way this is related, could you elaborate?
Sorry, I completely misread the PR. It is not related.
for Aligned_Word'Alignment use
-
instructions if they are
generated by the compiler, or indeed if they are in hand written
assembler source files.
Cheers
Nick
nd marketing it and that they will
be contributing patches for the gcc port at some point in the future.
Cheers
Nick
file.
Does this bug look familiar? 20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing. Is there
any more information that I provide that would be helpful? I've
attached the command line, specs and a stacktrace from cc1plus.
-nick
/dept/rnd/ve
ee_equal): Handle SSA_NAME.
>
> Yep, and I didn't put it in the release branch. Bad Dale. OK to do
> that?
>
> If this is the same problem, changing the VN hashtable size to 1
> should make it show up reproducibly.
>
The released 4.0.0 successfully compiles the code that was having
problems before.
-nick
t=arm-elf-linux --enable-languages=c
$ ./cc1 -quiet test.c -mthumb -O2
../../bug.c: In function ‘foo’:
../../bug.c:3: internal compiler error: in create_mem_ref, at
tree-ssa-address.c:585
Please submit a full bug report,
Nick.
eciding if the variable is going to
be emitted should really be resolved ?
Cheers
Nick
port?
Support for the 64-bit PE file format I guess.
Cheers
Nick
This will create four sections: .text, .text.exception, .init and
.init.exception. In the future other substitution sequences in
addition to %S may be provided.
* Support for the ARMv8.1 architecture has been added to the AArch64
and ARM ports. This includes support for the Adv.SIMD, LOR and
PAN architecture extensions.
Cheers
Nick
to explicitly enable or disable the use of the r2
BMX (bit manipulation) and CDX (code density) instructions via the
use of the new -mbmx -mno-bmx -mcdx and -mno-cdx options.
Cheers
Nick
** HP/PA running HP-UX (hppa*-*-hpux*)
** Itanium running HP-UX (ia64-*-hpux*)
Support for the "-xdb" command-line switch (HP-UX XDB compatibility
mode) has also been removed.
Cheers
Nick
PS. The monthly gcc/g++ DG tests show little change this time around:
Hi Alan,
On Fri, Sep 25, 2015 at 01:33:34PM +0100, Nick Clifton wrote:
* The new PowerPC64 specific linker command line option
--no-save-restore-funcs tells the linker not to provide the
out-of-line register save and restore functions used by -Os compiled
code. The default
at if the MCU name is not recognised the compiler will
assume that is only supports the MSP430 instruction set, and that it
does not have any hardware multiply support.
Tested with no regressions on an msp430-elf toolchain.
Cheers
Nick
gcc/ChangeLog
2015-10-12 Nick Clifton
* c
Hi Guys,
Sorry for the delay between these updates. My new job is keeping
me very busy... Anyway here are the highlights of the changes in
the GNU toolchain over the last two months:
The compiler and assembler now have support for the ARC EM/HS and
ARC600/700 architectures and the Po
rogram is multi-threaded. For
example:
Thread 3 "bar" hit Breakpoint 1 at 0x40087a: file program.c, line 20.
Thread 1 "main" received signal SIGINT, Interrupt.
That's all for now. More again in a couple of month's time.
Cheers
Nick
g GCC 6 release.
So if you are interested in what will happen, please see:
http://developerblog.redhat.com/2016/02/23/upcoming-features-in-gcc-6/
and:
http://developerblog.redhat.com/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/
Cheers
Nick
hat two or more
output sections are entirely independent from each other, except
that it does allow one way referencing. The NOCROSSREFS_TO
directive takes a list of output section names and complains if
the first section is referenced from any of the other sections.
Cheers
Nick
uivalent (isalnum_l, toascii_l,
strtoll_l, etc).
Cheers
Nick
d propagating elsewhere.
>
> CC-ing as this might affect them too.
>
> Hmm, the shell construct is so common that I think rather than auditing
> all the scripts throughout our tree I'd rather made a `configure' check
> for the buggy shell feature and reject any s
Secure Gateway veneers that must exist in the
output import library specified by --out-implib= and the
address they must have.
That's all for now. Hopefully the next update will be a bit sooner in
arriving.
Cheers
Nick
erent targets are building and
performing in order to get an overall feel for the state of the
sources.
Cheers
Nick
---
There are several things to report this month:
* The GCC version 5 branch has been created. No rel
ython/18285 (ptype expr-with-xmethod causes SEGV)
Cheers
Nick
GCC Merge:
Toolchains that do not build GCC successfully:
None.
Toolchains that do not build LIBGCC successfully:
mep-elf: ICE: in pre_and_rev
1 - 100 of 181 matches
Mail list logo
