public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* Question regarding m68k GCC compiler error
@ 2020-08-12 13:43 Lukasz Majewski
  2020-08-12 14:15 ` Florian Weimer
  2020-08-12 14:48 ` Jeff Law
  0 siblings, 2 replies; 7+ messages in thread
From: Lukasz Majewski @ 2020-08-12 13:43 UTC (permalink / raw)
  To: GNU C Library, libc-help

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Dear Community,

During development of following patch [1]
I've triggered some interesting error on m68k port:

pthread_cond_wait.c: In function
\342\200\230__pthread_cond_wait_common\342\200\231:
pthread_cond_wait.c:629:1: error: unable to find a register to spill in
class \342\200\230DATA_REGS\342\200\231
  629 | }
      | ^
pthread_cond_wait.c:629:1: error: this is the insn:
(jump_insn 485 484 486 27 (parallel [
            (set (pc)
                (if_then_else (eq (reg:DI 80 [ _123 ])
                        (reg:DI 142 [ s+-4 ]))
                    (label_ref 530)
                    (pc)))
            (clobber (scratch:DI))
            (clobber (scratch:SI))
        ]) "../sysdeps/nptl/futex-internal.h":552:10 5 {cbranchdi4_insn}
     (expr_list:REG_DEAD (reg:DI 142 [ s+-4 ])
        (int_list:REG_BR_PROB 536870916 (nil)))
 -> 530)
pthread_cond_wait.c:629: confused by earlier errors, bailing out


This error only happens on:

glibcs-m68k-linux-gnu
glibcs-m68k-linux-gnu-coldfire
glibcs-m68k-linux-gnu-coldfire-soft

Used gcc:
gcc version 10.2.1 20200810 [releases/gcc-10 revision
f098bc87dca:780e3a9fbae:b5cc5c95664347082100a504710f5ca0467306a5] (GCC)

After poking around it looks like this may be an internal gcc error.

How to reproduce:
1. Please use branch [2]
2. ../src/scripts/build-many-glibcs.py
/home/lukma/work/glibc/glibc-many-build --keep failed glibcs
m68k-linux-gnu m68k-linux-gnu-coldfire



Before I submit a GCC bug - has anybody encountered any similar issue
recently for this port?




Links:
[1] -
https://patchwork.ozlabs.org/project/glibc/patch/20200812133014.25766-1-lukma@denx.de/

[2]-
https://github.com/lmajewski/y2038_glibc/tree/y2038_edge-m68k-compiler-issue


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-12 13:43 Question regarding m68k GCC compiler error Lukasz Majewski
@ 2020-08-12 14:15 ` Florian Weimer
  2020-08-13  8:02   ` Lukasz Majewski
  2020-08-12 14:48 ` Jeff Law
  1 sibling, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2020-08-12 14:15 UTC (permalink / raw)
  To: Lukasz Majewski; +Cc: GNU C Library, libc-help

* Lukasz Majewski:

> Before I submit a GCC bug - has anybody encountered any similar issue
> recently for this port?

It's probably related to the six-argument system call.  These are
always difficult to handle on architectures with small register files.
It's not necessarily a GCC bug, sometimes it's just not possible to
solve this.

You should consider turning futex_abstimed_wait_cancelable64 into a
non-inline function.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-12 13:43 Question regarding m68k GCC compiler error Lukasz Majewski
  2020-08-12 14:15 ` Florian Weimer
@ 2020-08-12 14:48 ` Jeff Law
  2020-08-13  8:04   ` Lukasz Majewski
  1 sibling, 1 reply; 7+ messages in thread
From: Jeff Law @ 2020-08-12 14:48 UTC (permalink / raw)
  To: Lukasz Majewski, GNU C Library, libc-help

On Wed, 2020-08-12 at 15:43 +0200, Lukasz Majewski wrote:
> Dear Community,
> 
> During development of following patch [1]
> I've triggered some interesting error on m68k port:
> 
> pthread_cond_wait.c: In function
> \342\200\230__pthread_cond_wait_common\342\200\231:
> pthread_cond_wait.c:629:1: error: unable to find a register to spill in
> class \342\200\230DATA_REGS\342\200\231
>   629 | }
>       | ^
> pthread_cond_wait.c:629:1: error: this is the insn:
> (jump_insn 485 484 486 27 (parallel [
>             (set (pc)
>                 (if_then_else (eq (reg:DI 80 [ _123 ])
>                         (reg:DI 142 [ s+-4 ]))
>                     (label_ref 530)
>                     (pc)))
>             (clobber (scratch:DI))
>             (clobber (scratch:SI))
>         ]) "../sysdeps/nptl/futex-internal.h":552:10 5 {cbranchdi4_insn}
>      (expr_list:REG_DEAD (reg:DI 142 [ s+-4 ])
>         (int_list:REG_BR_PROB 536870916 (nil)))
>  -> 530)
> pthread_cond_wait.c:629: confused by earlier errors, bailing out
> 
> 
> This error only happens on:
> 
> glibcs-m68k-linux-gnu
> glibcs-m68k-linux-gnu-coldfire
> glibcs-m68k-linux-gnu-coldfire-soft
> 
> Used gcc:
> gcc version 10.2.1 20200810 [releases/gcc-10 revision
> f098bc87dca:780e3a9fbae:b5cc5c95664347082100a504710f5ca0467306a5] (GCC)
> 
> After poking around it looks like this may be an internal gcc error.
> 
> How to reproduce:
> 1. Please use branch [2]
> 2. ../src/scripts/build-many-glibcs.py
> /home/lukma/work/glibc/glibc-many-build --keep failed glibcs
> m68k-linux-gnu m68k-linux-gnu-coldfire
> 
> 
> 
> Before I submit a GCC bug - has anybody encountered any similar issue
> recently for this port?
Nope, haven't seen this.

As Florian noted, this could be a problem with simply using too many registers,
but we can't know without a self-contained testcase.

jeff
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-12 14:15 ` Florian Weimer
@ 2020-08-13  8:02   ` Lukasz Majewski
  2020-08-13 15:27     ` Jeff Law
  0 siblings, 1 reply; 7+ messages in thread
From: Lukasz Majewski @ 2020-08-13  8:02 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library, libc-help

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

Hi Florian,

> * Lukasz Majewski:
> 
> > Before I submit a GCC bug - has anybody encountered any similar
> > issue recently for this port?  
> 
> It's probably related to the six-argument system call.  These are
> always difficult to handle on architectures with small register files.
> It's not necessarily a GCC bug, sometimes it's just not possible to
> solve this.

I do get your point. However, this code is a simple refactoring of
existing code (as I just moved preprocessor macros to static inline
function).

> 
> You should consider turning futex_abstimed_wait_cancelable64 into a
> non-inline function.

Yes, I also thought about such solution.


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-12 14:48 ` Jeff Law
@ 2020-08-13  8:04   ` Lukasz Majewski
  2020-08-13 15:28     ` Jeff Law
  0 siblings, 1 reply; 7+ messages in thread
From: Lukasz Majewski @ 2020-08-13  8:04 UTC (permalink / raw)
  To: Jeff Law; +Cc: GNU C Library, libc-help

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

Hi Jeff,

> On Wed, 2020-08-12 at 15:43 +0200, Lukasz Majewski wrote:
> > Dear Community,
> > 
> > During development of following patch [1]
> > I've triggered some interesting error on m68k port:
> > 
> > pthread_cond_wait.c: In function
> > \342\200\230__pthread_cond_wait_common\342\200\231:
> > pthread_cond_wait.c:629:1: error: unable to find a register to
> > spill in class \342\200\230DATA_REGS\342\200\231
> >   629 | }
> >       | ^
> > pthread_cond_wait.c:629:1: error: this is the insn:
> > (jump_insn 485 484 486 27 (parallel [
> >             (set (pc)
> >                 (if_then_else (eq (reg:DI 80 [ _123 ])
> >                         (reg:DI 142 [ s+-4 ]))
> >                     (label_ref 530)
> >                     (pc)))
> >             (clobber (scratch:DI))
> >             (clobber (scratch:SI))
> >         ]) "../sysdeps/nptl/futex-internal.h":552:10 5
> > {cbranchdi4_insn} (expr_list:REG_DEAD (reg:DI 142 [ s+-4 ])
> >         (int_list:REG_BR_PROB 536870916 (nil)))  
> >  -> 530)  
> > pthread_cond_wait.c:629: confused by earlier errors, bailing out
> > 
> > 
> > This error only happens on:
> > 
> > glibcs-m68k-linux-gnu
> > glibcs-m68k-linux-gnu-coldfire
> > glibcs-m68k-linux-gnu-coldfire-soft
> > 
> > Used gcc:
> > gcc version 10.2.1 20200810 [releases/gcc-10 revision
> > f098bc87dca:780e3a9fbae:b5cc5c95664347082100a504710f5ca0467306a5]
> > (GCC)
> > 
> > After poking around it looks like this may be an internal gcc error.
> > 
> > How to reproduce:
> > 1. Please use branch [2]
> > 2. ../src/scripts/build-many-glibcs.py
> > /home/lukma/work/glibc/glibc-many-build --keep failed glibcs
> > m68k-linux-gnu m68k-linux-gnu-coldfire
> > 
> > 
> > 
> > Before I submit a GCC bug - has anybody encountered any similar
> > issue recently for this port?  
> Nope, haven't seen this.
> 
> As Florian noted, this could be a problem with simply using too many
> registers,

Ok.

> but we can't know without a self-contained testcase.

Could you be more specific about above statement? Aren't the above
reproduction steps enough?

> 
> jeff
> >   
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-13  8:02   ` Lukasz Majewski
@ 2020-08-13 15:27     ` Jeff Law
  0 siblings, 0 replies; 7+ messages in thread
From: Jeff Law @ 2020-08-13 15:27 UTC (permalink / raw)
  To: Lukasz Majewski, Florian Weimer; +Cc: libc-help, GNU C Library

On Thu, 2020-08-13 at 10:02 +0200, Lukasz Majewski wrote:
> Hi Florian,
> 
> > * Lukasz Majewski:
> > 
> > > Before I submit a GCC bug - has anybody encountered any similar
> > > issue recently for this port?  
> > 
> > It's probably related to the six-argument system call.  These are
> > always difficult to handle on architectures with small register files.
> > It's not necessarily a GCC bug, sometimes it's just not possible to
> > solve this.
> 
> I do get your point. However, this code is a simple refactoring of
> existing code (as I just moved preprocessor macros to static inline
> function).
Understood, but keep in mind that refactoring can easily change various metrics
that change compiler behavior -- particularly the inliner.

Jeff
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Question regarding m68k GCC compiler error
  2020-08-13  8:04   ` Lukasz Majewski
@ 2020-08-13 15:28     ` Jeff Law
  0 siblings, 0 replies; 7+ messages in thread
From: Jeff Law @ 2020-08-13 15:28 UTC (permalink / raw)
  To: Lukasz Majewski; +Cc: GNU C Library, libc-help

On Thu, 2020-08-13 at 10:04 +0200, Lukasz Majewski wrote:
> Hi Jeff,
> 
> > On Wed, 2020-08-12 at 15:43 +0200, Lukasz Majewski wrote:
> > > Dear Community,
> > > 
> > > During development of following patch [1]
> > > I've triggered some interesting error on m68k port:
> > > 
> > > pthread_cond_wait.c: In function
> > > \342\200\230__pthread_cond_wait_common\342\200\231:
> > > pthread_cond_wait.c:629:1: error: unable to find a register to
> > > spill in class \342\200\230DATA_REGS\342\200\231
> > >   629 | }
> > >       | ^
> > > pthread_cond_wait.c:629:1: error: this is the insn:
> > > (jump_insn 485 484 486 27 (parallel [
> > >             (set (pc)
> > >                 (if_then_else (eq (reg:DI 80 [ _123 ])
> > >                         (reg:DI 142 [ s+-4 ]))
> > >                     (label_ref 530)
> > >                     (pc)))
> > >             (clobber (scratch:DI))
> > >             (clobber (scratch:SI))
> > >         ]) "../sysdeps/nptl/futex-internal.h":552:10 5
> > > {cbranchdi4_insn} (expr_list:REG_DEAD (reg:DI 142 [ s+-4 ])
> > >         (int_list:REG_BR_PROB 536870916 (nil)))  
> > >  -> 530)  
> > > pthread_cond_wait.c:629: confused by earlier errors, bailing out
> > > 
> > > 
> > > This error only happens on:
> > > 
> > > glibcs-m68k-linux-gnu
> > > glibcs-m68k-linux-gnu-coldfire
> > > glibcs-m68k-linux-gnu-coldfire-soft
> > > 
> > > Used gcc:
> > > gcc version 10.2.1 20200810 [releases/gcc-10 revision
> > > f098bc87dca:780e3a9fbae:b5cc5c95664347082100a504710f5ca0467306a5]
> > > (GCC)
> > > 
> > > After poking around it looks like this may be an internal gcc error.
> > > 
> > > How to reproduce:
> > > 1. Please use branch [2]
> > > 2. ../src/scripts/build-many-glibcs.py
> > > /home/lukma/work/glibc/glibc-many-build --keep failed glibcs
> > > m68k-linux-gnu m68k-linux-gnu-coldfire
> > > 
> > > 
> > > 
> > > Before I submit a GCC bug - has anybody encountered any similar
> > > issue recently for this port?  
> > Nope, haven't seen this.
> > 
> > As Florian noted, this could be a problem with simply using too many
> > registers,
> 
> Ok.
> 
> > but we can't know without a self-contained testcase.
> 
> Could you be more specific about above statement? Aren't the above
> reproduction steps enough?
You're not likely to get enough upstream attention to this issue by requiring
folsk to check out your github bits.

The CPP output and command line are what we'd need.  You can get the former by
adding -save-temps to the command line which will create a .i file which is the
CPP output.  The command line you can just cut-n-paste.

jeff
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-08-13 15:28 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-12 13:43 Question regarding m68k GCC compiler error Lukasz Majewski
2020-08-12 14:15 ` Florian Weimer
2020-08-13  8:02   ` Lukasz Majewski
2020-08-13 15:27     ` Jeff Law
2020-08-12 14:48 ` Jeff Law
2020-08-13  8:04   ` Lukasz Majewski
2020-08-13 15:28     ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).