> Hmm, I don't think so. The removal was part of the E500
> related reorg, which was not committed to the branch.
You're right, I looked at the wrong branch.
--
Eric Botcazou
Hi!
As the testcase shows, we weren't diagnosing compound literals with
incomplete type at all. Fixed thusly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2012-06-02 Jakub Jelinek
PR c/53532
* c-decl.c (build_compound_literal): Call c_incomplete_type_e
Hi!
tree-chrec.c and tree-scalar-evolutions.c uses sizetype as type of
iv->step, but the following spot would use POINTER_TYPE, which leads
to ICEs. Fixed thusly, bootstrapped/regtested onx 86_64-linux and
i686-linux, ok for trunk/4.7?
2012-06-02 Jakub Jelinek
PR tree-optimization/53
On Fri, Jun 1, 2012 at 4:44 AM, Martin Jambor wrote:
> Hi,
>
> On Fri, Jun 01, 2012 at 11:31:20AM +0200, Richard Guenther wrote:
>> On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
>> wrote:
>> > Hi,
>> > When I modified GCC to change the majority of bitfield accesses
>> > which were done via compo
> Hi,
>
> This patch adds 4 flags to enable user to type in a list of name
> patterns. Compiler will match the function name with the given
> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
> attributes to function declaration. The static branch prediction
> checks if a basic block co
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
>> Hi,
>>
>> This patch adds 4 flags to enable user to type in a list of name
>> patterns. Compiler will match the function name with the given
>> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
>> attributes to function declaration.
> On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
> >> Hi,
> >>
> >> This patch adds 4 flags to enable user to type in a list of name
> >> patterns. Compiler will match the function name with the given
> >> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
> >> attributes to function
On Sat, Jun 2, 2012 at 6:06 PM, Jan Hubicka wrote:
>> On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
>> >> Hi,
>> >>
>> >> This patch adds 4 flags to enable user to type in a list of name
>> >> patterns. Compiler will match the function name with the given
>> >> patterns, and add "hot", "cold
The ffs function can be converted to ctz if the operand is known not
to be zero, as is the case for example in
while (x != 0) {
bit = ffs(x) - 1;
...
x &= ~(1 << bit);
}
CSE can already do this on x86, but the attached patch implements this
folding in VRP in a target-
Dear all,
I have realized a draft patch for the PR 46321, currently it works
only with the explicit DEALLOCATE.
Running the regression tests it doesn't pass the following:
- gfortran.dg/class_19.f03 (too much "__builtin_free")
- gfortran.dg/auto_dealloc_2.f90 (too much "__builtin_free")
- gfortr
> > Well, perhaps the feature would be more useful with command line option
> > allowing
> > to add an attribute instead of having special case command line options for
> > individual
> > cases.
>
> Hi, Honza, I'm not sure what you mean by "command line option allowing
> to add an attribution".
Hi,
ix86_sched_reorder should skip debug insns. Tested on Linux/ia32.
OK to install?
Thanks.
H.J.
---
2012-06-02 H.J. Lu
PR bootstrap/53555
* config/i386/i386.c (ix86_sched_reorder) Skip debug insns.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c6c2c5e
On Sat, Jun 2, 2012 at 9:17 PM, Jan Hubicka wrote:
>> > Well, perhaps the feature would be more useful with command line option
>> > allowing
>> > to add an attribute instead of having special case command line options
>> > for individual
>> > cases.
>>
>> Hi, Honza, I'm not sure what you mean b
For built-in macros, the patch is now stepping up until it sees a
location that is not for a built-in macro, and at point, checks if we
are in a system header.
It also uses the location of the '=' operator as the location for
assignment expressions. I had to adjust a couple of tests due to that c
On Fri, 2012-06-01 at 22:15 +0900, Kaz Kojima wrote:
> I see a new failure
>
> FAIL: gcc.target/sh/pr53512-1.c scan-assembler fsca
>
> on sh4-unknown-linux-gnu with the patch. Looks that the test
> fails due to TARGET_HAS_SINCOS which is defined on linux targets.
> It seems that we need a sin
committed as revision 188139
2012-06-2 Kenneth Zadeck
* expmed.c (expand_mult, choose_multiplier): Change "2 *
HOST_BITS_PER_WIDE_INT" to "HOST_BITS_PER_DOUBLE_INT".
* expr.c (convert_modes): Likewise.
* explow.c (plus_constant): Likewise.
* fixed-value.c (fixed_saturate1,
Hi Alessandro,
> I have realized a draft patch for the PR 46321, currently it works
> only with the explicit DEALLOCATE.
thanks for the patch! Some first comments without actually looking at
the patch in detail ...
> Running the regression tests it doesn't pass the following:
>
> - gfortran.dg/
Hi,
> - /* Build the assignment expression. */
> + /* Build the assignment expression. Its default
> + location is the location of the '=' token. */
> + input_location = loc;
> expr = build_x_modify_expr (loc, expr,
> assignment_o
Hi Janus,
> Sorry, I don't understand the last sentence. Why should it call some
> "__free..." instead of "doit"? And why is that test case even affected
> by your patch (you said it would only work with explicit DEALLOCATE,
> which does not appear in that test case)?
Yes, it is as I said... In
h
Hi,
>> Sorry, I don't understand the last sentence. Why should it call some
>> "__free..." instead of "doit"? And why is that test case even affected
>> by your patch (you said it would only work with explicit DEALLOCATE,
>> which does not appear in that test case)?
>
> Yes, it is as I said... In
On Sat, Jun 2, 2012 at 3:06 AM, Jan Hubicka wrote:
>> On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka wrote:
>> >> Hi,
>> >>
>> >> This patch adds 4 flags to enable user to type in a list of name
>> >> patterns. Compiler will match the function name with the given
>> >> patterns, and add "hot", "cold
Janus Weil wrote:
The patch actually gives a few warnings:
Looking at those warnings, they seem to be valid C++ but invalid C89. As
Stages 2 and 3 are, by default, compiled by C++, I assume that
Alessandro does not see those.
By contrast, I assume that you (Janus) build GCC with the C compi
Based on Honza's feedback, I think it is bettre to add command line
interface such as this:
-ffunction-attribute-list=:
or
-ffunction-attribute-filelist=:
e.g,
-ffunction-attribute-list=code:foo1,foo2,bar_*,blah
It probably needs to be processed as deferred option to allow other
option to be tr
> Actually Dehao also plans to teach the static predictor to understand
> standard library functions more (e.g IO functions) and add more naming
How this differ from annotating the library?
There are indeed quite some possibilities to do about library calls
One thing I always wondered about
Alessandro Fanfarillo wrote:
The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
calls the __free_s_bar_mod_S_bar function instead of the proper
doit().
That kind of makes sense: "foo" has no allocatable component
Hi,
> By contrast, I assume that you (Janus) build GCC with the C compiler, i.e.
> you configure with --disable-build-poststage1-with-cxx.
actually I used --disable-bootstrap, which also has the effect that
gfortran is built with the C compiler.
> Thus, a default boot strap, shouldn't fail. No
2012/6/2 Tobias Burnus :
> Alessandro Fanfarillo wrote:
>>
>> The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
>> calls the __free_s_bar_mod_S_bar function instead of the proper
>> doit().
>
>
> That kind of mak
From: David Miller
Date: Fri, 01 Jun 2012 13:50:48 -0400 (EDT)
> I hit the same problem, but solved it by removing the
> 'from' parameter entirely.
To move things forward I committed the following:
Restore Sparc build.
gcc/
* config/sparc/sparc.h (INITIAL_ELIMINAT
On 06/02/2012 12:40 PM, Paolo Carlini wrote:
That said, the tricks we are playing with the global input_location vs the loc
we are passing around still confuse me quite a lot. Actually any *assignment*
to input_location makes me a bit more nervous than I was already ;) Do you have
any idea whe
Oleg Endo wrote:
> The attached patch should fix the issue, by folding the existing sinsf2
> and cossf2 expanders into a single sincossf3. I ran the test cases
> again with TARGET_HAS_SINCOS set to '1' and to '0' and they pass.
OK for trunk.
Regards,
kaz
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
>> Actually Dehao also plans to teach the static predictor to understand
>> standard library functions more (e.g IO functions) and add more naming
>
> How this differ from annotating the library?
I find them more suitable to be compiler heuristi
On 05/24/2012 09:18 AM, Jason Merrill wrote:
OK, thanks.
I notice you haven't checked the patch in yet, is there a problem?
Jason
On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell wrote:
> I've committed this patch to fix and improve coverage reporting:
>
> 1) the time stamp local_tick will be -1 if the user overrides the random
> seed. In such cases the gcov data file should be deleted, just as it would
> if the time cannot
This patch adds new program summary information to the gcov
profile files that indicate how many profiled counts compose
the majority of the program's execution time. This is used to
provide an indication of the overall code size of the program.
The new profile summary information is then used to
34 matches
Mail list logo
