When doing a build, we use a pipe between GCC and GAS.
And because we wish to do some analysis of the assembly code,
we do not use -pipe but instead do '-S -c -'. And this has worked
fine for many years.
I was recently looking into collecting some coverage information.
To that end, I added --cove
Hello.
> I don't think you should have the unreachable "return false;" in is_even.
> The last "else if" can just be "else".
I don't think return false in is_even is unreachable. As per my
understanding, when one else if is true in the else if ladder, all the
subsequent "else ifs" including "else"
On 6/12/19 10:40 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
But GCC doesn't support such an implementation, does it?
Why would that be relevant?
Obviously because it makes no sense to cater to all conceivable
extensions provided by all sorts of imp
On Tue, 11 Jun 2019 18:01:55 -0500
Segher Boessenkool wrote:
> On Tue, Jun 11, 2019 at 09:44:30PM +0100, Jozef Lawrynowicz wrote:
> > --- a/gcc/lto/lto-lang.c
> > +++ b/gcc/lto/lto-lang.c
> > @@ -1260,9 +1260,9 @@ lto_build_c_type_nodes (void)
> > if (int_n_enabled_p[i])
> > {
> >
On Wed, Jun 12, 2019 at 10:13:57AM -0600, Martin Sebor wrote:
> But GCC doesn't support such an implementation, does it?
Why would that be relevant? The warning would cause people to make portable
code less portable (by removing the alloca (0) calls that were added there
for portability reasons),
On 6/12/19 9:25 AM, Michael Matz wrote:
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
Otherwise LGTM as the patch, but I'd like to hear from others whether
it is kosher to add such a special case to the warn_unused_result
attribute warning. And if the agreement is yes, I think it should be
doc
Hi,
On Wed, 12 Jun 2019, Martin Sebor wrote:
> > Otherwise LGTM as the patch, but I'd like to hear from others whether
> > it is kosher to add such a special case to the warn_unused_result
> > attribute warning. And if the agreement is yes, I think it should be
> > documented somewhere that a
On 6/12/19 5:37 AM, Jakub Jelinek wrote:
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
@@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
location_t loc = gimple_location (g);
if (fdecl)
- warning_at (loc, OPT_Wunused_result,
-
Hello.
Is this the correct sequence for regression test:
1. Revert back all the changes I made and then configure, build along with
make bootstrap
make -k check
collect the *.sum files
2. Apply the patch and do the configuration, build as above 1 and then
collect the *.sum files and compare them.
On Wed, Jun 12, 2019 at 01:30:14PM +0200, Martin Liška wrote:
> @@ -9447,10 +9448,19 @@ do_warn_unused_result (gimple_seq seq)
> location_t loc = gimple_location (g);
>
> if (fdecl)
> - warning_at (loc, OPT_Wunused_result,
> - "ignoring
On 6/12/19 1:22 PM, Jakub Jelinek wrote:
> On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
>> 2019-06-12 Martin Liska
>>
>> * calls.c (special_function_p): Make it global.
>> * calls.h (special_function_p): Declare.
>
> Why?
Not needed any longer.
>
>> * tree-cfg
On Wed, Jun 12, 2019 at 01:11:09PM +0200, Martin Liška wrote:
> 2019-06-12 Martin Liska
>
> * calls.c (special_function_p): Make it global.
> * calls.h (special_function_p): Declare.
Why?
> * tree-cfg.c (do_warn_unused_result): Do not
> warn for alloca(0).
> --- a/gcc/
On 6/11/19 6:03 PM, Jakub Jelinek wrote:
> On Tue, Jun 11, 2019 at 03:58:27PM +, Michael Matz wrote:
>> On Tue, 11 Jun 2019, Martin Liška wrote:
>>
>>> I see 3 occurrences of the alloca (0) in libiberty/regex.c, but there are
>>> properly
>>> guarded within:
>>>
>>> # ifdef C_ALLOCA
>>>
Hi all,
This is a patch to demonstrate some unusual behavior I have encountered in
combine.
A summary of the behaviour is:
when combining A -> B, the register equivalence notes of A are checked, the
register notes of B are not checked.
Is this expected behaviour?
from combine.c:1484 in combi
On 2019/6/12 4:04 PM, Richard Biener wrote:
On Wed, Jun 12, 2019 at 5:22 AM Li Jia He wrote:
Hi,
I recently did some analysis on the automatic vectorization of gcc, I
found that singed char can not be vectorized in the following code.
---
#define ITERATIONS 100
#if defined(do_reduce_
Hi!
On Tue, 11 Jun 2019 16:35:40 +0100, Jonathan Wakely
wrote:
> On Tue, 11 Jun 2019 at 16:33, Jonathan Wakely wrote:
> > On Tue, 11 Jun 2019 at 16:29, Thomas Schwinge
> > wrote:
> > > On Tue, 11 Jun 2019 16:18:51 +0100, Jonathan Wakely
> > > wrote:
> > > > On Tue, 11 Jun 2019 at 16:13, Tho
On Wed, Jun 12, 2019 at 5:22 AM Li Jia He wrote:
>
> Hi,
>
> I recently did some analysis on the automatic vectorization of gcc, I
> found that singed char can not be vectorized in the following code.
>
> ---
> #define ITERATIONS 100
>
> #if defined(do_reduce_signed_char)
> #define TYPE signed
Hi Lijia,
On 6/12/19 4:22 AM, Li Jia He wrote:
Hi,
I recently did some analysis on the automatic vectorization of gcc, I
found that singed char can not be vectorized in the following code.
---
#define ITERATIONS 100
#if defined(do_reduce_signed_char)
#define TYPE signed char
#elif defined
18 matches
Mail list logo
