Re: [PATCH] IPA REF: alias refactoring
Hi, this patch enhances alias manipulation for symtab_node. Honza suggested following changes. Patch is pre approved, will be committed if no comments and regressions. Bootstrapped on x86_64-pc-linux-gnu, regression tests have been running. Thanks, Martin gcc/ChangeLog: * cgraph.h (iterate_direct_aliases): New function. (FOR_EACH_ALIAS): New macro iterates all direct aliases for a node. * cgraph.c (cgraph_for_node_thunks_and_aliases): Usage of FOR_EACH_ALIAS added. (cgraph_for_node_and_aliases): Likewise. * cgraphunit.c (assemble_thunks_and_aliases): Likewise. * ipa-inline.c (reset_edge_caches): Likewise. (update_caller_keys): Likewise. * trans-mem.c (ipa_tm_execute): Likewise. *varpool.c (varpool_analyze_node): Likewise. (varpool_for_node_and_aliases): Likewise. * ipa-ref.h (first_referring_alias): New function. (last_referring_alias): Likewise. I missed it last time around, I think first_alias/last_alias are better names. first_alias is unused. If you added it I guess FOR_EACH_ALIAS should use it. We probably also can bring has_aliases_p inline and implement it using first_referring_alias. + /* If deleted item is IPA_REF_ALIAS, we have to move last + item of IPA_REF_LIST type to the deleted position. After that + we replace last node with deletion slot. */ + struct ipa_ref *last_alias = list-last_referring_alias (); You can avoid walking to last alias when the removed item is not IPA_REF_ALIAS. + + /* IPA_REF_ALIAS is always put at the beginning of the list. */ inserted? OK with these changes (or if you already comitted, just do them incrementally) Honza
Re: [PR 61424] std::regex matches right to left, not leftmost longest
On Tue, Jun 10, 2014 at 1:56 PM, Tim Shen timshe...@gmail.com wrote:
On Tue, Jun 10, 2014 at 9:54 AM, Jonathan Wakely jwak...@redhat.com wrote:
I'm sure this is because I still don't understand all the regex code,
but doesn't this change mean that for an extended mode regex with
backrefs, the user could define _GLIBCXX_REGEX_USE_THOMPSON_NFA and
backrefs wouldn't work?
Sorry I missed that basic POSIX (BRE) has back-references (damn!), but
extended POSIX (ERE) doesn't. So it should look like:
- if (!__re._M_automaton-_M_has_backref
+ if (!(__re._M_automaton-_M_has_backref || (__re._M_flags
regex_constants::ECMAScript))
...and all deleted _M_has_backref lines should be undeleted.
This patch is a temporary (I'm not sure how long though) workaround;
BFS's support for ECMAScript with no back-references shall be done
finally.
Sorry for late; this is the complete patch.
Bootstrapped and tested.
Thanks!
--
Regards,
Tim Shen
commit 10c1e55884525ff4c3ad959d29181b85966630c1
Author: Tim Shen tims...@google.com
Date: Fri Jun 27 19:24:29 2014 -0700
PR libstdc++/61424
* include/bits/regex.tcc (__regex_algo_impl): Use DFS for ECMAScript,
not just regex containing back-references.
* include/bits/regex_compiler.tcc (_Compiler::_M_disjunction):
exchange _M_next and _M_alt for alternative operator,
making matching from left to right.
* include/bits/regex_executor.h (_State_info::_M_get_sol_pos):
Add position tracking fom DFS.
* include/bits/regex_executor.tcc (_Executor::_M_main_dispatch,
_Executor::_M_dfs): Likewise.
* include/bits/regex_scanner.h: Remove unused enum entry.
* testsuite/28_regex/algorithms/regex_search/61424.cc: New
testcase from PR.
diff --git a/libstdc++-v3/include/bits/regex.tcc
b/libstdc++-v3/include/bits/regex.tcc
index a81f517..3322379 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -71,6 +71,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// _GLIBCXX_REGEX_USE_THOMPSON_NFA if they need to use this approach.
bool __ret;
if (!__re._M_automaton-_M_has_backref
+ !(__re._M_flags regex_constants::ECMAScript)
#ifndef _GLIBCXX_REGEX_USE_THOMPSON_NFA
__policy == _RegexExecutorPolicy::_S_alternate
#endif
diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc
b/libstdc++-v3/include/bits/regex_compiler.tcc
index 0df10cc..f15f7dd 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -103,9 +103,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
auto __end = _M_nfa._M_insert_dummy();
__alt1._M_append(__end);
__alt2._M_append(__end);
+ // __alt2 is state._M_next, __alt1 is state._M_alt. The executor
+ // executes _M_alt before _M_next, as well as executing left
+ // alternative before right one.
_M_stack.push(_StateSeqT(_M_nfa,
- _M_nfa._M_insert_alt(__alt1._M_start,
- __alt2._M_start, false),
+ _M_nfa._M_insert_alt(__alt2._M_start,
+ __alt1._M_start, false),
__end));
}
}
diff --git a/libstdc++-v3/include/bits/regex_executor.h
b/libstdc++-v3/include/bits/regex_executor.h
index 1991c00..e02fa65 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -173,6 +173,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void _M_queue(_StateIdT __i, const _ResultsVec __res)
{ _M_match_queue.emplace_back(__i, __res); }
+ _BiIter* _M_get_sol_pos() { return nullptr; }
+
// Saves states that need to be considered for the next character.
vectorpair_StateIdT, _ResultsVec _M_match_queue;
// Indicates which states are already visited.
@@ -191,12 +193,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Dummy implementations for DFS mode.
bool _M_visited(_StateIdT) const { return false; }
void _M_queue(_StateIdT, const _ResultsVec) { }
+ _BiIter* _M_get_sol_pos() { return _M_sol_pos; }
// To record current solution.
_StateIdT _M_start;
+ _BiIter _M_sol_pos;
};
-
public:
_ResultsVec _M_cur_results;
_BiIter _M_current;
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc
b/libstdc++-v3/include/bits/regex_executor.tcc
index aefa8f4..38b8ff2 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -82,6 +82,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_main_dispatch(_Match_mode __match_mode, __dfs)
{
_M_has_sol = false;
+
Re: [PR 61424] std::regex matches right to left, not leftmost longest
On 28/06/14 00:18 -0700, Tim Shen wrote:
diff --git a/libstdc++-v3/include/bits/regex_executor.h
b/libstdc++-v3/include/bits/regex_executor.h
index 1991c00..e02fa65 100644
--- a/libstdc++-v3/include/bits/regex_executor.h
+++ b/libstdc++-v3/include/bits/regex_executor.h
@@ -173,6 +173,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void _M_queue(_StateIdT __i, const _ResultsVec __res)
{ _M_match_queue.emplace_back(__i, __res); }
+ _BiIter* _M_get_sol_pos() { return nullptr; }
+
// Saves states that need to be considered for the next character.
vectorpair_StateIdT, _ResultsVec _M_match_queue;
// Indicates which states are already visited.
@@ -191,12 +193,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Dummy implementations for DFS mode.
bool _M_visited(_StateIdT) const { return false; }
void _M_queue(_StateIdT, const _ResultsVec) { }
+ _BiIter* _M_get_sol_pos() { return _M_sol_pos; }
Please put a space above this new function, otherwise it looks like
the Dummy implementations comment applies to this function, but in
fact that function is used for dfs mode.
Similarly, maybe there should be a Dummy implementation comment on
the _State_info__bfs, RV::_M_get_sol_pos function.
OK with that change, thanks for the fix.
Re: [Patch, PR 61061] Add state limit for regex NFA
On 27/06/14 09:53 -0700, Tim Shen wrote: On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini paolo.carl...@oracle.com wrote: The actual patch is missing.. ;) Sigh...every time. Sorry. PS: sorry for being distracted by other issues: what happened to the other regex issue? I think we are simply going to apply, when ready, your more complete fix, right? The problem given in the other PR (PR 61582) is also solved by this patch (but I forgot to mention that); They are all examples like nested range quantifiers. OK for trunk, thanks. I wonder if it would be better to use a sorted vectorpair_StateIdT,_StateIdT instead of a map, for improved memory footprint and runtime speed, but that can be changed later.
Re: [patch] change specific int128 - generic intN
(oups, the message got stuck in my mailer, should have been sent a while ago) On Tue, 24 Jun 2014, DJ Delorie wrote: Since the check for __STRICT_ANSI__ is removed, do we need to add __extension__ in front of __GLIBCXX_TYPE_INT_N_0 to avoid warning with -Wsystem-headers? I copied the code from the __int128 case, and it explicitly bypassed -Wsystem-headers... so we don't have that problem. Ah... indeed. That seems complicated. You just need to call emit_support_tinfo_1 on each of the types (see how fundamentals is used at the end of the function), no need to put everything in the array. Sure, *now* you tell me that :-) Sorry, I should have made that clearer when I introduced emit_support_tinfo_1... I can do it either way, but it's the same overhead to iterate through the types. Shoving it into the array is a bit more future-proof, but keeping the index in sync is a bit of work if the table ever changes. We are already going to have a second loop, not on the fundamentals array, calling emit_support_tinfo_1 for __float128 when available, so the array won't be complete anymore. More precisely, it will iterate either on all the types on which register_builtin_type was called or on float modes that don't correspond to float/double/long double (depends on how much they break ARM). Your choice ;-) Well, Jason's. -- Marc Glisse
[wwwdocs] Convert links to http://gcc.gnu.org/wiki to https
Applied. Gerald Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.108 diff -u -r1.108 lists.html --- lists.html 27 Jun 2014 11:48:45 - 1.108 +++ lists.html 28 Jun 2014 08:05:33 - @@ -94,7 +94,7 @@ liba href=https://gcc.gnu.org/ml/jit/;jit/a/b is for discussion and development of - a href=http://gcc.gnu.org/wiki/JIT;libgccjit/a, an experimental + a href=https://gcc.gnu.org/wiki/JIT;libgccjit/a, an experimental library for implementing Just-In-Time compilation using GCC as a back end. The list is intended for both users and developers of the library. Patches for the jit branch should go to both this list and Index: news.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v retrieving revision 1.142 diff -u -r1.142 news.html --- news.html 28 Jun 2014 07:45:05 - 1.142 +++ news.html 28 Jun 2014 08:05:34 - @@ -84,7 +84,7 @@ dtspanGCC now uses C++ as its implementation language/span span class=date[2012-08-14]/span/dt -ddThe a href=http://gcc.gnu.org/wiki/cxx-conversion;cxx-conversion/a +ddThe a href=https://gcc.gnu.org/wiki/cxx-conversion;cxx-conversion/a branch has been merged into trunk. This switches GCC's implementation language from C to a href=codingconventions.html#Cxx_ConventionsC++/a. Additionally, some data structures have been re-implemented in C++ @@ -125,7 +125,7 @@ dtspanAtomic memory model support/span span class=date[2011-11-06]/span/dt -ddC++11/C11 a href=http://gcc.gnu.org/wiki/Atomic/GCCMM;memory model/a +ddC++11/C11 a href=https://gcc.gnu.org/wiki/Atomic/GCCMM;memory model/a support has been added through a new set of built-in code__atomic/code functions. Code was contributed by Andrew MacLeod, Richard Henderson, and Aldy Hernandez, all of Red Hat, Inc. @@ -135,14 +135,14 @@ span class=date[2011-11-18]/span/dt ddIUUK (Computer Science Institute, Charles University), CE-ITI (Institute for Theoretical Computer Science) and Google are organizing -a a href=http://gcc.gnu.org/wiki/cauldron2012;workshop for GNU +a a href=https://gcc.gnu.org/wiki/cauldron2012;workshop for GNU Tools developers/a. The workshop will be held in July 2012 at Charles University, Prague./dd dtspanTransactional memory support/span span class=date[2011-11-15]/span/dt ddAn implementation of the -ongoing a href=http://gcc.gnu.org/wiki/TransactionalMemory;transactional +ongoing a href=https://gcc.gnu.org/wiki/TransactionalMemory;transactional memory/a standard has been added. Code was contributed by Richard Henderson, Aldy Hernandez, and Torvald Riegel, all of Red Hat, Inc. The project was partially funded by @@ -154,7 +154,7 @@ dtspanPOWER7 on the GCC Compile Farm/span span class=date[2011-11-10]/span/dt ddIBM has donated a 64 processor POWER7 machine (3.55 GHz, 64 GB RAM) -to the a href=http://gcc.gnu.org/wiki/CompileFarm;GCC Compile Farm +to the a href=https://gcc.gnu.org/wiki/CompileFarm;GCC Compile Farm project/a. Hosting is donated by the OSU Open Source Lab./dd dtspanEpiphany processor support/span @@ -283,7 +283,7 @@ dda href=gcc-4.4/GCC 4.4.2/a has been released./dd dtOctober 3, 2009/dt -ddThe a href=http://gcc.gnu.org/wiki/LinkTimeOptimization;LTO/a +ddThe a href=https://gcc.gnu.org/wiki/LinkTimeOptimization;LTO/a branch has been merged into trunk. The next release of GCC will feature a new whole-program optimizer, able to perform interprocedural optimizations across different files, even if they are written in @@ -302,7 +302,7 @@ dtMay 6, 2009/dt ddGCC can now be extended using a generic a -href=http://gcc.gnu.org/wiki/plugins-branch;plugin framework/a on host +href=https://gcc.gnu.org/wiki/plugins-branch;plugin framework/a on host platforms that support dynamically loadable objects./dd dtApril 21, 2009/dt @@ -345,7 +345,7 @@ dtMay 22, 2008/dt ddAMD Developer Central has donated two bi-quad core machines with the latest AMD Opteron 8354 Barcelona B3 processors and 16GB of RAM -to the a href=http://gcc.gnu.org/wiki/CompileFarm;GCC Compile Farm +to the a href=https://gcc.gnu.org/wiki/CompileFarm;GCC Compile Farm project/a for use by free software developers. Hosting is donated by INRIA Saclay./dd @@ -443,7 +443,7 @@ GCC/a./dd dtJanuary 5, 2007/dt -dda href=http://gcc.gnu.org/wiki/mem-ssa;Memory SSA/a, a new +dda href=https://gcc.gnu.org/wiki/mem-ssa;Memory SSA/a, a new representation for memory expressions in SSA form has been contributed by Diego Novillo of Red Hat. This new mechanism improves a href=https://gcc.gnu.org/ml/gcc-patches/2006-12/msg00436.html;compile-times @@ -532,7 +532,7 @@ New DECL hierarchy. More information about these projects can be found at -a href=http://gcc.gnu.org/wiki/GCC_4.1_Projects;GCC 4.1 projects/a. +a href=https://gcc.gnu.org/wiki/GCC_4.1_Projects;GCC 4.1 projects/a.
Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.
On Mon, 23 Jun 2014, Tejas Belagod wrote: Here is a patch that restructures neon builtins to use vector types based on standard base types. We previously defined arm_neon.h's neon vector types(int8x8_t) using gcc's front-end vector extensions. We now move away from that and use types built internally(e.g. __Int8x8_t). These internal types names are defined by the AAPCS64 and we build arm_neon.h's public vector types over these internal types. e.g. typedef __Int8x8_t int8x8_t; as opposed to typedef __builtin_aarch64_simd_qi int8x8_t __attribute__ ((__vector_size__ (8))); Impact on mangling: This patch does away with these builtin scalar types that the vector types were based on. These were previously used to look up mangling names. We now use the internal vector type names(e.g. __Int8x8_t) to lookup mangling for the arm_neon.h-exported vector types. There are a few internal scalar types(__builtin_aarch64_simd_oi etc.) that is needed to efficiently implement some NEON Intrinsics. These will be declared in the back-end and registered in the front-end and aarch64-specific builtin types, but are not user-visible. These, along with a few scalar __builtin types that aren't user-visible will have implementation-defined mangling. Because we don't have strong-typing across all builtins yet, we still have to maintain the old builtin scalar types - they will be removed once we move over to a strongly-typed builtin system implemented by the qualifier infrastructure. Marc Glisse's patch in this thread exposed this issue https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00618.html. I've tested my patch with the change that his patch introduced, and it seems to work fine - specifically these two lines: + for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t)) +emit_support_tinfo_1 (TREE_VALUE (t)); If you still have that build somewhere, could you try: nm -C libsupc++.a | grep typeinfo and check how much your builtins appear there? With my patch you may have half-floats in addition to what you get without the patch (I think that's a good thing), but I hope not too much more... Thanks for working on this, -- Marc Glisse
[commit] Fix ABI fallout (Re: wide-int, rs6000)
Mike Stump wrote:
(rs6000_aggregate_candidate): Use wide-int interfaces.
[snip]
- /* Can't handle incomplete types. */
- if (!COMPLETE_TYPE_P (type))
- return -1;
+ /* Can't handle incomplete types nor sizes that are not
+fixed. */
+ if (!COMPLETE_TYPE_P (type)
+ || TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
This patch introduced an accidental change: the return -1; line was
deleted. This influences certain ABI decisions, e.g. whether a union
of two vector types is supposed to be passed in a VR or in GPRs.
(Noticed by running the ABI compatibility test suite.)
Fortunately, this bug never made it into any (FSF or distribtion)
GCC release, so we can simply fix it now without introducing any
incompatibilities ...
I've checked in the following patch as obvious.
Bye,
Ulrich
ChangeLog:
2014-06-28 Ulrich Weigand ulrich.weig...@de.ibm.com
* config/rs6000/rs6000.c (rs6000_aggregate_candidate): Revert
accidental change due to wide-int branch merge.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 212069)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -8766,6 +8766,7 @@
fixed. */
if (!COMPLETE_TYPE_P (type)
|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
+ return -1;
for (field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field))
{
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
[wwwdocs] Make five links relative
This is the right thing in general (considering mirror sites like http://www.gnu.org/software/gcc/) and the fact that we know do not need to convert these from http to https confirms that point. It also shows that mass converting the entire wwwdocs tree in a single step would not have been ideal. Applied. Gerald Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.31 diff -u -r1.31 branching.html --- branching.html 2 Mar 2012 14:27:48 - 1.31 +++ branching.html 28 Jun 2014 10:29:55 - @@ -64,7 +64,7 @@ lia href=translation.html#regenRegenerate codegcc.pot/code/a and codecpplib.pot/code. -a href=http://gcc.gnu.org/translation.html#submit;Send them +a href=translation.html#submitSend them to the translation project/a if no snapshot of this version was sent during development stage 3 or 4./li Index: lists.html === RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v retrieving revision 1.109 diff -u -r1.109 lists.html --- lists.html 28 Jun 2014 08:14:40 - 1.109 +++ lists.html 28 Jun 2014 10:29:55 - @@ -13,7 +13,7 @@ -- pThe GCC project has many mailing lists, which are archived on the web -(and a href=http://gcc.gnu.org/lists.html#searchbox;searchable/a). +(and a href=#searchboxsearchable/a). Please make yourself familiar with a href=#policiesour policies/a before a href=#subscribesubscribing/a and posting to these lists. /p Index: news/profiledriven.html === RCS file: /cvs/gcc/wwwdocs/htdocs/news/profiledriven.html,v retrieving revision 1.9 diff -u -r1.9 profiledriven.html --- news/profiledriven.html 3 Dec 2013 01:04:42 - 1.9 +++ news/profiledriven.html 28 Jun 2014 10:29:56 - @@ -85,7 +85,7 @@ heuristics that expose common behavior of programs, for instance that loops usually loop more than once, pointers are non-null and integers usually positive. The original predictor has been contributed by a -href=http://gcc.gnu.org/news/reorder.html;Stan Cox and Jason +href=reorder.htmlStan Cox and Jason Eckhardt for the basic block reordering pass/a. /p Index: projects/cli.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cli.html,v retrieving revision 1.24 diff -u -r1.24 cli.html --- projects/cli.html 3 Dec 2013 01:11:52 - 1.24 +++ projects/cli.html 28 Jun 2014 10:29:56 - @@ -361,7 +361,7 @@ lipThe frontend would provide a way of producing native executables from CIL images, analogous to how the iGNU Compiler - for Java/i (a href=http://gcc.gnu.org/java/;GCJ/a) provides a + for Java/i (a href=../java/GCJ/a) provides a way to produce native executables from Java classes./p/li /ul Index: testing/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/testing/index.html,v retrieving revision 1.34 diff -u -r1.34 index.html --- testing/index.html 28 Jun 2014 08:14:42 - 1.34 +++ testing/index.html 28 Jun 2014 10:29:56 - @@ -48,7 +48,7 @@ a href=http://gcc.gnu.org/install/test.html;Installing GCC: Testing/a for instructions on submitting test results./li liBuild cross compilers and test with simulators as described in - a href=http://gcc.gnu.org/simtest-howto.html;How to test GCC + a href=../simtest-howto.htmlHow to test GCC on a simulator/a./li liIf your system is beefy enough, do regular builds and test runs with RTL consistency checks enabled. This slows the compiler down by an
Re: [i386] Replace builtins with vector extensions
Ping, nobody has an opinion on this? Or some explanation why I am mistaken to believe that #pragma target makes it safer now? It would enable a number of optimizations, like constant propagation, FMA contraction, etc. It would also allow us to remove several builtins. On Sat, 17 May 2014, Marc Glisse wrote: Ping On Mon, 28 Apr 2014, Marc Glisse wrote: Ping http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00590.html (note that ARM seems to be doing the same thing for their neon intrinsics, see Ramana's patch series posted today) On Fri, 11 Apr 2014, Marc Glisse wrote: Hello, the previous discussion on the topic was before we added all those #pragma target in *mmintrin.h: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00374.html I believe that removes a large part of the arguments against it. Note that I only did a few of the more obvious intrinsics, I am waiting to see if this patch is accepted before doing more. Bootstrap+testsuite on x86_64-linux-gnu. 2014-04-11 Marc Glisse marc.gli...@inria.fr * config/i386/xmmintrin.h (_mm_add_ps, _mm_sub_ps, _mm_mul_ps, _mm_div_ps, _mm_store_ss, _mm_cvtss_f32): Use vector extensions instead of builtins. * config/i386/emmintrin.h (_mm_store_sd, _mm_cvtsd_f64, _mm_storeh_pd, _mm_cvtsi128_si64, _mm_cvtsi128_si64x, _mm_add_pd, _mm_sub_pd, _mm_mul_pd, _mm_div_pd, _mm_storel_epi64, _mm_movepi64_pi64, _mm_loadh_pd, _mm_loadl_pd): Likewise. (_mm_sqrt_sd): Fix comment. -- Marc Glisse
Re: [RFC PATCH] -fsanitize=nonnull and -fsanitize=returns-nonnull support
On Fri, 27 Jun 2014, Jakub Jelinek wrote: This patch implements sanitization for nonnull and returns_nonnull attributes. No documentation patch? Also, should this be documented in gcc-4.10/changes.html? As GCC 4.9.0+ now aggressively optimizes based on these attributes and we've seen several issues in real world apps, I think this is really needed. Nice! Is this worth pushing into GCC 4.9.1 as well? Gerald
[wwwdocs] http://gcc.gnu.org/install/ links
Convert references to http://gcc.gnu.org/install/ and sub-pages to https. Avoid some such links. Committed. Gerald Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.218 diff -u -r1.218 faq.html --- faq.html28 Jun 2014 07:45:04 - 1.218 +++ faq.html28 Jun 2014 11:57:20 - @@ -103,7 +103,7 @@ pThe host/target specific installation notes for GCC include information about known problems with installing or using GCC on particular platforms. These are included in the sources for a release in INSTALL/specific.html, -and the a href=http://gcc.gnu.org/install/specific.html;latest version/a +and the a href=https://gcc.gnu.org/install/specific.html;latest version/a is always available at the GCC web site. Reports of a href=http://gcc.gnu.org/buildstat.html;successful builds/a for several versions of GCC are also available at the web site./p @@ -217,7 +217,7 @@ the GNU versions of those programs./p pTo ensure that GCC finds the GNU assembler (the GNU linker), which -are required by a href=http://gcc.gnu.org/install/specific.html;some +are required by a href=https://gcc.gnu.org/install/specific.html;some configurations/a, you should configure these with the same --prefix option as you used for GCC. Then build amp; install GNU as (GNU ld) and proceed with @@ -457,7 +457,7 @@ transparently without requiring installation of any additional tools./p pIf you modified some sources or when building from SVN you may also -need a href=http://gcc.gnu.org/install/prerequisites.html#TOC1;some +need a href=https://gcc.gnu.org/install/prerequisites.html#TOC1;some additional tools/a./p Index: releases.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releases.html,v retrieving revision 1.112 diff -u -r1.112 releases.html --- releases.html 12 Jun 2014 12:47:25 - 1.112 +++ releases.html 28 Jun 2014 11:57:22 - @@ -17,7 +17,7 @@ of little use to you if you do not already have a C compiler on your machine./em If you don't already have a compiler, you need pre-compiled binaries. -Our a href=http://gcc.gnu.org/install/binaries.html;binaries page/a +Our a href=https://gcc.gnu.org/install/binaries.html;binaries page/a has references to pre-compiled binaries for various platforms./p pYou can also retrieve the current development sources Index: egcs-1.0/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.0/index.html,v retrieving revision 1.3 diff -u -r1.3 index.html --- egcs-1.0/index.html 3 Dec 2013 01:04:41 - 1.3 +++ egcs-1.0/index.html 28 Jun 2014 11:57:27 - @@ -200,7 +200,7 @@ pThe EGCS 1.0 releases include installation instructions in both HTML and plaintext forms (see the INSTALL directory in the toplevel directory of the distribution). However, we also keep the most up to date -a href=http://gcc.gnu.org/install/;installation instructions/a +installation instructions and a href=buildstat.htmlbuild/test status/a on our web page. We will update those pages as new information becomes available./p Index: egcs-1.1/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/egcs-1.1/index.html,v retrieving revision 1.7 diff -u -r1.7 index.html --- egcs-1.1/index.html 28 Jun 2014 07:45:08 - 1.7 +++ egcs-1.1/index.html 28 Jun 2014 11:57:27 - @@ -258,7 +258,7 @@ pEach release includes installation instructions in both HTML and plaintext forms (see the INSTALL directory in the toplevel directory of the distribution). However, we also keep the most up to date -a href=http://gcc.gnu.org/install/;installation instructions /a +installation instructions and a href=buildstat.htmlbuild/test status/a on our web page. We will update those pages as new information becomes available./p Index: gcc-2.95/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-2.95/index.html,v retrieving revision 1.4 diff -u -r1.4 index.html --- gcc-2.95/index.html 28 Jun 2014 07:45:10 - 1.4 +++ gcc-2.95/index.html 28 Jun 2014 11:57:28 - @@ -43,8 +43,7 @@ pThe sources include installation instructions in both HTML and plaintext forms in the codeinstall/code directory in the distribution. -However, the most up to date - a href=http://gcc.gnu.org/install/;installation instructions/a +However, the most up to date installation instructions and a href=buildstat.htmlbuild/test status/a are on the web pages. We will update those pages as new information becomes available./p Index: gcc-3.0/buildstat.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.0/buildstat.html,v retrieving revision 1.154 diff -u -r1.154 buildstat.html ---
Re: [wwwdocs] gcc-4.9/changes.html: Mention that LTO now generates slim objects
On Fri, 21 Mar 2014, Tobias Burnus wrote: Thanks for the suggestions - updated patch below. Here are two small tweaks I just committed on top of this. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.71 retrieving revision 1.72 diff -u -r1.71 -r1.72 --- changes.html11 Jun 2014 18:49:26 - 1.71 +++ changes.html28 Jun 2014 12:37:43 - 1.72 @@ -80,13 +80,13 @@ overall memory usage at link time./li liC++ hidden keyed methods can now be optimized out./li liWhen using a linker plugin, compiling with the code-flto/code - option now generates slim objects files (code.o/code) which only + option now generates slim object files (code.o/code) which only contain intermediate language representation for LTO. Use code-ffat-lto-objects/code to create files which contain additionally the object code. To generate static libraries suitable for LTO processing, use codegcc-ar/code and codegcc-ranlib/code; to list symbols from a slim object file use - codegcc-nm/code. (Requires that codear/code, + codegcc-nm/code. (This requires that codear/code, coderanlib/code and codenm/code have been compiled with plugin support.)/li /ul
Re: [Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals
On 06/27/2014 05:39 PM, paolo.carlini at oracle dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
Patch looks *great*. If it works, please send it to mailing list ASAP.
I think I finally got these weird user-defined string literal bugs.
Don't cross the streams!
Dr. Egon Spengler
PR C++/58781 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58781 - Unicode
strings broken in a strange way
PR C++/59867 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 - Template
string literal loses first symbol
PR C++/60249 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249 - Compiler
goes into semi-infinite loop with wrong usage of user defined string literals
Plus I fixed an misleading error message for string literal operator templates
(not available in C++11).
Built and tested clean on x86_64-linux.
OK?
I would also like to apply this to 4.9.
cp/
2014-06-28 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58781
PR c++/60249
PR c++/59867
* parser.c (cp_parser_userdef_string_literal()): Take a tree
not a cp_token*. (cp_parser_string_literal(): Don't hack
the token stream!
testsuite/
2014-06-28 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58781
PR c++/60249
PR c++/59867
* testsuite/g++.dg/cpp0x/pr58781.C: New.
* testsuite/g++.dg/cpp0x/pr60249.C: New.
* testsuite/g++.dg/cpp1y/pr59867.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 211481)
+++ cp/parser.c (working copy)
@@ -1893,7 +1893,7 @@
static tree cp_parser_userdef_char_literal
(cp_parser *);
static tree cp_parser_userdef_string_literal
- (cp_token *);
+ (tree);
static tree cp_parser_userdef_numeric_literal
(cp_parser *);
@@ -3713,8 +3713,7 @@
{
tree literal = build_userdef_literal (suffix_id, value,
OT_NONE, NULL_TREE);
- tok-u.value = literal;
- return cp_parser_userdef_string_literal (tok);
+ value = cp_parser_userdef_string_literal (literal);
}
}
else
@@ -3962,9 +3961,8 @@
as arguments. */
static tree
-cp_parser_userdef_string_literal (cp_token *token)
+cp_parser_userdef_string_literal (tree literal)
{
- tree literal = token-u.value;
tree suffix_id = USERDEF_LITERAL_SUFFIX_ID (literal);
tree name = cp_literal_operator_id (IDENTIFIER_POINTER (suffix_id));
tree value = USERDEF_LITERAL_VALUE (literal);
@@ -23156,10 +23154,17 @@
ok = false;
}
if (!ok)
- error (literal operator template %qD has invalid parameter list.
-Expected non-type template argument pack char...
- or typename CharT, CharT...,
- decl);
+ {
+ if (cxx_dialect = cxx1y)
+ error (literal operator template %qD has invalid parameter list.
+Expected non-type template argument pack char...
+ or typename CharT, CharT...,
+ decl);
+ else
+ error (literal operator template %qD has invalid parameter list.
+Expected non-type template argument pack char...,
+ decl);
+ }
}
/* Register member declarations. */
if (member_p !friend_p decl !DECL_CLASS_TEMPLATE_P (decl))
Index: testsuite/g++.dg/cpp0x/pr58781.C
===
--- testsuite/g++.dg/cpp0x/pr58781.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr58781.C(revision 0)
@@ -0,0 +1,18 @@
+// PR c++/58781
+// { dg-do compile { target c++11 } }
+
+#include cstddef
+
+int
+operator_s(const char32_t *a, size_t b)
+{
+ return 0;
+}
+
+int
+f()
+{
+ using a = decltype(U\x1181_s);
+ using b = decltype(U\x8111_s);
+ using c = decltype(U \x1181_s);
+}
Index: testsuite/g++.dg/cpp0x/pr60249.C
===
--- testsuite/g++.dg/cpp0x/pr60249.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr60249.C(revision 0)
@@ -0,0 +1,4 @@
+// PR c++/60249
+// { dg-do compile { target c++11 } }
+
+decltype(_) x;
Index: testsuite/g++.dg/cpp1y/pr59867.C
===
--- testsuite/g++.dg/cpp1y/pr59867.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr59867.C(revision 0)
@@ -0,0 +1,52 @@
+// PR c++/59867
+// { dg-do compile { target c++14 } }
+
+#include iostream
+using namespace std;
+
+// constant
+templatetypename T, T x
+ struct meta_value
+ {
+typedef meta_value type;
+typedef T value_type;
+static const T value = x;
+ };
+
+// array
+templatetypename T, T... data
+ struct meta_array
+ {
+typedef meta_array type;
+typedef T item_type;
+ };
+
+// static array - runtime array conversion utility
+templatetypename T
+ struct array_gen;
+
+templatetypename T,
[c++-concepts] constraint association
After merging from trunk this morning, I discovered that
DECL_SIZE_UNIT is now being used to store lists of specializations. I
had been using that to store template constraints. Oops.
This patch moves constraints outside the usual tree structures into an
association maintained in a hash table. It also lays the framework for
allowing constraints to be associated with any _*DECL node (templates,
functions, variables, types, etc).
Changelog below; committed as 212103.
2014-06-28 Andrew Sutton andrew.n.sut...@gmail.com
* gcc/cp/cp-tree.h (DECL_CONSTRAINTS): Remove this macro; use
get_constraints instead.
(set_constraints): new.
* gcc/cp/cxx-pretty-print.c (pp_cxx_template_declaration): Use
get_constraints.
* gcc/cp/pt.c (get_specialization_constraints): Use get_constraints.
(build_template_decl): Use get_constraints.
(process_partial_specialization): Use get_constraints.
(add_inherited_template_parms): Use get_constraints.
(redeclare_class_template): Use get_constraints.
(is_compatible_template_arg): Use get_constraints.
(tsubst_friend_class): Use get_constraints.
(tsubst_decl): Uset get_constraints.
* gcc/cp/semantics.c (finish_template_template_parm): Use
get_constraints.
(fixup_template_type): Use get_constraints.
* gcc/cp/constraint.cc (constraints): New global association
of declarations to constraints.
(get_constraints): Return the associated constraints from the
hash table.
(set_constraints): New. Associate constraints with a declaration.
(check_template_constraints): Use get_constraints.
(equivalently_constrained): Use get_constraints.
(more_constrained): Use get_constraints.
(diagnose_constraints): Use get_constraints.
* gcc/testsuite/g++.dg/concepts/partial-spec.C: New.
Andrew
Index: gcc/cp/cxx-pretty-print.c
===
--- gcc/cp/cxx-pretty-print.c (revision 212100)
+++ gcc/cp/cxx-pretty-print.c (working copy)
@@ -2220,7 +2220,7 @@ pp_cxx_template_declaration (cxx_pretty_
pp_newline_and_indent (pp, 3);
}
- if (tree c = DECL_CONSTRAINTS (t))
+ if (tree c = get_constraints (t))
{
pp_cxx_ws_string (pp, requires);
pp-expression (CI_REQUIREMENTS (c));
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c (revision 212101)
+++ gcc/cp/pt.c (working copy)
@@ -846,7 +846,7 @@ get_specialization_constraints (tree typ
// that type. If it is an explicit specialization, return null since
// non-templates cannot be constrained.
if (tree d = get_specializing_template_decl (type))
-return DECL_CONSTRAINTS (d);
+return get_constraints (d);
else
return NULL_TREE;
}
@@ -4147,10 +4147,10 @@ build_template_decl (tree decl, tree par
{
tree tmpl = build_lang_decl (TEMPLATE_DECL, DECL_NAME (decl), NULL_TREE);
DECL_TEMPLATE_PARMS (tmpl) = parms;
- DECL_CONSTRAINTS (tmpl) = constr;
DECL_CONTEXT (tmpl) = DECL_CONTEXT (decl);
DECL_SOURCE_LOCATION (tmpl) = DECL_SOURCE_LOCATION (decl);
DECL_MEMBER_TEMPLATE_P (tmpl) = member_template_p;
+ set_constraints (tmpl, constr);
return tmpl;
}
@@ -4319,7 +4319,7 @@ process_partial_specialization (tree dec
arguments but different constraints. */
tree main_type = TREE_TYPE (maintmpl);
tree main_args = INNERMOST_TEMPLATE_ARGS (CLASSTYPE_TI_ARGS (main_type));
- tree main_constr = DECL_CONSTRAINTS (maintmpl);
+ tree main_constr = get_constraints (maintmpl);
if (comp_template_args (inner_args, main_args)
equivalent_constraints (current_template_reqs, main_constr))
error (partial specialization %qT does not specialize any
@@ -5229,13 +5229,13 @@ add_inherited_template_parms (tree fn, t
// If the inherited constructor was constrained, then also
// propagate the constraints to the new declaration by
// rewriting them in terms of the local template parameters.
- tree cons = DECL_CONSTRAINTS (inherited);
+ tree cons = get_constraints (inherited);
if (cons)
{
++processing_template_decl;
tree reqs = instantiate_requirements (CI_REQUIREMENTS (cons), args);
--processing_template_decl;
- DECL_CONSTRAINTS (tmpl) = make_constraints (reqs);
+ set_constraints (tmpl, make_constraints (reqs));
}
DECL_TEMPLATE_INFO (fn) = build_template_info (tmpl, args);
@@ -5354,7 +5354,7 @@ redeclare_class_template (tree type, tre
}
// Cannot redeclare a class template with a different set of constraints.
- if (!equivalent_constraints (DECL_CONSTRAINTS (tmpl), cons))
+ if (!equivalent_constraints (get_constraints (tmpl), cons))
{
error_at (input_location, redeclaration %q#D with different
constraints, tmpl);
@@ -6586,8 +6586,8 @@ is_compatible_template_arg (tree parm, t
Re: [fortran,patch] Binding label can be any initialisation expression
ping*2 ping To reinforce the message in my earlier email: we can fine-tune the list of allowed characters in identifiers later, but I’d like to get this patch in already (so it gets large exposure before the 4.10 release). FX Binding label can be any initialisation expression. Well, only scalar character of the default kind, but still… This patch achieves this goal by following the obvious plan, which has not changed since I wrote it in PR 36275 in 2008 :) The custom matcher for binding label, in gfc_match_bind_c(), is removed and the generic matcher gfc_match_init_expr() is called, followed by checks that the expression obtained fulfills the constraints of a C identifier. So, now is the time to think about PR 38839 (what characters to allow as a binding label): right now, I allow alphadecimals, underscore and dollar. From the PR comments, it seems like @ and ` might be also allowed for universal-character names, but they are not supported by GCC on platforms I tested right now. Let me know what you think, but I don’t think we should worry to much about it. Bootstrapped and regtested on x86_64-apple-darwin13, comes with testcases. OK to commit? FX bind_c.diff Description: Binary data bind_c.ChangeLog Description: Binary data
Re: [RFC PATCH] -fsanitize=nonnull and -fsanitize=returns-nonnull support
On Sat, Jun 28, 2014 at 01:29:47PM +0200, Gerald Pfeifer wrote: On Fri, 27 Jun 2014, Jakub Jelinek wrote: This patch implements sanitization for nonnull and returns_nonnull attributes. No documentation patch? I'll add it soon. Also, should this be documented in gcc-4.10/changes.html? We'll mention all the new undefined behavior sanitizers, there have been many added already post 4.9.0. As GCC 4.9.0+ now aggressively optimizes based on these attributes and we've seen several issues in real world apps, I think this is really needed. Nice! Is this worth pushing into GCC 4.9.1 as well? This one is the only one that is actually hard to push into 4.9.x, as it requires new libubsan entrypoints. Jakub
Re: [v3] Tighten some config/abi/pre/gnu.ver patterns
Hi, On 06/08/2014 06:02 PM, Paolo Carlini wrote: Hi, as discussed, tested x86_64-linux multilib, committed. for now I reverted this. Things get too complicated when we have to conditionally export some symbols depending on the target (see libstdc++/61536). Thanks, Paolo.
Re: [v3] Tighten some config/abi/pre/gnu.ver patterns
On Sat, 28 Jun 2014, Paolo Carlini wrote: for now I reverted this. Things get too complicated when we have to conditionally export some symbols depending on the target (see libstdc++/61536). A single extra symbol (for the unusual -O0 compilation) is better than 200 before the patch though. I think the patch is a good thing (also for future-proofing) even if one or two extra symbols remain because they are hard to remove. Also, none of this is urgent, it can all wait several weeks if you are busy. -- Marc Glisse
Re: [PATCH] Implement -fsanitize=bounds and internal calls in FEs
On Fri, 20 Jun 2014, Marek Polacek wrote: +@item -fsanitize=bounds +@opindex fsanitize=bounds + +This option enables instrumentation of array bounds. Various out of bounds +accesses are detected. Flexible array members are not instrumented, as well +as initializers of variables with static storage. Can you make this Flexible array members and initializers... (or ...as well as...)? The current wording confused me a bit at first. And I believe there should be no empty line after @opindex. Gerald
[c++-concepts] Compiler options/bootstrap
This patch restores C++98 as the default language in this branch and disables -fconcepts by default. Using -std=c++1z will enable -fconcepts. I wanted to give an error if -fconcepts is used with dialect = cxx11, but I didn't find the right place to put the check. This also adds a new format specifier (Z) to the cxxdiag flags. That warning was turning into an error in the bootstrap build. FYI: The bootstrap builds cleanly for me now. Committed in r212105. 2014-06-28 Andrew Sutton andrew.n.sut...@gmail.com * gcc/c-family/c.opt (flag_concepts): Don't enable by default. * gcc/c-family/c-opts.c (set_std_cxx1z): Enable concepts if -std=cxx1z is selected. * gcc/c-family/c-format.c (gcc_cxxdia): Add Z as format specifier. * gcc/cp/c-common.c (cxx_dialect): Make -std=c++98 the default language again. * gcc/cp/lex.c (cxx_init): Don't set flag_concepts explicitly. * gcc/testsuite/g++.dg/concepts/*.C: Updat build flags. Andrew
Re: [Patch, PR 61061] Add state limit for regex NFA
On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely jwak...@redhat.com wrote: I wonder if it would be better to use a sorted vectorpair_StateIdT,_StateIdT instead of a map, for improved memory footprint and runtime speed, but that can be changed later. In this case, we keep inserting (__m[__u] = __id) and looking up (__m.count()) the container in a crossover order, which required a map to minimize both's complexity. -- Regards, Tim Shen
[wwwdocs,Java] Remove five obsolete entries from java/faq.html
REQUEST FOR HELP: It would be great if one of the Java experts could advise which further entries to remove or adjust. I volunteer to make the actual changes, if that helps. Now to this patch: Working on the web pages in general, I noticed a number of obsolete FAQ entries in our Java FAQ. Some of them are (better) covered in our general documentation, some of them refer to really old versions of GCC. For example, x86-64 is not included in the supported platforms mentioned, one entry talks about version before 3.0,... Applied. Gerald 2014-06-28 Gerald Pfeifer ger...@pfeifer.com * faq.html: Remove five obsolete entries. Index: faq.html === RCS file: /cvs/gcc/wwwdocs/htdocs/java/faq.html,v retrieving revision 1.72 diff -u -r1.72 faq.html --- faq.html28 Jun 2014 07:45:14 - 1.72 +++ faq.html28 Jun 2014 17:09:44 - @@ -11,8 +11,6 @@ lia href=#1_0General Questions/a ol lia href=#1_1What license is used for libgcj?/a/li -lia href=#1_3How can I contribute to libgcj/a/li -lia href=#1_5Will gcj and libgcj work on my machine?/a/li lia href=#1_6How can I debug my Java program?/a/li lia href=#1_7Can I interface byte-compiled and native java code?/a/li /ol @@ -32,12 +30,6 @@ lia href=#2_8What features of the Java language are/arn't supported/a/li /ol /li -lia href=#3_0Build Issues/a - ol -lia href=#3_1I need something more recent than the last release; how - should I build it?/a/li - /ol -/li lia href=#4_0Gcj Compile/Link Questions/a ol lia href=#4_1Why do I get ttundefined reference to `main'/tt @@ -48,8 +40,6 @@ lia href=#4_4Where does GCJ look for files? /a/li lia href=#4_5How does gcj resolve wether to compile .class or .java files? /a/li -lia href=#4_6I'm getting link errors!/a/li -lia href=#4_7I'm getting 'undefined symbol: __dso_handle'/a/li /ol /li lia href=#5_0Runtime Questions/a @@ -87,28 +77,6 @@ /dl hr / - h3a name=1_31.3 How can I contribute to libgcj?/a/h3 - dl -dd - You can send simple bug fixes in as patches. Please follow the a href=http://gcc.gnu.org/contribute.html;GCC - guidelines for submitting patches/a. For more complex changes, you - must sign copyright over to the Free Software Foundation. See the a href=contrib.htmlcontribution/a - page for details. -/dd - /dl - - hr / - h3a name=1_51.5 Will gcj and libgcj work on my machine?/a/h3 - dl -dd - Gcj and libgcj are known to work more or less with IA-32 and - SPARC Solaris, Tru64 Unix, as well as IA-32, IA-64, Alpha, and PowerPC - Linux. They might work on other systems. Generally speaking, porting to a new - system should not be hard. This would be a good way to volunteer. -/dd - /dl - - hr / h3a name=1_61.6 How can I debug my Java program?/a/h3 dl dd @@ -267,15 +235,6 @@ /dd /dl - h2a name=3_0Build Issues/a/h2 - - h3a name=3_13.1 I need something more recent than the last release. - How should I build it?/a/h3 - dl -dd - Please read a href=build-snapshot.htmlhere/a. -/dd - /dl h2a name=4_0Gcj Compile/Link Questions/a/h2 @@ -352,36 +311,6 @@ /dd /dl - hr / - h3a name=4_64.6 I'm getting link errors/a/h3 - - dl -dd - pIf you get errors at link time that refer to - 'undefined reference to `java::lang::Object type_info function', - verify that you have compiled any CNI C++ files with the - -fno-rtti option. This is only required for versions of GCJ earlier - than 3.0./p -/dd - /dl - - hr / - h3a name=4_74.7 I'm getting 'undefined symbol: __dso_handle'/a/h3 - dl -dd - pSome versions of the GNU linker have broken support for the '.hidden' - directive, which results in problems with shared libraries built with - recent versions of gcc. /p - - pThere are three solutions: /p - ul -lidowngrade to binutils that don't support .hidden at all,/li -liupgrade to a recent binutils, or/li -liundef the HAVE_GAS_HIDDEN definition in gcc's auto-host.h -(and rebuild gcc)./li - /ul -/dd - /dl h2a name=5_0Runtime Questions/a/h2
Fix representation of gcov_info_type
Hi,
This is first bug noticed by the type consistency checks I added.
gcov_info_type is a structure that contains function pointer to itself. While
building it we first build a structure w/o size and fields, then we build a
function type that produces a qualified variant of the structure (not sure why
that legwork is needed). Then we add fields via finish_builtin_struct.
It sets the fields to structure but not its variant and then does layout_type
that actually copies size to all variants. So we end up with TYPE_COMPLETE_P
variant
that has size but no fields. This is quite obviously wrong.
Fixed thus. Bootstrapped, lto-bootstrapped and regtested x86_64-linux, comitted.
* stor-layout.c (finish_builtin_struct): Copy fields into
the variants.
Index: stor-layout.c
===
--- stor-layout.c (revision 212098)
+++ stor-layout.c (working copy)
@@ -2065,7 +2065,7 @@ void
finish_builtin_struct (tree type, const char *name, tree fields,
tree align_type)
{
- tree tail, next;
+ tree tail, next, variant;
for (tail = NULL_TREE; fields; tail = fields, fields = next)
{
@@ -2074,6 +2074,10 @@ finish_builtin_struct (tree type, const
DECL_CHAIN (fields) = tail;
}
TYPE_FIELDS (type) = tail;
+ for (variant = TYPE_MAIN_VARIANT (type);
+ variant != 0;
+ variant = TYPE_NEXT_VARIANT (variant))
+TYPE_FIELDS (variant) = tail;
if (align_type)
{
Fix ipa-devirt WRT type variants
Hi,
this is another bug noticed. Here ipa-devirt attempts to merge binfos of two
representations
of the same ODR type, but forgets about variants.
I also noticed that using variant instead of the type may end up in incomplete
type and/or
we may waste polymorphic call target cache by duplicated entries. I made the
contextes to
be always main variants thus.
Bootstrapped, lto-bootstrapped/regtested x86_64-linux, comitted.
* ipa-devirt.c (set_type_binfo): New function.
(add_type_duplicate): Use it.
(get_odr_type): Sanity check that binfos points to main variants.
(get_class_context): Be sure the context's outer_type is main variant.
(contains_type_p): Walk main variant.
(get_polymorphic_call_info_for_decl): Set outer_type to be main variant.
(get_polymorphic_call_info): Likewise.
(possible_polymorphic_call_targets): Sanity check that we operate on
main
variant.
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 212098)
+++ ipa-devirt.c(working copy)
@@ -334,6 +334,17 @@ static odr_hash_type *odr_hash;
static GTY(()) vec odr_type, va_gc *odr_types_ptr;
#define odr_types (*odr_types_ptr)
+/* Set TYPE_BINFO of TYPE and its variants to BINFO. */
+void
+set_type_binfo (tree type, tree binfo)
+{
+ for (; type; type = TYPE_NEXT_VARIANT (type))
+if (COMPLETE_TYPE_P (type))
+ TYPE_BINFO (type) = binfo;
+else
+ gcc_assert (!TYPE_BINFO (type));
+}
+
/* TYPE is equivalent to VAL by ODR, but its tree representation differs
from VAL-type. This may happen in LTO where tree merging did not merge
all variants of the same type. It may or may not mean the ODR violation.
@@ -446,16 +457,17 @@ add_type_duplicate (odr_type val, tree t
{
unsigned int i;
- TYPE_BINFO (val-type) = TYPE_BINFO (type);
+ set_type_binfo (val-type, TYPE_BINFO (type));
for (i = 0; i val-types-length (); i++)
{
if (TYPE_BINFO ((*val-types)[i])
== master_binfo)
- TYPE_BINFO ((*val-types)[i]) = TYPE_BINFO (type);
+ set_type_binfo ((*val-types)[i], TYPE_BINFO (type));
}
+ BINFO_TYPE (TYPE_BINFO (type)) = val-type;
}
else
- TYPE_BINFO (type) = master_binfo;
+ set_type_binfo (type, master_binfo);
}
}
}
@@ -495,6 +507,7 @@ get_odr_type (tree type, bool insert)
val = ggc_cleared_allocodr_type_d ();
val-type = type;
+ gcc_assert (BINFO_TYPE (TYPE_BINFO (val-type)) = type);
val-bases = vNULL;
val-derived_types = vNULL;
val-anonymous_namespace = type_in_anonymous_namespace_p (type);
@@ -1102,7 +1115,7 @@ get_class_context (ipa_polymorphic_call_
if (!fld)
goto give_up;
- type = TREE_TYPE (fld);
+ type = TYPE_MAIN_VARIANT (TREE_TYPE (fld));
offset -= pos;
/* DECL_ARTIFICIAL represents a basetype. */
if (!DECL_ARTIFICIAL (fld))
@@ -1116,7 +1129,7 @@ get_class_context (ipa_polymorphic_call_
}
else if (TREE_CODE (type) == ARRAY_TYPE)
{
- tree subtype = TREE_TYPE (type);
+ tree subtype = TYPE_MAIN_VARIANT (TREE_TYPE (type));
/* Give up if we don't know array size. */
if (!tree_fits_shwi_p (TYPE_SIZE (subtype))
@@ -1159,7 +1172,8 @@ static bool
contains_type_p (tree outer_type, HOST_WIDE_INT offset,
tree otr_type)
{
- ipa_polymorphic_call_context context = {offset, outer_type,
+ ipa_polymorphic_call_context context = {offset,
+ TYPE_MAIN_VARIANT (outer_type),
false, true};
return get_class_context (context, otr_type);
}
@@ -1272,7 +1286,7 @@ get_polymorphic_call_info_for_decl (ipa_
{
gcc_assert (DECL_P (base));
- context-outer_type = TREE_TYPE (base);
+ context-outer_type = TYPE_MAIN_VARIANT (TREE_TYPE (base));
context-offset = offset;
/* Make very conservative assumption that all objects
may be in construction.
@@ -1329,7 +1343,7 @@ get_polymorphic_call_info (tree fndecl,
*otr_token = tree_to_uhwi (OBJ_TYPE_REF_TOKEN (ref));
/* Set up basic info in case we find nothing interesting in the analysis. */
- context-outer_type = *otr_type;
+ context-outer_type = TYPE_MAIN_VARIANT (*otr_type);
context-offset = 0;
base_pointer = OBJ_TYPE_REF_OBJECT (ref);
context-maybe_derived_type = true;
@@ -1415,7 +1429,8 @@ get_polymorphic_call_info (tree fndecl,
if (TREE_CODE (TREE_TYPE (fndecl)) == METHOD_TYPE
SSA_NAME_VAR (base_pointer) == DECL_ARGUMENTS (fndecl))
{
- context-outer_type = TREE_TYPE (TREE_TYPE (base_pointer));
+ context-outer_type
+= TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE
ipa-prop WRT type variants
Hi,
this patch does similar change to ipa-prop as I did to ipa-devirt; it makes
sure that
all the types in jump functions are main variants that reduces diversity in LTO
streaming
and makes us less likely to hit incomplete types.
It also makes sure that the type change detection works on main variant because
pointer
equality is used there for types.
Bootstrapped/regtested x86_64-linux, comitted.
* ipa-prop.c (ipa_set_jf_known_type): Record always the main variant
of the type.
(ipa_set_ancestor_jf) Likewise.
(check_stmt_for_type_change): Check that we work on main variant.
(detect_type_change): Look into main variant.
(compute_known_type_jump_func): Check that main variant has BINFO.
Index: ipa-prop.c
===
--- ipa-prop.c (revision 212098)
+++ ipa-prop.c (working copy)
@@ -438,6 +438,11 @@ static void
ipa_set_jf_known_type (struct ipa_jump_func *jfunc, HOST_WIDE_INT offset,
tree base_type, tree component_type)
{
+ /* Recording and propagating main variants increases change that types
+ will match. */
+ base_type = TYPE_MAIN_VARIANT (base_type);
+ component_type = TYPE_MAIN_VARIANT (component_type);
+
gcc_assert (TREE_CODE (component_type) == RECORD_TYPE
TYPE_BINFO (component_type));
if (!flag_devirtualize)
@@ -529,6 +534,8 @@ ipa_set_ancestor_jf (struct ipa_jump_fun
{
if (!flag_devirtualize)
type_preserved = false;
+ if (type)
+type = TYPE_MAIN_VARIANT (type);
gcc_assert (!type_preserved
|| (TREE_CODE (type) == RECORD_TYPE
TYPE_BINFO (type)
@@ -712,7 +720,9 @@ check_stmt_for_type_change (ao_ref *ao A
if (stmt_may_be_vtbl_ptr_store (stmt))
{
tree type;
+
type = extr_type_from_vtbl_ptr_store (stmt, tci);
+ gcc_assert (!type || TYPE_MAIN_VARIANT (type) == type);
if (tci-type_maybe_changed
type != tci-known_current_type)
tci-multiple_types_encountered = true;
@@ -749,10 +759,12 @@ detect_type_change (tree arg, tree base,
/* Be sure expected_type is polymorphic. */
|| !comp_type
|| TREE_CODE (comp_type) != RECORD_TYPE
- || !TYPE_BINFO (comp_type)
- || !BINFO_VTABLE (TYPE_BINFO (comp_type)))
+ || !TYPE_BINFO (TYPE_MAIN_VARIANT (comp_type))
+ || !BINFO_VTABLE (TYPE_BINFO (TYPE_MAIN_VARIANT (comp_type
return true;
+ comp_type = TYPE_MAIN_VARIANT (comp_type);
+
/* C++ methods are not allowed to change THIS pointer unless they
are constructors or destructors. */
if (TREE_CODE(base) == MEM_REF
@@ -1408,8 +1420,8 @@ compute_known_type_jump_func (tree op, s
/* Be sure expected_type is polymorphic. */
|| !expected_type
|| TREE_CODE (expected_type) != RECORD_TYPE
- || !TYPE_BINFO (expected_type)
- || !BINFO_VTABLE (TYPE_BINFO (expected_type)))
+ || !TYPE_BINFO (TYPE_MAIN_VARIANT (expected_type))
+ || !BINFO_VTABLE (TYPE_BINFO (TYPE_MAIN_VARIANT (expected_type
return;
op = TREE_OPERAND (op, 0);
Re: [commit] Fix ABI fallout (Re: wide-int, rs6000)
On Jun 28, 2014, at 3:31 AM, Ulrich Weigand uweig...@de.ibm.com wrote: Mike Stump wrote: (rs6000_aggregate_candidate): Use wide-int interfaces. [snip] -/* Can't handle incomplete types. */ -if (!COMPLETE_TYPE_P (type)) - return -1; +/* Can't handle incomplete types nor sizes that are not + fixed. */ +if (!COMPLETE_TYPE_P (type) +|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST) Ouch, sorry. At least 8 eyes missed it. Does this fix the -m32 issue? I've checked in the following patch as obvious. Thanks.
Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris
On 06/26/14 02:18, Rainer Orth wrote: Ok for mainline? Could you please reformat the c_fix_arg's and test-text to be here strings a la: c_fix_arg = - _EOS_ #undef signbit #define signbit(x) (sizeof(x) == sizeof(float) \ \ ? __builtin_signbitf(x) \ \ : sizeof(x) == sizeof(long double) \ \? __builtin_signbitl(x) \ \: __builtin_signbit(x)); _EOS_; I changed the here string thingy to eat that tab-backslash and leave the rest of the tabs a few years ago. That is considerably more readable than: c_fix_arg = #undef\tsignbit\n #define\tsignbit(x)\t(sizeof(x) == sizeof(float) \\\n \t\t\t ? __builtin_signbitf(x) \\\n \t\t\t : sizeof(x) == sizeof(long double) \\\n \t\t\t ? __builtin_signbitl(x) \\\n \t\t\t : __builtin_signbit(x)); and the other two are worse. Thank you!
[objc++] Fix code setting binfo
Hi,
this patch fixes similar bug as in ipa-devirt. objc_xref_basetypes is used when
building obj-C++ structure. The structure always contains self-reference that
builds type variant early. The variant's binfo is one assigned by
C++ FE's version of xref_basetypes, while the main variant gets overwritten
here. Fixed thus.
Honza
Bootstrapped/regtested x86_64-linux, comitted.
* objc-act.c (objc_xref_basetypes): Set TYPE_BINFO of type variants,
too.
Index: objc-act.c
===
--- objc-act.c (revision 212098)
+++ objc-act.c (working copy)
@@ -2695,12 +2695,16 @@ objc_copy_binfo (tree binfo)
static void
objc_xref_basetypes (tree ref, tree basetype)
{
+ tree variant;
tree binfo = make_tree_binfo (basetype ? 1 : 0);
-
TYPE_BINFO (ref) = binfo;
BINFO_OFFSET (binfo) = size_zero_node;
BINFO_TYPE (binfo) = ref;
+ gcc_assert (TYPE_MAIN_VARIANT (ref) == ref);
+ for (variant = ref; variant; variant = TYPE_NEXT_VARIANT (variant))
+TYPE_BINFO (variant) = binfo;
+
if (basetype)
{
tree base_binfo = objc_copy_binfo (TYPE_BINFO (basetype));
[wwwdocs] Migrate http://gcc.gnu.org/bugzilla/buglist.cgi to https
Applied. Richi, Jakub, I noticed that you seem to have stopped including those with GCC 4.7 and later. Any particular reason? It appears useful to me. Gerald Index: gcc-3.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/changes.html,v retrieving revision 1.60 diff -u -r1.60 changes.html --- gcc-3.3/changes.html28 Jun 2014 07:45:11 - 1.60 +++ gcc-3.3/changes.html28 Jun 2014 19:51:09 - @@ -1277,7 +1277,7 @@ h2a name=3.3.4GCC 3.3.4/a/h2 pThis is the a -href=http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.4;list +href=https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.4;list of problem reports (PRs)/a from GCC's bug tracking system that are known to be fixed in the 3.3.4 release. This list might not be complete (that is, it is possible that some PRs that have been fixed @@ -1288,7 +1288,7 @@ h2a name=3.3.5GCC 3.3.5/a/h2 pThis is the a -href=http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.5;list +href=https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.5;list of problem reports (PRs)/a from GCC's bug tracking system that are known to be fixed in the 3.3.5 release. This list might not be complete (that is, it is possible that some PRs that have been fixed @@ -1299,7 +1299,7 @@ h2a name=3.3.6GCC 3.3.6/a/h2 pThis is the a -href=http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.6;list +href=https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVEDamp;resolution=FIXEDamp;target_milestone=3.3.6;list of problem reports (PRs)/a from GCC's bug tracking system that are known to be fixed in the 3.3.6 release. This list might not be complete (that is, it is possible that some PRs that have been fixed Index: gcc-3.3/gcj-status.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/gcj-status.html,v retrieving revision 1.7 diff -u -r1.7 gcj-status.html --- gcc-3.3/gcj-status.html 21 Oct 2012 13:12:19 - 1.7 +++ gcc-3.3/gcj-status.html 28 Jun 2014 19:51:09 - @@ -12,7 +12,7 @@ pWe are tracking all bugs in Bugzilla. Any bugs that we want to fix for the 3.3 release will be marked emhigh/em priority (a -href=http://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=allwordssubstamp;component=javaamp;long_desc_type=substringamp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;bug_severity=criticalamp;emailassigned_to1=1amp;emailtype1=substringamp;email1=amp;emailassigned_to2=1amp;emailreporter2=1amp;emailcc2=1amp;emailtype2=substringamp;bugidtype=includeamp;cmdtype=doitamp;order=Bug+Number;see +href=https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=allwordssubstamp;component=javaamp;long_desc_type=substringamp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;bug_severity=criticalamp;emailassigned_to1=1amp;emailtype1=substringamp;email1=amp;emailassigned_to2=1amp;emailreporter2=1amp;emailcc2=1amp;emailtype2=substringamp;bugidtype=includeamp;cmdtype=doitamp;order=Bug+Number;see list/a)./p h2 Packages /h2 Index: gcc-3.4/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.4/changes.html,v retrieving revision 1.161 diff -u -r1.161 changes.html --- gcc-3.4/changes.html28 Jun 2014 07:45:11 - 1.161 +++ gcc-3.4/changes.html28 Jun 2014 19:51:10 - @@ -1225,7 +1225,7 @@ A vast number of bugs have been fixed in 3.4.0, too many to publish a complete list here. a -href=http://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexpamp;short_desc=%5C%5B3%5C.4.*%5BRr%5Degressionamp;target_milestone=3.4.0amp;bug_status=RESOLVEDamp;resolution=FIXED;Follow +href=https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexpamp;short_desc=%5C%5B3%5C.4.*%5BRr%5Degressionamp;target_milestone=3.4.0amp;bug_status=RESOLVEDamp;resolution=FIXED;Follow this link/a to query the Bugzilla database for the list of over 900 bugs fixed in 3.4.0. This is the list of all bugs marked as resolved and fixed in 3.4.0 that
[C++ Patch] PR 51400
Hi,
this issue manifests itself as an ICE on the gcc_assert toward the end
of start_decl:
if (VAR_P (decl)
DECL_NAMESPACE_SCOPE_P (decl) !TREE_PUBLIC (decl)
!was_public
!DECL_THIS_STATIC (decl) !DECL_ARTIFICIAL (decl))
{
/* This is a const variable with implicit 'static'. Set
DECL_THIS_STATIC so we can tell it from variables that are
!TREE_PUBLIC because of the anonymous namespace. */
gcc_assert (CP_TYPE_CONST_P (TREE_TYPE (decl)) || errorcount);
DECL_THIS_STATIC (decl) = 1;
}
and the reason seems clear to me: both handle_noreturn_attribute and
handle_const_attribute call build_pointer_type and discard the
TYPE_QUALS on the original POINTER_TYPE. That seems obviously incorrect.
The below fixes the ICE and passes testing.
Thanks!
Paolo.
/
/c-family
2014-06-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/51400
* c-common.c (handle_noreturn_attribute, handle_const_attribute):
Do not discard TYPE_QUALS of type.
/testsuite
2014-06-28 Paolo Carlini paolo.carl...@oracle.com
PR c++/51400
* g++.dg/cpp0x/constexpr-attribute3.C: New.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 212104)
+++ c-family/c-common.c (working copy)
@@ -6575,9 +6575,11 @@ handle_noreturn_attribute (tree *node, tree name,
else if (TREE_CODE (type) == POINTER_TYPE
TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE)
TREE_TYPE (*node)
- = build_pointer_type
- (build_type_variant (TREE_TYPE (type),
-TYPE_READONLY (TREE_TYPE (type)), 1));
+ = (build_qualified_type
+(build_pointer_type
+ (build_type_variant (TREE_TYPE (type),
+ TYPE_READONLY (TREE_TYPE (type)), 1)),
+ TYPE_QUALS (type)));
else
{
warning (OPT_Wattributes, %qE attribute ignored, name);
@@ -6988,9 +6990,11 @@ handle_const_attribute (tree *node, tree name, tre
else if (TREE_CODE (type) == POINTER_TYPE
TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE)
TREE_TYPE (*node)
- = build_pointer_type
- (build_type_variant (TREE_TYPE (type), 1,
-TREE_THIS_VOLATILE (TREE_TYPE (type;
+ = (build_qualified_type
+(build_pointer_type
+ (build_type_variant (TREE_TYPE (type), 1,
+ TREE_THIS_VOLATILE (TREE_TYPE (type,
+ TYPE_QUALS (type)));
else
{
warning (OPT_Wattributes, %qE attribute ignored, name);
Index: testsuite/g++.dg/cpp0x/constexpr-attribute3.C
===
--- testsuite/g++.dg/cpp0x/constexpr-attribute3.C (revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-attribute3.C (working copy)
@@ -0,0 +1,5 @@
+// PR c++/51400
+// { dg-do compile { target c++11 } }
+
+constexpr int (*f)() __attribute__((noreturn)) = 0;
+constexpr int (*g)() __attribute__((const)) = 0;
[PATCH PR C++/58781, 59867, 60249 ] Various user-defined string literal issues involving character encodings, dropped bytes, semi-infinite loops
Please disregard previous email Re: [Bug c++/60249] [c++11] Compiler
goes into semi-infinite loop with wrong usage of user defined string
literals
A new patch with tweaked testcase is attached. Sorry for the noise.
I finally fixed these weird user-defined string literal bugs.
I was messing with cp_token stream unnecessarily and poorly. Changed by
using a tree in cp_parser_userdef_string_literal.
PR C++/58781 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58781 -
Unicode strings broken in a strange way
PR C++/59867 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 -
Template string literal loses first symbol
PR C++/60249 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249 -
Compiler goes into semi-infinite loop with wrong usage of user defined
string literals
Plus I fixed an misleading error message for string literal operator
templates (not available in C++11).
Built and tested clean on x86_64-linux.
OK?
I would also like to apply this to 4.9.
Ed Smith-Rowland
cp/
2014-06-28 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58781
PR c++/60249
PR c++/59867
* parser.c (cp_parser_userdef_string_literal()): Take a tree
not a cp_token*. (cp_parser_string_literal(): Don't hack
the token stream!
testsuite/
2014-06-28 Edward Smith-Rowland 3dw...@verizon.net
PR c++/58781
PR c++/60249
PR c++/59867
* testsuite/g++.dg/cpp0x/pr58781.C: New.
* testsuite/g++.dg/cpp0x/pr60249.C: New.
* testsuite/g++.dg/cpp1y/pr59867.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 212100)
+++ cp/parser.c (working copy)
@@ -1899,7 +1899,7 @@
static tree cp_parser_userdef_char_literal
(cp_parser *);
static tree cp_parser_userdef_string_literal
- (cp_token *);
+ (tree);
static tree cp_parser_userdef_numeric_literal
(cp_parser *);
@@ -3721,8 +3721,7 @@
{
tree literal = build_userdef_literal (suffix_id, value,
OT_NONE, NULL_TREE);
- tok-u.value = literal;
- return cp_parser_userdef_string_literal (tok);
+ value = cp_parser_userdef_string_literal (literal);
}
}
else
@@ -3970,9 +3969,8 @@
as arguments. */
static tree
-cp_parser_userdef_string_literal (cp_token *token)
+cp_parser_userdef_string_literal (tree literal)
{
- tree literal = token-u.value;
tree suffix_id = USERDEF_LITERAL_SUFFIX_ID (literal);
tree name = cp_literal_operator_id (IDENTIFIER_POINTER (suffix_id));
tree value = USERDEF_LITERAL_VALUE (literal);
@@ -23202,10 +23200,17 @@
ok = false;
}
if (!ok)
- error (literal operator template %qD has invalid parameter list.
-Expected non-type template argument pack char...
- or typename CharT, CharT...,
- decl);
+ {
+ if (cxx_dialect = cxx1y)
+ error (literal operator template %qD has invalid parameter list.
+Expected non-type template argument pack char...
+ or typename CharT, CharT...,
+ decl);
+ else
+ error (literal operator template %qD has invalid parameter list.
+Expected non-type template argument pack char...,
+ decl);
+ }
}
/* Register member declarations. */
if (member_p !friend_p decl !DECL_CLASS_TEMPLATE_P (decl))
Index: testsuite/g++.dg/cpp0x/pr58781.C
===
--- testsuite/g++.dg/cpp0x/pr58781.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr58781.C(working copy)
@@ -0,0 +1,18 @@
+// PR c++/58781
+// { dg-do compile { target c++11 } }
+
+#include cstddef
+
+int
+operator_s(const char32_t *a, size_t b)
+{
+ return 0;
+}
+
+int
+f()
+{
+ using a = decltype(U\x1181_s);
+ using b = decltype(U\x8111_s);
+ using c = decltype(U \x1181_s);
+}
Index: testsuite/g++.dg/cpp0x/pr60249.C
===
--- testsuite/g++.dg/cpp0x/pr60249.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr60249.C(working copy)
@@ -0,0 +1,6 @@
+// PR c++/60249
+// { dg-do compile { target c++11 } }
+
+decltype(_) x; // { dg-error unable to find string literal operator }
+
+// { dg-error invalid type in declaration before invalid { target *-*-* }
4 }
Index: testsuite/g++.dg/cpp1y/pr59867.C
===
--- testsuite/g++.dg/cpp1y/pr59867.C(revision 0)
+++ testsuite/g++.dg/cpp1y/pr59867.C(working copy)
@@ -0,0 +1,52 @@
+// PR c++/59867
+// { dg-do compile { target c++14 } }
+
+#include iostream
+using namespace std;
+
+// constant
+templatetypename T, T x
+ struct meta_value
+ {
+typedef meta_value type;
+typedef T value_type;
+static const T value = x;
+ };
+
+// array
+templatetypename T, T... data
+
Re: [PATCH] Fix gennews
On Thu, 12 Jun 2014, Richard Biener wrote: It seems the https transition broke refering to permanently moved URL gcc-3.0/gcc-3.0.html (I get a certificate error or some such), breaking gennews and thus gcc_release. Fixed like below which makes gennews succeed. Committed to the 4.7 branch. Richard. 2014-06-12 Richard Biener rguent...@suse.de * gennews: Use gcc-3.0/index.html. I also applied this to trunk and the GCC 4.9 branch. Gerald
update address taken: don't drop clobbers
Hello,
we currently drop clobbers on variables whose address is not taken
anymore. However, rewrite_stmt has code to replace them with an SSA_NAME
with a default definition (an uninitialized variable), and I believe
rewrite_update_stmt should do the same. This allows us to warn sometimes
(see testcase), but during the debugging I also noticed several places
where it allowed CCP to simplify further PHIs, so this is also an
optimization.
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed bootstrap+testsuite on all
languages except for ada. Indeed, the compiler wanted to coalesce several
SSA_NAMEs, including those new ones, in out-of-ssa, but couldn't. There
are abnormal PHIs involved. Maybe it shouldn't have insisted on coalescing
an undefined ssa_name, maybe something should have prevented us from
reaching such a situation, but creating a new variable was the simplest
workaround.
Some things could be done to improve the error message in uninit:
- getting the location of the variable,
- differenciating uninitialized from clobbered,
but that can come later.
Bootstrap+testsuite (all,obj-c++,ada,go) on x86_64-unknown-linux-gnu.
2014-06-30 Marc Glisse marc.gli...@inria.fr
PR tree-optimization/60770
gcc/
* tree-ssa.c (execute_update_addresses_taken): Don't drop clobbers.
* tree-into-ssa.c (maybe_register_def): Replace clobbers with a
default definition.
gcc/testsuite/
* gcc.dg/tree-ssa/pr60770-1.c: New file.
--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c (working copy)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options -O -Wall } */
+
+int f(int n){
+ int*p;
+ {
+int yyy=n;
+p=yyy;
+ }
+ return *p; /* { dg-warning yyy } */
+}
Index: gcc/tree-into-ssa.c
===
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF is a naked symbol that needs renaming, create a new
name for it. */
if (marked_for_renaming (sym))
{
if (DECL_P (def))
{
- tree tracked_var;
-
- def = make_ssa_name (def, stmt);
+ if (gimple_clobber_p (stmt) is_gimple_reg (sym))
+ {
+ /* Replace clobber stmts with a default def. Create a new
+variable so we don't later think we must coalesce, which would
+fail with some ada abnormal PHIs. Still, we try to keep a
+similar name so error messages make sense. */
+ unlink_stmt_vdef (stmt);
+ gsi_replace (gsi, gimple_build_nop (), true);
+ tree id = DECL_NAME (sym);
+ const char* name = id ? IDENTIFIER_POINTER (id) : 0;
+ tree newvar = create_tmp_var (TREE_TYPE (sym), name);
+ def = get_or_create_ssa_default_def (cfun, newvar);
+ }
+ else
+ def = make_ssa_name (def, stmt);
SET_DEF (def_p, def);
- tracked_var = target_for_debug_bind (sym);
+ tree tracked_var = target_for_debug_bind (sym);
if (tracked_var)
{
gimple note = gimple_build_debug_bind (tracked_var, def, stmt);
/* If stmt ends the bb, insert the debug stmt on the single
non-EH edge from the stmt. */
if (gsi_one_before_end_p (gsi) stmt_ends_bb_p (stmt))
{
basic_block bb = gsi_bb (gsi);
edge_iterator ei;
edge e, ef = NULL;
Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c (revision 212109)
+++ gcc/tree-ssa.c (working copy)
@@ -1607,32 +1607,20 @@ execute_update_addresses_taken (void)
rhs = gimple_assign_rhs1 (stmt);
if (gimple_assign_lhs (stmt) != lhs
!useless_type_conversion_p (TREE_TYPE (lhs),
TREE_TYPE (rhs)))
rhs = fold_build1 (VIEW_CONVERT_EXPR,
TREE_TYPE (lhs), rhs);
if (gimple_assign_lhs (stmt) != lhs)
gimple_assign_set_lhs (stmt, lhs);
- /* For var ={v} {CLOBBER}; where var lost
- TREE_ADDRESSABLE just remove the stmt. */
- if (DECL_P (lhs)
-TREE_CLOBBER_P (rhs)
-bitmap_bit_p (suitable_for_renaming, DECL_UID (lhs)))
- {
- unlink_stmt_vdef (stmt);
-
[wwwdocs] Reduce/relativize links in gcc-*/*
Remove a couple of links. Make a couple of links relative. Consistently use bug tracker to refer to our Bugzilla system. As a side effect, this further reduces the number of http links to gcc.gnu.org. Applied. Gerald Index: gcc-3.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-3.3/changes.html,v retrieving revision 1.61 diff -u -r1.61 changes.html --- gcc-3.3/changes.html28 Jun 2014 20:35:50 - 1.61 +++ gcc-3.3/changes.html28 Jun 2014 22:41:27 - @@ -916,8 +916,7 @@ h3Bug Fixes/h3 -pThis section lists the problem reports (PRs) from -a href=http://gcc.gnu.org/bugzilla/;GCC's bug tracking system/a +pThis section lists the problem reports (PRs) from GCC's bug tracker that are known to be fixed in the 3.3.2 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here)./p @@ -1058,8 +1057,7 @@ h3Bug Fixes/h3 -pThis section lists the problem reports (PRs) from -a href=http://gcc.gnu.org/bugzilla/;GCC's bug tracking system/a +pThis section lists the problem reports (PRs) from GCC's bug tracker that are known to be fixed in the 3.3.3 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here)./p Index: gcc-4.0/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v retrieving revision 1.65 diff -u -r1.65 changes.html --- gcc-4.0/changes.html28 Jun 2014 20:35:51 - 1.65 +++ gcc-4.0/changes.html28 Jun 2014 22:41:27 - @@ -346,7 +346,7 @@ h3Fortran/h3 ul -liA new a href=http://gcc.gnu.org/fortran/;Fortran/a front end +liA new a href=../fortran/Fortran/a front end has replaced the aging GNU Fortran 77 front end. The new front end supports Fortran 90 and Fortran 95. It may not yet be as stable as the old Fortran front end. Index: gcc-4.3/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/changes.html,v retrieving revision 1.129 diff -u -r1.129 changes.html --- gcc-4.3/changes.html28 Jun 2014 20:35:51 - 1.129 +++ gcc-4.3/changes.html28 Jun 2014 22:41:28 - @@ -163,8 +163,7 @@ platforms and code-msse/-msse2/code for i?86 and x86_64./li liMore information on porting to GCC 4.3 from previous versions -of GCC can be found in -the a href=http://gcc.gnu.org/gcc-4.3/porting_to.html;porting +of GCC can be found in the a href=porting_to.htmlporting guide/a for this release./li /ul Index: gcc-4.3/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/porting_to.html,v retrieving revision 1.11 diff -u -r1.11 porting_to.html --- gcc-4.3/porting_to.html 28 Jun 2014 07:45:13 - 1.11 +++ gcc-4.3/porting_to.html 28 Jun 2014 22:41:28 - @@ -9,8 +9,7 @@ p The GCC 4.3 release series differs from previous GCC releases in more -than the usual list -of a href=http://gcc.gnu.org/gcc-4.3/changes.html;new +than the usual list of a href=changes.htmlnew features/a. Some of these changes are a result of bug fixing, and some old behaviors have been intentionally changed in order to support new standards, or relaxed in standards-conforming ways to facilitate Index: gcc-4.4/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/changes.html,v retrieving revision 1.87 diff -u -r1.87 changes.html --- gcc-4.4/changes.html28 Jun 2014 20:35:51 - 1.87 +++ gcc-4.4/changes.html28 Jun 2014 22:41:28 - @@ -121,8 +121,7 @@ are issued, then GCC warns about the unknown options./li liMore information on porting to GCC 4.4 from previous versions -of GCC can be found in -the a href=http://gcc.gnu.org/gcc-4.4/porting_to.html;porting +of GCC can be found in the a href=porting_to.htmlporting guide/a for this release./li /ul Index: gcc-4.4/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/porting_to.html,v retrieving revision 1.8 diff -u -r1.8 porting_to.html --- gcc-4.4/porting_to.html 27 Jun 2014 18:53:31 - 1.8 +++ gcc-4.4/porting_to.html 28 Jun 2014 22:41:28 - @@ -9,8 +9,7 @@ p The GCC 4.4 release series differs from previous GCC releases in more -than the usual list -of a href=http://gcc.gnu.org/gcc-4.4/changes.html;new +than the usual list of a href=changes.htmlnew features/a. Some of these changes are a result of bug fixing, and some old behaviors have been intentionally changed in order to support new standards, or relaxed in standards-conforming ways to facilitate Index: gcc-4.6/changes.html
Re: [i386] Replace builtins with vector extensions
On Sat, 28 Jun 2014, Ulrich Drepper wrote: On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse marc.gli...@inria.fr wrote: Ping, nobody has an opinion on this? Or some explanation why I am mistaken to believe that #pragma target makes it safer now? It would enable a number of optimizations, like constant propagation, FMA contraction, etc. It would also allow us to remove several builtins. I see no problem with using the array-type access to the registers. As for replacing the builtins with arithmetic operators: I appreciate the possibility for optimization. But is there any chance the calls could not end up being implemented with a vector instruction? I think that would be bad. The intrinsics should be a way to guarantee that the programmer can create vector instructions. Otherwise we might just not support them. There is always a risk, but then even with builtins I think there was a small risk that an RTL optimization would mess things up. It is indeed higher if we expose the operation to the optimizers earlier, but it would be a bug if an optimization replaced a vector operation by something worse. Also, I am only proposing to handle the most trivial operations this way, not more complicated ones (like v[0]+=s) where we would be likely to fail generating the right instruction. And the pragma should ensure that the function will always be compiled in a mode where the vector instruction is available. ARM did the same and I don't think I have seen a bug reporting a regression about it (I haven't really looked though). Thanks, -- Marc Glisse
[patch, libgfortran] PR61640 KIND=4 Character Array Internal Unit Read Fail
The attached patch is obvious and simple. I will commit to trunk soon.
There are two things obvious about this.
1) Using the wrong function for wide characters.
2) No one must be using this feature of Fortran since the bug exists at least
back to 4.5
;)
Regression tested on x86-64-linux-gnu.
Test case attached. I would suggest since it is a wrong code bug, we should at
least port to 4.9.1. I will wait a while before doing that and won't if anyone
feels strongly about not doing so. A portion of the patch in eat_spaces is a
correction to the fix for PR61499 for KIND=4.
Regards,
Jerry
2014-06-28 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/61640
* io/list_read.c (next_char_internal): Adjust the read length to
a single wide character. (eat_spaces): Add missing paren.
* io/unix.c (mem_read4): Use the correct mem_alloc function for
wide character internal reads.
Index: list_read.c
===
--- list_read.c (revision 212104)
+++ list_read.c (working copy)
@@ -273,7 +273,7 @@ next_char_internal (st_parameter_dt *dtp)
/* Get the next character and handle end-of-record conditions. */
if (dtp-common.unit) /* Check for kind=4 internal unit. */
- length = sread (dtp-u.p.current_unit-s, c, sizeof (gfc_char4_t));
+ length = sread (dtp-u.p.current_unit-s, c, 1);
else
{
char cc;
@@ -399,7 +399,7 @@ eat_spaces (st_parameter_dt *dtp)
{
for (i = 0; i dtp-u.p.current_unit-bytes_left; i++)
{
- if (dtp-internal_unit[offset + i * sizeof (gfc_char4_t)]
+ if (dtp-internal_unit[(offset + i) * sizeof (gfc_char4_t)]
!= (gfc_char4_t)' ')
break;
}
Index: unix.c
===
--- unix.c (revision 212104)
+++ unix.c (working copy)
@@ -808,10 +808,10 @@ mem_read4 (stream * s, void * buf, ssize_t nbytes)
void *p;
int nb = nbytes;
- p = mem_alloc_r (s, nb);
+ p = mem_alloc_r4 (s, nb);
if (p)
{
- memcpy (buf, p, nb);
+ memcpy (buf, p, nb * 4);
return (ssize_t) nb;
}
else
! { dg-do run }
! PR61640 KIND=4 Character Array Internal Unit Read Fail
program read_internal
integer :: x(9),i
integer :: y(9)
character(kind=4,len=30), dimension(3) :: source
y = reshape ((/ 1,1,-1,1,-1,1,-1,1,1 /), shape(x))
source=[4_ 1 1 -1,4_ 1 -1 1,4_ -1 1 1]
!print *, (trim(source(i)), i=1,3)
read(source,*) (x(i), i=1,9) ! This read fails for KIND=4 character
if (any(x /= y )) call abort
end program read_internal
[C++] Avoid producing duplicate binfos for member pointers
Jason, this is another case cought by the type variant checking. build_ptrmemfunc_type, for qualified type, first calls itself recursively to produce member pointer type for unqalified variant. Subsequentely it produces the member pointer from scratch - I believe it is because the field decl representing pointer should be qualified, so we have rather rare case where we do not share fields in between type and variant (other is Fortran when dropping restrict quantifiers deeply from the structure). It however produces fresh BINFO for the variant and overwrites its BINFO_TYPE pointer to t. I do not see a reason for having duplicated binfo here: both structures should be equivalent from type inheritance POV. This patch just avoids the duplicated BINFO and copies one from unqalified variant, if available. Seems sane? Bootstrapped/regtested x86_64-linux. * decl.c (build_ptrmemfunc_type): Do not produce duplicated BINFO for the variant. Index: cp/decl.c === --- cp/decl.c (revision 212098) +++ cp/decl.c (working copy) @@ -8074,7 +8074,6 @@ build_ptrmemfunc_type (tree type) = build_ptrmemfunc_type (TYPE_MAIN_VARIANT (type)); t = make_class_type (RECORD_TYPE); - xref_basetypes (t, NULL_TREE); /* Let the front end know this is a pointer to member function... */ TYPE_PTRMEMFUNC_FLAG (t) = 1; @@ -8109,8 +8108,10 @@ build_ptrmemfunc_type (tree type) TYPE_MAIN_VARIANT (t) = unqualified_variant; TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (unqualified_variant); TYPE_NEXT_VARIANT (unqualified_variant) = t; - TREE_TYPE (TYPE_BINFO (t)) = t; + TYPE_BINFO (t) = TYPE_BINFO (unqualified_variant); } + else +xref_basetypes (t, NULL_TREE); /* Cache this pointer-to-member type so that we can find it again later. */
[wwwdocs] gcc-4.4/porting_to.html: convert a textual reference to a proper one
...and improve wording and markup a bit. Applied. Gerald Index: bugs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v retrieving revision 1.113 diff -u -r1.113 index.html --- bugs/index.html 28 Jun 2014 07:45:05 - 1.113 +++ bugs/index.html 28 Jun 2014 23:28:17 - @@ -350,7 +350,8 @@ anything)./p/dd -dtCasting does not work as expected when optimization is turned on./dt +dt id=casting_and_optimizationCasting does not work as expected when +optimization is turned on./dt ddpThis is often caused by a violation of aliasing rules, which are part of the ISO C standard. These rules say that a program is invalid if you try Index: gcc-4.4/porting_to.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/porting_to.html,v retrieving revision 1.9 diff -u -r1.9 porting_to.html --- gcc-4.4/porting_to.html 28 Jun 2014 22:44:29 - 1.9 +++ gcc-4.4/porting_to.html 28 Jun 2014 23:28:17 - @@ -95,10 +95,10 @@ using code-fno-strict-aliasing /code or by ignoring this class of warning via code-Wno-strict-aliasing/code. To fix, access the structure from pointers of an equivalent type, use a union, use -memcpy, or (if using C++) use placement new. See the section titled -quot;Casting does not work as expected when optimization is turned -onquot; on a href=http://gcc.gnu.org/bugs/;bug reporting -documentation page/a for more information. +memcpy, or (if using C++) use placement codenew/code. +See the section a href=../bugs/#casting_and_optimization +Casting does not work as expected when optimization is turned on/a +in our bug reporting documentation for more information. /p h2C++ language issues/h2
Re: [RFC] Add a .gitattributes file for use with git-merge-changelog
Ouch; it looks like my last attempt to reply to this missed gdb-patches@ due to a gmane accident? Samuel Bronson naes...@gmail.com writes: Tom Tromey tro...@redhat.com writes: Samuel == Samuel Bronson naes...@gmail.com writes: Samuel [Am I really supposed to CC this to gcc@ like binutils/MAINTAINERS Samuel says I should?] I think just for files that are intended to be put in both trees and shared. Well, they're certainly welcome to add such a file to their repository. Samuel Individual users will still have to: Samuel 1. Install git-merge-changelog Samuel 2. Set up the merge driver in their git config What happens if they do not? Not much; git just falls back to the default (text) merge driver in that case. (This appears to have been so obvious that nobody actually bothered to document it?) I find myself wondering: how much commentary should go into the .gitattributes file, and do such files get ChangeLog entries? -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: Optimize type streaming
Minor comments below, ok with those changes.
Thanks!
This is version of patch I commited after additional testing on building of
some bigger apps with LTO. The main change (in addition to those requested) is
that I moved the fixups into lto_copy_fields_not_streamed and added loop before
SCC unification. I plan to do more of the copying and it would be getting hard
to walk all the copies in compare_tree_sccs_1.
Second change is that I moved back streaming of DECL_FIELDS. THere are two cases
where we produce variant with different fields - a member pointer with different
qualifiers and gfc_nonrestricted_type that recursively drops restrict qualifiers
from the types. These seems valid reasons.
I also removed use of TYPE_MAXVAL and TYPE_MINVAL and expanded individual uses.
MAXVAL/MINVAL is kind of hack and even the updated conditions wasn't quite
correct
on when these are used and when these needs to be copied. There are quite few
types that do not use this field at all and there is no need to stream it.
Bootstrapped/regtested x86_64-linux and comitted.
Honza
* tree-streamer-out.c (pack_ts_type_common_value_fields): Stream if type
is complete.
(write_ts_type_common_tree_pointers): Do not stream fields not set for
incomplete
types; do not stream duplicated fields for variants; sanity check that
variant
and type match.
(write_ts_type_non_common_tree_pointers): Likewise.
* tree-streamer-in.c (unpack_ts_type_common_value_fields): Mark in
TYPE_SIZE whether
type is complete.
(lto_input_ts_type_common_tree_pointers): Do same changes as in
write_ts_type_common_tree_pointers
(lto_input_ts_type_non_common_tree_pointers): Likewise.
* lto.c (lto_copy_fields_not_streamed): New function.
(compare_tree_sccs_1): Do not compare fields shared in between type
and variant.
(lto_read_decls): Fixup types first before inserting into hash.
Index: tree-streamer-in.c
===
--- tree-streamer-in.c (revision 212098)
+++ tree-streamer-in.c (working copy)
@@ -357,6 +357,13 @@ unpack_ts_type_common_value_fields (stru
TYPE_RESTRICT (expr) = (unsigned) bp_unpack_value (bp, 1);
TYPE_USER_ALIGN (expr) = (unsigned) bp_unpack_value (bp, 1);
TYPE_READONLY (expr) = (unsigned) bp_unpack_value (bp, 1);
+ /* This bit represent if type is complete, or if the TYPE_SIZE
+ is non-NULL. Mark this fact into TYPE_SIZE. The actual values
+ will be filled in later. */
+ if ((unsigned) bp_unpack_value (bp, 1))
+TYPE_SIZE (expr) = error_mark_node;
+ else
+TYPE_SIZE (expr) = NULL_TREE;
TYPE_PRECISION (expr) = bp_unpack_var_len_unsigned (bp);
TYPE_ALIGN (expr) = bp_unpack_var_len_unsigned (bp);
TYPE_ALIAS_SET (expr) = bp_unpack_var_len_int (bp);
@@ -794,19 +801,29 @@ static void
lto_input_ts_type_common_tree_pointers (struct lto_input_block *ib,
struct data_in *data_in, tree expr)
{
- TYPE_SIZE (expr) = stream_read_tree (ib, data_in);
- TYPE_SIZE_UNIT (expr) = stream_read_tree (ib, data_in);
- TYPE_ATTRIBUTES (expr) = stream_read_tree (ib, data_in);
+ TYPE_MAIN_VARIANT (expr) = stream_read_tree (ib, data_in);
+
+ /* Variants share most the properties with the main variant. */
+ if (TYPE_MAIN_VARIANT (expr) == expr)
+{
+ if (COMPLETE_TYPE_P (expr))
+ {
+ TYPE_SIZE (expr) = stream_read_tree (ib, data_in);
+ TYPE_SIZE_UNIT (expr) = stream_read_tree (ib, data_in);
+ }
+ TYPE_ATTRIBUTES (expr) = stream_read_tree (ib, data_in);
+}
+ /* The fileds not streamed will be copied by
+ lto_copy_fields_not_streamed. */
TYPE_NAME (expr) = stream_read_tree (ib, data_in);
+ TYPE_CONTEXT (expr) = stream_read_tree (ib, data_in);
+ TYPE_STUB_DECL (expr) = stream_read_tree (ib, data_in);
/* Do not stream TYPE_POINTER_TO or TYPE_REFERENCE_TO. They will be
reconstructed during fixup. */
/* Do not stream TYPE_NEXT_VARIANT, we reconstruct the variant lists
during fixup. */
- TYPE_MAIN_VARIANT (expr) = stream_read_tree (ib, data_in);
- TYPE_CONTEXT (expr) = stream_read_tree (ib, data_in);
/* TYPE_CANONICAL gets re-computed during type merging. */
TYPE_CANONICAL (expr) = NULL_TREE;
- TYPE_STUB_DECL (expr) = stream_read_tree (ib, data_in);
}
/* Read all pointer fields in the TS_TYPE_NON_COMMON structure of EXPR
@@ -818,21 +835,48 @@ lto_input_ts_type_non_common_tree_pointe
struct data_in *data_in,
tree expr)
{
- if (TREE_CODE (expr) == ENUMERAL_TYPE)
-TYPE_VALUES (expr) = stream_read_tree (ib, data_in);
- else if (TREE_CODE (expr) == ARRAY_TYPE)
-TYPE_DOMAIN (expr) = stream_read_tree (ib, data_in);
- else if (RECORD_OR_UNION_TYPE_P (expr))
+ if (TYPE_MAIN_VARIANT (expr) == expr)
+{
+ if (TREE_CODE (expr) ==
Re: [PATCH] Convert XCOFF ASM_DECLARE_FUNCTION_NAME to function
BTW, if I enable MAKE_DECL_ONE_ONLY for XCOFF, the endless loop does not occur, so it clearly has some effect on AIX. Maybe it can function well-enough on AIX. - David
[Committed] Fix lto.c compiling
I committed this as obvious. The changelog says it all.
Thanks,
Andrew
2014-06-28 Andrew Pinski apin...@cavium.com
* lto.c (lto_read_decls): Fix comment in comment.
Index: lto.c
===
--- lto.c (revision 212118)
+++ lto.c (working copy)
@@ -1970,7 +1970,7 @@ lto_read_decls (struct lto_file_decl_dat
len, scc_entry_len, scc_hash))
continue;
- /* /* Do remaining fixup tasks for prevailing nodes. */
+ /* Do remaining fixup tasks for prevailing nodes. */
bool seen_type = false;
for (unsigned i = 0; i len; ++i)
{
Index: ChangeLog
===
--- ChangeLog (revision 212118)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-06-28 Andrew Pinski apin...@cavium.com
+
+ * lto.c (lto_read_decls): Fix comment in comment.
+
2014-06-28 Jan Hubicka hubi...@ucw.cz
* lto.c (lto_copy_fields_not_streamed): New function.
