On Mon, 24 Feb 2020 12:05:28 +0100
Petr Tesarik wrote:
> Hi all,
>
> I'm looking into reviving the efforts to port gcc to VideoCore IV [1].
> One issue I've run into is the need to find out target branch distance
> at compile time. I looked around, and it's not the first one
> architecture with
Hi,
msp430-elf has an issue in the debugging information generated for function
epilogues, where the CFA offset is not updated as the epilogue progresses and
the stack pointer is modified by different instructions.
For msp430 function prologues, instructions that modify the stack pointer are
mark
Hi,
On Tue, 12 May 2020 11:05:58 +0200
Martin Liška wrote:
> Hi.
>
> Thanks to Jakub, we finally set up an experimental environment:
> gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
>
> The repository now contains a new pre-commit hook that validates
> the git commit format ([1]) and provides
Hi Segher,
On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote:
> Hi Jozef,
>
> On Thu, Mar 26, 2020 at 12:33:38PM +0000, Jozef Lawrynowicz wrote:
> > In some cases, I can fix the CFA offset by marking these epilogue insns as
> > frame_related anyway, and a
Some setjmp/longjmp tests[1] depend on the value of an auto set before setjmp
to to be retained after returning from the longjmp. As I understand, this
behaviour is actually undefined, according to the gccint manual.
Section 3 "Interfacing to GCC Output" of gccint says:
If you use longjmp, bewar
On Mon, 8 Apr 2019 14:45:17 +0200
Richard Biener wrote:
> On Mon, Apr 8, 2019 at 2:31 PM Michael Matz wrote:
> >
> > Hi,
> >
> > On Mon, 8 Apr 2019, Richard Biener wrote:
> >
> > > Not sure if in this case we run into an RTL optimization that breaks
> > > things
> > > (PRE / scheduling / inva
On Mon, 8 Apr 2019 14:00:39 +0100
Jozef Lawrynowicz wrote:
> I'll file a bugzilla once I have more concrete details.
>
> Jozef
I filed BZ90032 for what I believe to be a bug during the reload pass.
Jozef
The MSP430 target in the large memory model uses the (non-ISO) __int20 type for
SIZE_TYPE and PTRDIFF_TYPE.
The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
"__int20 unsigned" in user code.
When compiling with the "-pedantic-errors" flag, the use of any of these
builtin macros
On Wed, 5 Jun 2019 11:49:21 -0500
Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> > I'm assuming it would not be valid to modify the behaviour of __extension__
> > so it can be placed within a declaration, and not just
On Wed, 5 Jun 2019 17:12:25 -0500
Segher Boessenkool wrote:
> On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> > On Wed, 5 Jun 2019 11:49:21 -0500
> > Segher Boessenkool wrote:
> > > The documentation says
> > >
> > > '
On Thu, 6 Jun 2019 10:09:32 +0200
Richard Biener wrote:
> On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz wrote:
> >
> > I would appreciate if anyone can help me decide if:
> > - It would be OK for the use of builtin macros such as __SIZE_TYPE__ to
> > somehow
>
On Mon, 10 Jun 2019 13:32:42 -0500
Segher Boessenkool wrote:
> On Mon, Jun 10, 2019 at 05:20:31PM +0100, Jozef Lawrynowicz wrote:
> > On Thu, 6 Jun 2019 10:09:32 +0200
> > Richard Biener wrote:
> >
> > > On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz
&g
On Mon, 10 Jun 2019 17:09:10 -0500
Segher Boessenkool wrote:
> On Mon, Jun 10, 2019 at 08:58:00PM +0100, Jozef Lawrynowicz wrote:
> > On Mon, 10 Jun 2019 13:32:42 -0500
> > Segher Boessenkool wrote:
> > > That is not a fix, that is sweeping the problem under th
On Tue, 11 Jun 2019 18:01:55 -0500
Segher Boessenkool wrote:
> On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote:
> > --- a/gcc/lto/lto-lang.c
> > +++ b/gcc/lto/lto-lang.c
> > @@ -1260,9 +1260,9 @@ lto_build_c_type_nodes (void)
> >
For MSP430, the folding of identical functions marked with the "interrupt"
attribute by -fipa-icf-functions results in wrong code being generated.
Interrupts have different calling conventions than regular functions, so
inserting a CALL from one identical interrupt to another is not correct and
wil
Hi,
On Fri, 19 Jul 2019 16:32:21 +0300 (MSK)
Alexander Monakov wrote:
> On Fri, 19 Jul 2019, Jozef Lawrynowicz wrote:
>
> > For MSP430, the folding of identical functions marked with the "interrupt"
> > attribute by -fipa-icf-functions results in wrong code being ge
On Fri, 26 Jul 2019 18:39:50 +0100
Richard Sandiford wrote:
> [Catching up after being away, sorry if this has already been resolved.]
>
> Jozef Lawrynowicz writes:
> > For MSP430, the folding of identical functions marked with the "interrupt"
> > attribute by
On Wed, 31 Jul 2019 11:49:58 +0200
Richard Biener wrote:
> On Tue, Jul 30, 2019 at 3:41 PM Jozef Lawrynowicz
> wrote:
> >
> > On Fri, 26 Jul 2019 18:39:50 +0100
> > Richard Sandiford wrote:
> >
> > > [Catching up after being away, sorry if this has al
For msp430-elf in the large memory model there are PSImode (20-bit) pointers.
POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
We get poor code generated for the following code snippet:
const int table[2] = {1, 2};
int
foo (char i)
{
return table[i];
}
The RTL generated by exp
On Mon, 23 Sep 2019 07:30:21 -0600
Jeff Law wrote:
> On 9/23/19 5:56 AM, Jozef Lawrynowicz wrote:
> > For msp430-elf in the large memory model there are PSImode (20-bit)
> > pointers.
> > POINTERS_EXTEND_UNSIGNED == 1 and "char" is unsigned by default.
> >
On Mon, 23 Sep 2019 10:56:55 -0500
Segher Boessenkool wrote:
> On Mon, Sep 23, 2019 at 12:56:20PM +0100, Jozef Lawrynowicz wrote:
> > (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
> > (zero_extend:HI (reg:QI 12 R12 [ i ])))
> > (nil))
> > .
> &g
I've added a new define_expand for msp430 to handle "mulhisi", but when testing
the changes, some builtin tests (e.g. builtin-arith-overflow-{1,5,p-1}.c) fail.
I've narrowed a test case down to:
void
foo (unsigned int r, unsigned int y)
{
__builtin_umul_overflow ((unsigned int) (-1), y, &r);
}
On Wed, 9 Oct 2019 16:03:34 +0200
Jakub Jelinek wrote:
> On Wed, Oct 09, 2019 at 02:40:42PM +0100, Jozef Lawrynowicz wrote:
> > I've added a new define_expand for msp430 to handle "mulhisi", but when
> > testing
> > the changes, some builtin tests (e.g
On Wed, 16 Oct 2019 19:02:17 +0200
Jakub Jelinek wrote:
> On Wed, Oct 16, 2019 at 05:51:11PM +0100, Jozef Lawrynowicz wrote:
> > We call expand_expr_real_2 from expand_mul_overflow (internal-fn.c:1604).
> > When we process the arguments to:
> > __builtin_umul_overflow ((
ks,
Jozef
>From bd9647e2e3794f33754575ac10b67c1a49729af7 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 30 Oct 2019 19:48:54 +
Subject: [PATCH] Implement REMOVE_DSO_HANDLE
---
libgcc/config/msp430/t-msp430 | 1 +
libgcc/crtstuff.c | 8 +++-
2 files changed, 8 insertions(+), 1 deletio
On Thu, 19 Dec 2019 16:47:42 -0500
Erick Ochoa wrote:
> Hello,
>
> I am working on testing an optimization. I am starting to write
> tests in the GCC testing suite. However, I want to develop some
> fine grain testing for my own sake.
>
> This optimization I am working on, is a variant of struc
I've written a patch to fix the transparent_union attribute when the first
field in a union is MODE_PARTIAL_INT, but I noticed that the current code
only allows the TYPE_MODE of a UNION_TYPE to be of MODE_INT class.
See stor-layout.c (compute_record_mode), particularly this section:
/* If we o
27 matches
Mail list logo
