Re: [RFC] Replace Java with Go in default languages
On Wed, Nov 13, 2013 at 5:20 PM, Jeff Law wrote: > On 11/13/13 09:00, Tom Tromey wrote: >>> >>> "Jeff" == Jeff Law writes: >> >> >> Jeff> Given the problems Ian outlined around adding Go to the default >> Jeff> languages and the build time issues with using Ada instead of Java, >> Jeff> I'm unsure how best to proceed. >> >> IIRC from upthread the main reason to keep one of these languages is >> -fnon-call-exceptions testing. >> >> How about just writing some tests for that, in C++? It may not be quite >> as good but it seems like it could be a reasonable first pass; with more >> obscure issues caught by subsequent testing, much as is the case for >> non-core targets. > > The biggest issue with this approach is when we find a non-call-exceptions > issue, the source language for the testcase is going to likely be Java, Ada > or Go. Converting that to C++ can be a bit painful. > > I'd certainly like to see such tests, but I fear getting any kind of decent > coverage (relative to what we get today building Ada or GCJ) is going to > take a *long* time. You can add a -fnon-call-exceptions torture case to the g++.dg/torture case and at least get all the ICEs for free (that's most cases). Richard. > jeff
Re: Great example of why "everything is a tree" sucks
On Wed, Nov 13, 2013 at 5:50 PM, Jakub Jelinek wrote: > On Wed, Nov 13, 2013 at 04:43:45PM +, Joseph S. Myers wrote: >> On Wed, 13 Nov 2013, Jeff Law wrote: >> >> > On 11/13/13 08:59, Joseph S. Myers wrote: >> > > On Wed, 13 Nov 2013, Steven Bosscher wrote: >> > > >> > > > Really the best place to start IMHO would be to evict 'tree' from the >> > > > front ends. That would really be a step towards making the front ends >> > > > independent of the rest of the compiler, and it would simplify changes >> > > > towards static 'tree' types. >> > > >> > > From a C perspective, a useful change that would facilitate moving the >> > > IR >> > > away from tree would be moving most of fold to operate on GIMPLE instead >> > > of on trees (that is, rewriting it as GIMPLE optimizations; I don't think >> > > this can be a mechanical refactoring). >> > [ ... ] >> > Yes. That is most certainly part of "the plan". Andrew, myself and others >> > have discussed it extensively. It's a lot of work, but getting the tree >> > folder disentangled from the gimple optimizers is definitely on the hit >> > list. >> >> Note that *removing* things from the tree folder (and convert.c, and >> shorten_compare, and shorten_binary_op, and any other such fold-like >> things) once they've been moved to GIMPLE is a critical part of making it >> easier to clean up front-end IR; having them in both places won't help. > > Richard B. had the idea of generating parts of fold-const and corresponding > GIMPLE ops from some meta definition file. Yeah, I hope to tackle the fold-const.c vs. GIMPLE mess during stage3 when everyone else is fixing bugs. (haha) Richard. > Note, in many cases, removing optimizations from fold-const.c leads to > regressions on code assuming something is folded (especially in > initializers). Sure, that is all typically undocumented GNU extensions, > but we had several such problems in the past already. > Jakub
Re: Enable -Wreturn-type by default ?
Sylvestre Ledru a écrit:
> I would like to propose the activation by default of -Wreturn-type.
>
> The main objective would to provide a warning for such code:
>
> int foo() {
> return;
> }
>
> For now, it is only enabled when we have -Wall:
> $ gcc -c foo.c
> $ gcc -Wall -c foo.c
> foo.c: In function ‘foo’:
> foo.c:2:2: warning: ‘return’ with no value, in function returning
> non-void [-Wreturn-type]
I am wondering why this warning hasn't been activated by default in the
first place, for C++ at least?
Note that using g++ to compile the example above with -std=c++98 yields:
foo.c:2:2: error: return-statement with no value, in function returning
‘int’ [-fpermissive]
So what do we gain from not emitting that warning by default there?
For C, I am not sure about, but I'd find it useful to have that warning
enabled there too, so I guess I'd like to hear why the warning wasn't
enabled there by default there as well.
Cheers.
--
Dodji
Re: Enable -Wreturn-type by default ?
On 14 November 2013 11:31, Dodji Seketeli wrote:
>
> For C, I am not sure about, but I'd find it useful to have that warning
> enabled there too, so I guess I'd like to hear why the warning wasn't
> enabled there by default there as well.
A return statement with no operand is always wrong, but -Wreturn-type
also warns about this, which is valid:
int f(int c)
{
if (c)
return 0;
function_that_never_returns();
}
The noreturn attribute is not portable, and can't necessarily be added
to library functions not controlled by the user.
So maybe it makes sense to split -Wreturn-type to separately handle
"return with no value in function returning non-void" and "control
reaches end of non-void function".
Re: [RFC] Replace Java with Go in default languages
> The machine is an older quad core, so if you're building one something > with more cores and Ada + its runtime parallelizes better than java + > its runtime, then you'd probably see materially different results. What happens if you do make STAGE1_CFLAGS="-O -g" -j4 instead of a bare make -j4 on the machine? -- Eric Botcazou
Re: Enable -Wreturn-type by default ?
Jonathan Wakely a écrit:
> A return statement with no operand is always wrong, but -Wreturn-type
> also warns about this, which is valid:
>
> int f(int c)
> {
> if (c)
>return 0;
> function_that_never_returns();
> }
>
[...]
> So maybe it makes sense to split -Wreturn-type to separately handle
> "return with no value in function returning non-void" and "control
> reaches end of non-void function".
That would make sense, yes.
--
Dodji
Re: Enable -Wreturn-type by default ?
-Wreturn-type also warns about "return type defaults to ‘int’” for functions where the return type is not explicitly given. FX
Re: proposal to make SIZE_TYPE more flexible
On Wed, 13 Nov 2013, DJ Delorie wrote: > I tried to hack in support for intN_t in a backend, and it was a maze > of initialization sequence nightmares. So I guess we need to do the > intN_t part first. Is someone working on this? If not, is there a > spec I could use to get started on it? Instead of a target-independent __int128 keyword, there would be a set (possibly empty) of __intN keywords, determined by a target hook. Everything handling __int128 would be updated to work with a target-determined set of types instead. Preferably, the number of such keywords would be arbitrary (so I suppose there would be a single RID_INTN for them) - that seems cleaner than the system for address space keywords with a fixed block from RID_ADDR_SPACE_0 to RID_ADDR_SPACE_15. -- Joseph S. Myers jos...@codesourcery.com
Re: Enable -Wreturn-type by default ?
On Thu, 14 Nov 2013, Dodji Seketeli wrote: > For C, I am not sure about, but I'd find it useful to have that warning > enabled there too, so I guess I'd like to hear why the warning wasn't > enabled there by default there as well. Presumably because C90 allowed return without a value in a function returning non-void, as long as the caller didn't use the return value (which in turn probably arose because in pre-standard C, people wouldn't use a void return type, they'd just omit the return type and let it be implicit int). Return without a value in a function returning non-void, implicit int and implicit function declarations are all things removed in C99 for which it may now make sense to enable warnings by default. -- Joseph S. Myers jos...@codesourcery.com
Re: Enable -Wreturn-type by default ?
On 11/14/2013 06:31 AM, Dodji Seketeli wrote:
int foo() {
return;
}
I am wondering why this warning hasn't been activated by default in the
first place, for C++ at least?
Note that using g++ to compile the example above with -std=c++98 yields:
foo.c:2:2: error: return-statement with no value, in function returning
‘int’ [-fpermissive]
So what do we gain from not emitting that warning by default there?
If we already give an error, we don't want to give a redundant warning.
I'm confused about what you're asking here.
Jason
Re: Enable -Wreturn-type by default ?
Jason Merrill a écrit: > If we already give an error, we don't want to give a redundant > warning. I'm confused about what you're asking here. Ah, I thought g++ was just emitting an error with -std=something. It's actually is emitting the error by default. It's just cc1 that needs changing then. Sorry about the confusion. -- Dodji
suspect code in fold-const.c
in doing the wide int conversion, i have found the following code on the trunk which seems somewhat suspect: this code from fold-const.c starts on line 13811. else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi && TREE_INT_CST_LOW (arg1) == signed_max_lo && TYPE_UNSIGNED (arg1_type) /* We will flip the signedness of the comparison operator associated with the mode of arg1, so the sign bit is specified by this mode. Check that arg1 is the signed max associated with this sign bit. */ && width == GET_MODE_BITSIZE (TYPE_MODE (arg1_type)) /* signed_type does not work on pointer types. */ && INTEGRAL_TYPE_P (arg1_type)) it seems that the check on bitsize should really be a check on the precision of the variable. If this seems right, i will correct this on the trunk and make the appropriate changes to the wide-int branch. kenny
Re: proposal to make SIZE_TYPE more flexible
> Instead of a target-independent __int128 keyword, there would be a set > (possibly empty) of __intN keywords, determined by a target hook. Or *-modes.def ?
Re: proposal to make SIZE_TYPE more flexible
On Thu, 14 Nov 2013, DJ Delorie wrote: > > Instead of a target-independent __int128 keyword, there would be a set > > (possibly empty) of __intN keywords, determined by a target hook. > > Or *-modes.def ? That would be one possibility - if the idea is to define __intN for all integer modes not matching a standard type (and passing targetm.scalar_mode_supported_p), I advise posting details of what effect this would have for all targets so we can see how many such types would get added. (I don't advise having __intN when there are matching standard integer types as that would introduce unnecessary complications regarding whether __intN is the same type, or a distinct one needing its own name mangling and rank for promotion. Draft TS 18661-3 does have _Float32 etc. as always distinct types from float etc., but I don't see any use for that for integer types for now.) -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
> That would be one possibility - if the idea is to define __intN for all > integer modes not matching a standard type (and passing > targetm.scalar_mode_supported_p), I advise posting details of what effect > this would have for all targets so we can see how many such types would > get added. I was thinking of using the existing PARTIAL/FRACTIONAL_INT_MODE macros. avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3); bfin/bfin-modes.def:PARTIAL_INT_MODE (DI, 40, PDI); m32c/m32c-modes.def:PARTIAL_INT_MODE (SI, 24, PSI); msp430/msp430-modes.def:PARTIAL_INT_MODE (SI, 20, PSI); rs6000/rs6000-modes.def:PARTIAL_INT_MODE (TI, 128, PTI); sh/sh-modes.def:PARTIAL_INT_MODE (SI, 22, PSI); sh/sh-modes.def:PARTIAL_INT_MODE (DI, 64, PDI); I suspect we'd have to filter out the power-of-two PSI ones though, leaving: avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3); bfin/bfin-modes.def:PARTIAL_INT_MODE (DI, 40, PDI); m32c/m32c-modes.def:PARTIAL_INT_MODE (SI, 24, PSI); msp430/msp430-modes.def:PARTIAL_INT_MODE (SI, 20, PSI); sh/sh-modes.def:PARTIAL_INT_MODE (SI, 22, PSI); I'm assuming we need a mode to go with any type we create? Otherwise, we could add a FRACTIONAL_INT_TYPE(wrapper-mode, bits) macro to add yet more.
Re: [RFC] Replace Java with Go in default languages
On 11/14/13 04:50, Eric Botcazou wrote: The machine is an older quad core, so if you're building one something with more cores and Ada + its runtime parallelizes better than java + its runtime, then you'd probably see materially different results. What happens if you do make STAGE1_CFLAGS="-O -g" -j4 instead of a bare make -j4 on the machine? Sure, I'll give it a spin tonight. I've been meaning to do a similar experiment for a long time, this is close enough to serve both purposes :-) jeff
Re: proposal to make SIZE_TYPE more flexible
On Thu, 14 Nov 2013, DJ Delorie wrote: > > That would be one possibility - if the idea is to define __intN for all > > integer modes not matching a standard type (and passing > > targetm.scalar_mode_supported_p), I advise posting details of what effect > > this would have for all targets so we can see how many such types would > > get added. > > I was thinking of using the existing PARTIAL/FRACTIONAL_INT_MODE macros. FRACTIONAL_INT_MODEs probably work more reliably as integer types than PARTIAL_INT_MODEs, given Bernd's fixes a couple of years ago (I'm not clear on why we actually need both). But I was imagining something that would cover TImode as well, so replacing the existing logic around __int128. > I suspect we'd have to filter out the power-of-two PSI ones though, leaving: I think the filter should be based on being the same number of bits as a standard type (char / short / int / long / long long) rather than being power-of-two. > I'm assuming we need a mode to go with any type we create? Otherwise, Actually, no - bit-fields have funny-sized types that work without their own modes (they should automatically get the next larger integer mode, with padding bits). If you don't have a mode, presumably arithmetic on a larger mode and masking the results is the best way of doing arithmetic on your special type. But this may not be well-optimized (as far as I know the lowering of such operations to use modes the target supports still takes place entirely at RTL expansion time, when it might be better to do it on GIMPLE and let GIMPLE optimizers work on the larger-type arithmetic). If you do want types without corresponding modes, that goes back to having a hook to list the relevant type sizes. -- Joseph S. Myers jos...@codesourcery.com
Re: proposal to make SIZE_TYPE more flexible
> If you do want types without corresponding modes, that goes back to > having a hook to list the relevant type sizes. Perhaps a FRACTIONAL_INT_TYPE() macro then, for when there's no machine mode to go with it? Although I'm struggling to imagine a case where a target would need to define a bit-sized type that doesn't correspond to any machine mode.
Re: proposal to make SIZE_TYPE more flexible
On Thu, 14 Nov 2013, DJ Delorie wrote: > > If you do want types without corresponding modes, that goes back to > > having a hook to list the relevant type sizes. > > Perhaps a FRACTIONAL_INT_TYPE() macro then, for when there's no > machine mode to go with it? Although I'm struggling to imagine a case > where a target would need to define a bit-sized type that doesn't > correspond to any machine mode. Whatever you do, there needs to be a runtime iteration to decide which modes get types, given that whether a mode is supported can depend on command-line options (TImode only being supported for -m64, for example). -- Joseph S. Myers jos...@codesourcery.com
Re: suspect code in fold-const.c
On 11/14/13 09:16, Kenneth Zadeck wrote: in doing the wide int conversion, i have found the following code on the trunk which seems somewhat suspect: this code from fold-const.c starts on line 13811. else if (TREE_INT_CST_HIGH (arg1) == signed_max_hi && TREE_INT_CST_LOW (arg1) == signed_max_lo && TYPE_UNSIGNED (arg1_type) /* We will flip the signedness of the comparison operator associated with the mode of arg1, so the sign bit is specified by this mode. Check that arg1 is the signed max associated with this sign bit. */ && width == GET_MODE_BITSIZE (TYPE_MODE (arg1_type)) /* signed_type does not work on pointer types. */ && INTEGRAL_TYPE_P (arg1_type)) it seems that the check on bitsize should really be a check on the precision of the variable. If this seems right, i will correct this on the trunk and make the appropriate changes to the wide-int branch. I'd strongly suggest talking with Eric. It looks like the mode test is on purpose. From the change which introduced that code: commit 8aa01816af90c5c9b6e3718ee263678ce5f3d93e Author: ebotcazou Date: Fri Dec 1 22:46:45 2006 + * fold-const.c (fold_binary) : Use the precision of the type instead of the size of its mode to compute the highest and lowest possible values. Still check the size of the mode before flipping the signedness of the comparison. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@119422 138bc75d-0d04-0410-96 And it's associated thread on gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00242.html
Recent ia64 change causing problems with Ada
2013-11-14 Kirill Yukhin PR target/57491 * config/ia64/ia64.c (ia64_split_tmode_move): Relax `dead' flag setting. Is causing various failures bootstrapping Ada. The symptom is tripping this assert in cselib.c: /* The register should have been invalidated. */ gcc_assert (REG_VALUES (dreg)->elt == 0); Reverting the patch gets the Ada bootstrap farther on ia64 -- far enough to run into the problems I introduced with the isolate-erroneous-paths optimization. If you would address it appropriately, I'd appreciate it. In the mean time I've reverted it in my local tree so I can debug my own ia64 issue :-) jeff
