On Sat, 2024-12-28 at 09:00 -0600, Paul Markfort via Gcc wrote:
> I realize that C is not a line oriented language and usually
> completely ignores line termination characters (so yes this is
> probably not a simple thing to do).
You probably really want this capability added to the preprocessor,
Many of the GNU toolchain projects are adding zstd compression. This
is good, but the configure support for this is not ideal.
In particular for GCC, there are a number of issues.
The first problem is that the two subdirectories that use zstd
(libbacktrace and gcc) use very different methods to
I've tried this with both older versions as well as GCC 12.3 (latest I
have access to). This is on GNU/Linux on x86_64.
I have the following code:
#include
class Exception : public std::exception
{
public:
Exception(const char* text, ...)
__attribute__((format(printf, 2,
On Wed, 2023-08-09 at 11:14 +0200, Luís Carlos Carneiro Gonçalves via
Gcc wrote:
> Without -O3 and -O2 the OpenCL gave consistently good results without
> returning any error.
>
> I think my code is Ok but I open to criticism.
By "has a bug" we don't necessarily mean something that is obviously
w
On Sat, 2023-07-08 at 12:33 -0400, Paul Smith wrote:
> On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote:
> > That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not
> > suitable for a constexpr.
>
> Oh right, obviously.
>
> Well, I guess I'll have t
On Sat, 2023-07-08 at 17:30 +0200, Andreas Schwab wrote:
> That needs to be sysconf (_SC_SEM_VALUE_MAX), and thus is not
> suitable for a constexpr.
Oh right, obviously.
Well, I guess I'll have to try to figure out why it's not defined.
Sigh.
I have been trying to make clangd work with my GCC-based builds (it's a
long story don't ask) and after a ton of effort (and, unfortunately,
some hacks due to clangd limitations) there is one thing left that's
causing a lot of spurious errors:
In gcc/libstdc++-v3/include/bits/semaphore_base.h we f
On Tue, 2023-06-06 at 16:36 +0800, Julian Waters via Gcc wrote:
> Sorry for my outburst, to the rest of this list. I can no longer stay
> silent and watch these little shits bully people who are too kind to
> fire back with the same kind of venom in their words.
Many of us have had Dave in our kil
On Mon, 2023-05-29 at 17:16 -0300, Alexandre Oliva via Gcc wrote:
> On May 17, 2023, Arsen Arsenović wrote:
>
> > ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to
> > implement various bits of LSP functionality, such as handling
> > multiple TUs.
>
> I recall advancing that suggestio
On Thu, 2023-05-18 at 10:52 -0400, Ben Boeckel wrote:
> PCH files can "be ignored" in some sense because they can be
> recalculated from `#include` files pretty easily. Module files,
> however, cannot.
This makes it even more important that there be a GCC-based LSP server,
if a Clang-based one can
On Wed, 2023-05-17 at 18:38 -0400, Ben Boeckel wrote:
> > egregious example I'm aware of is that they look for GCC-named
> > precompiled headers (.gch), even though the Clang PCH format is
> > completely different. So if Clang (and the LSP servers built on
> > it) find a .gch header file they will
On Wed, 2023-05-17 at 17:28 +0300, Eli Zaretskii via Gcc wrote:
> If there are no current plans for implementing LSP, I hope someone
> will work on that soon, given that Emacs can now use it, and because
> having a GCC-based LSP implementation will allow people to use their
> installed GCC as the b
FYI I reported this crash to the GCC bugzilla yesterday:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
and it was closed as a dup of this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
If people want to watch it.
On Sun, 2023-05-14 at 10:50 +, Thomas Backlund via Gcc wrote:
>
OK here's something super-strange I discovered:
Enabling -faddress=sanitize in GCC, causes the glob(3) function to
misbehave.
I'm using GCC 11.3 / glibc 2.35 (x86_64 native). I have this simple
program:
$ cat /tmp/tstglob.c
#include
#include
int main(int argc, char *argv[])
{
glob_t gl =
On Wed, 2023-03-01 at 20:59 +0300, Berke Yavas via Gcc wrote:
> One thing I haven't figured out yet, how can I debug C++ frontend(or
> any other language frontend) with CLion. If anybody managed to do
> this (or using another IDE), could you please share your settings
> with me?
Since CLion is (a)
What is going on out there these days? I've added more addresses from
the GCC mailing list to my killfile in the last week than in the
previous two years combined.
Yeesh.
On Wed, 2022-12-14 at 17:32 +0200, Mohamed Atef via Gcc wrote:
> Hello all,
> As I mentioned before, I don't have much time to contribute.
> So is there any way I can contribute some medium project I can work
> on but myself in the long run? I loved this community, I contributed
> before so can
On Tue, 2022-12-13 at 11:35 -0600, Dave Blanchard wrote:
> *angry, grumpy, pissed off, GNU-hating distro maintainer enters the
> chat*
> nobody on the mailing list has any idea what it could possibly be I
> guess, since nobody responded to my email.
Yes, I can't imagine any other reason no one has
On Tue, 2022-12-13 at 11:28 -0500, Jim Anderson via Gcc wrote:
> 1) I could not find any place to download the man page. I lost my
> internet connect and I have not man page :(
You didn't say what platform you're working on, nor how you obtained
the GCC that you are using, but recall that the GCC
On Sat, 2022-11-26 at 03:20 -0600, Dave Blanchard wrote:
> GNU GCC/GLIBC IS THE MOST PAINFUL PIECE OF SHIT FUCKING SOFTWARE ON
> THE PLANET TO BOOTSTRAP.
Seems like a good time to remember the old adage, if you think everyone
else is the asshole then you should consider that it's really you who's
On Tue, 2022-10-18 at 14:14 -0400, Siddhesh Poyarekar wrote:
> On 2022-10-18 14:13, Siddhesh Poyarekar wrote:
> > only Job Corbet's questions to Carlos/David are pending an answer;
>
> s/Job/Jon/ sorry about misspelling your name.
I thought it was great! We all have known for years that Jon has
std::tuple elements are retrieved via std::get<> (template) not
[] (array); have the generated output string match this.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): Use <> not [].
---
The previous patch seems uncontroversial to me. I don't know about this
Show 0-based offsets for std::tuple members, to match with std::get.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdTuplePrinter): don't increment
self.count until after generating the result string.
---
libstdc++-v3/python/libstdcxx/v6/printers.py | 13 +++
On Sun, 2021-06-06 at 17:41 -0400, Paul Smith wrote:
> How can I figure out why the compiler decides, while compiling
> foo.cxx, that MyClass is virtual and needs a vtable when as far as I
> can tell it's not (if I use nm on MyClass.o I see no hints of vtable
> etc.)
Err... I
I have a class which is NOT, as far as I can see, polymorphic.
It doesn't inherit from any other class and none of its methods are
declared virtual. The class implementation and all its callers all
compile just fine.
Is there some other way that a class can be thought to be virtual,
stealthily (
On Tue, 2021-06-01 at 11:50 -0400, David Edelsohn via Gcc wrote:
> The current, active license in GPL v3.0. This is not an announcement
> of any change in license.
>
> Quoting Jason Merrill:
>
> "GCC's license is "GPL version 3 or later", so if there ever needed
> to be a GPL v4, we could move t
On Mon, 2021-04-26 at 21:01 +, Romain GEISSLER via Gcc wrote:
> So anyone has some insider information about the FSF copright
> assignment process ?
I have no insider information but you can try asking on
gnu-prog-disc...@gnu.org (I think that list is open)
I assume you're communicating with
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> I have a templated class C that required its type T to have operator
> bool() defined in order to work properly.
Never mind, I think there was some local error where things were not
being recompiled when they should be. I don't kn
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> But!! When I nm the individual cxx.o files none of these operator
> symbols appear, at all!
As you might have expected, this turns out to be wrong: the symbols
were just in a set of object files that I did not expect. I'll see
On Sun, 2020-10-04 at 03:36 -0400, Paul Smith wrote:
> I made it static inline like this:
>
> static inline bool operator!(T t) { return t != T::EMPTY; }
Obviously in my real code I used t == T::EMPTY here... :-/
I'm using GCC 8.1.0 / binutils 2.30 (I plan to upgrade to latest stuff
in the next few weeks or so...), on GNU/Linux Intel 64bit.
I have a templated class C that required its type T to have operator
bool() defined in order to work properly.
I want to use that with a enum class so clearly that doe
On Wed, 2020-08-12 at 15:05 -0500, Segher Boessenkool wrote:
> > As usual I've built my own version of GCC, and then I check it into
> > Git so that all builds can use this one canonical compiler
> > regardless of operating system, etc.
>
> There's your problem. Git is not an archiver. Git does
On Wed, 2020-08-12 at 16:53 +0100, Jonathan Wakely wrote:
> On Wed, 12 Aug 2020 at 14:33, Paul Smith
> wrote:
>
> > I'm not talking about PREFIX/lib, though. As can be seen from my
> > question I'm talking about PREFIX///lib. This is
> > where GCC keeps it
On Wed, 2020-08-12 at 15:37 +0200, Jakub Jelinek wrote:
> The important thing is that GCC wants to be relocatable, so most
> paths are not hardcoded into the compiler, but depend on where the
> gcc driver actually is. One can then just move the whole gcc tree
> somewhere else and it should still w
On Wed, 2020-08-12 at 15:08 +0200, Jakub Jelinek wrote:
> > I think it's worth adding this to bugzilla. Depending on the
> > existence of empty directories seems less than ideal.
>
> But canonicalizing the paths without taking the filesystem state into
> account will significantly change the behav
This is a kind of esoteric problem, but all the more annoying for that.
As usual I've built my own version of GCC, and then I check it into Git
so that all builds can use this one canonical compiler regardless of
operating system, etc.
After being checked into Git, the compiler started failing to
On Mon, 2020-08-03 at 17:02 -0600, Martin Sebor wrote:
> If the code is designed to treat Node sort of like a struct with
> a flexible array member I would suggest to make that explicit by
> adding a zero-element array member to Node and using it to access
> other memory. E.g., add:
>
> unsi
I'm testing upgrading from GCC 9.3 to 10.2 and I'm seeing this new
warning:
$ g++ --version
x86_64-unknown-linux-gnu-g++ (GCC) 10.2.0
...
$ g++ -Wall -Werror -O2 -c -o stringop.o stringop.cpp
In member function 'void LeafNode::markUpdate()',
inlined from 'void applyTo(LeafNod
Hi all; thanks for the help recently with sysroot compilers. I was
able to get things building following advice from Joseph and Jonathan.
I did want to mention that I noticed that GCC got non-trivially slower
between my previous version (8.1) and this new version (9.3).
I have a decently-sized C
On Wed, 2020-03-11 at 17:15 +, Jonathan Wakely wrote:
> My thinking was to build GCC inside the container, then package up the
> results and install that on your dev machines (outside a container).
> But actually that won't work because you'd also need to package the
> glibc from the container,
On Wed, 2020-03-11 at 14:17 +, Jonathan Wakely wrote:
> On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > The tricky bit is that although both the host and target are always
> > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> > much older systems
On Mon, 2020-03-09 at 22:01 +, Joseph Myers wrote:
> On Mon, 9 Mar 2020, Paul Smith wrote:
> > I have a sysroot I've created (downloading RPMs from older systems and
> > unpacking them) which is sufficient to build GCC (and binutils etc.) I
> > need the GCC binari
I have a somewhat complex makefile that I've been using for many years
to build GCC: it builds tools needed (make, bison, flex, m4, binutils),
downloads the source prerequisites and links them, etc.
I'd like some advice, hopefully an easy answer, that allows me to
simplify that system, which curre
On Fri, 2020-02-28 at 17:37 +0100, Martin Jambor wrote:
> > Recently Honza, me and others discussed LTO's interaction with
> > build systems, and that perhaps the module mapper could be
> > generalized for other purposes. (Yes, still need to resurrect my
> > Make PoC)
>
> see also the "Create a g
On Thu, 2020-02-27 at 16:58 +, Jonathan Wakely wrote:
> > That's a problem then as were assuming a user's build system for this
> > to work. I mean for now its fine but in the future wouldn't it de a
> > good ideal to not assume this?
>
> It works fine for everybody. There's just an optimisati
On Wed, 2020-02-26 at 17:23 +, Jonathan Wakely wrote:
> I compiled this program:
>
> #include
>
> int main()
> {
> std::unordered_map m;
> m[3] = 5;
> return m[1];
> }
>
> And with Fedora 31's GDB 8.3.50 I get this behaviour:
I can't reproduce with a simple test either. But in my fu
Hi all. I was seeing a strange error in GDB (8.2.1) debugging some C++
code while trying to print a value. The pretty printer was throwing Python
exceptions.
Debugging it I discovered the problem, which is here (from GCC 9.2):
libstdc++-v3/python/libstdcxx/v6/printers.py:
# Starting with the
On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > In my experience the output of git log is a total mess so cannot
> > > replace ChangeLogs. But we can well decide to drop ChangeLog for
> > > the testsuite.
> >
> > Well, glibc has moved to extracting them from git, building
> > polici
On Mon, 2020-01-13 at 11:33 +, Jonathan Wakely wrote:
> I imagine a lot of people are going to feel lost in the first few
> weeks of using Git.
I don't do IRC (and I'm not a GCC dev :)) but I'm happy to help via email.
One thing I'll say though: if you're an Emacs user then IMO you should run
On Mon, 2019-12-09 at 18:09 +, Andrew Haley wrote:
> On 12/9/19 5:03 PM, Nicholas Krause wrote:
> > > https://gcc.gnu.org/projects/cxx-status.html#cxx11
> >
> > I'm asking of what support exists in the gcc codebase itself not
> > for other projects using gcc.
>
> That is what you got.
IIUC N
me to investigate further I'm happy to
do that: please provide some pointers/advice for debugging.
On Wed, 2019-05-01 at 10:56 -0400, Paul Smith wrote:
> On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote:
> > > Unfortunately my GCC is heavily optimized and stripped so backtr
On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote:
> > Unfortunately my GCC is heavily optimized and stripped so backtraces
> > are useless. I will generate a debuggable GCC and see if I can get
> > more info on the ICE.
>
> I have created a GCC with debug enabled so
On Tue, 2019-04-30 at 09:43 -0400, Paul Smith wrote:
> Here's the thing: I added the "-MD -MF foo.d" options to the PCH file
> compile (I wanted to get a manifest of which files were included in the
> PCH file). Without those options I cannot reproduce this at all (in a
&
On Tue, 2019-04-30 at 09:34 -0600, Zan Lynx wrote:
> > In the meantime, does this remind anyone of an existing bug,
> > hopefully one that was fixed in 8.2 or 8.3?
>
> It does remind me of a race condition bug with a Makefile I wrote
> years ago.
>
> One or two build tasks did not properly depend
I have GCC 8.1.0 / binutils 2.30 on GNU/Linux 64bit (built locally).
My codebase is almost all C++.
I'm implementing precompiled headers and it was going well. However,
sometimes a PCH file is generated that causes the compiler to ICE when
trying to use it during a source file compilation:
:
On Sat, 2019-03-23 at 22:54 +0530, Vinaya Dandur wrote:
> My mistake. Thanks, but even if you include the issue still
> exists. Yes TRAP_BRKPT is not included in signal.h, however gcc somehow
> finds the definition for TRAP_BRKPT and I don't know how. This works in
> other hosts.
A peruse of the
On Sat, 2019-03-23 at 21:55 +0530, Vinaya Dandur wrote:
> Thank you. Yes it is not an issue with the GCC but the TRAP_BRKPT is
> defined in signal.h which the GCC could include but can't find the
> constant mentioned.
> Is there any way this problem could be resolved ? any pointers I can
> get ?
I
I was looking through the diffs between GCC 8.1.0 and GCC 8.2.0 and saw
this change, which doesn't look right to me: it changes munmap() to use
the new static_pagesize variable, but that variable is not assigned
until after it's used. Since it's global it's always 0, so this code
runs munmap(0, 0)
On Fri, 2018-07-27 at 14:53 +, Michael Matz wrote:
> perl is currently included in the bootstrap set. There's no reason
> why python couldn't be included as well,
If Perl is already in the bootstrap set and the awk scripts are hard to
maintain then why can't the awk scripts be rewritten in Pe
On Mon, 2018-07-09 at 10:57 -0600, Jeff Law wrote:
> On 07/09/2018 10:53 AM, Janus Weil wrote:
> > 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> > > David Edelsohn :
> > > > > The truth is we're near the bleeding edge of what conventional tools
> > > > > and hardware can handle gracefully. Most j
On Wed, 2018-02-07 at 19:26 -0500, Paul Smith wrote:
> Thanks for the conversation. I'm moving forward with a real global
> operator new/delete and working out the magic needed to ensure those
> symbols are not global in our shared library.
I remember one annoying thing I ran
On Thu, 2018-02-08 at 11:26 +, Michael Matz wrote:
> As I said upthread, the mangled name of a type (sans _Z prefix) is what is
> stored as the type name for RTTI purposes (i.e. std::type_info::name()).
>
> It's just that the debug info currently doesn't have any reference to that
> definite
On Thu, 2018-02-08 at 01:17 +0100, Marc Glisse wrote:
> On Wed, 7 Feb 2018, Paul Smith wrote:
> > > > My question is, what do I need to do to ensure this behavior
> > > > persists if I create a global operator new/delete?
> > > >
> > > > Is it
On Wed, 2018-02-07 at 16:38 -0700, Martin Sebor wrote:
> I'm not sure I see how defining operator new inline can work
> unless you recompile the world (i.e., all the DSOs used by
> the program, including libstdc++). As Marc already hinted,
> if libstdc++ dynamically allocates an object using the de
On Wed, 2018-02-07 at 11:32 +0100, Marc Glisse wrote:
> On Tue, 6 Feb 2018, Paul Smith wrote:
>
> > My environment has been using GCC 6.2 (locally compiled) on
> > GNU/Linux systems. We use a separate heap management library
> > (jemalloc) rather than the libc allocator.
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all fo
On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote:
> Your problem is probably linked to these issues, if you want to follow
> them:
>
> gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932
> gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013
>
> As Carl said, it's a good idea to t
Hi all; are we on track to have a GCC 7.3 sometime in the next few
weeks, as per usual for the last few years? Not looking for a date,
just a feeling.
I'm not sure why my toolchain rollouts always seem to fall right around
the time of a new fix release for GCC...
Thanks!
On Tue, 2017-05-02 at 18:17 -0500, Joel Sherrill wrote:
> With gcc 6.3.0, we have this in our build recipe:
>
> %define mpfr_version 2.4.2
> %define mpc_version 0.8.1
> %define gmp_version 4.3.2
Best thing to do is look at the contrib/download_prerequisites script
that comes with the GCC
On Sat, 2017-01-21 at 13:25 -0800, L A Walsh wrote:
> It may be this should go to "gcc-help", due to my
> not seeing my error, but
Probably better to start there... if it's really a GCC bug you'll be
quickly redirected here.
> for (i==0; i < sizeof(source)/(2*sizeof(source[0])); ++i) {
On Thu, 2017-01-12 at 21:49 +, Yuri Gribov wrote:
> Note that documentation for -static-libgcc explicitly mentions that
> There are several situations in which an application should
> use the shared libgcc instead of the static version. The most
> common of these is when
TL;DR:
I have an issue where if I have a .so linked with -static-lib* making
all STL symbols private, and if I throw an exception out of that .so to
be caught by the caller, then I get a SIGABRT from a gcc_assert() down
in the guts of the signal handling:
#0 0x7773a428 in raise () from /l
On Wed, 2016-09-14 at 10:13 +0100, Jonathan Wakely wrote:
> On 11 September 2016 at 22:38, Paul Smith wrote:
> > I wonder if someone can comment on this situation: I'll do some testing
> > but I likely can't test everything.
> >
> > I'm creating DSO&#x
I wonder if someone can comment on this situation: I'll do some testing
but I likely can't test everything.
I'm creating DSO's for GNU/Linux with GCC 4.9.2 right now. I want to
upgrade to GCC 6.2.0. My code is written in C++. I'm aware of the C++
STL ABI break in GCC 5.x.
I have users who will
On Wed, 2016-07-27 at 16:06 +0200, Richard Biener wrote:
> I'm doing 4.9.4 now and 6.2 only afterwards so you can expect 6.2 earliest
> in about three weeks.
OK, thanks for the info. I'll have to discuss with folks and see if
they can wait that long, and take a look at the issues in 6.1 which are
Hi all. Don't want to be a noodge but is there any info on a timeline
for the 6.2 release?
I'm planning a major tools upgrade (from GCC 4.9.2) and I've been kind
of putting it off until 6.2 is out so I can jump to that... but the
natives are getting restless as they want some C++ features that ar
On Tue, 2015-01-06 at 09:43 +0100, Jakub Jelinek wrote:
> GCC trunk -fsanitize=undefined (in particular
> -fsanitize=nonnull-attribute)
> diagnoses it:
> /tmp/mystring.cpp:103:26: runtime error: null pointer passed as
> argument 2, which is declared to never be null
Unfortunately adding -fsanitize
On Tue, 2015-01-06 at 09:43 +0100, Jakub Jelinek wrote:
> On Tue, Jan 06, 2015 at 03:18:48AM -0500, Paul Smith wrote:
> > Hi all. It's possible my code is doing something illegal, but it's also
> > possible I've found a problem with -O3 optimization in GCC 4.9.2.
Hi all. It's possible my code is doing something illegal, but it's also
possible I've found a problem with -O3 optimization in GCC 4.9.2. I've
built this same code with GCC 4.8.2 -O3 on GNU/Linux and it works fine.
It also works with GCC 4.9.2 with lower -O (-O2 for example).
When I try a build
79 matches
Mail list logo
