On Tue, Jun 21, 2011 at 1:11 PM, Richard Guenther
wrote:
> On Mon, Jun 20, 2011 at 3:56 PM, Christian Bruel
> wrote:
>> On 06/20/2011 03:41 PM, Rainer Orth wrote:
>>>
>>> Christian Bruel writes:
>>>
2011-06-16 Christian Bruel
PR 49139/43654
>>>
>>> Please use the correct
On Mon, Jun 20, 2011 at 3:56 PM, Christian Bruel wrote:
> On 06/20/2011 03:41 PM, Rainer Orth wrote:
>>
>> Christian Bruel writes:
>>
>>> 2011-06-16 Christian Bruel
>>>
>>> PR 49139/43654
>>
>> Please use the correct PR number format here:
>>
>> PR middle-end/49139
>> PR mi
On 06/20/2011 03:41 PM, Rainer Orth wrote:
Christian Bruel writes:
2011-06-16 Christian Bruel
PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise the check-in notices don't get into the PRs.
OK
On Jun 20, 2011, at 6:41 AM, Rainer Orth wrote:
> Christian Bruel writes:
>
>> 2011-06-16 Christian Bruel
>>
>> PR 49139/43654
>
> Please use the correct PR number format here:
>
> PR middle-end/49139
>PR middle-end/43654
>
> Otherwise the check-in notices don't get
On Mon, Jun 20, 2011 at 3:32 PM, Christian Bruel wrote:
> In addition to the approved part of the patch, I finally got the testsuite
> and a full Linux distribution to build without false warnings, with the
> additional following changes:
>
> * two false warnings detected during a Linux distrib re
Christian Bruel writes:
> 2011-06-16 Christian Bruel
>
> PR 49139/43654
Please use the correct PR number format here:
PR middle-end/49139
PR middle-end/43654
Otherwise the check-in notices don't get into the PRs.
Thanks.
Rainer
--
In addition to the approved part of the patch, I finally got the
testsuite and a full Linux distribution to build without false warnings,
with the additional following changes:
* two false warnings detected during a Linux distrib rebuild
- __typeof (__error) doesn't propagate the inline keyw
Unfortunately still not satisfactory, I've been testing it against a few
packages, and I notice excessive warnings with the use of __typeof (__error)
that doesn't propagate the inline keyword.
For instance, a reduced use extracted from the glibc
extern __inline __attribute__ ((__always_inline__
On 06/08/2011 11:11 AM, Richard Guenther wrote:
On Wed, Jun 8, 2011 at 9:46 AM, Christian Bruel wrote:
Hello Richard,
On 06/06/2011 11:55 AM, Richard Guenther wrote:
On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel
wrote:
OK, the only difference is that we don't have the node analyze
On Wed, Jun 8, 2011 at 9:46 AM, Christian Bruel wrote:
> Hello Richard,
>
> On 06/06/2011 11:55 AM, Richard Guenther wrote:
>>
>> On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel
>> wrote:
>>>
>>>
> OK, the only difference is that we don't have the node analyzed here,
> so
> externall
Hello Richard,
On 06/06/2011 11:55 AM, Richard Guenther wrote:
On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel wrote:
OK, the only difference is that we don't have the node analyzed here, so
externally_visible, etc are not set. With the initial proposal the
warning
was emitted only if the
On Mon, Jun 6, 2011 at 10:58 AM, Christian Bruel wrote:
>
>
>>> OK, the only difference is that we don't have the node analyzed here, so
>>> externally_visible, etc are not set. With the initial proposal the
>>> warning
>>> was emitted only if the function could not be inlined. Now it will be
>>>
OK, the only difference is that we don't have the node analyzed here, so
externally_visible, etc are not set. With the initial proposal the warning
was emitted only if the function could not be inlined. Now it will be
emitted for each DECL_COMDAT (decl)&& !DECL_DECLARED_INLINE_P (decl)) even
> >>
> >> whenever you take the address of an always_inline function
> >> (because then you can confuse GCC by indirectly calling
> >> such function which we might inline dependent on optimization
> >> setting and which we might discover we didn't inline only
> >> dependent on optimization setting)
On Wed, Jun 1, 2011 at 3:01 PM, Christian Bruel wrote:
>
>
> On 06/01/2011 12:02 PM, Richard Guenther wrote:
>>
>> On Tue, May 31, 2011 at 6:03 PM, Christian Bruel
>> wrote:
>>>
>>>
>>> On 05/31/2011 11:18 AM, Richard Guenther wrote:
On Tue, May 31, 2011 at 9:54 AM, Christian Bruel
On 06/01/2011 12:02 PM, Richard Guenther wrote:
On Tue, May 31, 2011 at 6:03 PM, Christian Bruel wrote:
On 05/31/2011 11:18 AM, Richard Guenther wrote:
On Tue, May 31, 2011 at 9:54 AM, Christian Bruel
wrote:
Hello,
The attached patch fixes a few diagnostic discrepancies for always_in
On Tue, May 31, 2011 at 6:03 PM, Christian Bruel wrote:
>
>
> On 05/31/2011 11:18 AM, Richard Guenther wrote:
>>
>> On Tue, May 31, 2011 at 9:54 AM, Christian Bruel
>> wrote:
>>>
>>> Hello,
>>>
>>> The attached patch fixes a few diagnostic discrepancies for always_inline
>>> failures.
>>>
>>> Ill
On 05/31/2011 11:18 AM, Richard Guenther wrote:
On Tue, May 31, 2011 at 9:54 AM, Christian Bruel wrote:
Hello,
The attached patch fixes a few diagnostic discrepancies for always_inline
failures.
Illustrated by the fail_always_inline[12].c attached cases, the current
behavior is one of:
- s
On Tue, May 31, 2011 at 11:18:18AM +0200, Richard Guenther wrote:
> The patch is not ok, we may not fail to inline an always_inline
> function. To make this more consistent I proposed to warn
> whenever you take the address of an always_inline function
> (because then you can confuse GCC by indire
On Tue, May 31, 2011 at 9:54 AM, Christian Bruel wrote:
> Hello,
>
> The attached patch fixes a few diagnostic discrepancies for always_inline
> failures.
>
> Illustrated by the fail_always_inline[12].c attached cases, the current
> behavior is one of:
>
> - success (with and without -Winline), si
Hello,
The attached patch fixes a few diagnostic discrepancies for
always_inline failures.
Illustrated by the fail_always_inline[12].c attached cases, the current
behavior is one of:
- success (with and without -Winline), silently not honoring always_inline
gcc fail_always_inline1.c -S -
21 matches
Mail list logo
