On 3/24/19 6:21 PM, Martin Sebor wrote: > The error issued when the aligned attribute argument is too big > to be represented is incorrect: it says the maximum alignment > is 1U << 31 when it should actually be 1 << 28. This was a typo > introduced when the error message was enhanced earlier in GCC 9. > > The test I added to verify the fix for the typo exposed another > bug introduced in the same commit as the incorrect value in > the error message: assuming that the attribute aligned argument > fits in SHWI. > > The attached patch corrects both problems. It has been tested > on x86_64-linux. I will commit it as obvious sometime this week > unless there are any objections or suggestions for changes. > > Martin > > PS I have a couple of questions related to the affected code: > 1) Does GCC support building with compilers where int is not 32 > bits wide, or where BITS_PER_UNIT is not 3? (I.e., either is > less or more?) We've certainly supported 16 bit ints in the past. H8/300 would be an example. It defaults to 16 bit ints. But I don't think we've tested that in a very long time -- my tester is only testing with -mint32.
Look for INT_TYPE_SIZE in config/*/*.h We've never supported bootstrapping in that mode, just crosses. AVR is probably the most interesting as it even has an flag to make "int" be 8 bits. It's probably the best tested target in this space. BITS_PER_UNIT is more of a hardware characteristic. It's generally 8. THough I thought one of the TI chips defined it to 32. I suspect you weren't really looking for BITS_PER_UNIT here. > 2) Is there a supported target that doesn't have __INT64_TYPE__? > (And if so, how do I find it in a test? I couldn't find > anythhing in target-supports.exp). Some of the embedded ports most likely. Again, H8/300 might be a port to look at. You can dig through config/newlib-stdint.h to see how the sizes of standard types are defined for newlib. You then have to dig into how the port defines LONG_TYPE_SIZE, LONG_LONG_TYPE_SIZE, etc etc. Given a cross, you can use sizeof (whatever) to get the sizes if you don't mind slogging through a bit of assembly code to figure things out. jeff