2012/5/11 Georg-Johann Lay :
> Currently avr_assemble_integer emits an assembler warning to
> make gas complain about missing feature
>
> http://sourceware.org/PR13503
>
> if a 3-byte address must be assembled.
>
> As PR13503 is implemented now, avr-gcc can use this feature.
>
> It's only needed fo
On Sat, May 12, 2012 at 6:39 PM, Xinliang David Li wrote:
> On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
> wrote:
>> On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li
>> wrote:
>>
>>> The downside is that the dump file format will look different from the
>>> stderr output which is less t
On Sun, May 13, 2012 at 11:11 PM, Eric Botcazou wrote:
>> I'd say simply test gimple_has_side_effects instead.
>
> We could go one step farther then and do the replacement in
>
> if (gimple_has_volatile_ops (stmt)
> || stmt_could_throw_p (stmt))
> continue;
>
> I t
On Sun, May 13, 2012 at 6:02 PM, Razya Ladelsky wrote:
> Hi,
>
> This patch changes the minimum number of iterations of outer loops for the
> runtime check which tests whether it is worthwhile to parallelize the loop
> or not.
> The current minimum number of iterations for all loops is MIN_PER_THR
On May 13, 2012, at 00:03 , David Edelsohn wrote:
>
> I forgot to ask, is there a non-Ada, target-specific testcase that you
> can add to ensure this functionality does not get broken?
>
> Thanks, David
Something like that in cp/eh ?
// { dg-do run { target { { *-*-aix5* } } } }
// { dg-option
On May 12, 2012, at 16:43 , David Edelsohn wrote:
> Please do not create another definition of the register number for LR.
Oh ...
> Earlier in the file it is defined as R_LR. Dropping in a completely
> self-contained chunk with its own naming is confusing. LR_REGNO is
> fine, but please define
I stumbled over the following code which is the reason we are not
properly going into-ssa during gimplification in some cases.
The code can't matter as we unconditionally set DECL_GIMPLE_REG_P.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-05-14 Richard Guenther
On Sun, May 13, 2012 at 10:45 AM, Eric Botcazou wrote:
> Hi,
>
> this patch has been in our tree for a while and helps in Ada where you can do
> block assignments to structures at will. I've attached a C testcase. The
> unpatch compiler generates for it on PowerPC at -O2:
>
> foo:
> lis 1
On Sun, May 6, 2012 at 12:23 AM, H.J. Lu wrote:
> On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
> wrote:
>> Ping for this patch to always supply a mode to plus_constant:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
>>
>> I've done a diff of the changes since the original
Boolean logic is hard ... this fixes a bug in the previous re-org
of clean/op_valid_in_sets.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-05-14 Richard Guenther
PR tree-optimization/53340
* tree-ssa-pre.c (op_valid_in_sets): Fix error in last c
On 05/09/2012 05:53 PM, Vladimir Makarov wrote:
It is pretty interesting and original idea. My only major objection to
the patch is about treatment of ALLOCNO_CHEAP_CALLS_CROSSED_NUM. I think
it should be accumulated as ALLOCNO_CALLS_CROSSED_NUM.
Changed (places in ira-buld.c).
I don't expect
On Mon, May 14, 2012 at 02:08:34PM +0200, Bernd Schmidt wrote:
> --- gcc/builtins.def (revision 187411)
> +++ gcc/builtins.def (working copy)
> @@ -532,10 +532,10 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_BZERO,
> DEF_EXT_LIB_BUILTIN(BUILT_IN_INDEX, "index",
> BT_FN_STRING_CONST_STRING_INT, ATTR_
On 05/14/2012 01:22 AM, Alexandre Oliva wrote:
Is it ok for the 4.7 branch too?
Yes.
Jason
On Mon, 14 May 2012, Manuel L?pez-Ib??ez wrote:
> 2012-05-13 Manuel L?pez-Ib??ez
>
> c-family/
> * c.opt (Wc++0X-compat,Wdelete-non-virtual-dtor,Wjump-misses-init,
> Wreorder): Use LangEnabledBy.
> * c-opts.c (c_common_handle_option): Do not enable them
> explicitly. Ca
On Mon, May 14, 2012 at 6:03 AM, Olivier Hainque wrote:
>
> On May 13, 2012, at 00:03 , David Edelsohn wrote:
>>
>> I forgot to ask, is there a non-Ada, target-specific testcase that you
>> can add to ensure this functionality does not get broken?
>>
>> Thanks, David
>
> Something like that in cp/
On 05/14/2012 09:09 AM, Jakub Jelinek wrote:
+ if (debug_info_level>= DINFO_LEVEL_VERBOSE
+ && !VEC_empty (macinfo_entry, macinfo_table))
Let's make this a macro, perhaps "have_macinfo"?
Jason
Richard Guenther writes:
> On Sun, May 6, 2012 at 12:23 AM, H.J. Lu wrote:
>> On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
>> wrote:
>>> Ping for this patch to always supply a mode to plus_constant:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00892.html
>>>
>>> I've done a diff
Hi,
On 05/14/2012 05:58 AM, Jason Merrill wrote:
On 05/13/2012 11:24 PM, Paolo Carlini wrote:
tree r = build_x_modify_expr
- (RECUR (TREE_OPERAND (t, 0)),
+ (input_location,
And EXPR_LOC_OR_HERE (t).
Here I think EXPR_LOC_OR_HERE (TREE_OPERAND (t, 1)) is better.
Why? TREE_O
Dear Tobias,
OK for trunk - just a wee typo to correct:
s/+ parameter available to the caller; gfortran save it in the
.mod files. */
/+ parameter available to the caller; gfortran saves it in the
.mod files. *//
Thanks for the patch.
Paul
On 13 May 2012 15:50, Tobias Burnus wrote:
> T
On May 14, 2012, at 15:14 , David Edelsohn wrote:
> Yes, something like that test.
>
> Should the test go in g++.dg/eh or in g++.target/powerpc?
It's really about the general capability to have unwinding get
through signal handlers. The same test (same sources) should work on
other targets th
On Mon, May 14, 2012 at 09:20:16AM -0400, Jason Merrill wrote:
> On 05/14/2012 09:09 AM, Jakub Jelinek wrote:
> >+ if (debug_info_level>= DINFO_LEVEL_VERBOSE
> >+ && !VEC_empty (macinfo_entry, macinfo_table))
>
> Let's make this a macro, perhaps "have_macinfo"?
Like this?
2012-05-14 Jakub
Hi!
During work on dwz I've discovered wrong -g3 debug info emitted e.g. for
Ada sources. While DW_AT_macro_info can point to just '\0' termination
of .debug_macinfo section (but it is IMHO pointless, I don't see what
distinction between -g2 and -g3 if no content of macinfo is provided
would be g
This fixes a few omissions in generalizing strided load support.
Bootstrap and regtest on x86_64-unknown-linux-gnu is running.
Richard.
2012-05-14 Richard Guenther
PR tree-optimization/53331
* tree-vect-data-refs.c (vect_verify_datarefs_alignment): Ignore
strided loa
This makes sure we consistently (in all paths into the gimplifier)
mark generated _LHS_(!) for renaming. This exposes enough bugs in
OMP lowering in SSA form (via autopar) that this is 3/n and not 2/n
which relies on random stmt operands being rewritten into SSA form
for random stmt gimplificatio
This enables autopar to pass testing with gimplifying only ever
marking lhs for renaming (I bet this catches not all cases in
omp-low.c, but rather than going for a search myself I'm going
to wait for testcases to show up to increase autopar test coverage).
For this to be easy I made make_rename_
On May 14, 2012, at 3:23 PM, Richard Sandiford wrote:
> Richard Guenther writes:
>> On Sun, May 6, 2012 at 12:23 AM, H.J. Lu wrote:
>>> On Thu, May 3, 2012 at 11:15 AM, Richard Sandiford
>>> wrote:
Ping for this patch to always supply a mode to plus_constant:
http://gcc.gnu.
This removes the calls to mark_symbols_for_renaming (or replaces them
with their side-effect of doing a forced update_stmt) in most remaining
places.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-05-14 Richard Guenther
* tree-vect-data-refs.c (vect_set
> The following patch fixes the build (not reg-tested, but looks obvious):
>
> 2012-05-14 Tristan Gingold
>
> * config/ia64/ia64.c (ia64_expand_prologue): Adjust calls to
> plus_constant.
Yes, that's the correct fix. Sorry for the stupid breakage.
--
Eric Botcazou
On Mon, May 14, 2012 at 9:39 AM, Olivier Hainque wrote:
>
> On May 14, 2012, at 15:14 , David Edelsohn wrote:
>> Yes, something like that test.
>>
>> Should the test go in g++.dg/eh or in g++.target/powerpc?
>
> It's really about the general capability to have unwinding get
> through signal hand
> I notice that D.7 seems to suggest that if the nested function is not
> inlinable and shared between all instances of the containing function
> that we put a normal (non-abstract/concrete) instance of the nested
> function inside the abstract function for the containing function. But
> I agree t
On 04/17/12 11:03, Marc Glisse wrote:
> 2012-04-17 Marc Glisse
>
> PR target/502607
> * config/i386/i386.c (ix86_expand_vec_perm_const): Move code to ...
> (canonicalize_perm): ... new function.
> (expand_vec_perm_2vperm2f128_vshuf): New function.
> (ix86_expand_vec_perm_con
We are trying to examine all uses of a reg, but overlook those in a
REG_EQUIV note. This is problematic as documented in the PR.
The following patch fixes it according to Pat Haugen. Bootstrapped and
tested on x86_64-linux, ok?
Bernd
* ira.c (find_moveable_pseudos): Skip registers whose
DF
OK.
Jason
PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00383.html
And on a general note, what is the opinion of the C/C++ maintainers
about tracking the original source code more faithfully than currently
done?
Cheers,
Manuel.
On 5 May 2012 11:06, Manuel López-Ibáñez wrote:
> This patch adds the
On 05/14/2012 09:22 AM, Paolo Carlini wrote:
In terms of implementation details: the new _loc variant (I'm also
finding useful a build_min_loc and a build_min_non_dep_loc, by the way)
seems identical to the non-_loc variant besides calling
SET_EXPR_LOCATION, thus I'm thinking: would it make sense
Hi!
Apparently the http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177973
changes broke .debug_macro predefines handling, which are after that
change no longer emitted into a transparent include which can be comdat
optimized, as the predefines no longer have lineno 0, but usually 1.
Fixed thusly
Dear Paul,
On 05/14/2012 03:31 PM, Paul Richard Thomas wrote:
OK for trunk - just a wee typo to correct:
Fixed. Thanks for the review! I have now committed the attached patch as
Rev. 187472.
Tobias
2012-05-14 Tobias Burnus
PR fortran/49110
PR fortran/51055
PR fortran/53329
* trans-e
On 05/14/2012 11:54 AM, Eric Botcazou wrote:
Hmm, why isn't current_function_decl == decl when we're trying to emit
the abstract instance of a nested function?
Because it is emitted when the first instance of the parent function is seen,
and in this case current_function_decl == parent_decl.
On 05/14/2012 12:49 PM, Jason Merrill wrote:
On 05/14/2012 11:54 AM, Eric Botcazou wrote:
Hmm, why isn't current_function_decl == decl when we're trying to emit
the abstract instance of a nested function?
Because it is emitted when the first instance of the parent function
is seen,
and in this
On 05/14/2012 06:24 PM, Jason Merrill wrote:
On 05/14/2012 09:22 AM, Paolo Carlini wrote:
In terms of implementation details: the new _loc variant (I'm also
finding useful a build_min_loc and a build_min_non_dep_loc, by the way)
seems identical to the non-_loc variant besides calling
SET_EXPR_LO
OK.
Jason
Hi!
This is an updated version of the xbegin bugfix.
Bootstrapped/regtested on x86_64-linux and i686-linux,
tested with the testcase by Andi on RTM capable hw (or was it sim?).
Ok for trunk?
2012-05-14 Andrew Pinski
H.J. Lu
Jakub Jelinek
PR target/53315
On 2012/05/11 22:15:37, carrot wrote:
http://codereview.appspot.com/6206055/diff/4001/gcc/ChangeLog
File gcc/ChangeLog (right):
http://codereview.appspot.com/6206055/diff/4001/gcc/ChangeLog#newcode11
gcc/ChangeLog:11:
It seems you also merged in another patch r187012, please mention it.
ht
Hi
Since patches in PRs don't get much attention,
this is an email about the attached patches
from Sebastian Huber and myself to correct
the arm rtems target name situation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325
There is a long explanation in the PR but the short
version is that alt
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make the non-_loc names macros that just call
the _loc
On 05/14/2012 07:38 PM, Jason Merrill wrote:
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make the non
On 05/10/2012 01:53 PM, Dodji Seketeli wrote:
+ if (found_decl_spec && ds != ds_last)
Do we still need found_decl_spec?
+ if (decl_spec_seq_has_spec_p (&decl_specifiers, ds_inline))
permerror (input_location, "explicit instantiation shall not use"
On Mon, May 14, 2012 at 7:02 PM, Jakub Jelinek wrote:
> This is an updated version of the xbegin bugfix.
> Bootstrapped/regtested on x86_64-linux and i686-linux,
> tested with the testcase by Andi on RTM capable hw (or was it sim?).
>
> Ok for trunk?
>
> 2012-05-14 Andrew Pinski
> H
I understand that this is an issue in C because the enumerators have
integer type, but in C++ they have the enumeration type, so I'm not sure
why we're having trouble. Is the problem that the promotion to integer
type is folded away into a new INTEGER_CST?
And on a general note, what is the
On 05/14/2012 12:15 PM, Bernd Schmidt wrote:
We are trying to examine all uses of a reg, but overlook those in a
REG_EQUIV note. This is problematic as documented in the PR.
The following patch fixes it according to Pat Haugen. Bootstrapped and
tested on x86_64-linux, ok?
Ok, thanks.
On 05/14/2012 08:08 AM, Bernd Schmidt wrote:
On 05/09/2012 05:53 PM, Vladimir Makarov wrote:
It is pretty interesting and original idea. My only major objection to
the patch is about treatment of ALLOCNO_CHEAP_CALLS_CROSSED_NUM. I think
it should be accumulated as ALLOCNO_CALLS_CROSSED_NUM.
Ch
On 2012/04/12 21:14:29, shenhan wrote:
Hi, the newest chrome gcc (from google-main) fails to linking
anything, by
looking into specs file, it seems that 'link_emulation' section is
missing in
specs.
The problem I found is that SUBTARGET_EXTRA_SPECS, which is not empty
for
chromeos, is ov
On Mon, 14 May 2012, Manuel López-Ibáñez wrote:
> PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00383.html
The general idea of checking this information in shorten_compare seems
reasonable. (shorten_compare's optimization function is one that really
ought to be done in generic code, but t
On Mon, 14 May 2012, Joel Sherrill wrote:
> There is a long explanation in the PR but the short
> version is that although we fully intended to switch
> the arm-rtems target from ELF to EABI we never
> intended the target name "arm-*-rtemseabi*" to
> become the preferred arm RTEMS target name.
> W
Hello!
As mentioned in the PR [1], comment #9, the fix for the ICE is not
optimal (if not wrong). The problem with mem/mem operands was fixed as
a fixup in the expander, where operands[1] was pulled into a register.
Unfortunately, unaligned moves should not be handled in the same way
as aligned mo
> Our normal procedure is to generate a declaration when we see a function
> in its enclosing context, and then fix it up later when we see the
> definition. Why not handle this similarly?
Because we want to generate an abstract instance of the nested function within
the abstract instance of the
On 05/14/2012 04:17 PM, Eric Botcazou wrote:
Our normal procedure is to generate a declaration when we see a function
in its enclosing context, and then fix it up later when we see the
definition. Why not handle this similarly?
Because we want to generate an abstract instance of the nested fun
After r187015 (Mar 31), gcc builds for rx-elf are failing with:
make[3]: Entering directory
`/greed/dj/m32c/gcc/rx-elf-head/rx-elf/64-bit-double/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/greed/dj/m32c/gcc/rx-elf-head/./gcc/xgcc
-B/greed/dj/m32c/gcc/rx-elf-he
This patch to libgo uses the new -fgo-pkgpath option when building
libgo. This produces a standard library that uses the same type
reflection strings and PkgPath information as the other Go library.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch
Hi,
On 05/14/2012 07:38 PM, Jason Merrill wrote:
On 05/14/2012 12:53 PM, Paolo Carlini wrote:
Yeah. I'm trying to replace *all* the current ones with the _loc
variant. The patch as you can imagine is becoming *huge*. Some details
will probably need another pass.
One approach would be to make
OK for google branch.
google/gcc-4_7 may also need this patch.
http://codereview.appspot.com/6206055/
On 05/01/2012 09:14 PM, rbmj wrote:
These minor changes are needed to build libstdc++ on vxWorks.
Note- these diffs are based off of gcc 4.7.0
Bump? I'm sorry for not following all the protocols, but I did create a
bug afterwards and I've waited a while. I know it's trivial, but to me
it
Two cleanup items for the sampling instrumentation interfaces. First,
rename variables from *rate* to *period*, since what is being specified
is a sampling period (time between recorded samples) not a rate.
Second, add flag __gcov_has_sampling to indicate when a file was
compiled with -fprofile-gen
On Mon, 30 Apr 2012, Olivier Hainque wrote:
> Hello,
>
> "sed s/?/p -e d" as used in s-header-vars doesn't work on
> at least ia64-hpux, where s/.../p only prints out if -n was
> requested as well.
>
> The attached patch fixes this by using '-n' instead of a
> trailing '-e d'
> * Makefile.
Looks good.
thanks,
David
On Mon, May 14, 2012 at 7:18 PM, Teresa Johnson wrote:
> Two cleanup items for the sampling instrumentation interfaces. First,
> rename variables from *rate* to *period*, since what is being specified
> is a sampling period (time between recorded samples) not a rate.
>
Hi.
This patch creates leb128.h which contains a few functions for
reading leb128 values.
They're in a header as static inlines because they can be speed critical.
I've only included what I need in GDB.
Ok to check in?
2012-05-14 Doug Evans
* leb128.h: New file.
Index: leb128.h
66 matches
Mail list logo
