On Wed, 6 Dec 2006 09:00:30 -0800, H. J. Lu wrote:
>On Wed, Dec 06, 2006 at 08:43:17AM -0800, Randy Dunlap wrote:
>> On Tue, 5 Dec 2006 23:00:14 -0800 H. J. Lu wrote:
>>
>> > On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
>> > LOCKREP_PREFIX isn't fixed. Currently, gas genera
It's a wrong-code regression in GCC 4.8 to 6.0 where it generates
NEON code with unaligned memory operands, causing alignment faults
at runtime.
Does gcc allow backends to have a say in how pointers are represented
(bits beyond the address), what happens in conversions between pointer
types, and what happens in conversions between pointers and uintptr_t?
The target in question has:
- one pointer format and set of load/store instructions fo
Richard Biener writes:
> On Wed, Sep 30, 2015 at 11:23 AM, Mikael Pettersson
> wrote:
> > Does gcc allow backends to have a say in how pointers are represented
> > (bits beyond the address), what happens in conversions between pointer
> > types, and what happen
Paul Shortis writes:
> I've now confirmed this same issue occurs on a stock i386 build
> when -fomit-frame-pointer is specified with -O2 and a test case
> with reasonable register pressure.
Then please open a bug report in gcc's bugzilla with the test case
and instructions on how to reproduce
I have a toy backend based on the moxie backend as a template. During its
development I found some oddities in the moxie backend that may be bugs.
1. The REGNO_OK_FOR_INDEX_P(NUM) macro in moxie.h is:
#define REGNO_OK_FOR_INDEX_P(NUM) MOXIE_FP
Since MOXIE_FP is 0, this returns false for every r
Seems like the weekly snapshots from gcc-6-branch were disabled before
the 6.4.0 release but not re-enabled afterwards. The snapshots from
trunk and gcc-{7,5}-branch are being generated as usual.
Gerald Pfeifer writes:
> On Fri, 14 Jul 2017, Mikael Pettersson wrote:
> > Seems like the weekly snapshots from gcc-6-branch were disabled before
> > the 6.4.0 release but not re-enabled afterwards. The snapshots from
> > trunk and gcc-{7,5}-branch are being generated as
Guillem Jover writes:
> On Mon, 2011-02-21 at 17:59:06 +, Joseph S. Myers wrote:
> > On Mon, 21 Feb 2011, Guillem Jover wrote:
> > > if you'd consider accepting something ressembling the attached patch
> >
> > A pre-existing condition, but in general where the code you're changing
> > h
Hans-Peter Nilsson writes:
> On Mon, 1 Aug 2011, Richard Henderson wrote:
>
> > On 08/01/2011 01:30 PM, Michael Walle wrote:
> > > 1) function inlining
> > > 2) deferred argument evaluation
> > > 3) because our target has no barrel shifter, (arg >> 10) is emitted as a
> > > function call
Michael Walle writes:
>
> Hi,
>
> > To confirm that try -fno-tree-ter.
>
> "lm32-gcc -O1 -fno-tree-ter -S -c test.c" generates the following working
> assembly code:
>
> f2:
> addi sp, sp, -4
> sw (sp+4), ra
> addi r2, r0, 10
> calli__ashrsi3
I'm seeing what appears to be a recent massive performance regression
with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE.
Right now 4.7-20110827's stage2 gengtype has been running for almost
10 hours on my ARM build machine, but the process is tiny and no swapping
occurs. To put t
Mikael Pettersson writes:
> I'm seeing what appears to be a recent massive performance regression
> with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE.
>
> Right now 4.7-20110827's stage2 gengtype has been running for almost
> 10 hours on my ARM
Mikael Pettersson writes:
> Mikael Pettersson writes:
> > I'm seeing what appears to be a recent massive performance regression
> > with trunk's gengtype, as compiled and run in stage 2, on ARM V5TE.
> >
> > Right now 4.7-20110827's stage2 gen
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
>On 12.08.2009 23:07, Martin Guy wrote:
>> On 8/12/09, Joel Sherrill wrote:
>>> So any ACATS results from any other ARM target would be
>>> appreciated.
>>
>> I looked into gnat-arm for the new Debian port and the conclusion was
>> tha
When browsing e.g. gcc-cvs via the web it used to be possible to click on a
newly added file and get a 'download raw' (I think it was called) option to
see the file without all that idiotic html formatting. That seems to be gone
now. For me, at least, this is extremely counterproductive.
Ian Lance Taylor writes:
> Mikael Pettersson writes:
>
> > When browsing e.g. gcc-cvs via the web it used to be possible to click on a
> > newly added file and get a 'download raw' (I think it was called) option to
> > see the file without all that idiotic
Ludovic Brenta writes:
> Mikael Pettersson writes:
> > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
> >>is there any arm-linx-gnueabi gnat binary that could be used to bootstrap
> >>an
> >>initial gnat-4.4 package for debian?
> >
Laurent GUERBY writes:
> On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose
> > > wrote:
> > > >On 12.08.2009 23:07, Marti
Mikael Pettersson writes:
> Laurent GUERBY writes:
> > On Sat, 2009-08-22 at 23:33 +0200, Laurent GUERBY wrote:
> > > On Mon, 2009-08-17 at 12:00 +0200, Mikael Pettersson wrote:
> > > > On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose
> wrote:
> &g
Kaveh R. Ghazi writes:
> From: "Dennis Clarke"
>
> >>> > target GCC GMP MPFR
> >>> >
> >>> > sparc-sun-solaris2.11 4.1.1 4.2.1 2.3.2
> >>> > i386-pc-solaris2.10 4.1.1 4.2.1 2.3.2
> >>> > mips-sgi-irix6.5 3.4.5 4.3.0 2.3.2
> >>> > alpha-dec-osf4.0f 3.4.4 4.2.1 2.3.2
> >>> >
> >>> > All t
On Mon, 18 Jan 2010 13:55:16 -0500, Jean Christophe Beyler wrote:
>I have a current issue on my port. Basically the stack is defined as follows :
>
>1) CALL_USED save area
>2) Local variables
>3) Caller arguments passed on the stack
>4) 8 words to save arguments passed in registers, even if not pas
On Tue, 16 Mar 2010 06:50:30 -0800, H.J. Lu wrote:
> 2010/3/8 Pawe=C5=82 Sikora :
> > hi,
> >
> > during development a cross platform appliacation on x86 workstation
> > i've enabled an alignemnt checking [1] to catch possible erroneous
> > code before it appears on client's sparc/arm cpu with si
It seems the bot or whatever that generates the weekly snapshots
has stopped working for the 4.3 branch. I would have expected a
new snapshot 2-3 days ago but found nothing on the mirrors.
(And there has been commits since the last snapshot.)
/Mikael
Shaun Pinney writes:
> Hello all,
>
> Essentially, we have code which works fine on x86/PowerPC but fails on ARM
> due
> to differences in how misaligned accesses are handled. The failures occur in
> multiple large modules developed outside of our team and we need to find a
> solution. T
linux-gnueabi, and with
a native bootstrap and regtest on arm-linux-gnueabi.
Ok for 4.6? 4.5? (I don't have svn write access.)
libstdc++-v3/
2010-07-20 Mikael Pettersson
PR libstdc++/44902
* libsupc++/unwind-cxx.h (__cxa_type_match): Correct prototype.
(__cxa_beg
Mikael Pettersson writes:
> The prototypes for two ARM EH routines don't match their actual
> definitions in eh_arm.cc, resulting in build-time warnings. When
> -Werror is active, the build fails. See PR44902.
>
> Fixed simply by updating the prototypes to m
Kenny Simpson writes:
> Last month I sent a list of bugreports that were 4.7 regressions, but had
> patches which fixed them for 4.8. It looks like ~7 of these had been
> backported and 10 more bugreports now exist with potential for backporting
> as well.
...
> 53844 - missed-optimization
Konstantin Vladimirov writes:
> Hi,
>
> Minimal reproduction for x86:
>
> #include
> #include
> #include
>
> jmp_buf something_happened;
> int key_gdata = 2;
>
> int store_data;
>
> void __attribute__((noinline))
> initiate(void)
> {
> longjmp(something_happened, 1);
> }
On Fri, 3 May 2013 12:49:14 +, Paulo Matos wrote:
> Hello,
>
> It seems to me there's a bug in
> simplify_const_relational_operation:simplify-rtx.c.
> If you set STORE_VALUE_FLAG to -1, if you get to
> simplify_const_relational_operation
> with code: NE, mode: BImode, op0: reg, op1: const_
Paulo Matos writes:
> That explains why GCC removes the condition but the main issue of the memset
> recursion still stands.
Known problem. See GCC PR56888.
Hendrik Greving writes:
> gcc --version
> gcc (GCC) 4.8.1
>
> (4.7.2 seems to work)
>
> gcc -g -fPIC -O2 -Wall -o test test.c
>
> ./test
> type_a is 0x0
>
> Correct would be 0x14000. I don't see how the C-code could be
> ambiguous, I think this is a bug?
>
> test.c:
>
> #inclu
Bernd Roesch writes:
> hello
>
> there is a C++ game called dunelegacy which work on other GCC architecture ok
> On G++ 68k it compile ok, but produce wrong code, because there seem
> something diffrent in
> va_list. The value of
> SDL_RWops is transfer wrong.
>
> I do not understand wh
Andreas Enge writes:
> We are pleased to announce the immediate availability of the first release
> candidate for GNU MPC 1.0 at
>http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz
>sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3
>
> Reports on successful installations a
Andreas Enge writes:
> We are pleased to announce the immediate availability of the first release
> candidate for GNU MPC 1.0 at
>http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz
>sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3
>
> Reports on successful installations a
BELBACHIR Selim writes:
> Hi,
>
> I'm working on a gcc/gnat port for a private target (gcc 4.5.2, gnat 6.4.2).
> On this target, scalar values shall be stored in $R registers whereas
> pointer values shall be stored in $C registers. My current ABI for
> procedure/function calls uses $R an
Mike Hommey writes:
> On Thu, Mar 07, 2013 at 01:14:03AM -0800, Andrew Pinski wrote:
> > On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey wrote:
> > > On Thu, Mar 07, 2013 at 12:28:22AM -0800, Andrew Pinski wrote:
> > >> On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey
> > >> wrote:
> > >> > Hi,
Mike Hommey writes:
> On Thu, Mar 07, 2013 at 11:12:40AM +0100, Mikael Pettersson wrote:
> > Mike Hommey writes:
> > > On Thu, Mar 07, 2013 at 01:14:03AM -0800, Andrew Pinski wrote:
> > > > On Thu, Mar 7, 2013 at 12:33 AM, Mike Hommey
> > wrote:
>
Aurelien Jarno writes:
> On Wed, Mar 05, 2008 at 11:58:34AM -0800, Joe Buck wrote:
> >
> > Aurelien Jarno wrote:
> > > >Since version 4.3, gcc changed its behaviour concerning the x86/x86-64
> > > >ABI and the direction flag, that is it now assumes that the direction
> > > >flag is cleared
(Note I'm reading the gcc mailing list via the Web archives, which
doesn't let me
create "proper" replies. Oh well.)
On Sun Jun 18 09:58:56 GMT 2023, wrote:
> Hi, this is my first time with open source development. I worked in
> automotive for 22 years and we (generally) were using tricore series
I'm working on a GCC backend for an older processor with very
primitive addressing support. The only way to load from or store to
memory is to compute the address into a register, and then use that
register in the load or store instruction. There are no immediate or
register offsets in memory acces
On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote:
> Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From
> a quick search I see that the iq2000 and rx backends are rewriting some
> PLUS expression addresses with insn sequence to calculate the address.
I have partial succes
On Sat, Jun 8, 2024 at 5:11 PM Jeff Law wrote:
>
>
>
> On 6/8/24 3:32 AM, Mikael Pettersson via Gcc wrote:
> > On Thu, Jun 6, 2024 at 8:59 PM Dimitar Dimitrov wrote:
> >> Have you tried defining TARGET_LEGITIMIZE_ADDRESS for your target? From
> >> a quick
43 matches
Mail list logo
