Hi
Commit 017c45fa2a4da40893f0aacd96164f04c78cb245 bumped BASE-VER to 15.0.1, but
the commit message says it's been bumped
to 14.0.1. I guess it will obvious to readers that it's a typo, but want to fix
it.44.
Chris
s a halfway house solution where memcpy only handles
null pointers contingent on the value of some other parameter. This is hard to
document, hard to teach static analysis tools, and hard to verify when reading
calling code.
I do not think it serves anyone.
Best regards,
Chris
_
makers
Record in the list contains: Communication Name, Title, Company Name, Website,
Physical Address, Communication Number, Fax Number, SIC, Industry type, Emails,
and Verification results
If you are interested, I am happy to send value.
Regards
Chris altieri- Coordinator
On 25/3/2023 11:08 am, Stuff Received wrote:
> On 2023-03-24 19:51, Chris Johns wrote:
>> On 25/3/2023 10:07 am, Jonathan Wakely wrote:
>>> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, >> <mailto:jwakely@gmail.com>> wrote:
>>> On Fri, 24 Mar 2
On 25/3/2023 10:07 am, Jonathan Wakely wrote:
> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, <mailto:jwakely@gmail.com>> wrote:
> On Fri, 24 Mar 2023, 23:03 Chris Johns, <mailto:ch...@contemporary.net.au>> wrote:
>
> Hi,
>
> I
build the tools rather than
clang from Xcode.
Is aarch64-apple-darwin supported? I am seeing:
*** Configuration aarch64-apple-darwin22.3.0 not supported
Thanks
Chris
On 15/6/22 7:56 pm, Richard Biener wrote:
> On Wed, Jun 15, 2022 at 11:27 AM Chris Johns
> wrote:
>>
>> Hi,
>>
>> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a
>> chip vendor is using it when building controller software tha
...
build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not
supported (see config.log for details).
Should the enable option be passed to these packages?
I have assumed the enable option for LTO is for the cross compiler and not the
host gcc?
Thanks
Chris
On Thu, Sep 16, 2021 at 5:50 PM enh wrote:
> plus testing for _equality_ can (as mentioned earlier) have slightly
> different properties from the three-way comparator behavior of
> bcmp()/memcmp().
>
llvm-libc's implementation only returns the boolean, though.
The mem* functions are extremely s
On Thu, Sep 16, 2021 at 2:31 PM Noah Goldstein
wrote:
>
>
> On Thu, Sep 16, 2021 at 12:55 PM Chris Kennelly via Libc-alpha <
> libc-al...@sourceware.org> wrote:
>
>> On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
>> wrote:
>>
>> > Hi All,
>&g
On Thu, Sep 16, 2021 at 1:04 PM Noah Goldstein
wrote:
> Hi All,
>
> This is a proposal for a new interface to be supported by libc.
>
> The new interface is the same as the old 'bcmp()' routine. Essentially
> the goal of this proposal is to add a reserved namespace for a new
> function, '__memcmp
What I see here in sum is another high level tightly integrated Red Hat
employee saying the gist of "I'm really not saying it out of my
employer's interest and it has nothing to do with my personal
feelings".
Every single proponent of this argument that I have seen so far is
employed by one of the
I think (if it matters to anyone what I think) that would be great to
see as long as there was some social/cultural incentive to not elect
"gatekeeper" types. I see alot of folks with very thin skin misusing
the authority they are trusted with in open source communities, it's
just never over any o
beliefs into the GCC project roadmap beyond its
technical and licensing goals.
I would encourage anyone reading this to start treating this discussion
as off-topic disruption for the GCC SC.
-C
On Mon, 2021-04-12 at 17:22 -0400, Nathan Sidwell wrote:
> On 4/11/21 9:34 PM, Chris Punches via
Hello,
I've been reading quietly on how the GCC SC handles this and generally
only lurk here so that I can stay informed on GCC changes. I am nobody
you would probably care about, but, maybe I will be one day. No one
ever really knows.
I thought you'd like to know what "nobody" thinks, because,
There are a lot of issues https://github.com/xiangzhai/dragonegg/issues so
> I need smarter developers' help.
Hi Leslie,
Out of curiosity, what is motivating this work? What is the usecase for
dragonegg these days, now that Clang has great C++ support? Are you interested
in Ada + LLVM or some other frontend?
-Chris
https://gcc.gnu.org/codingconventions.html#ExternC
In the `Extern "C"` commentary, the coding conventions says:
Definitions within the body of a namespace are not indented.
This should read
Definitions within the body of an `extern "C"` block are not indented.
Cheers,
Chris Gregory!
On 28/02/2015 9:12 am, Manuel López-Ibáñez wrote:
On 02/19/15 14:56, Chris Johns wrote:
My main concern is not knowing the trap has been added to the code. If I
could build an application and audit it somehow then I can manage it. We
have a similar issue with the possible use of FP registers
registers being used in
general code (ISR save/restore trade off).
Can the ELF be annotated in some GCC specific way that makes it to the
final executable to flag this is happening ? We can then create tools to
audit the executables.
Chris
Please add 'BUILD_CFLAGS="-g -O2 -fbracket-depth=1024”' to the configure
command line before the configure script is referenced, ie:
$ BUILD_CFLAGS="-g -O2 -fbracket-depth=1024” ../gcc-4.9.0/configure ...
Chris
On 12/07/2014 4:52 am, Franzi Edo. wrote:
make CFLAGS="-g -O2 -fbracket-depth=512”
(512, 1024, 2048 … no way)!
For a cross-compiler I think this should be BUILD_CFLAGS and I suggest
1024 rather than 512 ?
Chris
On 4/05/2014 12:34 pm, Andrew Pinski wrote:
On Sat, May 3, 2014 at 5:48 PM, Chris Johns wrote:
On 3/05/2014 10:57 pm, Franzi Edo. wrote:
Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the
On 4/05/2014 12:34 pm, Andrew Pinski wrote:
On Sat, May 3, 2014 at 5:48 PM, Chris Johns wrote:
On 3/05/2014 10:57 pm, Franzi Edo. wrote:
Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the
/libc/include
\
--with-mpfr=${PATH_TOOLS_GCC}/cross/mpfr-${MPFR_VER} \
--with-gmp=${PATH_TOOLS_GCC}/cross/gmp-${GMP_VER} \
--with-mpc=${PATH_TOOLS_GCC}/cross/mpc-${MPC_VER}"
Any idea?
Add CFLAGS="-O2 -fbracket-depth=1024" to the command line before configure.
Chris
Regards,
Edo
turning a simple problem into a complex one.
-Chris
hmarks across a wider range of code than just spec (which is notoriously
"hacked" by compiler developers) and Clang generates better code (and faster)
than GCC in many cases.
-Chris
Hi,
My name is Chris Gallimore and I am a headhunter. I am currently recruiting
for a compiler design engineer with knowledge of GCC to join Ericsson in the
UK. I was hoping that somebody here might be interested or might know
somebody. If so, please drop me an email at chris.gallim
things from the clang
> front-end, but also still allow the more in-depth analysis done by our
> tree-ssa code.
FWIW, the Clang static analyzer uses just such a representation: it is a CFG
formed out of AST nodes.
-Chris
s proposal has not been implemented, and does not
reflect the details of what we're implementing in Clang (Doug can give more
details if you're interested). Doug and Daveed are working closely on the
modules WG, which will eventually bring forward an updated proposal.
-Chris
On Nov 27, 2012, at 11:05 PM, Xinliang David Li wrote:
> On Tue, Nov 27, 2012 at 10:40 PM, Chris Lattner wrote:
>>
>> On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
>>
>>> Chris Lattner writes:
>>>> Clang has fantastic support for PCH... and soo
On Nov 27, 2012, at 9:08 PM, Miles Bader wrote:
> Chris Lattner writes:
>> Clang has fantastic support for PCH... and soon modules. We don't
>> plan to drop PCH support when modules is implemented.
>
> Do you have a pointer to the modules proposal clang will
GCC terminology, both use a "streaming" approach for
writing out code, and a lot of the mechanics of that streaming logic are
similar. Modules adds a bunch of additional logic on top of what PCH uses
though.
-Chris
ntastic support for PCH... and soon modules. We don't plan to drop
PCH support when modules is implemented.
-Chris
windows. I'm not sure how important these communities are though...
-Chris
>
> Removing PCH will give us more implementation freedom for the memory
> management project
> (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives).
>
> With some effort, we could revive the str
Basile Starynkevitch wrote:
On Thu, 19 Jul 2012 13:23:40 +1000
Chris Jones wrote:
Is there any reason that I can't create a new front-end translator for
gcc using QT?
GCC being a free GPLv3 software, you could always fork it and do that. But I am
not sure
to understand what you reall
Is there any reason that I can't create a new front-end translator for
gcc using QT?
Regards
--
Chris Jones @ kernel.devproj...@gmail.com
also on oracle.kernel...@gmail.com and netbsd.kernel...@gmail.com
OpenSUSE 12.1 (Primary)|TinyCore|Slitaz|Parabola|OpenIndiana|NetBS
put into a seperate inline namespace, so compiling fails at
link-time rather than at run-time?
Chris
David Brown wrote:
On 11/06/2012 09:45, Chris Jones wrote:
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task?
I would think that would depend
Is it possible to modify the source code of gcc to enable to compilation
of a completely new programming language, as yet unrecognized? How much
of a big job would I be looking at for such a task?
Regards
--
Chris Jones
OpenSUSE Linux x86_64 (PC)|Android (Smartphone)|Windows
compiler
adds something) really like this. OTOH, being able to support this well
requires that all warnings have an associated -Wno-XX flag associated with them.
-Chris
7;t
support them, because you can do:
#ifndef __has_builtin
#define __has_builtin(x) 0
#endif
in your code, but you can't do anything like this for #assertion. That and
assertions don't have any coverage over the features that you're interested in,
and the grammar doesn't have a good way to handle multiple cases like
features/attributes/extensions/etc.
-Chris
magic, like __LINE__ for instance? I am still not sure what you are
> asking...
Yes, they are compiler magic. __has_attribute() __has_extension() etc all work
the same way as well.
> Interestingly enough:
> $ cat q.c
> __has_builtin
> $ clang -E q.c
>
Nice catch, fixed in r149397. Thanks!
-Chris
On Jan 30, 2012, at 7:56 AM, Ludovic Courtès wrote:
> Hello,
>
> Chris Lattner skribis:
>
>> On Jan 20, 2012, at 5:24 PM, Jonathan Wakely wrote:
>>
>>> On 21 January 2012 00:32, Vincent Lefevre wrote:
>>>> On 2012-01-20 23:28:07 +, Jonath
produces:
t.c:1:1: error: unknown type name 'Int'; did you mean 'int'?
Int foo (void)
^
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
:)
-Chris
that GCC's fault too?
If fact, some do:
http://clang.llvm.org/docs/LanguageExtensions.html#feature_check
-Chris
artup time.
-Chris
On Jan 21, 2012, at 12:14 AM, Basile Starynkevitch
wrote:
> On Sat, 21 Jan 2012 01:32:29 +0100
> Vincent Lefevre wrote:
>
>> On 2012-01-20 23:28:07 +, Jonathan Wakely wrote:
>>> May I politely suggest that this is the wrong place to compl
On 11/11/2011 3:17 PM, Andrew Pinski wrote:
On Fri, Nov 11, 2011 at 12:13 PM, Chris Metcalf wrote:
I'm cc'ing the gcc mailing list with this reply, so if someone there
can provide an authoritative statement, that would be great. It looks
like right now the i386/x86_64, ia64
On 11/11/2011 1:09 PM, Roland McGrath wrote:
2011-11-09 Chris Metcalf
* bits/byteswap.h (__bswap*): Use __builtin_bswap for gcc 4.3 and
above. Improves code generation for gcc 4.3 and 4.4 compilers
without bswap pattern detection.
This seems reasonable if some GCC folks can
uild glibc. Seems
pretty yucky to me.)
Take a look at the "gcc and glibc from scratch" section of
http://www.tilera.com/scm/source.html . I don't know if this will handle
your problem, but we do end up with libgcc_eh.a when the dust settles, and
it avoids having to build uClibc :-)
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
On Mar 13, 2011, at 12:42 PM, Steven Bosscher wrote:
> (sorry Chris, I forgot the list)
>
> On Mar 13, 2011, at 11:59 AM, Chris Lattner wrote:
>
>> Sorry, I actually mean 255 of course, because of the NO_SECT
>> sentinel. Here are the relevant bits from nlist.h.
On Mar 13, 2011, at 12:05 PM, Jack Howarth wrote:
> On Sun, Mar 13, 2011 at 11:55:02AM -0700, Chris Lattner wrote:
>>
>> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>>
>>>> Yes, I agree that this is a better solution. This error was put into the
&g
"things worked"
>> only out of luck before.
>
> Interesting, so there is no -ffunction-section type tricks at darwin?
Correct, darwin doesn't support that flag in a useful way. Instead, macho has
a (poorly defined and understood) concept of "atoms" tha
On Mar 13, 2011, at 11:55 AM, Chris Lattner wrote:
> On Mar 13, 2011, at 11:26 AM, Jack Howarth wrote:
>
>>> Yes, I agree that this is a better solution. This error was put into the
>>> linker to detect some overflow conditions for part of the code that
>>> ex
things worked"
>> only out of luck before.
>>
>> -Chris
>
> Chris,
> Is there any documentation or example code on how to properly use
> subsections in mach-o?
> My fear is that we are moving from one poorly documented technique to another
> which may
ey won't
> happen for 6-9 months at best), we always we have to worry that they will
> break this
> 'feature' somewhere else in their tool chain. Better to follow the strictest
> possible reading
> of mach-o object format to protect ourselves from overzealous Apple interns.
Yes, I agree that this is a better solution. This error was put into the
linker to detect some overflow conditions for part of the code that expected
the section number to only be a byte. It is likely that "things worked" only
out of luck before.
-Chris
belf for
> FSF gcc on darwin). My understanding was that the lto design did not allow
> the number
> of sections required in the lto files to be reduced.
Hi Jack,
Please file a bug against the apple bug tracker explaining exactly what you
need to work with some example .o files.
-Chris
On 2/16/2011 3:46 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 12:39 PM, Andrew Pinski wrote:
>> On Wed, Feb 16, 2011 at 12:35 PM, Chris Metcalf wrote:
>>> For what it's worth, the Tilera 64-bit architecture (forthcoming) includes
>>> support for a 32-bit compat
the 64-bit and 32-bit binaries just by the Elf class, a
proposed by H.J. above. This seems plausible given that it does capture
the differences correctly; everything else is the same, just the Elf
class. (And we use /lib vs /lib32 on the 64-bit platform to support the
32-bit shared libraries, etc.)
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
On Dec 5, 2010, at 9:49 AM, Chris Lattner wrote:
>
> On Dec 5, 2010, at 3:19 AM, Richard Guenther wrote:
>
>>> $ clang t.cc -S -o - -O3 -mkernel -fomit-frame-pointer -mllvm
>>> -show-mc-encoding
>>> .section__TEXT,__text,regular,pure_inst
ne noalias i8* @_Z4testl(i64 %count) ssp {
entry:
%0 = tail call %0 @llvm.umul.with.overflow.i64(i64 %count, i64 4)
%1 = extractvalue %0 %0, 1
%2 = extractvalue %0 %0, 0
%3 = select i1 %1, i64 -1, i64 %2
%call = tail call noalias i8* @_Znam(i64 %3)
ret i8* %call
}
More information on the overflow intrinsics is here:
http://llvm.org/docs/LangRef.html#int_overflow
-Chris
architectures where you
>> have to load a large constant), but it is slightly worse code than what
>> Chris Lattner showed.
>
> It's possible to improve slightly on the LLVM code by using the
> overflow flag (at least on i386/amd64), as explained in this blog
> post:
st forces the size passed in to operator new to -1ULL, which
throws bad_alloc.
-Chris
ee whether this is feasible or not.
>
>
> Another addition in a similar vein would be __nonaligned, for targets which
> cannot directly access non-aligned data. The loads and stores would be done
> byte-wise for slower but correct functionality.
Why not just handle this in the frontend during gimplification?
-Chris
usable. If
you're interested in LLVM, please follow up on the llvmdev mailing list.
-Chris
2.8 Announcement:
http://lists.cs.uiuc.edu/pipermail/llvm-announce/2010-October/36.html
2.8 Release Notes:
http://llvm.org/releases/2.8/docs/ReleaseNotes.html
LLDB: http://lldb.llvm.org/
On Sep 15, 2010, at 12:23 AM, Kevin André wrote:
> On Tue, Sep 14, 2010 at 17:55, Chris Lattner wrote:
>>
>> On Sep 14, 2010, at 7:22 AM, David Edelsohn wrote:
>>
>>> On Mon, Sep 13, 2010 at 6:33 PM, Ian Lance Taylor wrote:
>>>> From the perspect
hus the llvm backend and code generator) if you don't
want to. Just convert from clang ASTs to generic or gimple.
-Chris
ssigned).
The code in the apple branch on the fsf server *is* copyright assigned to the
FSF.
-Chris
hing to do, particularly when it
> doesn't cost anything.
Hi Nicola,
I don't have the authority to do this, it is not my copyright to assign.
-Chris
us on the code that is already assigned to the FSF.
-Chris
nt
> that allows them to sub-assign but that sounds even more complicated to
> me.)
Right, that's why it is reasonable (to me) to assume that stuff in the apple
branch on the fsf servers are fair game.
-Chris
t on opendarwin.
I'm not a lawyer, so this isn't legal advice, just my understanding of FSF
policies and the mechanics of how the copyright transfer works.
-Chris
back into the state to repro the problem takes a long time.
It is a useful feature and Apple did implement it in their toolchain, but it's
worth noting that they've ripped it out since then. Their specific
implementation was too fragile to work consistently.
-Chris
er.
Some information is here:
http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html
It currently supports darwin x86 quite well. ELF/PECOFF and ARM support are in
active development. It sped up clang by ~10% at -O0 -g.
-Chris
assortment of improvements and new features, this is the
first release to officially include the DragonEgg GCC plugin. See
http://dragonegg.llvm.org/ for more details.
-Chris
're looking for history, look at both sides of it.
I wrote a long and detailed email about GCC forks, long term corporate
branches, the impact of the GPL on all this, etc. However, it is so off topic,
I'm happy to just delete it and drop the issue :-)
-Chris
On Apr 26, 2010, at 12:23 PM, Ian Lance Taylor wrote:
> Chris Lattner writes:
>
>> w.r.t. "hoarding", I'll point out that (in the context of GCC) being
>> able to enforce copyright is pretty useless IMO. While you can
>> force someone to release th
er because there are substantially
different goals involved. The LLVM project is much more focused on the
technology and the community, the GCC project is more focused on ensuring
software freedom (as defined by the FSF). There isn't anything wrong with
having different goals.
-Chris
d to ask your employer
> for some paper to legally contribute code? Are you sure you are not
> exposing yourself to a legal risk?
This is such an incredibly immense scoop of FUD that I couldn't help but
respond to it :-) Isn't this thread supposed to be about finding ways to
improve GCC?
-Chris
held by people.
In any case the aims of the FSF are quite clear, and IMO it seems that the
explicit copyright assignment is a real and necessary part of achieving those
aims. Different projects just have different goals.
-Chris
Who
> defines the conditions?
That web page is everything that there is. I am aware that this is not as
legally air-tight as the FSF disclaimer, but empirically many companies seem to
have no problem with it.
-Chris
On Apr 25, 2010, at 2:47 AM, Manuel López-Ibáñez wrote:
> On 25 April 2010 06:20, Chris Lattner wrote:
>>
>> On Apr 23, 2010, at 3:35 PM, Manuel López-Ibáñez wrote:
>>
>>> On 24 April 2010 00:18, Alfred M. Szmidt wrote:
>>>>
>>>> The dis
ture legal troubles.
On what do you base these assertions? Every point seems wrong to me.
-Chris
lic.
I'm not sure why you think that. Unlike the FSF, all of the LLVM projects'
requirements are public:
http://llvm.org/docs/DeveloperPolicy.html
LLVM does not require a copyright assignment. People can send in random
patches and they get immediately applied.
-Chris
hook points unless it wants to do
> only code completion after . and -> (and not e.g. after :: and many other
> tokens). For C++ tentative parsing is probably the biggest problem that
> needs solving.
I predict it won't be accepted into GCC mainline either, but we'll see. :)
-Chris
gt;> effort?
>>
>> Surely trying to persuade people to contribute to some other project
>> rather than gcc is off-topic here. Even if not, it's pretty hostile.
>
> Would such a feature be accepted in GCC? Otherwise, this seems like a
> misunderstanding. Chris was not
er much faster (may be 2 times
> because I did not use -fwhole-program). I'll post the results in an hour.
Sounds good, thanks! I suspect the gcc build times will improve.
-Chris
-O3 and dragonegg with LTO to get a better comparison?
-Chris
h seems highly, uh, "inspired" from the exact same functionality in
Clang. Any reason not to contribute to that effort?
-Chris
tion aspects are
just as important. You can definitely implement all this by forking out to an
assembler etc, the implementation will just not be great.
-Chris
ng without some
major architecture changes.
-Chris
x27;t matter much because there has surely been significant progress
since gcc 4.2.
-Chris
ously small snippet. No
> doubt other C++ hackers have particular annoyances.
>
Hi Benjamin,
I wrote a little blog post that shows off some of the things that Clang can do.
It would be great to improve some of GCC/G++'s diagnostics in a similar way:
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
-Chris
ly, this is one of the reasons I'm particularly interested in common
errors like missing semi colons, . vs ->, use of things like <::foo>,
explaining overload set failures, etc.
> The valid code issues I can flag in the existing bug reports.
Ok, thanks again.
-Chris
ow if
C++'0x affects this though.
7) There are some clang bugs here. Access control is not yet enabled by
default (affects 20397, 39728), and a variety of other bugs (affects 14283,
38612). I file Clang PR#6782/6783 to track these.
Thanks again for putting this together,
-Chris
C and (real soon now) C++
compiler that is GCC-free. Further questions should definitely go to the llvm
or clang lists. More information is at http://clang.llvm.org/
-Chris
offer on site.
Thank you for your attention to this matter.
Chris Perry
NRG INC
50 Cockle Hill Road
Salem, CT 06420
401-484-5022 - direct
203-413-3348 - fax
WE BUY-SELL-TRADE-CISCO-LUCENT-SUN-NORTEL-AVAYA-DIALOGIC-FOUNDRY & MANY MORE
NOW PURCHASING TEST AND MEDICAL EQUIPMENT!
If you do
on in this example though. The code is
probably using some undefined behavior and getting zapped.
-Chris
> This function produces completely bogus code in LLVM, presumably because
> some kind of LTO proves that CC1000SendReceiveP is never written. Of course,
> this assumptio
f the companies who employed the original
authors
had the alternative of hooking into GCC without contributing their
code?
There's some evidence that they would not have.
I thought it *was* a goal to allow attaching new (GPL3 compatible)
backends?
-Chris
s/2.6/docs/ReleaseNotes.html
Cheers,
-Chris
On Sep 24, 2009, at 7:57 AM, Jason Merrill wrote:
On 09/15/2009 12:35 PM, Chris Lattner wrote:
The second major feature of Blocks vs c++ lambdas is that they can be
"copied onto the heap". This allows things like "Grand Central
Dispatch"
to work: you can write code
1 - 100 of 347 matches
Mail list logo
