Hi, Thomas!
Likewise, if you have any comments on my patch series for »initial
support for OpenACC data clauses«, I'd like to hear them.
Sure:
+ else if (!strcmp (present_or_copy, p))
+result = PRAGMA_OMP_CLAUSE_PRESENT_OR_COPY;
+ else if (!strcmp (present_or_copyin, p))
+
The cross references generated for formal verification in GNATprove mode
did not include constant objects. The needs have changed, and these should
be included now, with a specific type character 'c' to distinguish them
from references to non-constant objects.
Tested on x86_64-pc-linux-gnu,
When a dynamic run-time range check was generated to check the bounds
of an aggregate, the reason was wrong, resulting in an exception
message saying length check failed instead of range check failed.
The following test:
1. with Ada.Exceptions; use Ada.Exceptions;
2. with Ada.Text_IO;
Subprograms Assign and Copy in Containers.Ordered_Maps and
Containers.Hashed_Maps were not assigning or copying anything.
This patch fixes that. The test is to use these subprograms with a non
empty Source map and to check that the Target map is not empty.
Tested on x86_64-pc-linux-gnu, committed
The compiler now uses Replace instead of Rewrite, when the semantic
analyzer discovers that what looked like a selected component was
in factt a function call. This avoids a special case in ASIS for
handling an undecorated original node. This is an internal change
only with no functional effect
This patch implements the following rules concerning the refinement of external
abstract states:
* A state abstraction that is not specified as External shall not have
constituents which are External states.
* An External state abstraction shall have at least one constituent that is
External
For single entry protected objects, the entry was served (in case of pending
call and when compiled without checks) after a function call. This is useless,
and not coherent with code generated without -gnatp.
The following program displays 'Barrier called' only three times:
gnatmake -gnatp main
On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
Thanks for comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837
The patch with a test case is attached.
+/* { dg-options -Os -fno-omit-frame-pointer -mapcs -mabi=aapcs-linux -marm
-mfloat-abi=softfp
On Mon, Jan 27, 2014 at 06:17:38PM +0100, Richard Biener wrote:
Huh, so we have C for cross-builds and C++ for bootstraps.
No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
C++ compiler.
And even for stage{2,3} C can be optionally used by asking for it using a
Hans-Peter Nilsson h...@bitrange.com wrote:
On Mon, 27 Jan 2014, Mikael Morin wrote:
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are
cases
This fixes a tsan warning in shared_ptr by replacing the non-atomic
load with a call to _M_get_use_count() which does a relaxed atomic
load.
Tested x86_64-linux, committed to trunk. Will commit to 4.8 soon too.
commit a795f4e757d0f0ca11324a2c4f62cbe1bd876ec7
Author: Jonathan Wakely
On 16 January 2014 12:12, Alex Velenko alex.vele...@arm.com wrote:
This patch implements test cases for following NEON intrinsics:
vdup_lane_f32
vdup_lane_s[8,16]
vdup_lane_s[32,64]
vdup_n_[p,s,u][8,16]
vdup_n_[s,u][32,64]
vdupb_lane_[s,u]8
vduph_lane_[s,u]16
vdupd_lane_[f,s,u]64
Ok.
For future cleanup, It will be better to define a new helper function
is_profile_missing_p (cfun) -- which checks entry count for
instrumentation based FDO, and something else for autofdo.
David
On Fri, Jan 24, 2014 at 9:28 PM, Dehao Chen de...@google.com wrote:
This patch fixes
Committed to branch dmalcolm/jit:
gcc/jit/
* libgccjit.h (enum gcc_jit_binary_op): Remove
GCC_JIT_BINARY_OP_FLOATING_DIVIDE, which I accidentally added
as part of a880c0d9c642730550f39d328f29a1d9935cb07e.
---
gcc/jit/ChangeLog.jit | 6 ++
gcc/jit/libgccjit.h | 6
[ Yes, 16351, it's that old. ]
First, as is often the case, this warning is not going to catch
everything. Dead code elimination, unreachable code elimination, etc
can/will remove NULL pointer dereferences and if that happens we don't
get a warning. It also will not catch cases where a
Committed to dmalcolm/jit:
gcc/jit/
* internal-api (gcc::jit::recording::context::new_call): Verify
the argument count of the call against the parameter count of the
function, issuing an error if there's a mismatch.
* internal-api.h
Hi,
I will apply following patch soon, if there aren't any objection.
gcc/ChangeLog:
2014-01-27 Kai Tietz kti...@redhat.com
* config/i386/cygwin-stdint.h (INT64_TYPE): Make dependent on target
architecture instead of host.
(UINT64_TYPE, INT_LEAST64_TYPE, INT_FAST16_TYPE, INT_FAST32_TYPE,
Hi,
Thomas Schwinge wrote:
Regarding my comments, please keep in mind that I don't have a lot of
Fortran experience; neither as a user nor as an implementor
How about CC-ing fortran@gcc for Fortran patches - it increases the
chance that some Fortran maintainer will give some comment on them.
This is the best I've come up with to avoid dereferencing an invalid
pointer when calling vector::data() on an empty vector.
For C++03 we reurn the vector's pointer type, so can just return the
internal pointer, but for C++11 we need to convert that to a raw
pointer, which we do by
Hi,
The .code16gcc directive was added to binutils back in 1999:
---
'.code16gcc' provides experimental support for generating 16-bit code
from gcc, and differs from '.code16' in that 'call', 'ret', 'enter',
'leave', 'push', 'pop', 'pusha', 'popa', 'pushf', and 'popf'
instructions default to
This is the best I've come up with to avoid undefined behaviour when
calling vector::data() on an empty vector.
In C++03 mode we return vector::pointer, so can just return the
internal pointer. In C++11 mode we need to dereference it, but only
when it's valid.
Any suggestions for improvements
Hi,
On 27/gen/2014, at 20:38, Jonathan Wakely jwak...@redhat.com wrote:
This is the best I've come up with to avoid dereferencing an invalid
pointer when calling vector::data() on an empty vector.
For C++03 we reurn the vector's pointer type, so can just return the
internal pointer, but
On 27 January 2014 20:12, Marc Glisse wrote:
On Mon, 27 Jan 2014, Jonathan Wakely wrote:
This is the best I've come up with to avoid dereferencing an invalid
pointer when calling vector::data() on an empty vector.
For C++03 we reurn the vector's pointer type, so can just return the
internal
Hi Jakub et al.,
Did you get a chance to look at this _Cilk_for patch?
Thanks,
Balaji V. Iyer.
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Iyer, Balaji V
Sent: Friday, January 24, 2014 3:34 PM
To: Jakub
On Mon, Jan 27, 2014 at 08:41:14PM +, Iyer, Balaji V wrote:
Did you get a chance to look at this _Cilk_for patch?
IMHO it is not as much work as you are fearing, at most a few hours of work
to get it right, and well worth doing. So, please at least try it out
and if you get stuck
Just something I noticed while looking at one of our P1 regressions.
Installed as obvious.
Jeff
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 12ee84c..5f47e0b 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -1597,7 +1597,7 @@ inline_small_functions (void)
max_size =
On Mon, Jan 27, 2014 at 11:09 AM, Jeff Law l...@redhat.com wrote:
First, as is often the case, this warning is not going to catch everything.
Dead code elimination, unreachable code elimination, etc can/will remove
NULL pointer dereferences and if that happens we don't get a warning. It
also
Committed to dmalcolm/jit:
gcc/jit/
* internal-api.c (gcc::jit::playback::context::compile): Removal
of the code-creation callback (96b218c9a1d5f39fb649e02c0e77586b180e8516)
accidentally removed the implementation of
GCC_JIT_BOOL_OPTION_DUMP_GENERATED_CODE;
Le 27/01/2014 09:49, Janus Weil a écrit :
Did you bootstrap test the 4.7 backport?
Yes, works like a charm here.
I also see the build problem (configuring with
--enable-languages=c,fortran --disable-bootstrap).
I have committed the following as http://gcc.gnu.org/r207152
I made sure it
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
Sent: Monday, January 27, 2014 3:50 PM
To: Iyer, Balaji V
Cc: Jason Merrill; 'Jeff Law'; 'Aldy Hernandez'; 'gcc-patches@gcc.gnu.org';
'r...@redhat.com'
Subject:
Hi,
We fail here to create a typename_type on dependent using
declarations. In fact, facing a USING_DECLs on spotted places, either
we want to strip non-dependent USING_DECLs or we want to create a
typename_type. The attached patch simply propagates the change made to
fix c++/14258 through
On 01/27/14 14:02, Ian Lance Taylor wrote:
We utilize the analysis done for the erroneous-paths optimization. The
optimizations and warnings can be enabled/disabled independently. The
warnings are not enabled by -Wall.
I want to raise the usual caution about warnings that are based on
Indeed, default constructor and copy constructor shall not be noexcept
qualified.
IMO we should be able to make move constructor noexcept by using a
special allocator for the underlying unordered_map that would allow to
replace an entry with an other one without requiring a
On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote:
On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
* config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
for generic and recent AMD chips
Index: config/i386/x86-tune.def
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
have separate tunables for 32-bit and 64-bit code)?
I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
x86_64 and i686
On Mon, Jan 27, 2014 at 2:19 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote:
On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
* config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
for generic and
I am checking in this testsuite patch as an obvious fix after checking
with Richard Sandiford.
Steve Ellcey
sell...@mips.com
2014-01-27 Steve Ellcey sell...@mips.com
* gcc.target/mips/pr52125.c: Add -mno-optgp option.
diff --git a/gcc/testsuite/gcc.target/mips/pr52125.c
On Mon, Jan 27, 2014 at 10:15 AM, Uros Bizjak ubiz...@gmail.com wrote:
+2013-12-29 Allan Sandfeld Jensen sandf...@kde.org
Missing space in ChangeLog entry.
+ * config/i386/i386.c (get_builtin_code_for_version): Separate
+ Westmere from Nehalem, Ivy Bridge from Sandy Bridge and
+
On 27 January 2014 20:35, Jonathan Wakely wrote:
On 27 January 2014 20:12, Marc Glisse wrote:
On Mon, 27 Jan 2014, Jonathan Wakely wrote:
This is the best I've come up with to avoid dereferencing an invalid
pointer when calling vector::data() on an empty vector.
For C++03 we reurn the
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
have separate tunables for 32-bit and 64-bit code)?
I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
x86_64 and i686
Hi David,
I had to fix a couple of tests. I have attached the patch with the
fixed tests. The fixes are simple. The tests fail due to two reasons:
1) Tests like bmi2-pext32-1a.c fail because the vectorize loop is
unrolled and directive { scan-assembler-times bmi2_pext_si3 1 }
fails because
Ok.
David
On Mon, Jan 27, 2014 at 5:02 PM, Sriraman Tallam tmsri...@google.com wrote:
Hi David,
I had to fix a couple of tests. I have attached the patch with the
fixed tests. The fixes are simple. The tests fail due to two reasons:
1) Tests like bmi2-pext32-1a.c fail because the
On Mon, 27 Jan 2014, Bruce Korb wrote:
On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Sun, 8 Dec 2013, Bruce Korb wrote:
On 12/08/13 13:06, Gerald Pfeifer wrote:
Lovely. Thank you very much!
(Looks like nobody replied to this and it isn't committed.)
On Mon, 27 Jan 2014, Richard Biener wrote:
Huh, so we have C for cross-builds and C++ for bootstraps.
No, we use a C host compiler in both cases. Only stages 2 and 3 build with a
C++ compiler.
Tomatos potatoes! As fortran isn't built until then, it'll be
built as C for cross-builds and C++
On 28 January 2014 01:07, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
Thanks for comments.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837
The patch with a test case is attached.
+/* { dg-options
maybe_constant_value doesn't deal well with void expressions, and we
shouldn't expect it to.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 0d1fe0783012b1e43b630f526f90e3a9cd6be434
Author: Jason Merrill ja...@redhat.com
Date: Mon Jan 27 10:01:30 2014 -0500
PR c++/59097
This testcase uses the name of a non-static member function as a
truthvalue, which is ill-formed and confuses
c_common_truthvalue_conversion. Avoid the ICE by explicitly comparing
it to nullptr, which will get the invalid use of member function error
we want.
Tested x86_64-pc-linux-gnu,
stabilize_expr can't deal with a volatile vector variable; it tries to
stabilize a glvalue with side-effects by storing its address in a
temporary and then dereferencing that, but if the type of the reference
is volatile then that doesn't actually help at all.
In this case, there's a simple
The first patch implements core DR 1288, which adjusts the
list-initialization rules so that an initializer-list containing a
single element of the same type as the target is treated as the
initializer by itself.
The second patch expands the excess braces diagnostic to cover reference
Missing initializers in an aggregate initialization mean that the
members with no explicit initializer are themselves initialized from {},
which more or less means value-initialization. But that's ill-formed
for a reference, so we don't need to recurse forever.
Tested x86_64-pc-linux-gnu,
We had been representing a template non-type parameter as the plain
TEMPLATE_PARM_INDEX in the CLASSTYPE_TI_ARGS of the template, even for a
reference. But when we substitute into that, the reference
automatically decays, so it gets wrapped in an INDIRECT_REF that then
doesn't compare the
We were tsubsting trait arguments wrong: a type gets tsubst, not
tsubst_copy.
Tested x86_64-pc-linux-gnu, applying to trunk, 4.7, 4.8.
commit bf602b5f571b47d41ee271fea8d7c6dfa11433ec
Author: Jason Merrill ja...@redhat.com
Date: Mon Jan 27 13:29:01 2014 -0500
PR c++/58504
* pt.c
Since duplicate_decls throws away the new decl before returning 1, we
need to make sure that we don't have anything pointing to it. In a
TYPE_DECL, the type points back to the decl via TYPE_NAME, so we always
need to choose the type from the olddecl.
Tested x86_64-pc-linux-gnu, applying to
In the original testcase we were failing to prefer the copy assignment
(which can take the result of the conversion operator directly) to a
copy constructor followed by move assignment. The best way to fix this
was to make the latter ill-formed, as it is supposed to be under DR
1138: just as
On 01/27/2014 04:28 PM, Fabien Chêne wrote:
+ if (DECL_DEPENDENT_P (decl) USING_DECL_TYPENAME_P (decl))
+{
+ /* We have found a type introduced by a using
+declaration at class scope that refers to a dependent
+type.
+
+using typename :: [opt]
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +0400
From: Yury Gribov y.gri...@samsung.com
To: GCC Patches gcc-patches@gcc.gnu.org
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions
On Tue, Jan 28, 2014 at 12:56:28AM +0100, Jan Hubicka wrote:
On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
have separate tunables for 32-bit and 64-bit code)?
I admit I haven't performed trunk
On Fri, Jan 24, 2014 at 10:34:10AM -0700, Jeff Law wrote:
Of course, then your question becomes, why exclude CPPFLAGS? (And if
CPPFLAGS needs to be excluded here, then I should have just used
CPPFLAGS=-DGENERATOR_FILE for the recursive configure call..) I'm not
sure now, I'll have to do some
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and fail (by unluck) on newer ones.
Thus, I will
Did you bootstrap test the 4.7 backport?
Yes, works like a charm here.
I also see the build problem (configuring with
--enable-languages=c,fortran --disable-bootstrap).
Looks like you committed C++ code there, in module.c:
...
3867 static void
3868 skip_list (int nest_level = 0)
Hello!
+2013-12-29 Allan Sandfeld Jensen sandf...@kde.org
Missing space in ChangeLog entry.
+ * config/i386/i386.c (get_builtin_code_for_version): Separate
+ Westmere from Nehalem, Ivy Bridge from Sandy Bridge and
+ Broadwell from Haswell.
--- a/gcc/config/i386/i386.c
+++
Hi,
I was playing about with an old patch and found that
the implementation of create_gimple_tmp was removed by
this patch:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01694.html
But that its declaration was left in gimple-builder.h.
A quick grep shows that this was the only remaining mention
Hi,
I've tripped myself over with these three options too many times,
actually, their behaviour is very simple.
This patch clarifies the language used to describe the options, and
puts them in a logical order. I'm happy to reword again if this
is still not clear.
OK?
Thanks,
James
---
gcc/
Hello,
On 23 Jan 14:22, Uros Bizjak wrote:
(define_expand avx512pf_scatterpfmodedf
[(unspec
[(match_operand:avx512fmaskmode 0 register_or_constm1_operand)
(mem:DF
(match_par_dup 5
[(match_operand 2 vsib_address_operand)
Hi all,
This patch is a amendment and rebase of a previous patch:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02365.html
No new __ARM_ARCH_7VE__ is defined. Instead, __ARM_ARCH_7A__ is defined
with additional extensions (e.g. __ARM_ARCH_EXT_IDIV__) when arch is set
to armv7ve.
This
On Mon, Jan 27, 2014 at 11:09 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
(define_expand avx512pf_scatterpfmodedf
[(unspec
[(match_operand:avx512fmaskmode 0 register_or_constm1_operand)
(mem:DF
(match_par_dup 5
[(match_operand 2 vsib_address_operand)
Hi, Thomas!
Thank you for your review.
I agree with all your notes. I'm going to reuse your implementation of
data clauses, add minimal GIMPLE infrastructure, and then resend patches.
--
Ilmir.
On 01/22/2014 11:53 AM, Andrey Turetskiy wrote:
We have some testcases, but they require XeonPhi hardware and a
working libgomp plugin. Our current version of the plugin depends on
some libraries, that are not open-sourced yet, so currently we can’t
share it.
However, you could examine what
DR 475 clarified that uncaught_exception shouldn't return true until we
are done creating the exception object and enter the unwinder:
http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#475
Fixed by moving the adjustment of the uncaughtExceptions count from the
allocation to the throw.
On Mon, 27 Jan 2014, Mikael Morin wrote:
Le 27/01/2014 02:56, Hans-Peter Nilsson a écrit :
On Sun, 26 Jan 2014, Mikael Morin wrote:
Le 18/01/2014 21:17, Mikael Morin a écrit :
Well, I guess that due to the touchy nature of the bug, there are cases
that work by luck on old versions and
Hi!
On Mon, 27 Jan 2014 17:12:04 +0400, Ilmir Usmanov i.usma...@samsung.com wrote:
Thank you for your review.
You're welcome.
Hopefully the merge from trunk into gomp-4_0-branch that I just committed
doesn't cause you additional work -- but as I told in my other email,
there were no conflicts
Hi!
On Fri, 24 Jan 2014 18:24:56 +0100, I wrote:
Jakub suggested (and I agree) the first thing to be done on
gomp-4_0-branch is a merge from trunk, which he hasn't done for a long
time. I have prepared this yesterday morning, and have it ready for
commit, but...
In r207132, I have now
On 21/01/14 10:52, James Greenhalgh wrote:
+ names passed from the commend line will be in ARGV, we want
s/commend/command.
Otherwise OK if no regressions.
Thanks,
Ramana
Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59915
The patch was successfully bootstrapped and tested on x86/x86-64 and
ppc64 (with -mlra).
Committed as rev. 207007.
2014-01-23 Vladimir Makarov vmaka...@redhat.com
PR
On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Sun, 8 Dec 2013, Bruce Korb wrote:
On 12/08/13 13:06, Gerald Pfeifer wrote:
Lovely. Thank you very much!
(Looks like nobody replied to this and it isn't committed.)
No, flex isn't required to build GCC as a
This implements the rule in SPARK RM 6.1.6 which specifies that only
functions may have convention Ghost explicitly specified. This test
program shows error messages not previously given (compiled with
-gnatc -gnatj60)
1. package Ghost_Illegal_1
2. with SPARK_Mode
3. is
4.
Hi,
as explained by Richard in the audit trail of the duplicate c++/54808,
the problem here is that the type checking code notices that we are
initializing the unnamed bit-field with a bare integer_zero_node.
Calling here too cp_convert_and_check works.
Tested x86_64-linux (probably not
As discussed in the PR, when a port does not have partial integer or
vector integer modes, expmed_mode_index will not be called with those
modes. However, our VRP analysis isn't aware of those constraints and
has to assume the MODE_PARTIAL_INT and MODE_VECTOR_INT cases could be used.
That
78 matches
Mail list logo
