This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Hi Joel, On Mar 16 14:58, Joel Sherrill wrote: > On 3/16/2015 2:49 PM, Yaakov Selkowitz wrote: > > On Mon, 2015-03-16 at 14:32 -0500, Joel Sherrill wrote: > >> On 3/16/2015 2:25 PM, Yaakov Selkowitz wrote: > >>> On Mon, 2015-03-16 at 13:02 -0500, Joel Sherrill wrote: > >>>> But remember, not every newlib target is an RTEMS target. This balance > >>>> could shift based on the other bare machine targets. Does someone > >>>> have *-elf targets handy for targets that do not have RTEMS to test using > >>>> my script and test case? > >>> Attached are what I ended up with after fixing the warnings. > >>> > >> Thanks!!! Can you add a unique #warning to each #define case and > >> see what the distribution is? > >> > >> I hacked on my version and ended up with this: > >> > >> 2 #warning "CASE: 1 long long only" > >> 8 #warning "CASE: 2 long but use int" > >> 7 #warning "CASE: 3 long use long" > >> 4 #warning "CASE: 4 int use int" > > 11 CASE: 1 > > 147 CASE: 2 > > 88 CASE: 3 > > 11 CASE: 4 > Were you testing all the multilb flags to get that many combinations? > > Hmmm.. Corinna any thoughts now on how you want case 2 and 3 structured? I don't quite follow your testcase. By checking for __SIZEOF_LONG_LONG__ == __SIZEOF_PTRDIFF_T__ first, you're catching all targets with sizeof(long)==siezof(long long) as well in this case. However, practically all these targets will use long as type for pointer arithmetic, which makes them equivalent to case 3 if the evaluation order would have been turned around. Are there any targets at all which would use long long in this case? Except for LLP64 Windows, which we don't support? Anyway. Aren't we moving away from the original problem? The original problem was, afaics, related to target multilibs which produce uintptr_t types different from the ones configured. Why is that so? Shouldn't the configury have catched that for each multilib? If not, why not, and how do we fix that? Do we really gain anything by introducing a massive ifdef mentioning all targets out there? This looks like overkill. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
Attachment:
pgpA5dNoEn3Jm.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |