Trying to cross build a native compiler for arm-linux on x86_64 linux currently
fails to build, if the libgmp development files are not available for the build
system. This works with 4.7, but fails with 4.8.
The build fails with:
TARGET_CPU_DEFAULT="" \
HEADERS="auto-build.h ansidecl.h"
On Tue, Jun 11, 2013 at 9:44 PM, Marc Glisse wrote:
> On Tue, 11 Jun 2013, Jeff Law wrote:
>
>> On 06/09/13 13:43, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> just adapting yet another function so it also works with vectors.
>>>
>>> It seemed convenient to add a new macro. The name sucks (it doesn't
On Tue, Jun 11, 2013 at 9:30 PM, Marc Glisse wrote:
> On Tue, 11 Jun 2013, Jeff Law wrote:
>
>> On 06/09/13 10:25, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> this patch removes some self-assignments. I don't know if this is the
>>> best way, but it passes a bootstrap and the testsuite on
>>> x86_64
The main point is to simplify the MEM_REF case, whose first part is a bit
convoluted, and replace TREE_TYPE (exp) with 'type' in some other places.
No functional changes whatsoever (and no conflicts with Alan's patch).
Bootstrapped/regtested on x86_64-suse-linux, applied on mainline as obvious.
On Wed, 12 Jun 2013, Richard Biener wrote:
On Tue, Jun 11, 2013 at 9:30 PM, Marc Glisse wrote:
On Tue, 11 Jun 2013, Jeff Law wrote:
On 06/09/13 10:25, Marc Glisse wrote:
Hello,
this patch removes some self-assignments. I don't know if this is the
best way, but it passes a bootstrap and th
On Wed, 12 Jun 2013, Richard Biener wrote:
On Tue, Jun 11, 2013 at 9:44 PM, Marc Glisse wrote:
On Tue, 11 Jun 2013, Jeff Law wrote:
On 06/09/13 13:43, Marc Glisse wrote:
Hello,
just adapting yet another function so it also works with vectors.
It seemed convenient to add a new macro. The
Hi,
this patch is basically preparation for Richard's new tree merging patch.
It allows merging multiple instances of same variable and function decls
prior symtab streaming by forcingly creating duplicate symtab entries as needed.
There are two issues. First symtab maintain hash mapping declarati
Hi!
gcc.dg/vect/slp-widen-mult-half.c fails on ppc64, because
vect_recog_widen_mult_pattern creates with WIDEN_MULT_EXPR
with invalid argument types - it is a HIxHI->SI multiplication,
and rhs1 is properly HImode, but rhs2 is INTEGER_CST with SImode
(which vect_handle_widen_op_by_const verified it
On Wed, 12 Jun 2013, Jakub Jelinek wrote:
> Hi!
>
> gcc.dg/vect/slp-widen-mult-half.c fails on ppc64, because
> vect_recog_widen_mult_pattern creates with WIDEN_MULT_EXPR
> with invalid argument types - it is a HIxHI->SI multiplication,
> and rhs1 is properly HImode, but rhs2 is INTEGER_CST with
On Wed, Jun 12, 2013 at 10:47 AM, Marc Glisse wrote:
> On Wed, 12 Jun 2013, Richard Biener wrote:
>
>> On Tue, Jun 11, 2013 at 9:30 PM, Marc Glisse wrote:
>>>
>>> On Tue, 11 Jun 2013, Jeff Law wrote:
>>>
On 06/09/13 10:25, Marc Glisse wrote:
>
>
> Hello,
>
> this patch re
On Wed, 12 Jun 2013, Marc Glisse wrote:
On Wed, 12 Jun 2013, Richard Biener wrote:
I suppose it's explicitely not allowing complex integer constants?
Hmm... Thanks, I keep forgetting complex :-(
Do we want A+~A -> -1-i for integer complex types? Is using BIT_NOT_EXPR
on them even legal? C
OK
/Marcus
On 11 June 2013 14:43, Sofiane Naci wrote:
> Hi,
>
> This patch fixes a bug in the move_lo_quad_ pattern.
>
> The pattern, shown below, issues a scalar MOV instruction for vector modes:
>
> (define_insn "move_lo_quad_"
> [(set (match_operand:VQ 0 "register_operand" "=w,w,w")
>
On Jun 11, 2013, at 16:50 , David Edelsohn wrote:
>> I solved this in gcc/config/rs6000/t-linux by replacing the line
>>
>> MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
>> rs6000/e500-double.h, $(tm_file_list)),,v1)
>>
>> with
>>
>> MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(f
This optimizes the very core streaming routines,
streamer_write_char_stream and streamer_write_uhwi_stream and
streamer_write_hwi_stream.
In streamer_write_char_stream you
can notice that writing the char possibly clobbers the pointer
(and everything else) because it uses alias set zero and may
Hi,
PR 57539 revealed two problems with remapping reference descriptors
during cloning of trees of inlined call graph nodes. First, when
indirect inlining is involved, we happily remove the reference
descriptor itself by calling ipa_free_edge_args_substructures in
ipa_propagate_indirect_call_info
Hi,
On Wed, Jun 12, 2013 at 01:59:29PM +0200, Martin Jambor wrote:
> 2013-06-10 Martin Jambor
>
> PR tree-optimization/57539
> * cgraphclones.c (cgraph_clone_node): Add parameter new_inlined_to, set
> global.inlined_to of the new node to it. All callers changed.
> * ip
Hi,
this is the simplest fix for the PR which happens because there is no
VDEF on a stmt if a particular function is not optimized. I'd like to
fix the bug with it on the branch. Bootstrapped and tested on
x86_64-linux. OK?
Thanks,
Martin
2013-06-11 Martin Jambor
PR tree-optimiz
Hi!
I've noticed we have use omp_lib_kinds even in interfaces which really don't
need those, are they aren't using anything from omp_lib_kinds.
Fixed thusly, committed to gomp-4_0-branch.
2013-06-12 Jakub Jelinek
* omp_lib.f90.in (omp_get_dynamic, omp_get_nested,
omp_in_paral
Hi!
This adds another libgomp entry-point, the function is supposed to return
1/.true. if running on host and 0/.false. when running on the accelerator.
So far we always run on the host.
Tested on x86_64-linux, committed to gomp-4_0-branch.
2013-06-12 Jakub Jelinek
* fortran.c (omp_i
Hi,
this is how I would like to fix the ICE when analyzing a function with
attribute optimize on trunk. Inlining, the other user of the
analysis, is already smart enough not to analyze such functions, so
this teaches IPA-CP to do the same thing. Consequently, functions
witrh attribute optimize(O
This limits the block-size granularity we use for increasing the
output buffer for LTO to 2MB. Previously it grows exponentially
and unlimited. I've increased the first block-size to 4096 bytes
from 1024 as well. Any comments on the particular limit?
Not sure if we could even optimize away the
Hi!
The num_threads clause on the #pragma omp teams construct has been replaced
with a new thread_limit clause. Changed for C++ FE thusly:
2013-06-12 Jakub Jelinek
* gimplify.c (gimplify_scan_omp_clauses): Handle
OMP_CLAUSE_THREAD_LIMIT.
* tree-pretty-print.c (dump_om
David: Can you have a look at libgfortran/config/fpu-aix.h - Thanks!
Uros: Can you have a look at libgfortran/config/fpu-387.h - Thanks!
The attached patch causes gfortran-compiled programs to print warnings like
Note: The following floating-point status flag is signalling:
IEEE_DIVIDE_BY_ZERO
Hi!
1) reference types in map/to/from clauses are supposed to map/copy what
those references refer to, so the reference var itself doesn't need to be
addressable. We'll need to remap the reference variable to a new reference
that will refer to the corresponding device object.
2) the spec now allo
Thanks Dominique and Andreas for reporting this issue.
Dominique Dhumieres wrote:
The test gfortran.dg/finalize_10.f90 fails in 32 bit mode [...]
The following patch fixes it
[...]
I have tried to weaken the test by not using any target and using a regexp
of the kind "(int|long)", but I did
Tobias Burnus wrote:
Dominique Dhumieres wrote:
I have tried to weaken the test by not using any target and using a
regexp
of the kind "(int|long)", but I did not succeeded.
Ups, I missed that Dominique's and Andreas' 32bit dumps are different
("unsigned int" vs. "character(kind=4)"). Thus,
OK, but please add a comment.
Jason
On Tue, Jun 11, 2013 at 10:44:12PM +0200, Jakub Jelinek wrote:
> There is another thing to solve BTW, op0 and/or op1 might have side-effects,
> if you are going to evaluate them more than once, they need to be surrounded
> into cp_save_expr resp. c_save_expr.
There's that unpleasant thing that cp_
On Wed, Jun 12, 2013 at 03:48:24PM +0200, Marek Polacek wrote:
> On Tue, Jun 11, 2013 at 10:44:12PM +0200, Jakub Jelinek wrote:
> > There is another thing to solve BTW, op0 and/or op1 might have side-effects,
> > if you are going to evaluate them more than once, they need to be surrounded
> > into
Am 12.06.2013 13:05, schrieb Olivier Hainque:
>
> On Jun 11, 2013, at 16:50 , David Edelsohn wrote:
>>> I solved this in gcc/config/rs6000/t-linux by replacing the line
>>>
>>> MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring
>>> rs6000/e500-double.h, $(tm_file_list)),,v1)
>>>
>>> with
>
On Wed, Jun 12, 2013 at 3:05 PM, Tobias Burnus wrote:
> David: Can you have a look at libgfortran/config/fpu-aix.h - Thanks!
> Uros: Can you have a look at libgfortran/config/fpu-387.h - Thanks!
>
+ unsigned short cw;
+
+ __asm__ ("fnstsw %0" : "=a" (cw));
__asm__ __volatile__ ("fnstsw\t%0" :
On 06/12/2013 03:38 PM, Jason Merrill wrote:
OK, but please add a comment.
Thanks. I added this:
// cp_parser_lookup_name has the same diagnostic,
// thus make sure to emit it almost once.
Paolo.
[CCing port maintainers]
Currently the MULTIARCH_DIRNAME is not correctly set for the x86_64-kfreebsd-gnu
target, and is not set at all for architectures which do have multilib
configurations by default. This patch makes sure that MULTIARCH_DIRNAME is
always set to the default multilib configurat
On 06/12/2013 04:05 PM, Paolo Carlini wrote:
On 06/12/2013 03:38 PM, Jason Merrill wrote:
OK, but please add a comment.
Thanks. I added this:
// cp_parser_lookup_name has the same diagnostic,
// thus make sure to emit it almost once.
As mentioned by Marc off-line,
Hi,
verifier needs update to tolerate duplicated nodes for a decl during LTO
streaming
state.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
* cgraph.c (verify_edge_corresponds_to_fndecl): Be lax about
decl has when in streaming stage.
* lto-symtab.c (lto_symtab_me
Hi,
This fixes up some of the fallout in the testsuite for ARM with the
DATA_ABI_ALIGNMENT changes recently.
Applied to trunk.
regards
Ramana
2013-06-12 Ramana Radhakrishnan
* gcc.target/arm/unaligned-memcpy-4.c (src, dst): Initialize
to ensure alignment.
* gcc.t
FLOAT_WORDS_BIG_ENDIAN doesn't work out too well for IBM extended
double when little-endian, because we're thinking to keep the large
magnitude double first. See the comment below on
LONG_DOUBLE_LARGE_FIRST.
This patch fixes all occurrences of FLOAT_WORDS_BIG_ENDIAN in the
rs6000 backend (all of
On Wed, Jun 12, 2013 at 10:53 AM, Alan Modra wrote:
> * config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
> * config/rs6000/rs6000.md (signbittf2): New insn.
> (extenddftf2_internal): Use LONG_DOUBLE_LARGE_FIRST.
> (abstf2_internal, cmptf_internal2): Likewi
As noted in the comment below, IBM long double is really an array of
two doubles. In little-endian mode this means the words of each
double should be reversed in write_real_cst, but the large magnitude
double remains the first element of the array.
This patch specially treats IBM long double so t
On Wed, Jun 12, 2013 at 03:52:08PM +0200, Jakub Jelinek wrote:
> No, you really need to use the cp_save_expr/c_save_expr, especially for
> C it e.g. fully folds etc. You want to call that in
> cp_build_binary_op etc., also because you want both the instrument_expr
> itself, but also the original b
On Wed, Jun 12, 2013 at 11:09:03AM -0400, David Edelsohn wrote:
> On Wed, Jun 12, 2013 at 10:53 AM, Alan Modra wrote:
>
> > * config/rs6000/rs6000.h (LONG_DOUBLE_LARGE_FIRST): Define.
> > * config/rs6000/rs6000.md (signbittf2): New insn.
> > (extenddftf2_internal): Use LON
Hi,
This test case:
void foo(long long *d, int *f)
{
int i;
for (i=0; i< 16; i++)
{
d[i] = f[i];
}
}
when vectorized for big-endian mode, generates this sequence of widening
operations:
...
_33 = (void *) ivtmp.22_25;
vect__11.5_39 = MEM[base: _33, offset: 0B];
vect__12.6_
On Wed, Jun 12, 2013 at 05:17:45PM +0200, Marek Polacek wrote:
> @@ -3867,6 +3868,7 @@ cp_build_binary_op (location_t location,
>tree final_type = 0;
>
>tree result;
> + tree orig_type = NULL;
>
>/* Nonzero if this is an operation like MIN or MAX which can
> safely be compute
What is your model for the way that the RTL and C statements in the
new signbittf2 pattern interact?
The C preparation statements are executed before the RTL code
generated from the RTL template. In the patch, it seems that the new
pattern is assuming that it can rely on some results produced by
On 06/12/13 02:03, Richard Biener wrote:
DSE looks like the right place to me as we are removing a store. Yes,
DCE removes a limited set of stores as well, but the way we remove this kind
of store makes it much more suited to DSE.
As of possibly trapping/throwing stores, we do not bother to pr
On 06/11/13 13:30, Marc Glisse wrote:
I'd be curious how often this triggers in GCC itself as well.
Do you know a convenient way to test that?
I usually put in some kind of debugging printfs during early development
which I can then grep for in build logs. Not very sexy, but effective
to
On Wed, Jun 12, 2013 at 05:29:21PM +0200, Jakub Jelinek wrote:
> > @@ -4070,8 +4081,12 @@ cp_build_binary_op (location_t location,
> > {
> > enum tree_code tcode0 = code0, tcode1 = code1;
> > tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
> > + cop1 = maybe_constant_
On Wed, Jun 12, 2013 at 9:05 AM, Tobias Burnus wrote:
> David: Can you have a look at libgfortran/config/fpu-aix.h - Thanks!
> Uros: Can you have a look at libgfortran/config/fpu-387.h - Thanks!
The AIX bits look correct. Thanks very much for investigating AIX support.
Thanks, David
On Wed, Jun 12, 2013 at 09:42:55AM -0600, Jeff Law wrote:
> On 06/12/13 02:03, Richard Biener wrote:
> >DSE looks like the right place to me as we are removing a store. Yes,
> >DCE removes a limited set of stores as well, but the way we remove this kind
> >of store makes it much more suited to DSE
Updated version:
* Uros suggestions are incorporated
* Changed from -f(no-)underflow-warning to
-ffpe-summary=[none,all,underflow,...]
Tobias Burnus wrote:
David: Can you have a look at libgfortran/config/fpu-aix.h - Thanks!
The attached patch causes gfortran-compiled programs to print warnin
On Mon, Jun 10, 2013 at 2:30 PM, Jason Merrill wrote:
> On 06/08/2013 09:34 AM, Andrew Sutton wrote:
>>
>> I think I previously put constraint_info in lang_decl_min, right next
>> to template_info no less. It was easy to manage there, and initialized
>> as part of build_template_decl. But this obv
On Mon, Jun 10, 2013 at 2:37 PM, Jason Merrill wrote:
> Since members of the anonymous namespace can't be defined in another
> translation unit, we should treat them like statics for diagnostic purposes.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Thank you!
-- Gaby
On Wed, Jun 12, 2013 at 03:05:30PM +0200, Tobias Burnus wrote:
> --- a/libgfortran/runtime/stop.c
> +++ b/libgfortran/runtime/stop.c
> @@ -32,6 +32,37 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see
> #endif
>
>
> +/* Fortran 2008 demands: If any exception (14) is s
Hi,
this bug is a sort of follow up to 10416, which I fixed some time ago
and was about avoiding -Wunused warnings for class types with
destructors with side-effects.
In this issue reporter notes that we don't handle in the same way
references, thus, considering the testcase, we do not warn
On 06/07/13 03:14, Richard Biener wrote:
+/* Given SSA_NAMEs NAME1 and NAME2, return true if they are candidates for
+ coalescing together, false otherwise.
+
+ This must stay consistent with the code in tree-ssa-live.c which
+ sets up base values in the var map. */
+
+bool
+gimple_can_c
[Jason/Richard: there are some things below I could use your feedback on.]
Hi Balaji.
Overall, a lot of the stuff in cp-array-notation.c looks familiar from
the C front-end changes. Can't you reuse a lot of it?
Otherwise, here are some minor nits...
+ /* If the function call is builti
On 06/12/2013 11:53 AM, Gabriel Dos Reis wrote:
I am still surprised though that we don't generate TEMPLATE_DECLs for
partial instantiations (since they are still morally templates.)
Yes, we should.
Jason
On 06/12/2013 11:58 AM, Paolo Carlini wrote:
-&& TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
+&& TREE_CODE (type) != REFERENCE_TYPE
This change is wrong; we specifically want to suppress the
unused-but-set warning for reference variables. Drop it and
Hi All,
This patch adds the needed 'dg-require-effective-target sync_*' lines to some
of the atomic tests so that they will not be run if the appropriate atomic
support is not available.
OK for trunk?
2013-06-12 Meador Inge
* gcc.dg/atomic-flag.c: Add dg-require-effective-target sync
Hi Aldy,
Below are my responses to a couple of the things you pointed out.
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, June 12, 2013 12:34 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Jason Merrill (ja
On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> where simd_uid would be some say integer constant, unique to the simd loop
> (at least unique within the same function, and perhaps inlining/LTO would
> need to remap).
If all we need is uniqueness, then perhaps an otherwise unused decl would do?
We'r
Hello Everyone,
Attach, please find a patch that will fix the issues in C/PR57541. The
issue reported was that the parameters passed into the builtin array notation
reduction functions were not checked correctly. This patch should fix that
issue. It is tested on x86 and x86_64 and it see
Hi,
Jason Merrill ha scritto:
>On 06/12/2013 11:58 AM, Paolo Carlini wrote:
>> - && TREE_CODE (TREE_TYPE (decl)) != REFERENCE_TYPE
>> + && TREE_CODE (type) != REFERENCE_TYPE
>
>This change is wrong; we specifically want to suppress the
>unused-but-set warning fo
On Wed, Jun 12, 2013 at 10:21:53AM -0700, Richard Henderson wrote:
> On 04/27/2013 11:17 AM, Jakub Jelinek wrote:
> > where simd_uid would be some say integer constant, unique to the simd loop
> > (at least unique within the same function, and perhaps inlining/LTO would
> > need to remap).
>
> If
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
> Then there is the _simduid_ clause (also can hold address of the decl), and
> after lowering it lives only in loop structure (
Humpf,
>I understand the general issue, but I'm not sure we can't use 'type'
>here: we don't even consider emitting the unused-but-set warning when
>TREE_USED (decl) is false and in this case I don't call non_reference
>at the outset.
I meant *only* in this case I call non_reference, you see my
Overall, a lot of the stuff in cp-array-notation.c looks familiar
from the C front- end changes. Can't you reuse a lot of it?
I looked into trying to combine many functionality. The issue that
prohibited me was templates and extra trees. For example, IF_STMT,
FOR_STMT, MODOP_EXPR, etc are not
On 06/12/2013 01:37 PM, Paolo Carlini wrote:
Rewording: as the one line comment says, I only call non_reference at the
outset when I know that either we'll end up producing the normal
unused-variable warning or nothing at all.
Oh, I see. But that's a rather subtle difference; better to have
The e500v2 (SPE) hardware is such that if the address of vector (double world
load / stores) are not double world aligned the instruction will trap.
So this alignment is not optional.
Edmar
On Fri, Jun 7, 2013 at 3:43 PM, Richard Henderson wrote:
> On 06/07/2013 12:25 PM, Jakub Jelinek wrote:
On Wed, 12 Jun 2013, Richard Biener wrote:
On Wed, Jun 12, 2013 at 10:47 AM, Marc Glisse wrote:
Essentially never. I tried with the fold_stmt version of the patch, and
libstdc++-v3/src/c++98/concept-inst.cc is the only file where it triggers.
Note that the case:
b=*a
*a=b
is already handled b
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Wednesday, June 12, 2013 1:40 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Jason Merrill (ja...@redhat.com);
> r...@redhat.com
> Subject: Re: [PATCH] Cilk Plus Array Notation for C++
>
>
> >> Overall
On Thu, 13 Jun 2013, Alan Modra wrote:
> This is of course an ABI change for any existing little-endian users
> of IBM long double literals in templates. On powerpc, I think we can
> safely say there are no such users. However it does look like MIPS
> also uses a variant of IBM long double, and
Matthias Klose writes:
> Index: config/mips/t-linux64
> ===
> --- config/mips/t-linux64 (revision 200012)
> +++ config/mips/t-linux64 (working copy)
> @@ -24,3 +24,13 @@
> ../lib32$(call
> if_multiarch,:mips64$(MIPS_EL)
Hi,
On 06/12/2013 07:46 PM, Jason Merrill wrote:
On 06/12/2013 01:37 PM, Paolo Carlini wrote:
Rewording: as the one line comment says, I only call non_reference at
the outset when I know that either we'll end up producing the normal
unused-variable warning or nothing at all.
Oh, I see. But th
I've ported the following four patches from the google/gcc-4_7 branch.
(I'll also push these to trunk shortly.)
Bootstrapped, tested, and committed at r200036.
-cary
gcc:
2012-08-09 Cary Coutant
Backport of pending upstream patch.
* dwarf2out.c (clone_as_declaration): Copy DW
Richard Sandiford writes:
> "Moore, Catherine" writes:
>> I'm testing a slightly different patch from the one that Steve posted:
>>
>> Index: mips.md
>> ===
>> --- mips.md (revision 199648)
>> +++ mips.md (working copy)
>> @@
"Jürgen Urban" writes:
>> > How much other changes will be currently accepted here? There is other
>> > stuff which I want to prepare and submit here, e.g.:
>> > 1. disable use of dmult and ddiv (ABI n32).
>> > 2. use trunc.w.s instead of cvt.w.s (to get single float working for
>> > normal range
OK.
Jason
Hi,
I am writing a tool to fix common style issues.
This is first part which deals with leading and trailing whitespaces.
I can follow this up with other refactorings, for example rewriting
K&R definitions.
I wrote a simple programs that fixes them.
Then it suffices for me or any volunteer to r
Hello Everyone,
I replaced abort and exit in one of the Cilk Plus Array Notation test
with return 1 and return 0, respectively. This patch (cut and pasted below) is
committed as obvious.
Thanks,
Balaji V. Iyer.
Index: gcc/testsuite/ChangeLog
A second part of this cleanup is optional.
If you want to preserve form feeds its your decision, If you want to
remove them here is patch.
http://kam.mff.cuni.cz/~ondra/0002-Formatted-by-form_feed.patch
Now we move to leading spaces,
If you want only to fix leading spaces followed by tab then please use
following patch
http://kam.mff.cuni.cz/~ondra/0003-Formatted-by-space_before_tab.patch
A followup to previous patch is more general pass that changes leading
spaces to tabs followed by at most 8 spaces.
http://kam.mff.cuni.cz/~ondra/0004-Formatted-by-leading_space.patch
Hi
Any news regarding this patch ?
Thanks
François
On 06/06/2013 10:33 PM, François Dumont wrote:
On 05/24/2013 01:00 AM, Paolo Carlini wrote:
On 05/23/2013 10:01 PM, François Dumont wrote:
Some feedback regarding this patch ?
Two quick ones: what if the hint is wrong? I suppose the in
On Wed, 12 Jun 2013, Marc Glisse wrote:
I suppose it's explicitely not allowing complex integer constants?
Hmm... Thanks, I keep forgetting complex :-(
And complex is even more of a pain than vector to handle.
Testing for CONSTANT_CLASS_P seems sufficient here. Some transformations also
se
Here is an overdue patch for the Airy function.
I repair the void function and I out two Airy functions as C++ extensions.
Built and tested on x86_64-linux.
OK?
Ed
CL_Airy
Description: Binary data
patch_Airy4
Description: Binary data
On Wed, 12 Jun 2013, Ondřej Bílka wrote:
I am writing a tool to fix common style issues.
This is first part which deals with leading and trailing whitespaces.
I can follow this up with other refactorings, for example rewriting
K&R definitions.
Bonus points for asking first ;-)
2013-06-12
Hello,
this is a fix for PR49074, where the temporary created by
gfc_conv_elemental_dependencies was leading to an ICE because it didn't
have the array reference expected by the scalarization code.
There was a bypass in gfc_conv_procedure_call avoiding exactly this
problem, but it is not reached
Hello Mikael,
Mikael Morin wrote:
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
OK - looks good to me. The test case is also nice and a bit tricky, I
tried it with three compilers: Two segfaulted at run time and only one
passed the test.
Tobias
On 06/12/13 14:17, Marc Glisse wrote:
On Wed, 12 Jun 2013, Marc Glisse wrote:
I suppose it's explicitely not allowing complex integer constants?
Hmm... Thanks, I keep forgetting complex :-(
And complex is even more of a pain than vector to handle.
Testing for CONSTANT_CLASS_P seems suffic
"Joseph S. Myers" writes:
> On Thu, 13 Jun 2013, Alan Modra wrote:
>> This is of course an ABI change for any existing little-endian users
>> of IBM long double literals in templates. On powerpc, I think we can
>> safely say there are no such users. However it does look like MIPS
>> also uses a
On Wed, 12 Jun 2013, Jeff Law wrote:
On 06/12/13 14:17, Marc Glisse wrote:
On Wed, 12 Jun 2013, Marc Glisse wrote:
I suppose it's explicitely not allowing complex integer constants?
Hmm... Thanks, I keep forgetting complex :-(
And complex is even more of a pain than vector to handle.
Te
Hi,
On 06/12/2013 10:28 PM, 3dw...@verizon.net wrote:
Here is an overdue patch for the Airy function.
I repair the void function and I out two Airy functions as C++ extensions.
Built and tested on x86_64-linux.
OK?
The functions are unused, please remove them and close the PR.
Thanks,
Paolo.
Make the array non-common so that it is treated as binding to the
current TU.
Tested on mipsisa32-sde-elf and applied.
Richard
gcc/testsuite/
* gcc.target/mips/mips.exp: Handle -f{no-,}common.
* gcc.target/mips/memcpy-1.c: Remove redundant dg-do.
Run with -fno-common.
I
Hello,
Le 10/06/2013 22:40, Tobias Burnus a écrit :
> My problem: I do not see where one can best handle the namelist for
> modules. One possibility would be gen_namespace_die - but that would
> come before the dies of all VAR_DECLs used in the namelist have been
> created. And the code seems to
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
> On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
> > So the built-ins would take address of this decl, something else?
>
> Perhaps address, perhaps just referenced uninitialized?
True, assuming no pass would actually want to change
Vladimir Makarov writes:
> Index: lra.c
> ===
> --- lra.c (revision 199753)
> +++ lra.c (working copy)
> @@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z)
> || (disp != NULL_RTX && ! CONSTANT_P (disp))
>
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
pr57518 happened because update_equiv_regs in IRA marked a reg
equivalent with a mem, lowered its mem_cost in scan_one_insn, set
NO_REGS to its rclass, but didn't consider the reg was used in
paradoxical subreg which prevented the reg from bei
On Tue, Jun 11, 2013 at 7:53 PM, Michael Meissner
wrote:
> I needed to rework the sync.md so that it would work correctly with no
> optimization (using SUBREG's at -O0 did not give us the even registers for
> holding PTImode values, so I created a PTImode temporary in load_lockedti and
> store_con
Background: on ARM and some other targets, the ABI requires that
volatile bit-fields be accessed atomically in a mode that corresponds to
the declared type of the field, which conflicts with GCC's normal
behavior of doing accesses in a mode that might correspond to the size
of a general-purpos
1 - 100 of 119 matches
Mail list logo
