Hi all,
I have just committed as obvious a simple one-line fix for a procedure
pointer problem (after a successful regtest):
http://gcc.gnu.org/viewcvs?view=revision&revision=186465
Cheers,
Janus
Hi Tobias,
> That's a GCC 4.6-4.8 regression. Pointer intents apply to the association
> status and not to the value. Thus, assigning to an intent(in) pointer is
> fine. The problem was that the LHS is no pointer due to the array access
> ("dt%ptr(1) =") thus, the check got triggered.
>
> Build a
ADDRESS has long had no meaning in .md files. This patch removes
the associated gen* support.
Borders on the obvious, but just to be sure: bootstrapped & regression
tested on x86_64-linux-gnu. OK to install?
Richard
gcc/
* genemit.c (gen_exp): Remove ADDRESS handling.
* genout
The comment in alias.c says:
The contents of an ADDRESS is not normally used, the mode of the
ADDRESS determines whether the ADDRESS is a function argument or some
other special value. Pointer equality, not rtx_equal_p, determines whether
two ADDRESS expressions refer to the same base
On Wed, Apr 11, 2012 at 5:54 AM, Tobias Burnus wrote:
> Dear all,
>
> my recent patch for setting PRIVATE module variables and procedures to
> TREE_PUBLIC()=0 had a flaw: I completely forgot about generic interfaces.
> Even if the specific name is PRIVATE, the specific function is still
> callable
C++11 inherits from C99, so we shouldn't complain about using %ld in
that mode.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 4433edb6e099fbb6251c1ab76266108c45582ebc
Author: Jason Merrill
Date: Fri Apr 13 16:03:59 2012 -0400
PR c++/52818
* c-format.c (CPLUSPLUS_STD_VER): C
We were incorrectly treating nullptr_t as a substitutable type.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d13e197a238f2cbcca283e8d2332ea75af00b297
Author: Jason Merrill
Date: Fri Apr 13 17:34:31 2012 -0400
PR c++/52706
* mangle.c (write_type): nullptr_t is a builtin type
> The testcase failed with ...
It is fixed by the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/public_private_module_3.f90
2012-04-15 11:18:00.0 +0200
+++ gcc/testsuite/gfortran.dg/public_private_module_3.f90 2012-04-15
19:09:10.0 +0200
@@ -58,3 +58,4 @@ con
H.J. Lu wrote:
The testcase failed with
/export/gnu/import/git/gcc-test-ia32/src-trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90:11.4:^M
^M
use m^M
1^M
Fatal Error: Can't open module file 'm.mod' for reading at (1): No
such file or directory^M
compiler exited with status 1
Ups
This patch tries to store the shortest form of a path to a system
file, either the original given or the canonical form returned by
realpath. User files are left untouched. This converts this:
t.cc: In function 'void f()':
t.cc:2:23: error: no matching function for call to 'sort(int)'
t.cc:2:23: n
Hi all,
here is a small patch for an OOP problem. For discussion see the PR.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
Cheers,
Janus
2012-04-15 Janus Weil
PR fortran/52968
* class.c (gfc_build_class_symbol): Make sure the 'f2k_derived'
namespace is prese
Hi,
tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
/
2012-04-15 Paolo Carlini
PR libstdc++/52702
* include/std/type_traits (is_trivially_destructible): Add.
(has_trivial_destructor): Remove.
* testsuite/util/testsuite_common_types.
On Wed, 6 Jul 2011, Paulo J. Matos wrote:
> On 06/07/11 16:08, Richard Guenther wrote:
>> See cgraph.c:clone_function_name, it uses the NO_DOT_IN_LABEL and
>> NO_DOLLAR_IN_LABEL target macros and ASM_FORMAT_PRIVATE_NAME.
> Why are NO_DOLLAR_IN LABEL and NO_DOT_IN_LABEL not listed in the "Output
>
On Wed, 11 Apr 2012, Andrew Haley wrote:
> I wonder what we're supposed to do about warnings that only trigger
> on 32-bit systems. Just wait for reports, or do we really have to
> boostrap with both?
I think it's okay not to bootstrap on 32-bit systems in addition
to your regular testers. I boo
.. hi all, hi Gaby,
a couple of days ago, Manuel suggested in the audit trail of the main
"caret diagnostics" PR, that now that we actually have got a form of it,
the kind of change I proposed to resolve PR 49152 may make much more
sense. In any case, my original patch still regtests fine toda
On Sun, Apr 15, 2012 at 8:54 PM, Paolo Carlini wrote:
> .. hi all, hi Gaby,
>
> a couple of days ago, Manuel suggested in the audit trail of the main "caret
> diagnostics" PR, that now that we actually have got a form of it, the kind
> of change I proposed to resolve PR 49152 may make much more se
In coerce_template_parms, inner_args is the set of args we're actually
working on, whereas "args" also includes any args of the enclosing
scope. Treating the latter as the former leads to problems when there
actually are multiple levels.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
For some reason, coerce_template_parameter_pack wasn't checking for and
diagnosing error_mark_node like coerce_template_parms does. Fixed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 601d1dd536710d65054d6a24bbae2bbf7f1e466b
Author: Jason Merrill
Date: Sun Apr 15 20:58:07 2012 -0400
On Sun, 15 Apr 2012, Gabriel Dos Reis wrote:
a hybrid approach; I would suggest something like this: (a) if caret
is in effect, then print
the caret pointing to the symbol in question; otherwise (b) print the
symbol and the type (as suggested by Marc).
I may have forgotten the details, but loo
Janus Weil wrote:
> here is a small patch for an OOP problem. For discussion see the PR.
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
OK and thanks for the patch. Note, however, that since Bernhard's patch*,
using cleanup-modules is usually not needed.
* http://gcc.gnu.org/ml/fortran/20
20 matches
Mail list logo
