Re: [PR 61424] std::regex matches right to left, not leftmost longest

[Tim Shen]

On Tue, Jun 10, 2014 at 1:56 PM, Tim Shen  wrote:
> On Tue, Jun 10, 2014 at 9:54 AM, Jonathan Wakely  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 
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.
  vector>  _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;
+  *_M_states._M_get_sol_pos() = _BiIter();
   _M_cur_resu

Re: [PR 61424] std::regex matches right to left, not leftmost longest

[Jonathan Wakely]

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.
  vector>  _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

[Jonathan Wakely]

On 27/06/14 09:53 -0700, Tim Shen wrote:

On Fri, Jun 27, 2014 at 12:37 AM, Paolo Carlini
 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
vector> instead of a map, for improved
memory footprint and runtime speed, but that can be changed later.

Re: [patch] change specific int128 -> generic intN

[Marc Glisse]

(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

[Gerald Pfeifer]

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 @@
 
   https://gcc.gnu.org/ml/jit/";>jit
   is for discussion and development of
-  http://gcc.gnu.org/wiki/JIT";>libgccjit, an experimental
+  https://gcc.gnu.org/wiki/JIT";>libgccjit, 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 @@
 
 GCC now uses C++ as its implementation language
 [2012-08-14]
-The http://gcc.gnu.org/wiki/cxx-conversion";>cxx-conversion
+The https://gcc.gnu.org/wiki/cxx-conversion";>cxx-conversion
 branch has been merged into trunk.  This switches GCC's implementation
 language from C to C++.
 Additionally, some data structures have been re-implemented in C++
@@ -125,7 +125,7 @@
 
 Atomic memory model support
 [2011-11-06]
-C++11/C11 http://gcc.gnu.org/wiki/Atomic/GCCMM";>memory model
+C++11/C11 https://gcc.gnu.org/wiki/Atomic/GCCMM";>memory model
 support has been added through a new set of built-in __atomic
 functions.  Code was contributed by Andrew MacLeod, Richard Henderson, and
 Aldy Hernandez, all of Red Hat, Inc. 
@@ -135,14 +135,14 @@
 [2011-11-18]
 IUUK (Computer Science Institute, Charles University), CE-ITI
 (Institute for Theoretical Computer Science) and Google are organizing
-a http://gcc.gnu.org/wiki/cauldron2012";>workshop for GNU
+a https://gcc.gnu.org/wiki/cauldron2012";>workshop for GNU
 Tools developers.  The workshop will be held in July 2012 at
 Charles University, Prague.
 
 Transactional memory support
 [2011-11-15]
 An implementation of the
-ongoing http://gcc.gnu.org/wiki/TransactionalMemory";>transactional
+ongoing https://gcc.gnu.org/wiki/TransactionalMemory";>transactional
 memory 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 @@
 POWER7 on the GCC Compile Farm
 [2011-11-10]
 IBM has donated a 64 processor POWER7 machine (3.55 GHz, 64 GB RAM)
-to the http://gcc.gnu.org/wiki/CompileFarm";>GCC Compile Farm
+to the https://gcc.gnu.org/wiki/CompileFarm";>GCC Compile Farm
 project.  Hosting is donated by the OSU Open Source Lab.
 
 Epiphany processor support
@@ -283,7 +283,7 @@
 GCC 4.4.2 has been released.
 
 October 3, 2009
-The http://gcc.gnu.org/wiki/LinkTimeOptimization";>LTO
+The https://gcc.gnu.org/wiki/LinkTimeOptimization";>LTO
 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 @@
 
 May 6, 2009
 GCC can now be extended using a generic http://gcc.gnu.org/wiki/plugins-branch";>plugin framework on host
+href="https://gcc.gnu.org/wiki/plugins-branch";>plugin framework on host
 platforms that support dynamically loadable objects.
 
 April 21, 2009
@@ -345,7 +345,7 @@
 May 22, 2008
 AMD Developer Central has donated two bi-quad core machines with
 the latest AMD Opteron 8354 "Barcelona B3" processors and 16GB of RAM
-to the http://gcc.gnu.org/wiki/CompileFarm";>GCC Compile Farm
+to the https://gcc.gnu.org/wiki/CompileFarm";>GCC Compile Farm
 project for use by free software developers.  Hosting is donated
 by INRIA Saclay.
 
@@ -443,7 +443,7 @@
 GCC.
 
 January 5, 2007
-http://gcc.gnu.org/wiki/mem-ssa";>Memory SSA, a new
+https://gcc.gnu.org/wiki/mem-ssa";>Memory SSA, a new
 representation for memory expressions in SSA form has been contributed
 by Diego Novillo of Red Hat.  This new mechanism improves 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 
-http://gcc.gnu.org/wiki/GCC_4.1_Projects";>GCC 4.1 projects.
+https://gcc.gnu.org/wiki/GCC_4.1_Projects";>GCC 4.1 projects.
 
 
 July 7, 2005
@@ -583,7 +583,7 @@
 
 January 27, 2005
 
-GCC now has a http://gcc.gnu.org/wiki/";>Wiki.
+GCC now has a https://gcc.gnu.org/wiki/";>Wiki.
 
 
 November 4, 2004
Index: benchmarks/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/benchmarks/index.html,v
retrieving revision 1.30
diff -u -r1.30 index.html
--- benchmarks/index.html   27 Jun 2014 15:04:39 -  1.30
+++ benchmarks/ind

Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.

[Marc Glisse]

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)

[Ulrich Weigand]

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  

* 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

[Gerald Pfeifer]

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 @@
 
 Regenerate
 gcc.pot and cpplib.pot.
-http://gcc.gnu.org/translation.html#submit";>Send them
+Send them
 to the translation project if no snapshot of this version was sent
 during development stage 3 or 4.
 
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 @@
 -->
 
 The GCC project has many mailing lists, which are archived on the web
-(and http://gcc.gnu.org/lists.html#searchbox";>searchable).
+(and searchable).
 Please make yourself familiar with our policies
 before subscribing and posting to these lists.
 
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 http://gcc.gnu.org/news/reorder.html";>Stan Cox and Jason
+href="reorder.html">Stan Cox and Jason
 Eckhardt for the basic block reordering pass.
 
 
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 @@
 
   The frontend would provide a way of producing native
   executables from CIL images, analogous to how the GNU Compiler
-  for Java (http://gcc.gnu.org/java/";>GCJ) provides a
+  for Java (GCJ) provides a
   way to produce native executables from Java classes.
 
 
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 @@
   http://gcc.gnu.org/install/test.html";>Installing GCC:
   Testing for instructions on submitting test results.
   Build cross compilers and test with simulators as described in
-  http://gcc.gnu.org/simtest-howto.html";>How to test GCC
+  How to test GCC
   on a simulator.
   If 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

[Marc Glisse]

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  

* 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

[Gerald Pfeifer]

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

[Gerald Pfeifer]

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 @@
 The 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 http://gcc.gnu.org/install/specific.html";>latest version
+and the https://gcc.gnu.org/install/specific.html";>latest version
 is always available at the GCC web site.
 Reports of http://gcc.gnu.org/buildstat.html";>successful builds
 for several versions of GCC are also available at the web site.
@@ -217,7 +217,7 @@
 the GNU versions of those programs.
 
 To ensure that GCC finds the GNU assembler (the GNU linker), which
-are required by http://gcc.gnu.org/install/specific.html";>some
+are required by https://gcc.gnu.org/install/specific.html";>some
 configurations,
 you should configure these with the same --prefix option as you used
 for GCC.  Then build & install GNU as (GNU ld) and proceed with
@@ -457,7 +457,7 @@
 transparently without requiring installation of any additional tools.
 
 If you modified some sources or when building from SVN you may also
-need http://gcc.gnu.org/install/prerequisites.html#TOC1";>some
+need https://gcc.gnu.org/install/prerequisites.html#TOC1";>some
 additional tools.
 
 
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.  If you don't already have a compiler, you need pre-compiled
 binaries.
-Our http://gcc.gnu.org/install/binaries.html";>binaries page
+Our https://gcc.gnu.org/install/binaries.html";>binaries page
 has references to pre-compiled binaries for various platforms.
 
 You 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 @@
 The 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
-http://gcc.gnu.org/install/";>installation instructions
+installation instructions
 and build/test status on our web page.  We
 will update those pages as new information becomes available.
 
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 @@
 Each 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
-http://gcc.gnu.org/install/";>installation instructions 
+installation instructions
 and build/test status on our web page.  We
 will update those pages as new information becomes available.
 
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 @@
 
 The sources include installation instructions in both HTML
 and plaintext forms in the install directory in the distribution.
-However, the most up to date
- http://gcc.gnu.org/install/";>installation instructions
+However, the most up to date installation instructions
 and build/test status are on the web pages.  We
 will update those pages as new information becomes available.
 
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
--- gcc-3.0/buildstat.html  27 Jun 2014 14:34:15 -  1.154
+++ gcc-3.0/buildstat.html  28 Jun 2014 11:57:28 -
@@ -13,11 +13,11 @@
 
 Instructions for running the test suite and for submitting 

Re: [wwwdocs] gcc-4.9/changes.html: Mention that LTO now generates slim objects

[Gerald Pfeifer]

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.
   C++ hidden keyed methods can now be optimized out.
   When using a linker plugin, compiling with the -flto
-  option now generates slim objects files (.o) which only
+  option now generates slim object files (.o) which only
   contain intermediate language representation for LTO. Use
   -ffat-lto-objects to create files which contain
   additionally the object code.  To generate static libraries suitable
   for LTO processing, use gcc-ar and
  gcc-ranlib; to list symbols from a slim object file use
- gcc-nm. (Requires that ar,
+ gcc-nm. (This requires that ar,
  ranlib and nm have been compiled with
  plugin support.)
 

Re: [Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals

[Ed Smith-Rowland]

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  ---
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    - Unicode 
strings broken in a strange way
PR C++/59867    - Template 
string literal loses first symbol
PR C++/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 "
-  " or ",
-  decl);
+   {
+ if (cxx_dialect >= cxx1y)
+   error ("literal operator template %qD has invalid parameter list."
+  "  Expected non-type template argument pack "
+  " or ",
+  decl);
+ else
+   error ("literal operator template %qD has invalid parameter list."
+  "  Expected non-type template argument pack ",
+  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 
+
+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 
+using namespace std;
+
+// constant
+template
+  struct meta_value
+  {
+typedef meta_value type;
+typedef T value_type;
+static const T value = x;
+  };
+
+// array
+template
+  struct meta_array
+  {
+typedef meta_array type;
+typedef T item_type;
+  };
+
+// static array -> runtime array conversion utility
+template
+  struct array_gen;
+
+template
+  struct array_gen>
+  {
+static const T value[sizeof...(xs)];
+  };
+
+template
+  const T
+  array_gen>::value[sizeof

Re: [i386] Replace builtins with vector extensions

[Ulrich Drepper]

On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse  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.

Re: [wwwdocs, patch, committed] Changed some http://gcc.gnu.org to https

[Gerald Pfeifer]

On Wed, 11 Jun 2014, Tobias Burnus wrote:
This patch converts some more files, but I think one should at 
some point change all files.


I'm working on this now, alas not per file, but according to
groups of links and trying to clean up some aspects (by reducing
links and make them relative where possible).

We're down to perhaps 90 links left, and some of these need more
special treatment.

Gerald

[c++-concepts] constraint association

[Andrew Sutton]

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  
* 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
 return true;
  

Re: [fortran,patch] Binding label can be any initialisation expression

[FX]

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

[Jakub Jelinek]

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

[Paolo Carlini]

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

[Marc Glisse]

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

[Gerald Pfeifer]

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

[Andrew Sutton]

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  
* 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

[Tim Shen]

On Sat, Jun 28, 2014 at 2:48 AM, Jonathan Wakely  wrote:
> I wonder if it would be better to use a sorted
> vector> 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

[Gerald Pfeifer]

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  

* 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 @@
 General Questions 
   
 What license is used for libgcj?
-How can I contribute to libgcj
-Will gcj and libgcj work on my machine?
 How can I debug my Java program?
 Can I interface byte-compiled and native java 
code?
   
@@ -32,12 +30,6 @@
 What features of the Java language are/arn't 
supported
   
 
-Build Issues 
-  
-I need something more recent than the last 
release; how
-  should I build it?
-  
-
 Gcj Compile/Link Questions 
   
 Why do I get undefined reference to 
`main' 
@@ -48,8 +40,6 @@
 Where does GCJ look for files? 
 How does gcj resolve wether to compile .class 
or 
   .java files? 
-I'm getting link errors!
-I'm getting 'undefined symbol: 
__dso_handle'
   
 
 Runtime Questions 
@@ -87,28 +77,6 @@
   
   
   
-  1.3 How can I contribute to libgcj?
-   
-
-  You can send simple bug fixes in as patches. Please follow the http://gcc.gnu.org/contribute.html";>GCC 
-  guidelines for submitting patches. For more complex changes, you 
-  must sign copyright over to the Free Software Foundation. See the contribution 
-  page for details.
-
-  
- 
-  
-  1.5 Will gcj and libgcj work on my machine?
-   
-
-  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.
-
-  
- 
-  
   1.6 How can I debug my Java program?

 
@@ -267,15 +235,6 @@
 
   
   
-  Build Issues
-
-  3.1 I need something more recent than the last 
release. 
-  How should I build it?
-   
-
-  Please read here.
-
-  
 
   Gcj Compile/Link Questions
  
@@ -352,36 +311,6 @@
 
   
   
-  
-  4.6 I'm getting link errors
-
-  
-
-  If 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.
-
-  
-
-  
-  4.7 I'm getting 'undefined symbol: 
__dso_handle'
-  
-
-  Some 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. 
-
-  There are three solutions: 
-  
-downgrade to binutils that don't support .hidden at all,
-upgrade to a recent binutils, or
-undef the HAVE_GAS_HIDDEN definition in gcc's auto-host.h
-(and rebuild gcc).
-  
-
-  
   
   Runtime Questions
  

Fix representation of gcov_info_type

[Jan Hubicka]

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

[Jan Hubicka]

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_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_alloc ();
   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

[Jan Hubicka]

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)

[Mike Stump]

On Jun 28, 2014, at 3:31 AM, Ulrich Weigand  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 signbit on Solaris

[Bruce Korb]

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

[Jan Hubicka]

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

[Gerald Pfeifer]

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 @@
 GCC 3.3.4
 
 This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.4";>list
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.4";>list
 of problem reports (PRs) 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 @@
 GCC 3.3.5
 
 This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.5";>list
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.5";>list
 of problem reports (PRs) 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 @@
 GCC 3.3.6
 
 This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.6";>list
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.3.6";>list
 of problem reports (PRs) 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 @@
 
 We are tracking all bugs in Bugzilla.  Any bugs that we want to fix
 for the 3.3 release will be marked high priority (http://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=allwordssubst&component=java&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_severity=critical&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&bugidtype=include&cmdtype=doit&order=Bug+Number";>see
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=allwordssubst&component=java&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_severity=critical&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&bugidtype=include&cmdtype=doit&order=Bug+Number";>see
 list).
 
  Packages 
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.
 http://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexp&short_desc=%5C%5B3%5C.4.*%5BRr%5Degression&target_milestone=3.4.0&bug_status=RESOLVED&resolution=FIXED";>Follow
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexp&short_desc=%5C%5B3%5C.4.*%5BRr%5Degression&target_milestone=3.4.0&bug_status=RESOLVED&resolution=FIXED";>Follow
 this link 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 are not flagged as 3.4 regressions.
@@ -1609,7 +1609,7 @@
 GCC 3.4.3
 
 This is the http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.4.3";>list
+href="https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=3.4.3";>list
 of problem reports (PRs) from GCC'

[C++ Patch] PR 51400

[Paolo Carlini]

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  

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  

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

[Ed Smith-Rowland]

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    - 
Unicode strings broken in a strange way
PR C++/59867    - 
Template string literal loses first symbol
PR C++/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 "
-  " or ",
-  decl);
+   {
+ if (cxx_dialect >= cxx1y)
+   error ("literal operator template %qD has invalid parameter list."
+  "  Expected non-type template argument pack "
+  " or ",
+  decl);
+ else
+   error ("literal operator template %qD has invalid parameter list."
+  "  Expected non-type template argument pack ",
+  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 
+
+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 
+using namespace std;
+
+// constant
+template
+  struct meta_value
+  {
+typedef meta_value type;
+typedef T value_type;
+static const T value = x;
+  };
+
+// array
+template
+  struct meta_array
+  {
+typedef meta_array type;
+typedef T it

Re: [PATCH] Fix gennews

[Gerald Pfeifer]

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  
> 
>   * 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

[Marc Glisse]

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  

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);
-  

Fix duplication of TYPE_SIZE/TYPE_SIZE_UNIT of variadic array type variants

[Jan Hubicka]

Hi,
this patch fixes another problem where we manage to produce a variant of
variadic array that has different TYPE_SIZE (but an equivalent expression).
This happens because remap_type_1 blindly copies all expressions referred by
variadic type while for variants it may just reuse ones it earlier copied when
producing a copy of the main variant.

Bootstrapped/regtested x86_64-linux, lto-bootstrapped and tested on Firefox
build with the main variant checking patch in, comitted.

Honza

* tree-inline.c (remap_type_1): Do not duplicate fields
that are shared in between type and its main variant.
Index: tree-inline.c
===
--- tree-inline.c   (revision 212098)
+++ tree-inline.c   (working copy)
@@ -451,6 +451,8 @@ remap_type_1 (tree type, copy_body_data
   TYPE_POINTER_TO (new_tree) = NULL;
   TYPE_REFERENCE_TO (new_tree) = NULL;
 
+  /* Copy all types that may contain references to local variables; be sure to
+ preserve sharing in between type and its main variant when possible.  */
   switch (TREE_CODE (new_tree))
 {
 case INTEGER_TYPE:
@@ -458,40 +460,72 @@ remap_type_1 (tree type, copy_body_data
 case FIXED_POINT_TYPE:
 case ENUMERAL_TYPE:
 case BOOLEAN_TYPE:
-  t = TYPE_MIN_VALUE (new_tree);
-  if (t && TREE_CODE (t) != INTEGER_CST)
-walk_tree (&TYPE_MIN_VALUE (new_tree), copy_tree_body_r, id, NULL);
-
-  t = TYPE_MAX_VALUE (new_tree);
-  if (t && TREE_CODE (t) != INTEGER_CST)
-walk_tree (&TYPE_MAX_VALUE (new_tree), copy_tree_body_r, id, NULL);
+  if (TYPE_MAIN_VARIANT (new_tree) != new_tree)
+   {
+ gcc_checking_assert (TYPE_MIN_VALUE (type) == TYPE_MIN_VALUE 
(TYPE_MAIN_VARIANT (type)));
+ gcc_checking_assert (TYPE_MAX_VALUE (type) == TYPE_MAX_VALUE 
(TYPE_MAIN_VARIANT (type)));
+
+ TYPE_MIN_VALUE (new_tree) = TYPE_MIN_VALUE (TYPE_MAIN_VARIANT 
(new_tree));
+ TYPE_MAX_VALUE (new_tree) = TYPE_MAX_VALUE (TYPE_MAIN_VARIANT 
(new_tree));
+   }
+  else
+   {
+ t = TYPE_MIN_VALUE (new_tree);
+ if (t && TREE_CODE (t) != INTEGER_CST)
+   walk_tree (&TYPE_MIN_VALUE (new_tree), copy_tree_body_r, id, NULL);
+
+ t = TYPE_MAX_VALUE (new_tree);
+ if (t && TREE_CODE (t) != INTEGER_CST)
+   walk_tree (&TYPE_MAX_VALUE (new_tree), copy_tree_body_r, id, NULL);
+   }
   return new_tree;
 
 case FUNCTION_TYPE:
-  TREE_TYPE (new_tree) = remap_type (TREE_TYPE (new_tree), id);
-  walk_tree (&TYPE_ARG_TYPES (new_tree), copy_tree_body_r, id, NULL);
+  if (TYPE_MAIN_VARIANT (new_tree) != new_tree
+ && TREE_TYPE (type) == TREE_TYPE (TYPE_MAIN_VARIANT (type)))
+   TREE_TYPE (new_tree) = TREE_TYPE (TYPE_MAIN_VARIANT (new_tree));
+  else
+TREE_TYPE (new_tree) = remap_type (TREE_TYPE (new_tree), id);
+  if (TYPE_MAIN_VARIANT (new_tree) != new_tree
+ && TYPE_ARG_TYPES (type) == TYPE_ARG_TYPES (TYPE_MAIN_VARIANT (type)))
+   TYPE_ARG_TYPES (new_tree) = TYPE_ARG_TYPES (TYPE_MAIN_VARIANT 
(new_tree));
+  else
+walk_tree (&TYPE_ARG_TYPES (new_tree), copy_tree_body_r, id, NULL);
   return new_tree;
 
 case ARRAY_TYPE:
-  TREE_TYPE (new_tree) = remap_type (TREE_TYPE (new_tree), id);
-  TYPE_DOMAIN (new_tree) = remap_type (TYPE_DOMAIN (new_tree), id);
+  if (TYPE_MAIN_VARIANT (new_tree) != new_tree
+ && TREE_TYPE (type) == TREE_TYPE (TYPE_MAIN_VARIANT (type)))
+   TREE_TYPE (new_tree) = TREE_TYPE (TYPE_MAIN_VARIANT (new_tree));
+
+  if (TYPE_MAIN_VARIANT (new_tree) != new_tree)
+   {
+ gcc_checking_assert (TYPE_DOMAIN (type) == TYPE_DOMAIN 
(TYPE_MAIN_VARIANT (type)));
+ TYPE_DOMAIN (new_tree) = TYPE_DOMAIN (TYPE_MAIN_VARIANT (new_tree));
+   }
+  else
+   TYPE_DOMAIN (new_tree) = remap_type (TYPE_DOMAIN (new_tree), id);
   break;
 
 case RECORD_TYPE:
 case UNION_TYPE:
 case QUAL_UNION_TYPE:
-  {
-   tree f, nf = NULL;
-
-   for (f = TYPE_FIELDS (new_tree); f ; f = DECL_CHAIN (f))
- {
-   t = remap_decl (f, id);
-   DECL_CONTEXT (t) = new_tree;
-   DECL_CHAIN (t) = nf;
-   nf = t;
- }
-   TYPE_FIELDS (new_tree) = nreverse (nf);
-  }
+  if (TYPE_MAIN_VARIANT (type) != type
+ && TYPE_FIELDS (type) == TYPE_FIELDS (TYPE_MAIN_VARIANT (type)))
+   TYPE_FIELDS (new_tree) = TYPE_FIELDS (TYPE_MAIN_VARIANT (new_tree));
+  else
+   {
+ tree f, nf = NULL;
+
+ for (f = TYPE_FIELDS (new_tree); f ; f = DECL_CHAIN (f))
+   {
+ t = remap_decl (f, id);
+ DECL_CONTEXT (t) = new_tree;
+ DECL_CHAIN (t) = nf;
+ nf = t;
+   }
+ TYPE_FIELDS (new_tree) = nreverse (nf);
+   }
   break;
 
 case OFFSET_TYPE:
@@ -500,8 +534,20 @@ remap_type_1 (tree type, copy_body_data
   gcc_unreachab

[wwwdocs] Reduce/"relativize" links in gcc-*/*

[Gerald Pfeifer]

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 @@
 
 Bug Fixes
 
-This section lists the problem reports (PRs) from 
-http://gcc.gnu.org/bugzilla/";>GCC's bug tracking system
+This 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).
@@ -1058,8 +1057,7 @@
 
 Bug Fixes
 
-This section lists the problem reports (PRs) from 
-http://gcc.gnu.org/bugzilla/";>GCC's bug tracking system
+This 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).
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 @@
 Fortran
 
   
-A new http://gcc.gnu.org/fortran/";>Fortran front end
+A new Fortran 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 -msse/-msse2 for i?86 and x86_64.
 
 More information on porting to GCC 4.3 from previous versions
-of GCC can be found in
-the http://gcc.gnu.org/gcc-4.3/porting_to.html";>porting
+of GCC can be found in the porting
 guide for this release.
   
 
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 @@
 
 
 The GCC 4.3 release series differs from previous GCC releases in more
-than the usual list
-of http://gcc.gnu.org/gcc-4.3/changes.html";>new
+than the usual list of new
 features. 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.

 More information on porting to GCC 4.4 from previous versions
-of GCC can be found in
-the http://gcc.gnu.org/gcc-4.4/porting_to.html";>porting
+of GCC can be found in the porting
 guide for this release.
  
 
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 @@
 
 
 The GCC 4.4 release series differs from previous GCC releases in more
-than the usual list
-of http://gcc.gnu.org/gcc-4.4/changes.html";>new
+than the usual list of new
 features. 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
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/changes.html,v
retrieving revision 1.150
diff -u -r1.150 changes.html
--- gcc-4.6/changes.html28 Jun 2014 20:35:51 -0

Re: [i386] Replace builtins with vector extensions

[Marc Glisse]

On Sat, 28 Jun 2014, Ulrich Drepper wrote:


On Sat, Jun 28, 2014 at 6:42 AM, Marc Glisse  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

[Jerry DeLisle]

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  

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

[Jan Hubicka]

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

[Gerald Pfeifer]

...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).
 
 
-Casting does not work as expected when optimization is turned on.
+Casting does not work as expected when
+optimization is turned on.
 
 This 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 -fno-strict-aliasing  or by ignoring this class of
 warning via -Wno-strict-aliasing. 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
-"Casting does not work as expected when optimization is turned
-on" on http://gcc.gnu.org/bugs/";>bug reporting
-documentation page for more information.
+memcpy, or (if using C++) use placement new. 
+See the section  
+Casting does not work as expected when optimization is turned on
+in our bug reporting documentation for more information.
 
 
 C++ language issues

Re: [RFC] Add a .gitattributes file for use with git-merge-changelog

[Samuel Bronson]

Ouch; it looks like my last attempt to reply to this missed gdb-patches@
due to a gmane accident?

Samuel Bronson  writes:

> Tom Tromey  writes:
>>> "Samuel" == Samuel Bronson  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

[Jan Hubicka]

> 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) == ENUME

Re: [PATCH] Convert XCOFF ASM_DECLARE_FUNCTION_NAME to function

[David Edelsohn]

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

[Andrew Pinski]

I committed this as obvious.  The changelog says it all.

Thanks,
Andrew

2014-06-28  Andrew Pinski  

* 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  
+
+   * lto.c (lto_read_decls): Fix comment in comment.
+
 2014-06-28  Jan Hubicka  
 
* lto.c (lto_copy_fields_not_streamed): New function.