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
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 perf
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +0400
From: Yury Gribov
To: GCC Patches
Hi,
This patch fixes the problem reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59600 : functions with
mismatching no_sanitize_address attribut
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] nested-na
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 y
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 tr
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
Date: Mon Jan 27 13:29:01 2014 -0500
PR c++/58504
* pt.c (tsubst_copy_and_bui
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 same
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, app
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
initial
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 so
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, ap
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
Date: Mon Jan 27 10:01:30 2014 -0500
PR c++/59097
* decl.c (comp
On 28 January 2014 01:07, Ramana Radhakrishnan
wrote:
> On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
> 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 -map
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
On Mon, 27 Jan 2014, Bruce Korb wrote:
> On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson 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.)
>
> >
Ok.
David
On Mon, Jan 27, 2014 at 5:02 PM, Sriraman Tallam 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 vectorize loop is
>
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
> 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
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
On Mon, Jan 27, 2014 at 10:15 AM, Uros Bizjak wrote:
> +2013-12-29 Allan Sandfeld Jensen
>
> 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/g
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
* gcc.target/mips/pr52125.c: Add -mno-optgp option.
diff --git a/gcc/testsuite/gcc.target/mips/pr52125.c
b/gcc/testsuite/gcc.target
On Mon, Jan 27, 2014 at 2:19 PM, Jakub Jelinek 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 recent AMD c
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 boot
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
> > ===
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
deallocate/allocat
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
optimiz
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 strip_u
> -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'
> S
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
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; reinstat
On Mon, Jan 27, 2014 at 11:09 AM, Jeff Law 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 will not c
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 = compute_
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 wit
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 J
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
Hi,
> On 27/gen/2014, at 20:38, 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 pointer, but for C++11 we
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 pointer, but for C++11 we need to convert that t
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 be
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 3
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 dereferencing,
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.
Hi,
I will apply following patch soon, if there aren't any objection.
gcc/ChangeLog:
2014-01-27 Kai Tietz
* 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,
INT_FAST64_TYPE, UINT
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 (gcc::jit::recording::function::
[ 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 NULL
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
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
Date: Mon
Hans-Peter Nilsson 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
>
On 16 January 2014 12:12, Alex Velenko 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
> vdups_lane_[f,s
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 wrote:
> This patch fixes performance regression for
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
On Thu, Jan 16, 2014 at 5:44 AM, Zhenqiang Chen
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 -g " } */
Can y
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
./
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 stat
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 (ba
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
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; us
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, commit
If we have a situation similar to
My_Label;
loop
...
end loop;
where we have a semicolon instead of a colon after My_Label, the
compiler used to simply complain that it expected end; instead
of end loop; With this change it now flags the bad semicolon
as shown in by this test progra
The latest SPARK spec removes AUTO as a possibility for the
SPARK_Mode pragma. The message for inconsistent SPARK modes
is also simplified, since the only case to worry about now
is trying to turn it ON when it is OFF. The following test
is compiled with -gnatj60:
1. pragma SPARK_Mode (Auto)
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))
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 i
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!
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 co
Hi!
On Mon, 27 Jan 2014 17:12:04 +0400, Ilmir Usmanov 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 visible, so I hope th
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 wort
On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson 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 hard and
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
PR regression/59915
* lr
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 ver
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 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 thes
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 Mon, Jan 27, 2014 at 11:09 AM, Kirill Yukhin wrote:
>> > (define_expand "avx512pf_scatterpfdf"
>> > [(unspec
>> > [(match_operand: 0 "register_or_constm1_operand")
>> > (mem:DF
>> >(match_par_dup 5
>> > [(match_operand 2 "vsib_address_operand")
>> > (mat
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 patc
Hello,
On 23 Jan 14:22, Uros Bizjak wrote:
> > (define_expand "avx512pf_scatterpfdf"
> > [(unspec
> > [(match_operand: 0 "register_or_constm1_operand")
> > (mem:DF
> >(match_par_dup 5
> > [(match_operand 2 "vsib_address_operand")
> > (match_operand:VI4_256_8_
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/
2
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
Hello!
+2013-12-29 Allan Sandfeld Jensen
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
+++ b/gcc/config/i386/i386.c
@@ -31298,1
>> 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 ne
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,
81 matches
Mail list logo
