As described in PR target/63810, this addresses several problems with
the validation and encoding of deployment target version strings for the
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ macro. There are
currently four testcases exercising inputs to -mmacosx-version-min
On Fri, May 15, 2015 at 09:04:52AM +0100, Kyrill Tkachov wrote:
Hi all,
It seems that AARCH64_TUNE_SLOWMUL somehow slipped from the arm backend into
the aarch64 one.
This macro is not used anywhere and I don't expect it will be used. It has
been there since
October 2012 i.e. when the
Hi,
This patch fixes misuse of abnormal bounds copy to avoid coalescing issue.
Bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk. Is
it OK for gcc-5?
Thanks,
Ilya
--
gcc/
2015-05-15 Ilya Enkovich enkovich@gmail.com
PR middle-end/66134
*
On 15/05/15 07:46, Kugan wrote:
Sorry, this is not the right fix. Looking at it.
Hi Kugan,
FWIW, I'm seeing this bootstrap failure as well.
If you have a patch for this, it would be appreciated.
Kyrill
Thanks,
Kugan
On 15/05/15 16:41, Kugan wrote:
Hi Richard,
r223090 seem to miss a
Hi Richard,
r223090 seem to miss a parenthesis and seem to be causing:
from ../../widen/gcc/fold-const.c:46:
../../widen/gcc/fold-const.c: In function 'tree_node*
fold_range_test(location_t, tree_code, tree, tree, tree)':
../../widen/gcc/config/arm/arm.h:2068:4: error: enumeral
On 15/05/15 07:41, Kugan wrote:
Hi Richard,
r223090 seem to miss a parenthesis and seem to be causing:
from ../../widen/gcc/fold-const.c:46:
../../widen/gcc/fold-const.c: In function 'tree_node*
fold_range_test(location_t, tree_code, tree, tree, tree)':
Hi all,
It seems that AARCH64_TUNE_SLOWMUL somehow slipped from the arm backend into
the aarch64 one.
This macro is not used anywhere and I don't expect it will be used. It has been
there since
October 2012 i.e. when the port was first contributed.
This patch removes that and the relevant
Hello.
Following patch is fix for GCC-5 branch for PR ipa/65908, was tested on
x86_64-linux-pc, as well as bootstrapped.
As soon as the patch is applied, I'm going to send the similar patch for trunk.
Ready for 5 branch?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2015-05-12 Martin Liska
Manuel López-Ibáñez lopeziba...@gmail.com writes:
Thanks for the review. I followed all your suggestions. For the
accessor functions, I was not sure what type you would prefer, so I
implemented them as C++ methods and made use of 'private' to be sure
they are the only way to access the
Sorry, this is not the right fix. Looking at it.
Thanks,
Kugan
On 15/05/15 16:41, Kugan wrote:
Hi Richard,
r223090 seem to miss a parenthesis and seem to be causing:
from ../../widen/gcc/fold-const.c:46:
../../widen/gcc/fold-const.c: In function 'tree_node*
Hi,
I have tried to refactor gimple_expr_type to make it more readable. Removed the
switch block and redundant if.
Please review this patch.
Thanks,
-Aditya
gcc/ChangeLog:
2015-05-15 hiraditya hiradi...@msn.com
* gimple.h (gimple_expr_type): Refactor to make it concise. Remove
On 27/04/15 15:52, Szabolcs Nagy wrote:
On 20/04/15 19:57, Szabolcs Nagy wrote:
Set up dynamic linker name for x86.
Patch v2.
(undef MUSL_DYNAMIC_LINKER* before defining it).
ping
(now with maintainers in cc)
gcc/Changelog:
2015-04-27 Gregor Richards gregor.richa...@uwaterloo.ca
On 20/04/15 19:53, Szabolcs Nagy wrote:
Set up dynamic linker name for arm.
ping
(now with maintainer in cc)
gcc/Changelog:
2015-04-16 Gregor Richards gregor.richa...@uwaterloo.ca
* config/arm/linux-eabi.h (MUSL_DYNAMIC_LINKER): Define.
Hello,
this patch was regtested on ppc64le-redhat-linux.
2015-05-15 Marc Glisse marc.gli...@inria.fr
gcc/
* convert.c (convert_to_integer, convert_to_vector): Include the
types in the error message.
gcc/testsuite/
* gcc.dg/simd-1.c: Update to the new message.
--
Marc
The change may be small enough that an assignment isn't needed.
We (ie, the gfortran developers) will need to check.
I think that’s small enough, compared to what we’ve accepted as such in the
past.
If not, a disclaimer by Russell putting his change in the public domain would
also be a quick
Hello!
As shown in the PR [1], reload can also schedule a replacement inside
memory address. Attached patch removes invalid check.
2015-05-15 Uros Bizjak ubiz...@gmail.com
PR target/66140
* config/alpha/alpha.c (get_aligned_mem): Also look for reload
replacements in memory
On 15 May 2015 at 10:39, Dodji Seketeli do...@redhat.com wrote:
Manuel López-Ibáñez lopeziba...@gmail.com writes:
-/* Expand the location of this diagnostic. Use this function for
consistency. */
+/* Return the location associated to this diagnostic. WHICH specifies
Here, I think only the
On 27/04/15 15:33, Szabolcs Nagy wrote:
On 21/04/15 15:16, pins...@gmail.com wrote:
I don't think you need to check if defaulting to little or big-endian here
are the specs always have one or the other passing through.
Also if musl does not support ilp32, you might want to error out. Or
Hi.
Following patch add support of dbg-cnt for IPA ICF pass.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2015-05-15 Martin Liska mli...@suse.cz
* dbgcnt.def: Add new counter.
* ipa-icf.c (sem_item_optimizer::merge_classes): Use the
counter.
---
gcc/dbgcnt.def | 1
Hi.
Following patch changes GCC so that it exits after -fdbg-cnt-list and counters
are sorted in dbgcnt.def file.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2015-05-15 Martin Liska mli...@suse.cz
* dbgcnt.def: Sort counters.
* opts.c (common_handle_option): Do not
On Thu, May 14, 2015 at 09:51:18AM -0400, David Edelsohn wrote:
On Wed, May 13, 2015 at 1:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Wed, May 13, 2015 at 01:25:16PM -0400, David Edelsohn wrote:
PR rtl-optimization/30967
* config/rs6000/rs6000.c
On Fri, May 15, 2015 at 10:38:57AM +0200, Martin Liška wrote:
Following patch is fix for GCC-5 branch for PR ipa/65908, was tested on
x86_64-linux-pc, as well as bootstrapped.
As soon as the patch is applied, I'm going to send the similar patch for
trunk.
I'll leave the review to Honza or
On 20/04/15 20:00, Szabolcs Nagy wrote:
The posix_memalign declaration is incompatible with musl for C++,
because of the exception specification. It also pollutes the
namespace and lacks protection against a potential macro definition
that is allowed by POSIX. The fix avoids source level
On 15/05/15 13:43, Uros Bizjak wrote:
On Fri, May 15, 2015 at 2:33 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
On 27/04/15 15:52, Szabolcs Nagy wrote:
On 20/04/15 19:57, Szabolcs Nagy wrote:
Set up dynamic linker name for x86.
Patch v2.
(undef MUSL_DYNAMIC_LINKER* before defining it).
On Sat, May 09, 2015 at 09:42:23AM -0700, Martin Uecker wrote:
here is a tentative patch to implement a new attribute nonzero,
which is similar to nonnull, but is not a function attribute
but a type attribute.
One reason is that nonnull is awkward to use. For this reason,
clang allows the
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Friday, May 15, 2015 10:30 AM
Just to summarize: By default in GCC v4.7.x, all the constants are put
into '.rodata.str1.4' section. In GCC v4.8.x from r192719 onwards, one
of the move instruction of the string
Hello,
these are just a few tweaks / clean-ups. The 'ord' pattern is the dual of
the 'unord' one I added last month. The tree_unary_nonnegative_warnv_p
change should have no effect (it is only used from VRP which does not
handle vectors (yet?)) but it seems right to handle vectors like
On 05/15/2015 12:38 PM, Jakub Jelinek wrote:
On Fri, May 15, 2015 at 10:38:57AM +0200, Martin Liška wrote:
Following patch is fix for GCC-5 branch for PR ipa/65908, was tested on
x86_64-linux-pc, as well as bootstrapped.
As soon as the patch is applied, I'm going to send the similar patch for
On 05/15/2015 05:26 AM, Uros Bizjak wrote:
2015-05-15 Uros Bizjak ubiz...@gmail.com
PR target/66140
* config/alpha/alpha.c (get_aligned_mem): Also look for reload
replacements in memory addresses.
(get_unaligned_address): Ditto.
Ok.
r~
On Fri, May 15, 2015 at 2:34 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
On 20/04/15 20:00, Szabolcs Nagy wrote:
The posix_memalign declaration is incompatible with musl for C++,
because of the exception specification. It also pollutes the
namespace and lacks protection against a potential
On Fri, May 15, 2015 at 2:33 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
On 27/04/15 15:52, Szabolcs Nagy wrote:
On 20/04/15 19:57, Szabolcs Nagy wrote:
Set up dynamic linker name for x86.
Patch v2.
(undef MUSL_DYNAMIC_LINKER* before defining it).
ping
(now with maintainers in cc)
Regression tested on trunk. OK to commit?
See the test case for the type of error that this patch
catches.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66057
* decl.c(gfc_match_generic): Detected a malformed GENERIC statement.
2015-05-XX Steven G. Kargl
On Wed, 2015-05-06 at 17:54 +0300, Gleb Fotengauer-Malinovskiy wrote:
2015-05-06 Gleb Fotengauer-Malinovskiy gle...@altlinux.org
PR libitm/61164
* local_atomic (__always_inline): Rename to...
(__libitm_always_inline): ... this.
OK. Thanks.
Regression tested on trunk. OK to commit?
Subject says it all.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66052
* decl.c(gfc_match_protected): Prevent dereference of NULL pointer.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66052
Version 2 includes proper test cases and documentation.
Hopefully the documentation even makes sense. Suggestions
and improvements there gratefully appreciated.
r~
---
gcc/config/i386/constraints.md | 5 ++
gcc/config/i386/i386.c | 137
I can change the error to something like
Intrinsic function NULL() cannot be an actual argument to
STORAGE_SIZE because it returns a disassociated pointer”
I think that’d be better, indeed.
No. This isn't a numbered constraint. I spent an hour or so
tracing though parent namespaces and
Regression tested on trunk. OK to commit?
The patch is self-explanatory.
Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66045
* expr.c (gfc_check_assign): Check for assignment of NULL() instead
of the (intended) pointer assignment.
2015-05-XX Steven G. Kargl
- You’re missing the match.c part of the patch (I really had a hard time
figuring out how the patch was supposed to work! then I read the one posted in
the PR)
- Let’s avoid the strcmp() string comparison and use “op == INTRINSIC_NONE” as
the condition (seems clearer and more efficient to me)
On Fri, May 15, 2015 at 05:34:14PM +0200, FX wrote:
Hi Steve,
+ gfc_error (%qs argument of %qs intrinsic at %L shall not be an
+ unallocated allocatable variable or a disassociated or
+ undefined pointer???,
Given that we know explicitly that the expr is
On Fri, May 15, 2015 at 05:45:54PM +0200, FX wrote:
- You're missing the match.c part of the patch (I really had
a hard time figuring out how the patch was supposed to work!
then I read the one posted in the PR)
Whoops, sorry about that. As you can see I have small patches
sitting in my
Regression tested on trunk. OK to commit?
The patch allows gfortran to check a portion of C1202
that was previously mishandled.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66057
* interface.c(gfc_match_end_interface): Enfornce F2008 C1202 (R1201).
2015-05-XX
Hi Steve,
+ gfc_error (%qs argument of %qs intrinsic at %L shall not be an
+unallocated allocatable variable or a disassociated or
+undefined pointer”,
Given that we know explicitly that the expr is NULL, wouldn’t it be nicer to
give only the relevant
On 15/05/15 16:05, H.J. Lu wrote:
On Mon, Apr 20, 2015 at 12:00 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
The posix_memalign declaration is incompatible with musl for C++,
because of the exception specification. It also pollutes the
namespace and lacks protection against a potential
This patch improves the documentation of the built-ins for atomic
operations.
First, to be consistent with the C++11 standard and make it easier for
users to relate the built-ins to the C++11 specification, the patch
changes 'memory model' to 'memory order'. The memory model is the whole
thing,
On Fri, May 15, 2015 at 1:42 PM, Rich Felker dal...@libc.org wrote:
On Fri, May 15, 2015 at 01:35:14PM -0700, H.J. Lu wrote:
On Fri, May 15, 2015 at 1:23 PM, Rich Felker dal...@libc.org wrote:
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
With relax branch in 32-bit, there are 2
On May 14, 2015, at 11:42 PM, Lawrence Velázquez v...@larryv.me wrote:
As described in PR target/63810, this addresses several problems
With this change, trunk matches the behavior of Apple LLVM Compiler
6.1.0 on 8,451 of 8,464 generated test inputs. (The discrepancies are
due to a bug in
Hi,
genmatch generates incorrect code for following (artificial) pattern:
(for op (plus)
op2 (op)
(simplify
(op @x @y)
(op2 @x @y)
generated gimple code: http://pastebin.com/h1uau9qB
'op' is not replaced in the generated code on line 33:
*res_code = op;
I think it would be a
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/64925
* symbol.c(check_conflict): Check for a conflict between a dummy
argument and an internal procedure name.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/64925
*
On Fri, May 15, 2015 at 4:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
My relax branch proposal works even without LTO.
I will borrow GOTPCREL from x86-64 and do
[hjl@gnu-6 relax-4]$ cat b.S
call *foo@GOTPCREL(%eax)
[hjl@gnu-6 relax-4]$ ./as -32 -o b.o b.S
[hjl@gnu-6 relax-4]$ ./objdump -dwr b.o
On Wed, May 13, 2015 at 10:52 AM, Eric Botcazou ebotca...@adacore.com wrote:
The libgo parts are fine, but since libgo is mirrored from an external
repository I'll commit those parts myself.
Thanks!
I assume I can go ahead and commit them now?
Yes, you can, the libgo bits are independent.
Hello,
There are codes like
extern void foo (void);
void
bar (void)
{
foo ();
}
Even with LTO, compiler may have to assume foo is external
when foo is compiled with LTO.
This is not exactly true if FOO is defined in other translation unit
compiled with LTO and hidden
On Fri, May 15, 2015 at 04:34:57PM -0700, H.J. Lu wrote:
On Fri, May 15, 2015 at 4:30 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 15, 2015 at 4:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
My relax branch proposal works even without LTO.
I will borrow GOTPCREL from x86-64 and do
On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hello,
There are codes like
extern void foo (void);
void
bar (void)
{
foo ();
}
Even with LTO, compiler may have to assume foo is external
when foo is compiled with LTO.
This is not exactly true if FOO is defined
On Fri, May 15, 2015 at 4:30 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 15, 2015 at 4:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
My relax branch proposal works even without LTO.
I will borrow GOTPCREL from x86-64 and do
[hjl@gnu-6 relax-4]$ cat b.S
call *foo@GOTPCREL(%eax)
call
On Fri, May 15, 2015 at 04:14:07PM -0700, H.J. Lu wrote:
On Fri, May 15, 2015 at 4:08 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hello,
There are codes like
extern void foo (void);
void
bar (void)
{
foo ();
}
Even with LTO, compiler may have to assume foo is external
when
I've had the attached patch in my tree for a
long and have had no issues. Regression tested
numerous times on trunk. OK to commit?
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/64925
* symbol.c(check_conflict): Check for a conflict between a dummy
argument
Regression tested on trunk. OK to commit?
The patch shuold be self-explanatory.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66043
* check.c (gfc_check_storage_size): Prevent the direct use of NULL()
in STORAGE_SIZE() reference.
2015-05-XX Steven G. Kargl
On Mon, Apr 20, 2015 at 12:00 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
The posix_memalign declaration is incompatible with musl for C++,
because of the exception specification. It also pollutes the
namespace and lacks protection against a potential macro definition
that is allowed by
The attached patch checks for mangled/incomplete
file positioning statements. Regression tested
on trunk with no new failures? OK to commit
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66039
* io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH,
The attached patch has been regression tested on
trunk. OK to commit?
As shown by the testcase, each individual line of code
is legal, but the ordering is incorrect. This leads to
an ICE, which can be correctly reported as a user error.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
Regression tested on trunk. OK to commit?
Poorly written code could invoke an ICE when an ordinary
error could have been emitted.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66044
* decl.c(gfc_match_entry): Change a gfc_internal_error() into
a
On Fri, 1 May 2015, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 12:03:35PM -0500, Segher Boessenkool wrote:
On Wed, Apr 29, 2015 at 09:25:21AM +, Kumar, Venkataramanan wrote:
diff --git a/gcc/combine.c b/gcc/combine.c
index 5c763b4..945abdb 100644
--- a/gcc/combine.c
+++
On 05/15/2015 12:39 PM, Eric Botcazou wrote:
You might consider a comment in active_insn_p and
emit_pattern_{after,before}_setloc so that if someone fixes
active_insn_p, they'll know to fix emit_pattern_{after,before}_setloc.
FIXME doesn't capture this interaction at all ;-)
I beg to differ,
On 05/15/2015 04:36 AM, mliska wrote:
Hi.
Following patch changes GCC so that it exits after -fdbg-cnt-list and counters
are sorted in dbgcnt.def file.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2015-05-15 Martin Liska mli...@suse.cz
* dbgcnt.def: Sort counters.
*
On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov amona...@ispras.ru wrote:
Ping? Any comment about this patch?
On Mon, 4 May 2015, Alexander Monakov wrote:
With -fno-plt, we don't have to reject even direct calls as sibcall
candidates.
This patch depends on '-fplt' flag that is
On 05/15/2015 03:03 AM, mliska wrote:
Hi.
Following patch add support of dbg-cnt for IPA ICF pass.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2015-05-15 Martin Liska mli...@suse.cz
* dbgcnt.def: Add new counter.
* ipa-icf.c (sem_item_optimizer::merge_classes): Use the
On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov amona...@ispras.ru wrote:
Ping? Any comment about this patch?
On Mon, 4 May 2015, Alexander Monakov wrote:
With -fno-plt, we don't have to reject even direct calls as sibcall
candidates.
This patch depends on '-fplt' flag that is
Dear Mikael, dear all,
I am struggling to find time for gfortran at present because of the
change in my personal circumstances. I am still working full time as a
consultant, whilst trying to sell the house and fix up all those
things that l'Administration Francaise makes so interesting (Having
This patch teaches the c and c++ front ends to error on invalid and
conflicting acc loop clauses. E.g., an acc loop cannot have 'gang seq'
and the worker and vector clauses inside parallel regions cannot have
optional kernel-specific arguments.
The c and c++ front end also error when it detects a
Whoops, sorry about that. As you can see I have small patches
sitting in my tree. I tried to untangle the 'svn diff’
Thanks for cleaning and submitting those! I’ll try to review them over the next
2 days, if nobody beats me to it :)
FX
On 04/17/2015 05:01 AM, Mikhail Maltsev wrote:
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
Review: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02672.html
I fixed minor issues mentioned in the review and updated the changelog
message.
Ping? Any comment about this patch?
On Mon, 4 May 2015, Alexander Monakov wrote:
With -fno-plt, we don't have to reject even direct calls as sibcall
candidates.
This patch depends on '-fplt' flag that is introduced in another patch.
This patch requires that with -fno-plt all sibcall
On 05/15/2015 04:37 AM, Dharmakan Rohit Arul Raj wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Friday, May 15, 2015 10:30 AM
Just to summarize: By default in GCC v4.7.x, all the constants are put
into '.rodata.str1.4' section. In GCC v4.8.x from r192719
On 01/05/15 10:28, Kyrill Tkachov wrote:
Can you please confirm that bootstraps with both arm and thumb pass?
That is, configured with --with-mode=arm and --with-mode=thumb
Hi Kyrill,
Bootstrapped on arm-none-gnueabihf with arm and thumb mode.
Following patch requires bics shift operand on
On Fri, May 15, 2015 at 12:48 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Fri, May 15, 2015 at 9:27 AM, Alexander Monakov amona...@ispras.ru
wrote:
Ping? Any comment about this patch?
On Mon, 4 May 2015, Alexander Monakov wrote:
With -fno-plt, we don't have to reject even direct calls
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
With relax branch in 32-bit, there are 2 cases:
1. PIC or PIE: We generate
set up EBX
relax call foo@PLT
It is almost the same as we do now, except for the relax prefix.
If foo is defined in another shared library or may be
Does it also catch the other cases shown in the PR? Things like:
generic :: 2
generic :: 2 =
generic :: 1 = x
generic :: ?
etc.
OK if so. If not, maybe it’s worth adding them at the same time?
FX
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66039
* io.c (match_filepos): Check for incomplete/mangled REWIND, FLUSH,
BACKSPACE, and ENDFILE statements
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66039
*
On Fri, May 15, 2015 at 01:35:14PM -0700, H.J. Lu wrote:
On Fri, May 15, 2015 at 1:23 PM, Rich Felker dal...@libc.org wrote:
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
With relax branch in 32-bit, there are 2 cases:
1. PIC or PIE: We generate
set up EBX
relax call
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66044
* decl.c(gfc_match_entry): Change a gfc_internal_error() into
a gfc_error()
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66044
* gfortran.dg/entry_21.f90: New test.
OK
On Fri, May 15, 2015 at 1:23 PM, Rich Felker dal...@libc.org wrote:
On Fri, May 15, 2015 at 01:08:15PM -0700, H.J. Lu wrote:
With relax branch in 32-bit, there are 2 cases:
1. PIC or PIE: We generate
set up EBX
relax call foo@PLT
It is almost the same as we do now, except for the relax
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66040
* parse.c(verify_st_order): Replace a gfc_internal_error with your
generic gfc_error.
2015-05-XX Steven G. Kargl ka...@gcc.gnu.org
PR fortran/66040
* gfortran.dg/misplaced_statement.f90:
Testing revealed a few bugs in how I handled paths that don't exist.
The new __gnu_test::nonexistent_path() function is a bit hacky but
should be good enough for the testsuite.
I've also made filesystem::temp_directory_path() check the TMP,
TEMPDIR and TEMP environment variables, as suggested in
You might consider a comment in active_insn_p and
emit_pattern_{after,before}_setloc so that if someone fixes
active_insn_p, they'll know to fix emit_pattern_{after,before}_setloc.
FIXME doesn't capture this interaction at all ;-)
I beg to differ, it's the same file and anyone fiddling with
+/* Return true if DECL_ARGUMENT types are valid to be merged. */
Perhaps bettter as
Perform additional check needed to match types function parameters that are
used. Unlike for normal parameters it matters if type is TYPE_RESTRICT and we
make an assumption that REFERENCE_TYPE parameters are
On 15/05/15 19:37 +0100, Jonathan Wakely wrote:
I've also made filesystem::temp_directory_path() check the TMP,
TEMPDIR and TEMP environment variables, as suggested in
[fs.op.temp_dir_path] at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4099.html#fs.op.temp_dir_path
rather than my
On 05/15/2015 12:25 PM, Mikhail Maltsev wrote:
On 04/17/2015 05:01 AM, Mikhail Maltsev wrote:
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
Review: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02672.html
I fixed minor issues mentioned in
On Fri, May 15, 2015 at 9:09 AM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
On 15/05/15 16:05, H.J. Lu wrote:
On Mon, Apr 20, 2015 at 12:00 PM, Szabolcs Nagy szabolcs.n...@arm.com
wrote:
The posix_memalign declaration is incompatible with musl for C++,
because of the exception
Le 09/05/2015 15:12, Mikael Morin a écrit :
Le 01/05/2015 20:25, Paul Richard Thomas a écrit :
Dear All,
By the time I went to commit, something had changed and the patch
caused a regression. I presume that the version that I had of Andre's
patch was not the same as the one committed. I'll
Hi,
This patch fixes testcase thumb1-far-jump-2.c to confirm to newer compilation
defaults.
Is patch ok?
gcc/testsuite
2015-05-15 Alex Velenko alex.vele...@arm.com
* gcc.target/arm/thumb1-far-jump-2.c (r4): Added int in definition.
---
The change may be small enough that an assignment isn't needed.
We (ie, the gfortran developers) will need to check.
I think that’s small enough, compared to what we’ve accepted as such in the
past.
If not, a disclaimer by Russell putting his change in the public domain would
also be a
On 13/05/15 19:11, Martin Galvan wrote:
Here's the new patch. I downloaded the gcc sources from the SVN
repository, removed the extra semicolon from my version of the files
and re-generated the patch using svn diff, making sure the context
info had all the tabs from the original. I then
Hello,
we already have the more complicated: x ~(x y) - x ~y (which I am
reindenting by the way) and the simpler: (~x | y) x - x y, so I am
proposing this one for completeness. Regtested on ppc64le-redhat-linux.
2015-05-15 Marc Glisse marc.gli...@inria.fr
gcc/
* match.pd ((x
On Fri, May 15, 2015 at 1:58 PM, Ramana Radhakrishnan
ramana.radhakrish...@arm.com wrote:
Thanks for doing this now the patch looks much better and I can apply it !
Unfortunately there are still problems with it and I'm not sure about your
testing procedures.
mov ip, r0
- Ada builds !TYPE_ARTIFICIAL variant of TYPE_ARTIFICIAL type.
Eric, I can not really make sense of this. Is this expected?
If we have artificial type, how it can become not?
Yes, that's a bit unexpected and probably comes from the case where we build a
variant and it's not really
On May 15, 2015, at 11:07 AM, Alex Velenko alex.vele...@arm.com wrote:
This patch fixes testcase thumb1-far-jump-2.c to confirm to newer compilation
defaults.
Is patch ok?
Ok.
96 matches
Mail list logo
