addressing. I will try to make time for them in the next
few weeks.
If you do have any suggestions for fixes to any of these problems, please do
feel free to add them to the relevant bug reports.
Cheers
Nick
it is not clear which tool is the source of the problem, then I would
suggest choosing the binutils first. If it turns out that specific issue
is actually caused by a problem in gcc, the bug report can always be moved
later on.
Cheers
Nick
gt; -std=gnuXX modes?
Meh, even though these macros are a small thing I don't accept the
"things are breaking anyway so let's break even more things" attitude.
This was something that many library authors did during the python 3
transition and that just made the problems orders of magnitude more
horrible.
Cheers,
Nick
expressions that cannot
be resolved this way. That is why the error message refers to
"converted into relocations" rather than just "converted into a
relocation".
Cheers
Nick
ed
I looked into providing a file name and line number with the error
message, but this would involve reworking a lot of the assembler's
internal expression parser.
Cheers
Nick
ntly for
nvptx?
Nope, none at all.
Harmonizing the effect of the -v option sounds like a good idea to me.
Cheers
Nick
both compilers).
This sounds like an opportunity to add a couple of new GNU object
attributes:
.gnu_attribute Tag_gnu_destructor_count,
.gnu_attribute Tag_gnu_tld_count,
Which would then translate into a GNU object attribute notes in the
object file.
Cheers
Nick
On 27 Jun 2022, Fangrui Song stated:
> I created https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new
> ch_type value: ELFCOMPRESS_ZSTD") after I saw that on LLVM side, Cole Kissane
> proposes that we add Zstandard as new compression method (mainly for .debug*
> sections, but also for s
program headers
and does not provide separate headers for code and data.
Cheers
Nick
the
prune_extra_warnings proc...
Cheers
Nick
gdb mainline sources with this release.
Whilst it is true that the gcc version of zlib sources had diverged slightly
from
the 1.2.11 release sources, I think that it was just some changes cherry picked
from the developments that went in to 1.2.12. So a simple rebase should be
safe.
Cheers
Nick
of zlib. I will wait a couple of
days to see if anyone else has any comments or concerns, but if not, then I
will apply the patches myself.
Cheers
Nick
Ok, sorry. I'll ask it on gcc-help.
Nick
On Wed, Sep 29, 2021 at 1:35 PM, Jonathan Wakely
wrote: On Wed, 29 Sept 2021 at 21:34, Nick Savoiu via Gcc
wrote:
>
> Should GCC report shadowing on 'valid' for this code?
> Nick
>
> struct S1{ bool valid;};
&g
Should GCC report shadowing on 'valid' for this code?
Nick
struct S1{bool valid;};
struct S2 : public S1{bool valid;};
struct S3 : public S2{bool valid;};
providing that when configuring
for
just "netbsd" there was a prominentant message in the config log saying
something like:
"netbsd format now treated as ELF based. Use netbsdaout if you want a.out format
files".
(Probably with slightly better wording than that).
Cheers
Nick
Hello,
This is Nick Vidal from Rocket.Chat
We’ve been part of GSoC for 5 years now, and as a way to celebrate and
give back to the open source community, this year we are reaching out
to other GSoC organizations to provide assistance on setting up
Rocket.Chat to engage with students (pro bono
On 9 Mar 2021, Jakub Jelinek via Binutils spake thusly:
> On Tue, Mar 09, 2021 at 11:38:07AM +, Hannes Domani via Dwz wrote:
>> Am Dienstag, 9. März 2021, 10:10:47 MEZ hat Mark Wielaard
>> Folgendes geschrieben:
>>
>> > Hi Allan,
>> >
>> > On Tue, Mar 09, 2021 at 09:06:54AM +0100, Allan Sa
't looked up what that is) though maybe
"segment" pseudo qualifiers the kernel defines expand to address space
variable attributes?
Maybe stripping all qualifiers is fine since you can add them back in
if necessary?
const volatile foo;
const nonqual_typeof(foo) bar = foo; // strips off both qualifiers,
re-adds const to bar
--
Thanks,
~Nick Desaulniers
use the result is a great way to have clang omit the use
from the final program. This has bitten us in the past getting MIPS
support up and running, and one of the MTK gfx drivers.
--
Thanks,
~Nick Desaulniers
uld be particularly helpful to have LLVM folks in
the room, please let me know and I'll help promote it.
See you at the show!
--
Thanks,
~Nick Desaulniers
accessor function which takes a parameter
indicating the desired field and which returns its current value would
also work.
What do people think ? Is this idea practical, or is there a better
solution ?
Cheers
Nick
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
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
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
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
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
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-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
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
e GIMPLE passes?
Just curious as I've not a RTL or backend expert,
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
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
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
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
xcept for the move constructor and assignment operator.
Thanks if possible,
Nick
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
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-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-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
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-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
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-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 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 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:
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-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
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-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
some changes including from Richard.
Thanks,
Nick
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
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
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+
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-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'
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
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
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
eems to be a mislabel to me but I'm new to the
code base so just thought
I would ask.
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
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
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
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 wondering as I sent a patch before the holidays if I should resend it
as I did not get any replies.
Thanks,
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
: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
so it
should be fixed.
Let me known if I am missing something,
Nick
vec_prefix::calculate_allocation call do:
if (v == NULL)
return
Thanks,
Nick
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
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-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
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
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
edocs/gccint/index.html#SEC_Contents
Thanks,
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
send a patch if that's the case,
Nick
send a patch if that's the case,
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
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
rts it.
What do you mean by nested functions actually as that means a lot
of things in compiler or language development.
Cheers,
Nick
Hi Guys,
A new version of GLIBC and a whole boatload of new GCC features
means that there is lots to report this time.
---
GLIBC:
Version 2.26 is now out. There are loads of new features and bug
fixes in this release. Some
with more autoconf-fu than me will
have a go one day though.
Cheers
Nick
configurations, and built and run an x86_64 gdb.
One thing that worries me though, is why hasn't this been done before?
Ie is there a special reason for staying with the old 2.2.7a libtool ?
If not, then does anyone object to my upgrading the gcc, gdb and
binutils mainline sources ?
Cheers
Nick
y
helpful before I sent in a patch to the patches list to get merged for the fix.
Take care,
Nick
with current or something?
Cheers,
Nick
P.S. I already sent this but this should be in around thread. Sorry for
polluting the ML.
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
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
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
currently working on that seems some help
either testing or otherwise?
Thanks for any answers,
Nick
lements 128-bit floating point as defined by ISO/IEC/IEEE
60559:2011 (IEEE 754-2008) and ISO/IEC TS 18661-3:2015.
That's it for this time. More in the fall...
Cheers
Nick
tead. This will mean fewer, but
longer blogs, but hopefully it will still be interesting reading.
Cheers
Nick
Hi Gerald,
> Thanks for that update, Nick. Surely interesting reading.
> Are you planning another update for March or so? ;-)
Thanks for the ping! I have been intending to write another
update for the last month or so, but I keep on letting it slip. :-(
I will make it my top priority fo
ns should not be built
outside of
a gcc build tree. Or at least any plugins that require intimate access to gcc's
internal headers.
> I'm still convinced that 99% of all (valid) plugin uses involve only
> introspection or well-defined instrumentation.
I agree, and I would like to see a move towards officially accepting these
plugins
into gcc's ecosystem.
Cheers
Nick
Should I create a patch and submit it for
official review ?
Cheers
Nick
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
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
uivalent (isalnum_l, toascii_l,
strtoll_l, etc).
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
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
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
1 - 100 of 180 matches
Mail list logo
