On Mon, 2020-05-11 at 17:14 +0200, Moritz Strübe wrote:
> I just wanted to point out that Herbceptions do not only fix
> performance
> issues, but also code-size problems. While anything below 4GB of RAM
> is
> considered under-powered for a PC, typical deep embedded
> environments
> have someth
On Tue, 2020-05-12 at 11:16 +0200, Florian Weimer wrote:
> That can only happen if the embedded people do not bother to show up
> in
> numbers. Of course the tools will move in different directions.
True (;
> > That's why the proposal by Herb is a real surprise and I really
> > hope
> > it could
On Tue, 2020-05-12 at 12:07 +0100, Jonathan Wakely wrote:
> You're talking about C++ exceptions in general, but the problems you
> mention seems to be issues with specific implementation properties.
Possibly true, but this argument - that all the problems are related to
specific implementation and
Hello!
A code that I wrote was warning-free in GCC 4.9, GCC 5 and GCC 6. It
was also warning-free with some older GCC 7 experimental snapshots (for
example 7-20170409). But in the most recent snapshot (including the
first RC), it started to produce a warning about aliasing. The code
basically boil
On Tue, 2017-05-02 at 12:17 +0200, Richard Biener wrote:
> But this shows
> an issue with GCC 7 so please open a bugreport.
Here it is - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593
Regards,
FCh
On Thu, 2017-05-04 at 15:01 -0600, Martin Sebor wrote:
> Now that GCC 7.1 has been released, should 7.1 be added
> to the versions in Bugzilla so that bugs can be assigned
> the right version? (I'm using 7.0 in the meantime.)
>
> Or is there someone not on this list I might need to bug
> with thi
Hello!
I've got a project which - when compiled with "arm-none-eabi" GCC 7.1
without optimizations - produces quite a lot of such messages:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
In file included from
../../include/distortos/internal/scheduler/SoftwareTimerList.hpp:17:0,
On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote:
> > When compiling libssp, ssp.c, function __guard_setup:
> > O_RDONLY is undeclared (ssp.c:93:34),
> > ssize_t is an unknown type name (ssp.c:96:7), and
> > size_t is an unknown type name (ssp.c:113:
I forgot to say, that the procedure and resulting toolchain is closely
modeled after the one provided by ARM on:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
It just has couple of tweaks like slightly different options for
newlib, completely disabled C++ exceptions and uses the most
On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote:
> Just to check, this is actually an
> arm-none-eabi toolchain? I looked over the compilation flags and it
> looks like it supports all Cortex-M processor features like such a
> toolchain should. Most instructions I could find seemed to build a
> mor
On Thu, 2017-11-23 at 06:51 +, Andrew Roberts wrote:
> But I've never seen it take me to a different bug after adding a
> comment
> before.
>From my experience, this is normal - after you perform any operation on
particular bug, it then takes you to the next bug on your "my bugs"
list. Probab
Hi!
I've compiled gcc 8.0.1-RC-20180427 to test it with my projects.
There's one new warning for which I cannot tell whether this is a bug
in headers or a bug in gcc.
I have a header from ARM that looks like this (there are more such
functions than these two):
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8
Here's a minimal test case:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
$ cat test.cpp
extern "C"
{
void f1()
{
union some_type{
char a[2];
int b;
} variable;
}
void f2()
{
union some_type{
char a[2];
int b;
} variable;
}
}
$ arm-none-eabi-gcc test.cpp -c
On Mon, 2018-04-30 at 15:38 -0400, Nathan Sidwell wrote:
> On 04/30/2018 03:21 PM, Jonathan Wakely wrote:
> > Nathan, is this a regression for this testcase? IIUC the local
> > types
> > and the local variables should have no linkage, and not conflict.
> >
>
> that does seem plausible. Freddie,
On Fri, 2018-04-27 at 23:39 +0200, Jakub Jelinek wrote:
> The second release candidate for GCC 8.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427
>
> and shortly its mirrors. It has been generated from SVN revision
> 259731.
>
> I have so far bootstrapped and teste
Hi!
In one of my embedded projects I have an option to enable LTO. This was
working more or less fine for GCC 6 and GCC 7, however for GCC 8.1.0
(and binutils 2.30) - with the same set of options - I see something
like this
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
$ arm-non
On Fri, 2018-05-11 at 11:19 +0200, Richard Biener wrote:
> Hmm, can you try without --gc-sections? "Old" GNU ld versions have
> a bug that wrecks debug info (sourceware PR20882).
Yes - you are right. Without --gc-sections the errors are gone. The bug
was marked as resolved and fixed a year ago, h
On Fri, 2018-05-11 at 13:06 +0200, David Brown wrote:
> For the Cortex-M devices (and probably many other RISC targets),
> -fdata-sections comes at a big cost - it effectively blocks
> -fsection-anchors and makes access to file-static data a lot bigger.
> People often use -fdata-sections and -ffunc
On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> That's an interesting result. Do you have any non-LTO objects?
> Basically I'm curious what ld eliminates that gcc with LTO doesn't.
Whole project is compiled with LTO, part of the project is provided as
a library (which is archived with
On Mon, 2018-05-14 at 16:34 +0200, David Brown wrote:
> Interesting. Making these sections and then using gc-sections should
> only remove code that is not used - LTO should do that anyway.
My guess - expressed in the other e-mail to the list - is that the
things LTO cannot remove but --gc-sectio
On Tue, 2018-05-15 at 21:39 +0200, Freddie Chopin wrote:
> On Fri, 2018-05-11 at 18:51 +0200, Richard Biener wrote:
> > As to a workaround for the ld bug you can try keeping all .debug_*
> > sections. IIRC 2.30 has the bug fixed (on the branch).
>
> Indeed - "keeping&qu
21 matches
Mail list logo
