https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #5 from Miro Kropacek ---
I have been told that one of the reasons why post-incrementing modes are not
supported / preferred these days is that they halt the CPU pipeline (of course,
totally not applicable on m68k). So with the offse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #3 from Miro Kropacek ---
> I wonder if the code we emit is measurably slower though? It's possibly
a little bit larger due to the two IV increments.
It's definitely slower as both offsets next to the An registers generate a
separa
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
Even as simple loop as this:
void f(const long* src, long* dst, int count) {
for (int i = 0; i < count
++
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
Created attachment 56688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56688&action=edit
Preprocessed output
This is a crash which seems to be specific to the
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
gcc/config/m68k/t-mlibs nicely unifies various m68k options and mappings.
However it doesn't allow extending (or
ormal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
man gcc states:
-m68060
[...]
This option inhibits the use of 68020 and 68881/68882 instructions that have to
be emulat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498
--- Comment #3 from Miro Kropacek ---
Fix is easy - just pass --disable-assembly to extra_configure_flags.
I guess gcc will have to deal with the 'none' target in the future anyway
because it is deprecated in gmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87498
--- Comment #1 from Miro Kropacek ---
> For x86_64's gmp, host is passed as "none-pc-linux-gnu", thus disabling
> assembly and passing -DNO_ASM to CFLAGS from gmp's configure (making the
> toplevel AM_CFLAGS useless).
I must correct myself her
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
While testing recent 7.3.0 on m68k I have noticed an inconsistency when it
comes to enabling/disabling assemly routines for gmp
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
int copyNextDtaToAtari(void);
char fsnextIsForUs;
int custom_fsnext( void *sp )
{
int res;
if(!fsnextIsForUs) {
return 0;
}
res = copyNextDtaToAtari
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59196
--- Comment #2 from Miro Kropacek ---
Done. Thanks for testing!
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
I've found a small bug in GCC source code. At line 631 in
gcc-4.6.4/gcc/config/m68k/m68k.c is:
m68k_tune_flags = all_devices[dev]->flags;
but should be:
m68k_tune_flags = all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48554
Summary: Regression for coldfire platform
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551
--- Comment #1 from Miro Kropacek 2011-04-11
09:48:18 UTC ---
Created attachment 23953
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23953
Test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48551
Summary: Following source code crashes the c++ compiler on
coldfire platform.
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
15 matches
Mail list logo
