Please allow me to resend former sample:
#define Z(a) a
#define Y Z
#define X(p) p + Y
X(1)(2);
The flow is:
1) `X' -- leader macro token by macro_start_expand.
2) `(', `1', `)' -- macro tokens, by cb_lex_token.
3) macro_end_arg.
4) `1', `+' -- macro replacement toke
On Jul 16, 2012, at 6:28 PM, Richard Henderson wrote:
> On 07/13/2012 07:13 AM, Tristan Gingold wrote:
>> +_Unwind_RaiseException (struct _Unwind_Exception *exc)
>> +{
>> + memset (exc->private_, 0, sizeof (exc->private_));
>> +
>> + RaiseException (STATUS_GCC_THROW, 0, 1, (ULONG_PTR *)&exc);
>
On Mon, Jul 16, 2012 at 09:55:30PM +0200, Steven Bosscher wrote:
>On Mon, Jul 16, 2012 at 5:57 PM, Steven Bosscher wrote:
>> Hello,
>>
>> There are comments in basic-block.h that advise to update certain
>> parts of the compiler if a new edge flag or basic block flag is added:
>>
>> -/* Always upd
On Wed, Jul 11, 2012 at 10:51:02AM +0530, Sandeep Soni wrote:
>The patch adds support for creating individual gimple statements for
>the gimple_cond and gimple_label statements.
>
>Diego, I need your help in generalizing to include all possible cases
>of these statements.
>
>Here is the ChangeLog
>
Fortran 2008 now also allows the "::" in module interfaces: "[module]
procedure [::] procedure-name-list"
The bug is also a sign for bad quality assurance as we previously only
fixed the issue for "module procedure" and not also for "procedure".
Build and regtested on x86-64-linux.
OK for the
gfortran always warned for BIND(C) procedures if one used "integer",
"integer(4)" etc. instead of "integer(c_int)". While the latter is
surely more portable than the former, all of them are identical on
nearly all systems. Hence, the other versions are rahter widely used.
In order to reduce th
gfortran warns (with -std=) for the obsolescence of
character*5 ...
which is correct. However, it also warns when using
character name*5
which is not (yet) obsolescent.
Fixed by the attached patch. In comment 5 you find Steve's version of
the patch, which I only saw after writing my patch. T
Hi Tobias,
> Fortran 2008 now also allows the "::" in module interfaces: "[module]
> procedure [::] procedure-name-list"
>
> The bug is also a sign for bad quality assurance as we previously only fixed
> the issue for "module procedure" and not also for "procedure".
>
> Build and regtested on x86-
On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer
wrote:
>
> I'm curious if the coding conventions were relaxed to allow for variable
> declarations that are not at the beginning of a function or scope?
>
> You seem to do this pretty often in the gimplefe..
>
> cheers,
Not really. I guess
On 06/26/2012 04:29 PM, Florian Weimer wrote:
Bootstrapped and tested on x86_86-unknown-linux-gnu, with no new
regressions (this time including Java). Okay for trunk?
Ping?
--
Florian Weimer / Red Hat Product Security Team
Hi,
> gfortran warns (with -std=) for the obsolescence of
> character*5 ...
> which is correct. However, it also warns when using
> character name*5
> which is not (yet) obsolescent.
>
> Fixed by the attached patch. In comment 5 you find Steve's version of the
> patch, which I only saw after w
Yunfeng ZHANG writes:
> Please allow me to resend former sample:
> #define Z(a) a
> #define Y Z
> #define X(p) p + Y
> X(1)(2);
> The flow is:
> 1) `X' -- leader macro token by macro_start_expand.
> 2) `(', `1', `)' -- macro tokens, by cb_lex_token.
> 3) macro_end_arg.
Hi,
After benchmarking on a number of cores and measuring good
improvements across the board on the Cortex-A9 , on some cores
(Cortex M) we saw no great improvements but no regressions either, we
should just turn this on by default for the ARM port as in general it
appears to give us a good win.
On Mon, Jul 16, 2012 at 9:55 PM, Steven Bosscher wrote:
> On Mon, Jul 16, 2012 at 5:57 PM, Steven Bosscher
> wrote:
>> Hello,
>>
>> There are comments in basic-block.h that advise to update certain
>> parts of the compiler if a new edge flag or basic block flag is added:
>>
>> -/* Always update
I committed this patch to the aarch64 branch to remove unused
__ARM_EABI__ gated code.
MarcusIndex: libgcc/config/aarch64/sfp-machine.h
===
--- libgcc/config/aarch64/sfp-machine.h (revision 189563)
+++ libgcc/config/aarch64/sfp-mach
Add a new debug procedure psloc, to display a source location.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Tristan Gingold
* treepr.ads (psloc): Declare.
* treepr.adb (psloc): New debug procedure to print a sloc.
(Print_Sloc): New procedure, from ...
Hi!
The following testcase ICEs on i?86, because combiner sees a zero extension
of the likely spilled cx register generated during expansion and as it is
not a simple register move, propagates it into a use many insns later in the
function, enlarging thus the lifetime of the hard register and caus
For consistency, entity Ada.Tags.Prim_Ptr must be decorated with
attribute Is_Dispatch_Table_Entity to help the backend generating
code for dispatching calls. This decoration was missing in CPP_Types
thus causing problems in some architectures (for example, IA-64/Linux).
Tested on x86_64-pc-linux-
On 07/17/2012 11:42 AM, Janus Weil wrote:
here is a patch which makes 'gfc_notify_std' print the relevant
version of the Fortran standard automatically when issuing
errors/warnings. Up to now this had to be done manually and was
forgotten (or inconsistent)
I think the patch is a good idea. Some
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Pascal Obry
* s-regexp.adb (Adjust): Fix access violation in Adjust.
Index: s-regexp.adb
===
--- s-regexp.adb(revision 189565)
+++ s-regexp.adb(
Currently pre/postconditions are enforced by means of expansions in the body
of the corresponding subprogram. If the subprogram is imported there is no
available body on which to insert the checking code, and thr user should be
warned that the contracts will not be enforced.
THe command:
gcc -
This change makes it so that the finalization blocks generated for controlled
transient objects, as well the final raise statement, are all wrapped into a
block, so as to make it easier for the back-end to understand the construct.
No functional changes.
Tested on x86_64-pc-linux-gnu, committed o
This patch fixes failures due to the use of 64-bit atomic
operations on ppc-linux. Undo of the previous patch for 64-bit atomic
operations only.
Note: this does NOT address the failure on ppc-darwin, which will be addressed
by another patch soon.
Tested on x86_64-pc-linux-gnu, committed on trunk
This patch ensures that when -gnatn1 is used gnatmake -s will not
always recompile.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Vincent Celier
* switch-m.adb (Normalize_Compiler_Switches): Recognize new
switches -gnatn1 and -gnatn2.
Index: switch-m.adb
==
In some cases, a cleanup action was missed.
No reduced testcase found.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-17 Tristan Gingold
* raise-gcc.c (get_call_site_action_for): Remove useless init
expression for p.
(get_action_description_for): Do not over
Richard,
attached patch implements an if-to-switch conversion tree pass
pass_if_to_switch. I will follow up this email with an infrastructure patch that
provides double_int_popcount and popcount_hwi.
The pass detects chains of ifs like this:
...
:
...
if (D.1993_3 == 32)
goto ;
e
On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore
wrote:
> On 06/05/2012 10:34 AM, Sandra Loosemore wrote:
>
>> 2012-06-05 Sandra Loosemore
>>
>> gcc/
>> * tree-ssa-loop-ivopts.c (comp_cost): Make complexity field
>> signed.
>> Update comments to indicate this is for addres
I've committed this patch to the aarch64 branch to suppress the output
of an lsl #0 suffix on movi and mvni instructions.
MarcusIndex: gcc/ChangeLog.aarch64
===
--- gcc/ChangeLog.aarch64 (revision 189570)
+++ gcc/ChangeLog.aarch64 (
On 17/07/12 13:21, Tom de Vries wrote:
> attached patch implements an if-to-switch conversion tree pass
> pass_if_to_switch. I will follow up this email with an infrastructure patch
> that
> provides double_int_popcount and popcount_hwi.
Bootstrapped and reg-tested (Ada inclusive) on x86_64, with
On Tue, Jul 17, 2012 at 1:25 PM, Tom de Vries wrote:
> On 17/07/12 13:21, Tom de Vries wrote:
>> attached patch implements an if-to-switch conversion tree pass
>> pass_if_to_switch. I will follow up this email with an infrastructure patch
>> that
>> provides double_int_popcount and popcount_hwi.
I've committed this patch to the aarch64 branch to fix a misplaced
parenthesis.
MarcusIndex: gcc/ChangeLog.aarch64
===
--- gcc/ChangeLog.aarch64 (revision 189571)
+++ gcc/ChangeLog.aarch64 (working copy)
@@ -1,5 +1,10 @@
2012-07-17
On Wed, Jun 27, 2012 at 7:38 PM, Fabien Chêne wrote:
> 2012/6/7 Fabien Chêne :
> [...]
>> ... committed as rev 188294.
>> I will backport it to 4.7 when it unfreezes.
>
> ... Eventually backported as rev 189021.
This causes PR53995.
Richard.
> --
> Fabien
On 07/17/2012 06:15 AM, Arnaud Charlet wrote:
This patch fixes failures due to the use of 64-bit atomic
operations on ppc-linux. Undo of the previous patch for 64-bit atomic
operations only.
Note: this does NOT address the failure on ppc-darwin, which will be addressed
by another patch soon.
Te
On 07/15/2012 11:49 PM, Hans-Peter Nilsson wrote:
Well, give up by default that is, and fix it up in a helper
function in glibc to hold a global byte-sized atomic lock for
the duration. (Sorry!) Yes, this means that
fold_builtin_atomic_always_lock_free is wrong. It knows about
alignment in gen
On 07/10/2012 02:09 AM, Jakub Jelinek wrote:
> On Tue, Jul 10, 2012 at 10:22:44AM +0200, Richard Henderson wrote:
>> I've not touched the interface to supportable_widening_operation,
>> which is still prepared to return a CALL_EXPR and some decls. After
>> this patch set it will never do so. I'm
On 07/17/2012 12:35 AM, Tristan Gingold wrote:
> So, the first element of ExceptionInformation will be exc.
>
> Should I add a comment ?
Ah right. Definitely.
Otherwise I don't see anything else in the way. Kai?
r~
Hi,
On 07/16/2012 07:39 PM, Jason Merrill wrote:
On 07/14/2012 05:54 AM, Paolo Carlini wrote:
The above change of yours appear to imply that, at variance with what I
had in my first draft, perform_typedefs_access_check shouldn't really
gain a tsubst_flags_t argument, because now it's called by
On Tue, Jul 17, 2012 at 11:01 AM, Sandeep Soni wrote:
> On Tue, Jul 17, 2012 at 1:22 PM, Bernhard Reutner-Fischer
> wrote:
>>
>> I'm curious if the coding conventions were relaxed to allow for variable
>> declarations that are not at the beginning of a function or scope?
>>
>> You seem to do this
2012/7/17 Richard Henderson :
> On 07/17/2012 12:35 AM, Tristan Gingold wrote:
>> So, the first element of ExceptionInformation will be exc.
>>
>> Should I add a comment ?
>
> Ah right. Definitely.
>
> Otherwise I don't see anything else in the way. Kai?
>
>
> r~
No, I don't have any objections.
On Tue, Jul 17, 2012 at 1:21 PM, Tom de Vries wrote:
> Richard,
>
> attached patch implements an if-to-switch conversion tree pass
> pass_if_to_switch.
Nice. I've been working on something similar, using the paper
"Efficient and Effective Branch Reordering Using Profile Data" (Mingui
Yang et. al.
I've arrived at get_object_{or_type,}alignment again looking at
PR53970. And I finally concluded we should unconditionally relying
on type-alignment on INDIRECT/MEM/TARGET_MEM_REF when we ask for
the alignment of an access (as opposed to when asking for the
alignment of an address). So the follo
I am far from being a gettext expert, but I think the new version
doesn't work. My understanding is that one can either mark strings for
translation - or one inserts a translation function call, which also
marks them for translation. In either case, the string passed to gettext
will be used as
Carrot,
Sorry about the delayed response.
On 3 July 2012 12:28, Carrot Wei wrote:
> On Thu, Jun 28, 2012 at 12:14 AM, Ramana Radhakrishnan
> wrote:
>> On 28 May 2012 11:08, Carrot Wei wrote:
>>> Hi
>>>
>>> This is the second part of the patches that deals with 64bit and. It
>>> directly
>>> e
On 17/07/12 13:29, Richard Guenther wrote:
> On Tue, Jul 17, 2012 at 1:25 PM, Tom de Vries wrote:
>> On 17/07/12 13:21, Tom de Vries wrote:
>>> attached patch implements an if-to-switch conversion tree pass
>>> pass_if_to_switch. I will follow up this email with an infrastructure patch
>>> that
>
On 07/17/2012 08:45 AM, Paolo Carlini wrote:
-check_default_argument (tree decl, tree arg)
+check_default_argument (tree decl, tree arg, tsubst_flags_t complain)
Hmm, I don't think substitution of default arguments can cause deduction
failure; it happens after we've chosen which function to ca
Hi,
Whilst looking at upstreaming some of CodeSourcery/Mentor's old
patches, I came across the following again, originally by Mark Shinwell
but last sent upstream by Andrew Stubbs:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
I've attached a new version, re-tested but not re-benchmark
Hi,
This patch (originally by Jie Zhang) optimizes vdup builtins which use
a constant argument into the immediate variants of the vdup
instructions, rather than generating separate immediate-loads and
register vdups, as is presently done. It also adds support for loading
floating-point constant 0.
Hi,
> Ditto here. Though, I think you are in danger of exceeding the buffer - if
> not here, then further down.
admitted - the buffer length could clearly be a problem (in connection
with translation).
> Wouldn't it be simplyer to keep the error print for Warning/Error, assign
> the messages t
On 16/07/12 14:45, Ulrich Weigand wrote:
> Hello,
>
> when testing an out-of-tree patch I ran into a latent bug.
> The symptom is error messages along the lines of
> /tmp/cc6q0E3x.s:38: Error: co-processor offset out of range
> caused by an out-of-range reference to a literal pool constant.
> This
This was around in my tree for some time, consolidates calling
add_referenced_vars into vect_get_new_vect_var. Also uses
create_tmp_reg consistently.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-07-17 Richard Guenther
* tree-vect-data-refs.c (vect_get
the pass does not handle induction variables, i.e. variables that feed
into themselves.
kenny
On 07/13/2012 03:53 AM, Tom de Vries wrote:
On 12/07/12 14:04, Kenneth Zadeck wrote:
you are on the right track with the example but combine will not get
this unless everything is in the same bb.
the
Richard Earnshaw wrote:
> Hmm, I wonder if we should just unconditionally call split_all_insns()
> at the start of md_reorg when -O0. This would address your problem, but
> have the added benefit that the length calculations would be more
> accurate. We're going to have to split the insns anyway
I overlooked adding a pass-control flag for strength reduction, added
here. I named it -ftree-slsr for consistency with other -ftree- flags,
but could change it to -fgimple-slsr if you prefer that for a pass named
gimple-ssa-...
Bootstrapped and tested on powerpc-unknown-linux-gnu with no new
reg
On 07/17/2012 03:15 AM, Arnaud Charlet wrote:
> + function Sync_Compare_And_Swap_32
> (Ptr : Address;
>Expected : uint32;
>Desired : uint32) return uint32;
> pragma Import (Intrinsic,
> + Sync_Compare_And_Swap_32,
>"__sync_val_c
On 07/17/2012 04:57 AM, Andrew MacLeod wrote:
> What is the nature of the atomic failures using the
> __atomic_compare_exchange built-in? Does it have anything to do
> with the expected value being returned by pointer?
It's a rue. He never was using __atomic_compare_exchange;
the "Atomic_*" was
On 07/17/2012 11:56 AM, Richard Henderson wrote:
On 07/17/2012 04:57 AM, Andrew MacLeod wrote:
What is the nature of the atomic failures using the
__atomic_compare_exchange built-in? Does it have anything to do
with the expected value being returned by pointer?
It's a rue. He never was using
On 17/07/12 16:17, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
>
>> Hmm, I wonder if we should just unconditionally call split_all_insns()
>> at the start of md_reorg when -O0. This would address your problem, but
>> have the added benefit that the length calculations would be more
>> accurat
Hi,
On 07/17/2012 04:10 PM, Jason Merrill wrote:
On 07/17/2012 08:45 AM, Paolo Carlini wrote:
-check_default_argument (tree decl, tree arg)
+check_default_argument (tree decl, tree arg, tsubst_flags_t complain)
Hmm, I don't think substitution of default arguments can cause
deduction failure;
On 17/07/12 15:14, Julian Brown wrote:
> Hi,
>
> Whilst looking at upstreaming some of CodeSourcery/Mentor's old
> patches, I came across the following again, originally by Mark Shinwell
> but last sent upstream by Andrew Stubbs:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
>
> I'
> From: Andrew MacLeod
> Date: Tue, 17 Jul 2012 14:24:48 +0200
> On 07/15/2012 11:49 PM, Hans-Peter Nilsson wrote:
> > Well, give up by default that is, and fix it up in a helper
> > function in glibc to hold a global byte-sized atomic lock for
> > the duration. (Sorry!) Yes, this means that
>
Richard Earnshaw wrote:
> On 17/07/12 16:17, Ulrich Weigand wrote:
> > Richard Earnshaw wrote:
> >
> >> Hmm, I wonder if we should just unconditionally call split_all_insns()
> >> at the start of md_reorg when -O0. This would address your problem, but
> >> have the added benefit that the length ca
On Tue, Jul 10, 2012 at 8:20 AM, Steven Bosscher wrote:
> Hello,
>
> These look like typos:
>
> * "power4-store-update" wants "iuX,iuY" for X=1|2 and Y=1|2. The
> "iu2,iu1" case appeared twice.
> * "power4-three" wants "iuX,iuX,iuY|iuX,iuY,iuY" for X=1|2 and Y=1|2.
> The "iu1,iu1,iu2" case appeare
For C2 to be considered the "current instantiation", we need to call
xref_basetypes while we're still pushed into its scope. So we can
actually simplify the code by moving the call into cp_parser_class_head.
Once we've fixed that, we need to fix tsubst_decl to handle USING_DECLs
for members o
gfortran properly handles the "#line" which come from #include
statements and look as
# 1234 "include_file_name.f90" 1
Here, the syntax is "# linenumber filename flags", where flags is a
space-delimited list of the flags 1,2,3, or 4. The problem is that the
gfortran didn't handle the case of
Hello,
On 17/07/2012 16:44, Janus Weil wrote:
> Hi,
>
>> Ditto here. Though, I think you are in danger of exceeding the buffer - if
>> not here, then further down.
>
> admitted - the buffer length could clearly be a problem (in connection
> with translation).
>
>
>> Wouldn't it be simplyer to
On 17/07/2012 20:52, Tobias Burnus wrote:
> gfortran properly handles the "#line" which come from #include
> statements and look as
>
> # 1234 "include_file_name.f90" 1
>
> Here, the syntax is "# linenumber filename flags", where flags is a
> space-delimited list of the flags 1,2,3, or 4. The pro
Nice.
On 17 July 2012 15:26, Julian Brown wrote:
> Hi,
>
> This patch (originally by Jie Zhang) optimizes vdup builtins which use
> a constant argument into the immediate variants of the vdup
> instructions, rather than generating separate immediate-loads and
> register vdups, as is presently don
On 17/07/2012 10:13, Tobias Burnus wrote:
> gfortran always warned for BIND(C) procedures if one used "integer",
> "integer(4)" etc. instead of "integer(c_int)". While the latter is
> surely more portable than the former, all of them are identical on
> nearly all systems. Hence, the other versions
On 17/07/2012 12:03, Tobias Burnus wrote:
> On 07/17/2012 11:42 AM, Janus Weil wrote:
>> +case GFC_STD_F2008_TS:
>> + strcat (buffer, " TS 29113:");
>> + break;
>
> That's currently correct. However, there is another post-Fortran 2008
> Technical Specification in preparation. (Coarra
Hello,
The attached patch fixes PR 33135 as discussed in the PR.
Tested with
make info dvi pdf
and
make check-gcc RUNTESTFLAGS="sh.exp=pr33135* --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2e,-m3,-m3e,-m2a/-mb,-m2a-single/-mb,-m4/-ml,
-m4/-mb,-m4-single/-ml,-m4-single/-mb,-m4a-single/-ml,-m4a-sin
Mikael Morin wrote:
On 17/07/2012 12:03, Tobias Burnus wrote:
On 07/17/2012 11:42 AM, Janus Weil wrote:
+case GFC_STD_F2008_TS:
+ strcat (buffer, " TS 29113:");
+ break;
That's currently correct. However, there is another post-Fortran 2008
Technical Specification in preparation.
On 16 July 2012 00:34, Gerald Pfeifer wrote:
> On Sun, 15 Jul 2012, Jonathan Wakely wrote:
>>> I think this also should go into the GCC 4.8 release notes
>>> (gcc-4.8/changes.html)?
>> I can do that too. There's no gcc-4.8 dir yet, do I need to copy over
>> the various other files from the gcc-4.7
Hello,
The attached patch folds some define_insn and define_split with
define_insn_and_split and removes constraints in some expander
definitions.
Tested on rev 189549 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,
-m4-single/-m
Hello,
The attached patch adds the test case from comment #3 of PR 38621 to the
test suite.
Tested with
make check-gcc RUNTESTFLAGS="compile.exp=pr38621.c --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/-ml,
-m4-single/-mb,-m4a-single/-ml,-m4a-single/-m
Richard, here is the patch against the current trunk, as I promised
last week in Prague. Please apply.
Thanks,
Roland
gcc/
2012-07-17 Roland McGrath
* config/arm/arm.c (arm_get_frame_offsets): Never use a fixed register
as the extra register to save/restore for stack-alignm
While working on my favorite mips option (-msynci) I noticed an odd thing.
If I compile with '-mips32 -mips16 -msynci' I got a warning about synci not
being supported but if I compiled with '-mips32r2 -mips16 -msynci' I did not
get a warning, even though -mips16 mode does not support synci. Furthe
Mikael Morin wrote:
On 17/07/2012 20:52, Tobias Burnus wrote:
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Sorry, I hit "Sent" a tad too early. The patch failed because it was
also parsing the first few lines of a cpped file, which are, e.g.,
# 1 "gfortran.dg/g77/cpp4.F"
# 1 "
As it turns out, the problem in this case was that we were building up a
canonical array as part of building up an array of the typedef, but we
didn't add it to the list of array variants, so
complete_vars/finalize_type_size couldn't find it to fix it up. Fixed
by adding it to the variant list
On 07/17/2012 02:36 PM, Alexandre Oliva wrote:
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00300.html
... except that post has patch 1 repeated as patch 3.
The actual patch 3 is missing.
That said, the first two patches are ok. Please repost #3.
r~
Okay, that won't work as one has to call error_print only once. Maybe
something like the following will work:
const char *msg, *msg2;
char *buffer;
msg = _("Warning: ");
msg2 = _("Deleted feature:");
buffer = (char *) alloca (strlen (msg) + strlen (msg2
On Jul 17, 2012, at 1:06 PM, Oleg Endo wrote:
> The attached patch adds the test case from comment #3 of PR 38621 to the
> test suite.
>
> Tested with
> make check-gcc RUNTESTFLAGS="compile.exp=pr38621.c --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-ml,-m4/-mb,-m4-single/
> From: Andrew MacLeod
> Date: Tue, 17 Jul 2012 14:24:48 +0200
> Any PR's you open related this this, copy me on them and I'll try to get
> them addressed.
I could separate the issues I saw into PRs 54003-6. That's all,
hopefully ...at least for now. :)
BTW, your @gcc.gnu.org account doesn't
On 07/17/2012 06:55 PM, Hans-Peter Nilsson wrote:
From: Andrew MacLeod
Date: Tue, 17 Jul 2012 14:24:48 +0200
Any PR's you open related this this, copy me on them and I'll try to get
them addressed.
I could separate the issues I saw into PRs 54003-6. That's all,
hopefully ...at least for now. :
On Tue, Jul 17, 2012 at 9:40 AM, Bernhard Reutner-Fischer
wrote:
> s/anem/name/g
Good catch.
>>> * tree-cfg.c (gimple_can_merge_blocks_p): Use EDGE_COMPLEX.
>
> I take it you added EDGE_ABNORMAL_CALL on purpose?
Yes. I don't think it matters in practice because such edges will
have EDG
Hi,
The patch below adds an v850-*-rtems* target configuration to GCC.
It's a sightly modified copy of the v850*-*-* target, with some RTEMS
specific changes added.
I would like to apply this patch to trunk and gcc-4_7-branch.
OK to commit?
Ralf
2012-06-27 Ralf Corsépius
* config
On Mon, Jul 16, 2012 at 8:57 AM, Steven Bosscher wrote:
> Hello,
>
> There are comments in basic-block.h that advise to update certain
> parts of the compiler if a new edge flag or basic block flag is added:
>
> -/* Always update the table in cfg.c dump_edge_info. */
>
> and
>
> - Always update
Oleg Endo wrote:
> The attached patch fixes PR 33135 as discussed in the PR.
> Tested with
>
> make info dvi pdf
>
> and
>
> make check-gcc RUNTESTFLAGS="sh.exp=pr33135* --target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2e,-m3,-m3e,-m2a/-mb,-m2a-single/-mb,-m4/-ml,
> -m4/-mb,-m4-single/-ml,-m4-singl
Oleg Endo wrote:
> The attached patch folds some define_insn and define_split with
> define_insn_and_split and removes constraints in some expander
> definitions.
>
> Tested on rev 189549 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m2a-single/-mb,-m4/-m
On Tue, 17 Jul 2012, Terry Guo wrote:
> Thanks for your comments. I updated the description to address this
> concern. Is it OK?
Looks good to me! And I meant to imply that you should feel
free to go ahead. :-)
Thanks,
Gerald
I've checked in this patch, which was conditionally approved 3+ years ago:
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00688.html
I did look at general usage for m68k and adding -mcpu is consistent with
other existing tests; there aren't enough of them that are
conditionalized in this way to
Hi again,
Hmm, now that I look at the code in instantiate_decl for
re-substituting to get additional errors, I guess I should have
factored that code out into a separate function and used it in the
access7 patch rather than add handling of FNDECL_RECHECK_ACCESS_P in
tsubst_decl.
I see. Could y
Like the subject line says; this is consistent with the existing test to
bail out for MIPS bare-metal. OK for mainline?
-Sandra
2012-07-17 Julian Brown
Sandra Loosemore
gcc/testsuite/
* gcc.c-torture/execute/20101011-1.c: Skip on bare-metal m68k.
Index: gcc/t
> It took me a couple of minutes to understand what you meant here, so
> please let me re-phrase to make sure I got it.
>
> You are saying that the callback function of the cb_lex_token event is
> set by the callback function of the macro_start_expand event.
>
> Is that correct?
Yes.
> And this m
On 07/17/2012 09:20 PM, Paolo Carlini wrote:
The below variant adds a fndecl_recheck_access_p and uses it in two
places, in tsubst_decl and instantiate_template_1. Did I understand
correctly?
I had something else in mind, but I'll take care of it.
Jason
Checking current_class_type isn't enough to determine whether we're at
class scope; in this testcase it's set, but current_scope() is the
member function, so we don't want to mess with the type.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit ab4e9d79eae7c11c4dc2e58437f45901c439dc
On Tue, Jul 17, 2012 at 6:16 PM, Diego Novillo wrote:
>
> Not so much, anymore
> (http://gcc.gnu.org/codingconventions.html#Variable). When gimplefe
> is merged into trunk, we will be using the C++ conventions which now
> allow this.
>
> No need to change anything, Sandy.
Ah..Saved by the skin
96 matches
Mail list logo
