Is there an idiom for target-specific back end code to ask the pass
manager if a particular pass (e.g., "split1") has already run?
I have some nios2 addressing mode improvement patches in the works that
depend on deferring splitting of some complex address forms until after
cse and fwprop, ins
On 10/02/2017 12:00 PM, Jakub Jelinek wrote:
On Mon, Oct 02, 2017 at 11:45:24AM -0600, Martin Sebor wrote:
What's more, in strict mode GCC transforms stpcpy calls to strcpy.
Only if the result is not needed or if the length of the source string
is already known. And we do that transformation
On 10/02/2017 11:54 AM, Joseph Myers wrote:
On Mon, 2 Oct 2017, Martin Sebor wrote:
IMO, a reasonable question a GCC user might ask is: when I make
a call to a standard library function via __builtin_foo() in
a language conformance mode where foo is not a standard function,
can I expect GCC to
On Mon, Oct 02, 2017 at 11:45:24AM -0600, Martin Sebor wrote:
> What's more, in strict mode GCC transforms stpcpy calls to strcpy.
Only if the result is not needed or if the length of the source string
is already known. And we do that transformation regardless of strict
mode. If the result is ne
On Mon, 2 Oct 2017, Martin Sebor wrote:
> IMO, a reasonable question a GCC user might ask is: when I make
> a call to a standard library function via __builtin_foo() in
> a language conformance mode where foo is not a standard function,
> can I expect GCC to transform it to some equivalent call to
On 10/02/2017 11:07 AM, Jakub Jelinek wrote:
On Mon, Oct 02, 2017 at 10:41:59AM -0600, Martin Sebor wrote:
I also take back what I said about application programs being
unaffected by this. Using the declaration to make these decisions
results in less optimal code when compiling in strict confor
On Mon, Oct 02, 2017 at 10:41:59AM -0600, Martin Sebor wrote:
> I also take back what I said about application programs being
> unaffected by this. Using the declaration to make these decisions
> results in less optimal code when compiling in strict conformance
> mode (e.g., -std=c11 or -std=c++14
On 10/02/2017 09:06 AM, Jakub Jelinek wrote:
On Mon, Oct 02, 2017 at 09:00:41AM -0600, Martin Sebor wrote:
Thanks. That makes sense to me. The wrinkle with this approach
is that the same code (same function) has different effects on
the compiler (as in, is subject to different optimization
dec
On Mon, Oct 02, 2017 at 09:00:41AM -0600, Martin Sebor wrote:
> Thanks. That makes sense to me. The wrinkle with this approach
> is that the same code (same function) has different effects on
> the compiler (as in, is subject to different optimization
> decisions, or can cause false positives/neg
On 10/02/2017 04:40 AM, Jakub Jelinek wrote:
On Mon, Oct 02, 2017 at 09:05:06PM +1030, Alan Modra wrote:
and taking different paths depending on whether or not the test
succeeds.
As far as can see, the tests have been there since the pass was
added, but I don't understand from the comments in t
On Mon, Oct 02, 2017 at 09:05:06PM +1030, Alan Modra wrote:
> > > and taking different paths depending on whether or not the test
> > > succeeds.
> > >
> > > As far as can see, the tests have been there since the pass was
> > > added, but I don't understand from the comments in the file what
> > >
On Mon, Oct 02, 2017 at 09:11:53AM +0200, Jakub Jelinek wrote:
> On Sun, Oct 01, 2017 at 03:52:39PM -0600, Martin Sebor wrote:
> > While debugging some of my tests I noticed unexpected differences
> > between the results depending on whether or not the stpcpy function
> > is declared. It turns out
On Sun, Oct 01, 2017 at 03:52:39PM -0600, Martin Sebor wrote:
> While debugging some of my tests I noticed unexpected differences
> between the results depending on whether or not the stpcpy function
> is declared. It turns out that the differences are caused by
> the handle_builtin_strcpy functio
13 matches
Mail list logo
