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
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 plac
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:
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 -Wr
> 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
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 sep
-Wreturn-type also warns about "return type defaults to ‘int’” for functions
where the return type is not explicitly given.
FX
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?
Inst
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 functio
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
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 the
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
&& TYP
> 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 ?
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 n
> 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.
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="
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
> 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-s
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
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
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.
21 matches
Mail list logo
