Re: copyright dates in binutils (and includes/)
On Mon, Mar 03, 2014 at 02:14:51PM +1030, Alan Modra wrote:
> I'll post update-copyright.py separately.
--- /src/gcc-current/contrib/update-copyright.py2013-02-07
12:55:28.272161270 +1030
+++ ./update-copyright.py 2014-03-03 13:44:35.650293322 +1030
@@ -74,6 +74,8 @@
'COPYING.LIB',
'COPYING3',
'COPYING3.LIB',
+'COPYING.LIBGLOSS',
+'COPYING.NEWLIB',
'LICENSE',
'fdl.texi',
'gpl_v3.texi',
@@ -110,6 +112,18 @@
'texinfo.tex',
])
+self.skip_extensions |= set ([
+# Maintained by the translation project.
+'.po',
+
+# Automatically-generated.
+'.pot',
+])
+
+self.skip_dirs |= set ([
+'autom4te.cache',
+])
+
def get_line_filter (self, dir, filename):
if filename.startswith ('ChangeLog'):
@@ -201,7 +215,7 @@
# A regexp for notices that might have slipped by. Just matching
# 'copyright' is too noisy, and 'copyright.*[0-9]' falls foul of
# HTML header markers, so check for 'copyright' and two digits.
-self.other_copyright_re = re.compile ('copyright.*[0-9][0-9]',
+self.other_copyright_re = re.compile
('(^|[^\._])copyright[^=]*[0-9][0-9]',
re.IGNORECASE)
self.comment_re = re.compile('#+|[*]+|;+|%+|//+|@c |dnl ')
self.holders = { '@copying': '@copying' }
@@ -530,144 +544,15 @@
return True
return GenericFilter.skip_file (self, dir, filename)
-class GCCFilter (GenericFilter):
+class LdFilter (GenericFilter):
def __init__ (self):
GenericFilter.__init__ (self)
-self.skip_files |= set ([
-# Not part of GCC
-'math-68881.h',
-])
-
-self.skip_dirs |= set ([
-# Better not create a merge nightmare for the GNAT folks.
-'ada',
-
-# Handled separately.
-'testsuite',
-])
-
self.skip_extensions |= set ([
-# Maintained by the translation project.
-'.po',
-
-# Automatically-generated.
-'.pot',
-])
-
-self.fossilised_files |= set ([
-# Old news won't be updated.
-'ONEWS',
-])
-
-class TestsuiteFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_extensions |= set ([
-# Don't change the tests, which could be woend by anyone.
-'.c',
-'.C',
-'.cc',
-'.h',
-'.hs',
-'.f',
-'.f90',
-'.go',
-'.inc',
-'.java',
+# ld testsuite output match files.
+'.ro',
])
-def skip_file (self, dir, filename):
-# g++.niklas/README contains historical copyright information
-# and isn't updated.
-if filename == 'README' and os.path.basename (dir) == 'g++.niklas':
-return True
-return GenericFilter.skip_file (self, dir, filename)
-
-class LibCppFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_extensions |= set ([
-# Maintained by the translation project.
-'.po',
-
-# Automatically-generated.
-'.pot',
-])
-
-class LibGCCFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_dirs |= set ([
-# Imported from GLIBC.
-'soft-fp',
-])
-
-class LibJavaFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_dirs |= set ([
-# Handled separately.
-'testsuite',
-
-# Not really part of the library
-'contrib',
-
-# Imported from upstream
-'classpath',
-'libltdl',
-])
-
-def get_line_filter (self, dir, filename):
-if filename == 'NameDecoder.h':
-return re.compile ('.*NAME_COPYRIGHT')
-if filename == 'ICC_Profile.h':
-return re.compile ('.*icSigCopyrightTag')
-return GenericFilter.get_line_filter (self, dir, filename)
-
-class LibMudflapFilter (GenericFilter):
-def __init__ (self):
-GenericFilter.__init__ (self)
-
-self.skip_dirs |= set ([
-# Handled separately.
-'testsuite',
-])
-
-class LibStdCxxFilter (GenericFilter):
-def __init__ (self):
-Gen
Is LLVM really pulling ahead of gcc?
Hi, I saw http://www.phoronix.com/scan.php?page=article&item=llvm34_gcc49_compilers&num=1 And LLVM/clang beaten gcc in serval tests.But I ran that tests,e.g.SciMark,it didn't appear to be like this on my i7 machine.Was that article written by Apple? -- Regards lin zuojian
Re: [C++ patch] for C++/52369
On 03/02/2014 04:55 PM, Fabien Chêne wrote: Hmm, sorry to iterate on this rather trivial issue, but it seems difficult to mimic the c++98 diagnostic. Actually, the c++98 diagnosic raises an error at the point of use, mention the class implied, and add a note at the ref/const member uninitialized. Doing that in c++11 is not currently possible because input_location is sabotaged early in maybe_explain_implicit_delete (unless there is some magic incantation in the diagnostic machinery I am not aware of), and the point of use is lost. Yes, in C++11 the point of use is the source location of the constructor, which is going to be different from where the constructor is called. I just meant use the same wording. I am inclined to think that if we reached one the two functions mentioned, an error had already been raised and we are trying to explain why. Thus, it seems to me that only notes should be emitted. Here we are actually explaining why the default constructor is deleted, which is a kind of subnote. I can see that argument, but it's deleted because if it were defined, that definition would be ill-formed, and we're giving the errors that we would see in that case. Jason
Re: [patch, libgfortran] PR60148 Strings in NAMELIST do not honor DELIM= in open statement
On Sun, Mar 02, 2014 at 02:49:20PM -0800, Jerry DeLisle wrote: > > For this patch I chose to stay consistent with what we currently do. I can > change it to standard conforming. Anyone else have any comments on this? > I would prefer standard conformance, but I'm not the one doing the work (so it's your call). -- Steve
Re: [patch, libgfortran] PR60148 Strings in NAMELIST do not honor DELIM= in open statement
On 03/02/2014 12:50 PM, Tobias Burnus wrote: --- snip --- > > gfortran seems to be special as it defaults to printing the " (quote) > delimiter > by default while other compilers seem to default to "none". > Looking back at the draft F95 standard that I have I am amazed. As you stated in your note the standard calls for no quotes on namelist write if no DELIM= has been specified. And yet, right after that, there is a note stating that the result of such a namelist write may not be correctly readable. That was a few years ago when we discussed this issue. IIRC the consensus was to make what is written as readable for default behavior. I think what we do now is the reasonable approach For this patch I chose to stay consistent with what we currently do. I can change it to standard conforming. Anyone else have any comments on this? Regards, Jerry
PR ipa/60150
Hi,
this patch fixes simple ordering issue in function_and_variable_visibility.
Bootstrapped/regtested x86_64-linux, comitted.
PR ipa/60150
* ipa.c (function_and_variable_visibility): When dissolving comdat
group, also set all symbols to local.
* g++.dg/lto/pr60150.H: New testcase.
* g++.dg/lto/pr60150_0.C: New testcase.
* g++.dg/lto/pr60150_1.C: New testcase.
Index: ipa.c
===
--- ipa.c (revision 208247)
+++ ipa.c (working copy)
@@ -970,15 +970,32 @@ function_and_variable_visibility (bool w
gcc_assert (whole_program || in_lto_p
|| !TREE_PUBLIC (node->decl));
node->unique_name = ((node->resolution == LDPR_PREVAILING_DEF_IRONLY
- || node->resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
- && TREE_PUBLIC (node->decl));
+ || node->unique_name
+ || node->resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
+ && TREE_PUBLIC (node->decl));
node->resolution = LDPR_PREVAILING_DEF_IRONLY;
if (node->same_comdat_group && TREE_PUBLIC (node->decl))
- /* cgraph_externally_visible_p has already checked all other nodes
- in the group and they will all be made local. We need to
- dissolve the group at once so that the predicate does not
- segfault though. */
- symtab_dissolve_same_comdat_group_list (node);
+ {
+ symtab_node *next = node;
+
+ /* Set all members of comdat group local. */
+ if (node->same_comdat_group)
+ for (next = node->same_comdat_group;
+next != node;
+next = next->same_comdat_group)
+ {
+ symtab_make_decl_local (next->decl);
+ next->unique_name = ((next->resolution ==
LDPR_PREVAILING_DEF_IRONLY
+ || next->unique_name
+ || next->resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP)
+ && TREE_PUBLIC (next->decl));
+ }
+ /* cgraph_externally_visible_p has already checked all other nodes
+in the group and they will all be made local. We need to
+dissolve the group at once so that the predicate does not
+segfault though. */
+ symtab_dissolve_same_comdat_group_list (node);
+ }
symtab_make_decl_local (node->decl);
}
Index: testsuite/g++.dg/lto/pr60150.H
===
--- testsuite/g++.dg/lto/pr60150.H (revision 0)
+++ testsuite/g++.dg/lto/pr60150.H (revision 0)
@@ -0,0 +1,20 @@
+struct Base {
+ virtual void f() = 0;
+};
+
+struct X : public Base { };
+struct Y : public Base { };
+struct Z : public Base { };
+struct T : public Base { };
+
+struct S : public X, public Y, public Z
+#ifdef XXX
+, public T
+#endif
+{
+ void f()
+#ifdef XXX
+ { }
+#endif
+ ;
+};
Index: testsuite/g++.dg/lto/pr60150_0.C
===
--- testsuite/g++.dg/lto/pr60150_0.C(revision 0)
+++ testsuite/g++.dg/lto/pr60150_0.C(revision 0)
@@ -0,0 +1,8 @@
+// { dg-lto-do run }
+#include "pr60150.H"
+
+int main()
+{
+ S s;
+ return 0;
+}
Index: testsuite/g++.dg/lto/pr60150_1.C
===
--- testsuite/g++.dg/lto/pr60150_1.C(revision 0)
+++ testsuite/g++.dg/lto/pr60150_1.C(revision 0)
@@ -0,0 +1,4 @@
+// { dg-options "-fno-lto" }
+#include "pr60150.H"
+
+void S::f() { }
Re: [C++ patch] for C++/52369
2014-02-28 22:52 GMT+01:00 Fabien Chêne :
> 2014-02-28 22:27 GMT+01:00 Jason Merrill :
>> Let's change the C++11 diagnostic to match the C++98 diagnostic. So,
>> "uninitialized const member in %q#T" + "%qD should be initialized".
>
> OK.
Hmm, sorry to iterate on this rather trivial issue, but it seems
difficult to mimic the c++98 diagnostic. Actually, the c++98 diagnosic
raises an error at the point of use, mention the class implied, and
add a note at the ref/const member uninitialized. Doing that in c++11
is not currently possible because input_location is sabotaged early in
maybe_explain_implicit_delete (unless there is some magic incantation
in the diagnostic machinery I am not aware of), and the point of use
is lost.
Reading the comment of synthesized_method_walk, which is the only
caller of walk_field_subobs:
"If diag is true, we're either being called from
maybe_explain_implicit_delete to give errors, or if constexpr_p is
non-null, from explain_invalid_constexpr_fn."
I am inclined to think that if we reached one the two functions
mentioned, an error had already been raised and we are trying to
explain why. Thus, it seems to me that only notes should be emitted.
Here we are actually explaining why the default constructor is
deleted, which is a kind of subnote. Hence, I would say that emitting
an error at this point would be seen as a different issue by the user.
All in all, in my opinion, just emitting a note would be appropriate
given the context.
If agreed, the comment above should be adjusted, and says "... called
from maybe_explain_implicit_delete to ***emit additional notes***...",
and the errors raised in callees shall be turned into notes.
Unfortunalely, the comment does not match the code and
synthesized_method_walk is called with diag=true in another context:
/* Warn about calling a non-trivial move assignment in a virtual base. */
if (kind == sfk_move_assignment && !deleted_p && !trivial_p
&& CLASSTYPE_VBASECLASSES (type))
{
location_t loc = input_location;
input_location = DECL_SOURCE_LOCATION (fn);
synthesized_method_walk (type, kind, const_p,
NULL, NULL, NULL, NULL, true,
NULL_TREE, NULL_TREE);
input_location = loc;
}
... Which breaks the logic above, even if it probably intends to reach
this warning later:
warning (OPT_Wvirtual_move_assign,
"defaulted move assignment for %qT calls a non-trivial "
"move assignment operator for virtual base %qT",
ctype, basetype);
This can of revamping I suggest can wait for next stage 1, obviously...
What do you think ?
--
Fabien
PR ipa/60306 (detect_type_change bug)
Hi, testcase in this PR shows interesting bug in detect_type_change. The function basically looks up in the alises walk and tries to find explicit stored to vtable. If none are found the type is assumed to be fully built. If some are found and they are all agree, the type is assumed to be in the construction stage or fully built based on the vtable. The code used to give up on first aliasing occurence of gimple_clobber. It seemed obvious change to not consider clobbers to be a statements changing dynamic type of memory location. http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01331.html This change however triggers wrong code in the testcase attached. Here we have a loop with offline construction but inline destructor. As the code walks the aliasing statements it skips the construction and assumes that the destructoin is what always happens. The code makes interesting assumptions about how construction/destruction code is organized and basically have a thinko confusing the fact htat we found known vtable initialization at *one* path with the fact that the vtable initialization was found at all paths. The assumptions are described by Martin as follows: /* Return true if STMT can modify a virtual method table pointer. This function makes special assumptions about both constructors and destructors which are all the functions that are allowed to alter the VMT pointers. It assumes that destructors begin with assignment into all VMT pointers and that constructors essentially look in the following way: 1) The very first thing they do is that they call constructors of ancestor sub-objects that have them. 2) Then VMT pointers of this and all its ancestors is set to new values corresponding to the type corresponding to the constructor. 3) Only afterwards, other stuff such as constructor of member sub-objects and the code written by the user is run. Only this may include calling virtual functions, directly or indirectly. There is no way to call a constructor of an ancestor sub-object in any other way. This means that we do not have to care whether constructors get the correct type information because they will always change it (in fact, if we define the type to be given by the VMT pointer, it is undefined). The most important fact to derive from the above is that if, for some statement in the section 3, we try to detect whether the dynamic type has changed, we can safely ignore all calls as we examine the function body backwards until we reach statements in section 2 because these calls cannot be ancestor constructors or destructors (if the input is not bogus) and so do not change the dynamic type (this holds true only for automatically allocated objects but at the moment we devirtualize only these). We then must detect that statements in section 2 change the dynamic type and can try to derive the new type. That is enough and we can stop, we will never see the calls into constructors of sub-objects in this code. Therefore we can safely ignore all call statements that we traverse. */ I think his analysis is correct, but we need an alias walker to let us know if we found something along all paths or some paths. The code can also be strenghtened to actually understand calls that define type. I attached patch to the PR that works harder and discovers constructions/destructions explicitly and makes us to devirtualize quite a bit more. For 4.9 we however need a simple fix. I tried to simply give up on calls but that basically disables all the ipa-cp devirtualization and breaks half of devirt testsuite. On Firefox it makes us to devirtualize 90% less out of calls that we devirtualize by ipa-cp (that is about 600). I tired to make it weaker as Martin originally suggested, by considering only calls that may change the value. Those are only ctors/dtors and aggregate returns. This makes us still optimize 30% less and break good part of testsuite. Obviously driving IPA propagation by analysis that turns and runs away in a panic on first occurence of a function call is not going to work well. So instead I decided to simply revert the change to ignore clobbers. This restores the shape of function it was in for several releases, so it should be safe. I believe it can be shown safe on two premises. We always analyze only static/automatic vars (not heap storage). We thus know that all uses are dominated by construction and if you miss it, there is always clobber just before the destruction. I have couple plans for 4.10. First I want to extend the alias walker to let me know if top of function was reached, so this code can be also use for heap allocated storage. I however also think we want to make the changes explicit all the way from FE to IPA passes instead of doing this rather fragile pattern matching. I will send RFC proposal on this. Bootstrapped/regtested and comitted. Honza PR ipa/60306 Revert:
[v3] Slightly improve operator new
Hello,
inlining operator new (with LTO or otherwise), I noticed that it has a
complicated implementation, which makes it hard to use this inlined code
for optimizations. This patch does two things:
1) there are 2 calls to malloc, I am turning them into just one. At -Os,
it does not change the generated code (RTL optimizers manage to merge the
calls to malloc). At other levels (-O2, -O3, and especially with -g) it
gives a smaller object file. And with just one malloc, some optimizations
become much easier (see my recent calloc patch for instance).
2) malloc is predicted to return null 19 times out of 20 because of the
loop (that didn't change with the patch), so I am adding __builtin_expect
to let gcc optimize the fast path.
Further discussion:
a) I didn't add __builtin_expect for the test (sz == 0), it didn't change
the generated code in my limited test. I was wondering if this test is
necessary (new doesn't seem to ever call operator new(0)) or could be
moved to operator new[] (new type[0] does call operator new[](0)), but
since one can call operator new directly, it has to be protected indeed,
so let's forget this point ;-)
(too bad malloc is replacable, so we can't use the fact that glibc already
does the right thing)
b) I have a bit of trouble parsing the standard. Is the nothrow operator
new supposed to call the regular operator new? In particular, if a user
replaces only the throwing operator new, should the nothrow operator new
automatically call that function? That's not what we are currently doing
(and it would be a perf regression).
"Required behavior: Return a non-null pointer to suitably aligned storage
(3.7.4), or else return a null pointer. This nothrow version of operator
new returns a pointer obtained as if acquired from the (possibly replaced)
ordinary version. This requirement is binding on a replacement version of
this function.
Default behavior: Calls operator new(size). If the call returns normally,
returns the result of that call. Otherwise, returns a null pointer."
Passes bootstrap+testsuite on x86_64-linux-gnu. Stage 1?
2014-03-03 Marc Glisse
* libsupc++/new_op.cc: Factor the calls to malloc, use __builtin_expect.
* libsupc++/new_opnt.cc: Likewise.
--
Marc GlisseIndex: libsupc++/new_op.cc
===
--- libsupc++/new_op.cc (revision 208255)
+++ libsupc++/new_op.cc (working copy)
@@ -39,22 +39,21 @@ extern "C" void *malloc (std::size_t);
#endif
_GLIBCXX_WEAK_DEFINITION void *
operator new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)
{
void *p;
/* malloc (0) is unpredictable; avoid it. */
if (sz == 0)
sz = 1;
- p = (void *) malloc (sz);
- while (p == 0)
+
+ while (__builtin_expect ((p = malloc (sz)) == 0, false))
{
new_handler handler = std::get_new_handler ();
if (! handler)
_GLIBCXX_THROW_OR_ABORT(bad_alloc());
handler ();
- p = (void *) malloc (sz);
}
return p;
}
Index: libsupc++/new_opnt.cc
===
--- libsupc++/new_opnt.cc (revision 208255)
+++ libsupc++/new_opnt.cc (working copy)
@@ -32,30 +32,28 @@ using std::bad_alloc;
extern "C" void *malloc (std::size_t);
_GLIBCXX_WEAK_DEFINITION void *
operator new (std::size_t sz, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
{
void *p;
/* malloc (0) is unpredictable; avoid it. */
if (sz == 0)
sz = 1;
- p = (void *) malloc (sz);
- while (p == 0)
+
+ while (__builtin_expect ((p = malloc (sz)) == 0, false))
{
new_handler handler = std::get_new_handler ();
if (! handler)
return 0;
__try
{
handler ();
}
__catch(const bad_alloc&)
{
return 0;
}
-
- p = (void *) malloc (sz);
}
return p;
}
Re: [patch, libgfortran] PR60148 Strings in NAMELIST do not honor DELIM= in open statement
Dear Jerry, hi all,
Jerry DeLisle wrote:
The attached patch fixes this by actually implementing it. I cleaned up some of
the code by getting rid of the tmp_delim variables and adding a "mode" to
write_character which is used to ignore delimiters when writing out variable
names and other namelist parts.
gfortran seems to be special as it defaults to printing the " (quote)
delimiter by default while other compilers seem to default to "none".
With the patch, gfortran distinguishes between "none" (i.e. no quote
character) and not set. When unset, gfortran continues to use the double
quote character for quotation and only with "none" is uses no quote
character.
I think gfortran's new behaviour is not not standard conform as the
standard states that DELIM= defaults to NONE. On
the other hand, the standard explicitly requires that on input the quote
characters have to be present.
Given that the current behaviour permits to read-back the namelist, I
think it is invalid but acceptable to default to DELIM=QUOTE. However, I
wonder whether we should document it at
gcc.gnu.org/onlinedocs/gfortran/Extensions-implemented-in-GNU-Fortran.html
I will prepare a test case.
Thanks!
I think a side-effect of the patch is that the two cases below behave
now differently: The first returns "tue", the other causes an error.
Before, both caused errors - which matches the result with Cray ftn and
PGI pgf90. ifort on the other hand reads the string successfully (at
least when the string var is shorter than trailing white spaces at the
end of the string.)
program namelistout
implicit none
character :: mystring*3 = 'tue'
namelist /mylist/ mystring
open(unit=10, file='junk.dat')
write(10, '(A)') ' &mylist mystring=tue /'
close(10)
mystring = repeat('X', 10)
open(unit=10,file='junk.dat',delim='none')
read(10, mylist)
write(*, mylist)
close(10)
mystring = repeat('X', 10)
open(unit=10,file='junk.dat')
read(10, mylist)
write(*, mylist)
close(10)
end program
Regression tested on x86_64.
OK for trunk or hold for next stage?
The patch looks good to me with a test case. I think we should/could
document the special (nonstandard conforming) behaviour in the
documentation. Actually, we could also mention the extended array
support - i.e. "&nml array(1) =1,2,3,4 /" to read "array(1:4)" - but
also make clear that this is an extension and that it should be avoided.
From my side, I think it can still go into the trunk.
+write_character (st_parameter_dt *dtp, const char *source, int kind, int
length, int mode)
{
int i, extra;
char *p, d;
- switch (dtp->u.p.current_unit->delim_status)
+ if (mode)
I think it would be clearer to use "mode == DELIM"
Tobias
2014-03-01 Jerry DeLisle
PR libfortran/60148
* io/inquire.c (inquire_via_unit): In the case of
DELIM_UNSPECIFIED set inquire return string to "NONE".
* io/list_read.c (read_character): In the case of DELIM_NONE and
namelists, complete the character read using the namelist
variable length.
* io/open.c (new_unit): Don't set delim status to none if not
specified so that DELIM_UNSPECIFIED can be used later.
* io/transfer.c (data_transfer_init): For namelist I/O, if the
unit delim status is unspecified set the current status to quote.
Otherwise, set current status to the unit status.
* io/unit.c (get_internel_unit, init_unit): Remember to set
flags_delim initially to DELIM_UNSPECIFIED so defaults come out
correctly.
* io/write.c (write_character): Add a new function argument
"mode" to signify that raw output is to be used vs output with
delimiters. If the mode is set to DELIM (1) proceed with
delimiters. (list_formatted_write_scalar): Write the separator
only if a delimiter was previously specified. Update the call to
write_character with the mode argument given.
(namelist_write_newline): Use the mode argument. (nml_write_obj):
Use the mode argument. Remove use of tmp_delim. Write the
semi-colon or comma correctly only when needed with using
delimiters. Cleanup whitespace.
(namelist_write): If delim is not specified in namelist I/O,
default to using quotes. Get rid of the tmp_delim variable and
use the new mode argument if write_character.
New Swedish PO file for 'gcc' (version 4.9-b20140202)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.9-b20140202.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH v2] Fix PR c++/25940
On 03/01/2014 08:13 PM, Patrick Palka wrote: On Sat, Mar 1, 2014 at 7:53 PM, Marc Glisse wrote: On Sat, 1 Mar 2014, Patrick Palka wrote: + error_at (input_location, + "redefinition of %q+#D with C language linkage", + x); + inform (input_location, + "%q+#D previously defined here", previous); It seems strange that both the new and the old declarations are at the same location... Isn't input_location is a symbolic value standing for the location of the decl argument that's being printed? No, it typically points to the last token parsed. The reason your diagnostics have the location of the decl arguments is because of the '+' in the %q+#D format, which overrides the location given in the first argument. So you could just as well use 0 instead of input_location, or use 'error' rather than error_at. Jason
Re: [PATCH] Fix fortran/pr60236
Bernd Edlinger wrote: This patch tries to solve the problem in a more general way, by classifying the target's expected result by using vect_element_align and vect_call_sqrtf attributes. This patch has been tested on armv7l-unknown-linux-gnueabihf, x86_64-unknown-linux-gnu and powerpc-apple-darwin9. OK for trunk? OK. Thanks for the patch - and thanks to Dominque for the Darwin testing. Tobias
[PING] [PATCH] Fix fortran/pr60236
Ping. > Subject: [PATCH] Fix fortran/pr60236 > Date: Sun, 23 Feb 2014 14:50:46 +0100 > > Hi, > > the test case gfortran.dg/vect/pr32380.f was found to fail on > armv7l-unknown-linux-gnueabihf. > The reason for this is that one out of 6 loops does not get vectorized, > because this target does > not support a vectorization of sqrtf. > > The same test case is known to fail on powerpc-apple-darwin9 due to a > different reason, see PR52229. > On that target 5 out of 6 loops do not get vectorized, because of an > alignment issue. That was solved > at that time by declaring some targets xfail. > > This patch tries to solve the problem in a more general way, by classifying > the target's expected > result by using vect_element_align and vect_call_sqrtf attributes. > > This patch has been tested on armv7l-unknown-linux-gnueabihf, > x86_64-unknown-linux-gnu and > powerpc-apple-darwin9. > > OK for trunk? > > Regards > Bernd. > > > P.S.: Many thanks to Dominique d'Humieres for reg-testing on > powerpc-apple-darwin9.
Re: [RFC] Do not consider volatile asms as optimization barriers #1
> Thanks for doing this. FWIW I agree it's probably the best stop-gap fix. > But the implication seems to be that unspec_volatile and volatile asms > are volatile in different ways. IMO they're volatile in the same way > and the problems for volatile asms apply to unspec_volatile too. I disagree, we need a simple way for the RTL middle-end as well as the back- ends to block most optimizations across a specific point (e.g. a non-local label as in HP's fix) and UNSPEC_VOLATILE is the best candidate, at least in the short term. > E.g. although cse.c will flush the table for unspec_volatile, > it isn't the case that unspec_volatile forces a containing function > to save all call-saved registers. That would be excessive for a plain > blockage instruction. So again we seem to be assuming one thing in places > like cse.c and another in the register allocator. Code that uses the DF > framework will also assume that registers are not implicitly clobbered > by an unspec_volatile: > [...] > Also, ira-lives.c (which tracks the liveness of both pseudo and hard > registers) doesn't mention "volatile" at all. Yes, the definition of a blockage instruction is somewhat vague and I agree that it shoudn't cause registers to be spilled. But it needs to block most, if not all, optimizations. > So most passes assume that no pseudos or hard registers will be > implicitly clobbered by unspec_volatile, just like for a volatile asm. > And IMO that's right. I think the rule should be the same for volatile > asms and unspec_volatiles, and the same for registers as it already is for > memory: if the instruction clobbers something, it should say so explicitly. IMO that would buy us nothing and, on the contrary, would add complexity where there currently isn't. We really need a simple blockage instruction. > Volatile itself should: > > (a) prevent deletion or duplication of the operation > (b) prevent reordering wrt other volatiles > (c) prevent the operation from being considered equivalent to any other > operation (even if it's structurally identical and has the same inputs) > > but nothing beyond that. Maybe UNSPEC_VOLATILE is a misnomer then and we should allow volatile UNSPECs along the above lines. -- Eric Botcazou
Re: [PATCH v4] PR middle-end/60281
Hi Bernd, I think about whether the best mode is so important to x86_64.There is no mov r/m64,imm64 refering to Intel Software Developer's Manual Volume 2A 3-505.imm32 is the biggest number.And asan clears stack using imms. And even if there is a mov r/m64,imm64 in the future.The gcc peephole pass will do its job.These constant moves will get combined. So Maybe the best mode is not so important. -- Regards lin zuojian
