Mallikarjun,
Thanks for trying this. I agree with you that current C implementation
is far from optimal.
It is in our road-map with a different approach, which will not simply
port current functions from armv7-m to armv6-m. This task is low
priority due to less common usage of fp in Cortex-M0*, s
Running into an unexpected result with GCC with following case, but
not sure if it is a valid C++ case.
#define nullptr 0
enum nonetype { none };
template
class class_zoo {
public:
const T *data;
int length;
class_zoo (nonetype) : data (nullptr), length (0) {}
class_zoo (const
On Fri, Aug 15, 2014 at 6:33 PM, Richard Biener
wrote:
> On Fri, Aug 15, 2014 at 10:45 AM, Joey Ye wrote:
>> Running into an unexpected result with GCC with following case, but
>> not sure if it is a valid C++ case.
>>
>> #define nullptr 0
>> enum nonetype
Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
which is already in newlib mainline. I think it solves the same issue
in a slight different approach.
Does it work for you?
Thanks,
Joey
On Thu, Aug 14, 2014 at 4:52 PM, Joern Rennecke
wrote:
> For embedded targets with small
On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme
wrote:
>> From: Grissiom [mailto:chaos.pro...@gmail.com]
>> Sent: Friday, August 29, 2014 11:51 PM
>>
>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
> > The namespace _[a-z] is still available for the user. Which m
Sounds a good idea to me, here is the list I'm using:
#include "params.h"
#include "flags.h"
#include "tree.h"
#include "tree-pass.h"
#include "basic-block.h"
#include "function.h"
#include "hash-table.h"
#include "tree-ssa-alias.h"
#include "tree-cfg.h"
#include "tree-ssa-operands.h"
#include "tre
Markus,
-mmcu probably will not work for ARM architectured MCUs. Reason are
* Confusion. -mcpu is encouraged and already widely used for ARM
architectures. Introducing -mmcu will be very confusing.
* Expensive effort. Either supporting none, or supporting all. There
are large number of MCUs from A
On Wed, Nov 12, 2014 at 1:47 AM, Joern Rennecke
wrote:
> On 11 November 2014 16:22, Joey Ye wrote:
>> * Expensive effort. Either supporting none, or supporting all. There
>> are large number of MCUs from ARM eco-system partners. Supporting all
>> of them is a large pr
In this case ldm is loading at alignment address. It is just loaded
more than sizeof a. So it can be the bus that does not permit
accessing memory beyond address range of a. Such a case I don't
believe compiler is doing wrong.
On Mon, May 18, 2015 at 4:50 PM, Richard Earnshaw
wrote:
> On 18/05/15
-fstrict-volatile-bitfields doesn't work incorrectly in some cases
when storing into a volatile bit-field.
Bernd provided a fix here about 1 year ago:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
But it is pending to trunk. Here are my humble opinions and hopefully
we can revive it:
Which Cortex-R you are targeting that supports both D16 and D32?
Thanks,
Joey
On Thu, Oct 17, 2013 at 3:13 PM, Sebastian Huber
wrote:
> Hello,
>
> it seems that it is not possible to deduce from GCC built-in defines whether
> we compile for the VFPv3-D16 or VFPv3-D32 floating point unit.
>
> tou
There is no macro to indicate VFP variances. Probably you can check
CPU variance instead. As I know Cortex-R only support D16.
Joey
On Thu, Oct 17, 2013 at 3:47 PM, Sebastian Huber
wrote:
> On 2013-10-17 09:28, Joey Ye wrote:
>>
>> Which Cortex-R you are targeting that supports b
Sandra, Bernd,
Can you take a look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
It seems a siimple case still doesn't work as expected. Did I miss anything?
Thanks,
Joey
Bernd,
If that's the case, can you please firstly fix invoke.texi where the
behavior of strict-volatile-bitfields is described? At least my
interpretation of current doc doesn't explain the behavior of the case
we are discussing. Also it should be a generic definition rather than
target specific o
Vlad,
When fixing PR60169, I found that reload fail to assert
verify_initial_elim_offsets ()
if (insns_need_reload != 0 || something_needs_elimination
|| something_needs_operands_changed)
{
HOST_WIDE_INT old_frame_size = get_frame_size ();
reload_as_needed (global);
Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7
$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
// { dg-final { scan-assembler "7" } }
static union
{
union
{
int i = 7;
};
};
Two issues make it very fragile. It onl
Greta,
Since this checkin, GCC ICE when build fix-point library with
-march=armv7e-m -O2. Reduced test case at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859
This is a show-stopper to cortex-m4 target.
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188742
Log:
The main function for ep
Since 4.7 register_tm_clones and deregister_tm_clones are added in
crtbegin.o. Built for ARM they eat 80 precious bytes of flash for each
application. They seem to be for transaction memory only and my build
doesn't need it.
I can simple disable them by -DUSE_TM_CLONE_REGISTERY=0 in a tmake_file.
> -Original Message-
> From: Ilija Kocho [mailto:ili...@siva.com.mk]
> Sent: Tuesday, October 09, 2012 21:08
> To: Joey Ye
> Cc: gcc@gcc.gnu.org; Terry Guo
> Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
>
> Hi Joey
>
> Thank you for
19 matches
Mail list logo
