RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

On Tue, 6 Jan 2015 16:32:35, Mike Stump wrote:
>
> On Jan 6, 2015, at 3:22 PM, Bernd Edlinger  wrote:
>> Yes, I think too that it can't fail under these conditions.
>
> If you mean your version… A lot has been written on how to to make racy code 
> non-racy… I’d refer you to the literature on all the various solutions people 
> have found to date. I don’t think I’ve ever seen anyone claim that affinity 
> can be used to solve race conditions like this. Do you have a pointer?
>

no, I agree, the affinity would just lower the likelihood, as sleep does.
The version with affinity is just disgusting, sorry to have posted it ;-).

I meant your version, with step(1)/step(2) between the race. It is probably 
bullet-proof.
But the version with sleep is more realistic.  That is however just a matter of 
taste...

If we can agree to use your version, then all tests in g++.dg/tsan and
c-c++-common/tsan that currently use sleep(1) should use your step function 
instead.
sleep_sync.c can use step but needs still to call sleep because it triggers on 
the
"As if synchronized via sleep" diagnostic.

I don't know what to make of simple_race.c, which uses usleep, but uses
a loop to repeat the race often. Maybe leave that one as a "realistic" test.


Bernd.
  

[Patch, libstdc++/64239] Use std::swap instead of swap in regex

[Tim Shen]

Bootstrapped and tested. It could be also patched to 4.9 branch.

Thanks!


-- 
Regards,
Tim Shen
commit dfe3a26759893849020a659b14fafe8b27e90dae
Author: timshen 
Date:   Tue Jan 6 19:30:27 2015 -0800

PR libstdc++/64239

* include/bits/regex.h (match_results<>::swap): Use std::swap
instead of swap.
* include/bits/regex_compiler.tcc (_Compiler<>::_M_quantifier):
Likewise.

diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index 9b7ed8c..b520039 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -1864,7 +1864,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   swap(match_results& __that)
   {
_Base_type::swap(__that);
-   swap(_M_begin, __that._M_begin);
+   std::swap(_M_begin, __that._M_begin);
   }
   //@}
 
diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc 
b/libstdc++-v3/include/bits/regex_compiler.tcc
index 57bafa3..33d7118 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -276,7 +276,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  auto& __tmp = (*_M_nfa)[__stack.top()];
  __stack.pop();
- swap(__tmp._M_next, __tmp._M_alt);
+ std::swap(__tmp._M_next, __tmp._M_alt);
}
}
  _M_stack.push(__e);

Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode

[Vladimir Makarov]

On 2015-01-05 8:40 PM, Bin.Cheng wrote:

On Tue, Jan 6, 2015 at 7:36 AM, Vladimir Makarov  wrote:

On 2015-01-05 12:31 PM, Jeff Law wrote:

On 01/05/15 00:44, Kito Cheng wrote:

Hi Vladimir:
This patch has a discusses with you in May 2014, this patch is about
the caller-save register store and restore instruction generation, the
current LRA implementation will miss caller-save store/restore
instruction if need one more instruction.

You said you will investigate for this on IRC, so I don't send the
patch last year, however ARM guys seem got this problem too, so I
think it's time to send this patch :)

ChangeLog

2015-01-05  Kito Cheng  

  * lra-constraints.c (split_reg): Fix caller-save store/restore
instruction generation.

Please reference PR64348 in the ChangeLog entry.

Please include a testcase if there isn't one in the regression suite
already.

Please indicate what platform this patch was bootstrapped and regression
tested on.

The dumping code immediately after the assert you removed has code like
this in both cases:



  fprintf (lra_dump_file,
"Rejecting split %d->%d "
"resulting in > 2 %s restore insns:\n",
original_regno, REGNO (new_reg), call_save_p ? "call" :
"");

Testing call_save_p here won't make any sense after your patch.

I'll let Vlad chime in on the correctness of allowing multi register
saves/restores in this code.


The solution itself is ok.  Prohibiting generation of more one insn was
intended for inheritance only as inheritance transformation can be undone
when the inheritance pseudo does not get a hard register. Undoing
multi-register splitting is difficult and also such splitting is doubtedly
profitable.

Splitting for save/restore is never undone.  So it is ok for this case to
generate multi-register saves/restores.

Kito, Jeff wrote reasonable changes for the patch.  Please, do them and you
can commit the patch.

Hi Vlad,
As for this specific case in PR64348, dump IR crossing function call
is as below:

   430: [sfp:SI-0x30]=r989:TI#0
   432: [r1706:SI+0x4]=r989:TI#4
   434: [r1706:SI+0x8]=r989:TI#8
   436: [r1706:SI+0xc]=r989:TI#12
   441: r0:DI=call [`__aeabi_idivmod'] argc:0
   REG_UNUSED r0:SI
   REG_CALL_DECL `__aeabi_idivmod'
   REG_EH_REGION 0x8000
   437: r1007:SI=sign_extend(r989:TI#0)
   REG_DEAD r989:TI

Save/restore are introduced because of use of r989:#0 in insn 437.
Register r989 is TImode register and assigned to r2/r3/r4/r5.  I can
think about two possible improvements to LRA splitter.  1) According
to ARM EABI, only r2/r3 need to be saved/restored; 2) In this case, we
only need to save/restore r989:TI#0, which is r2.  In fact, it has
already been saved to stack in insn 430, what we need is to restore
r989:TI#0 after function call.

What do you think about these?



Thanks for the interesting case.

It would be nice to implement this but it is hard.   For saving only r2 
we need live range analysis on sub-register level which is complicated 
(even IRA has such code only at most for 2-registers pseudos).  For 
reusing memory from insn 430 is complicated too if it is not equiv memory.


May be adding hard registers explicitly to this code could help 
(save/restore splitting is done only on the 1st LRA sub-pass; after that 
pseudos can get a call-clobbered hard register only if it does not 
intersect calls; if pseudo r989 is spilled on later LRA sub-passes we 
could remove code involving explicit subregisters). I'll think about this.

[doc, committed] tidy formatting of RS/6000 -mrecip= option

[Sandra Loosemore]

Quite some time ago (r184879) I reformatted the entry for the i386 
-mrecip= option as part of a general cleanup of that section.  Here's 
the corresponding change for the very similary RS/6000 option, which 
I've committed as an "obvious fix".


-Sandra


2015-01-06  Sandra Loosemore  

gcc/
* doc/invoke.texi (RS/6000 and PowerPC Options): Tidy formatting
of -mrecip= documentation.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi	(revision 219263)
+++ gcc/doc/invoke.texi	(working copy)
@@ -20630,15 +20630,39 @@ roots.
 This option controls which reciprocal estimate instructions
 may be used.  @var{opt} is a comma-separated list of options, which may
 be preceded by a @code{!} to invert the option:
-@code{all}: enable all estimate instructions,
-@code{default}: enable the default instructions, equivalent to @option{-mrecip},
-@code{none}: disable all estimate instructions, equivalent to @option{-mno-recip};
-@code{div}: enable the reciprocal approximation instructions for both single and double precision;
-@code{divf}: enable the single-precision reciprocal approximation instructions;
-@code{divd}: enable the double-precision reciprocal approximation instructions;
-@code{rsqrt}: enable the reciprocal square root approximation instructions for both single and double precision;
-@code{rsqrtf}: enable the single-precision reciprocal square root approximation instructions;
-@code{rsqrtd}: enable the double-precision reciprocal square root approximation instructions;
+
+@table @samp
+
+@item all
+Enable all estimate instructions.
+
+@item default 
+Enable the default instructions, equivalent to @option{-mrecip}.
+
+@item none 
+Disable all estimate instructions, equivalent to @option{-mno-recip}.
+
+@item div 
+Enable the reciprocal approximation instructions for both 
+single and double precision.
+
+@item divf 
+Enable the single-precision reciprocal approximation instructions.
+
+@item divd 
+Enable the double-precision reciprocal approximation instructions.
+
+@item rsqrt 
+Enable the reciprocal square root approximation instructions for both
+single and double precision.
+
+@item rsqrtf 
+Enable the single-precision reciprocal square root approximation instructions.
+
+@item rsqrtd 
+Enable the double-precision reciprocal square root approximation instructions.
+
+@end table
 
 So, for example, @option{-mrecip=all,!rsqrtd} enables
 all of the reciprocal estimate instructions, except for the

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump]

On Jan 6, 2015, at 3:22 PM, Bernd Edlinger  wrote:
> Yes, I think too that it can't fail under these conditions.

If you mean your version…  A lot has been written on how to to make racy code 
non-racy…  I’d refer you to the literature on all the various solutions people 
have found to date.  I don’t think I’ve ever seen anyone claim that affinity 
can be used to solve race conditions like this.  Do you have a pointer?

> If we prepare the test in this way it does not really contain any race 
> condition.
> 
> (*p4).val++;
>   step (1);
> 
> happens first, and then:
> 
>   step (2);
>   Global[1]++;
> 
> but we consider the test passed, when we see a diagnostic?

If tsan doesn’t work in the face of a race, then trivially, the code to test it 
cannot have a race.  The difference is letting tsan know there is a race, 
versus hiding the fact there is no race from it, so that it still thinks there 
is a race.  For test cases to diagnose a race, those cases must have the code 
that ensures there is not a race, hidden from view.

> As far as I can see, there is no interceptor for sched_yield, so using that 
> in the step function is OK.

Sounds good.

I’m running a test suite run now with my attribute patch.  I’ll ask the tsan 
people if it can go in, if it passes.

Go patch committed: Fix export of complex constants with 0 imaginary part

[Ian Lance Taylor]

This patch by Chris Manghane fixes the export data for complex
constants with a zero imaginary part.  This is
https://code.google.com/p/gofrontend/issues/detail?id=31 .
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian
diff -r fd1c78fac62c go/expressions.cc
--- a/go/expressions.cc Tue Jan 06 15:21:38 2015 -0800
+++ b/go/expressions.cc Tue Jan 06 16:12:09 2015 -0800
@@ -2450,7 +2450,7 @@
   if (!mpfr_zero_p(mpc_realref(val)))
 {
   Float_expression::export_float(exp, mpc_realref(val));
-  if (mpfr_sgn(mpc_imagref(val)) > 0)
+  if (mpfr_sgn(mpc_imagref(val)) >= 0)
exp->write_c_string("+");
 }
   Float_expression::export_float(exp, mpc_imagref(val));

Re: Housekeeping work in backends.html

[Max Filippov]

Hi Eric,

On Wed, Jan 7, 2015 at 2:39 AM, Eric Botcazou  wrote:
> The page is directly browsable at https://gcc.gnu.org/backends.html
>
> For the moxie, nvptx, rl178 and rx ports, maintainers can send me the string
> as Sandra did for the nios2 port and I'll update the document.

Xtensa is now supported by the QEMU, so probably question mark in its 'S' slot
may be removed.

-- 
Thanks.
-- Max

Re: Housekeeping work in backends.html

[Eric Botcazou]

> Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
> maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

The page is directly browsable at https://gcc.gnu.org/backends.html

For the moxie, nvptx, rl178 and rx ports, maintainers can send me the string 
as Sandra did for the nios2 port and I'll update the document.

-- 
Eric Botcazou

libgo patch committed: Add Go tool sources

[Ian Lance Taylor]

I've committed a patch to libgo to add the sources for three standard
Go tools: go, cgo, and gofmt.  The go tool is used by most Go
programmers to build, test, and install Go programs, as well as to
fetch Go code from the Internet.  It more or less replaces make.  The
cgo tool is invoked by the go tool, and supports calling back and
forth between Go and C.  The gofmt tool formats Go code in a standard
way.  These tools all have full support for gccgo already.

This patch was originally prepared by Lynn A. Boger before I made some changes.

As yet nothing builds these tools.  It doesn't make sense to build
them as part of libgo, because they logically need to be built for the
host, not the target.  I'm thinking that we will add something like
gnattools, a top-level directory that builds code that lives
elsewhere.

I haven't included a complete patch because it is slightly too large.
Most of the files are exact copies of the same files in the external
gc tree.  They have been changed for better support as part of the
gccgo tree; I've attached a file of those changes.  I've also attached
a file of the patches to files already present in libgo to support
these changes.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian
diff -ur /home/iant/go1.3/src/cmd/go/build.go libgo/go/cmd/go/build.go
--- /home/iant/go1.3/src/cmd/go/build.go2014-08-12 14:07:43.297932194 
-0700
+++ libgo/go/cmd/go/build.go2014-12-23 16:06:09.768565224 -0800
@@ -131,6 +131,7 @@
 var buildGccgoflags []string // -gccgoflags flag
 var buildRace bool   // -race flag
 
+var reqPkgSrc bool   // req src for Imports
 var buildContext = build.Default
 var buildToolchain toolchain = noToolchain{}
 
@@ -183,6 +184,12 @@
cmd.Flag.Var((*stringsFlag)(&buildContext.BuildTags), "tags", "")
cmd.Flag.Var(buildCompiler{}, "compiler", "")
cmd.Flag.BoolVar(&buildRace, "race", false, "")
+   switch build.Default.Compiler {
+   case "gc":
+   reqPkgSrc = true
+   case "gccgo":
+   reqPkgSrc = false
+   }
 }
 
 func addBuildFlagsNX(cmd *Command) {
@@ -562,15 +569,18 @@
// using cgo, to make sure we do not overwrite the binary while
// a package is using it.  If this is a cross-build, then the cgo we
// are writing is not the cgo we need to use.
+
if goos == runtime.GOOS && goarch == runtime.GOARCH && !buildRace {
-   if len(p.CgoFiles) > 0 || p.Standard && p.ImportPath == 
"runtime/cgo" {
-   var stk importStack
-   p1 := loadPackage("cmd/cgo", &stk)
-   if p1.Error != nil {
-   fatalf("load cmd/cgo: %v", p1.Error)
+   if reqPkgSrc {
+   if len(p.CgoFiles) > 0 || p.Standard && p.ImportPath == 
"runtime/cgo" {
+   var stk importStack
+   p1 := loadPackage("cmd/cgo", &stk)
+   if p1.Error != nil {
+   fatalf("load cmd/cgo: %v", p1.Error)
+   }
+   a.cgo = b.action(depMode, depMode, p1)
+   a.deps = append(a.deps, a.cgo)
}
-   a.cgo = b.action(depMode, depMode, p1)
-   a.deps = append(a.deps, a.cgo)
}
}
 
diff -ur /home/iant/go1.3/src/cmd/go/pkg.go libgo/go/cmd/go/pkg.go
--- /home/iant/go1.3/src/cmd/go/pkg.go  2014-08-12 14:07:43.301932155 -0700
+++ libgo/go/cmd/go/pkg.go  2014-12-23 16:06:09.772565214 -0800
@@ -488,6 +488,9 @@
continue
}
p1 := loadImport(path, p.Dir, stk, p.build.ImportPos[path])
+   if !reqPkgSrc && p1.Root == "" {
+   continue
+   }
if p1.local {
if !p.local && p.Error == nil {
p.Error = &PackageError{
diff -ur /home/iant/go1.3/src/cmd/go/test.go libgo/go/cmd/go/test.go
--- /home/iant/go1.3/src/cmd/go/test.go 2014-08-12 14:07:43.301932155 -0700
+++ libgo/go/cmd/go/test.go 2014-12-23 16:06:09.772565214 -0800
@@ -371,9 +371,11 @@
delete(deps, "unsafe")
 
all := []string{}
-   for path := range deps {
-   if !build.IsLocalImport(path) {
-   all = append(all, path)
+   if reqPkgSrc {
+   for path := range deps {
+   if !build.IsLocalImport(path) {
+   all = append(all, path)
+   }
}
}
sort.Strings(all)
@@ -541,6 +543,9 @@
stk.push(p.ImportPath + " (test)")
for _, path := range p.TestImports {
p1 := l

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

On Tue, 6 Jan 2015 11:47:30, Mike Stump wrote:
>
> On Jan 6, 2015, at 9:45 AM, Bernd Edlinger  wrote:
>> I tried your suggestion now, and it seems to work. (on a 4-way core AMD64 
>> laptop)
>>
>> Would you prefer this over adding a sleep in Thread1, which I posted 
>> previously?
>
> The problem with the patch is there is nothing in the patch that makes it 
> work. You merely lower the odds of it failing. The point of addressing the 
> problem, and the problem is, this test case randomly fails, is to change the 
> test case, so that it is impossible by design for the test case to ever fail. 
> In my version of the fix, I think it can't fail.

Yes, I think too that it can't fail under these conditions. Maybe that is just 
a philosophical problem.

If we prepare the test in this way it does not really contain any race 
condition.
   
(*p4).val++;
   step (1);

happens first, and then:

   step (2);
   Global[1]++;

but we consider the test passed, when we see a diagnostic?


>> Therefore it should not call sleep,
> Again, sleep can’t fix race conditions, so therefore tsan can never use it as 
> an indication that no race exists.  If it ever did, that would be a bug.  The 
> only case where that would not be true, would be a hard real time analysis 
> verifier, and, when we get one, sleep can be so modified.
>> because that can be intercepted, even if the code is not instrumented.
> I don’t see the relevance.


I mention that only, because sleep, usleep and nanosleep are intercepted by 
tsan_interceptors.cc
and calling them alters the printed diagnostics, some tests need to see "as if 
synchronized by sleep",
some don't.

As far as I can see, there is no interceptor for sched_yield, so using that in 
the step function is OK.

However the other use of step is a valid test, although one that always fails.
Here we see a real race condition with no tsan diagnostic, just because both
threads alter the same variable at the same nanosecond, that is remarkable.
Just as if tsan had a blind spot here.

Once again, with a 3-way handshake in case the Tread1 is scheduled before
pthread_create returns:

cat tiny-race.c
/* { dg-shouldfail "tsan" } */

#include 

void step(int);

int Global;

void *Thread1(void *x) {
  step (2);
  Global = 42;
  return x;
}

int main() {
  pthread_t t;
  pthread_create(&t, 0, Thread1, 0);
  step (1);
  step (3);
  Global = 43;
  pthread_join(t, 0);
  return 0;
}

/* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */

>> Unfortunately there is no __attribute__((no_sanitize_thread))
> So, is that any harder to add then:

If a new attribute is easier to implement than teaching the tsan.exp tcl script
that lib.c is something special, maybe...


Bernd.
  

Re: Housekeeping work in backends.html

[Eric Botcazou]

> I think that for nios2 the correct entry is probably "SCpd", but the
> descriptions of some of the things in the table are too terse for me to
> be 100% sure that's correct.  E.g., the nios2 architecture doesn't
> include the concept of "condition codes" at all, so how many registers
> they might occupy seems irrelevant.

I think 'C' is the correct setting in this case.  The 'p' letter has been 
toggled so it can be removed for nios2 and I think that 'b' can be added.

I have installed the attached patch for nios2.

Thanks for the feedback.

-- 
Eric BotcazouIndex: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.53
diff -u -r1.53 backends.html
--- backends.html	6 Jan 2015 23:04:05 -	1.53
+++ backends.html	6 Jan 2015 23:12:40 -
@@ -94,6 +94,7 @@
 mn10300  | ?? c  g  s
 msp430   |L  FIl g  s
 nds32|   F Cda  s
+nios2|   S C   bd
 pa   |   ? Q   CBD  qrm da e
 pdp11|L   ICqrce
 rs6000   | Q   Cqr pda

Re: Housekeeping work in backends.html

[Eric Botcazou]

> I might claim updating this shouldn't ever require a review :-)

OK, it was mainly about toggling the 'p' letter...

I have installed the attached patch for lm32 (based on info privately provided 
by Sébastien) and visium.

-- 
Eric BotcazouIndex: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.52
diff -u -r1.52 backends.html
--- backends.html	6 Jan 2015 22:48:32 -	1.52
+++ backends.html	6 Jan 2015 23:00:57 -
@@ -82,6 +82,7 @@
 i386 |   ? Qq   da
 ia64 |   ? Q   Cqr  da
 iq2000   | ???   FICBg  d t
+lm32 |   F   g bd
 m32c |L  FIl g  s
 m32r |   FI d   s
 m68k |   ?cp a
@@ -104,6 +105,7 @@
 tilegx   |   S Q   Cqg bda e
 tilepro  |   S   F C g bda e
 v850 | ??FI   c  gm d   s
+visium   |  Bg bd   s
 vax  |  M?I   c  a e
 xtensa   |   ? C   bd
 

Re: [debug-early] remove deferred_asm_name

[Jason Merrill]

Let's also run the testsuite with the environment variable 
GCC_COMPARE_DEBUG=1.


Jason

Re: C++ PATCH for c++/64455 (dependent variable template in constant expression)

[Jason Merrill]

On 01/06/2015 05:01 PM, Jason Merrill wrote:

We were complaining about IsType not being constant, but we shouldn't
think about it having a constant value or not, because it is
type-dependent; a variable template can have a specialization with a
different type.


The second patch fixes a diagnostic issue I noticed while working on the 
above patch: we should say something helpful when someone writes :: 
after a variable template-id.


Jason

C++ PATCH for c++/64455 (dependent variable template in constant expression)

[Jason Merrill]

We were complaining about IsType not being constant, but we shouldn't 
think about it having a constant value or not, because it is 
type-dependent; a variable template can have a specialization with a 
different type.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit dff5042c89e83955238c9ec5b43a73fa2d2f3310
Author: jason 
Date:   Tue Jan 6 20:44:51 2015 +

	PR c++/64455
	* pt.c (type_dependent_expression_p): Handle variable templates.
	* constexpr.c (potential_constant_expression_1): Use it.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219268 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index ee796df..4da263e 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3882,7 +3882,7 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict,
 	  || !CP_TYPE_CONST_NON_VOLATILE_P (TREE_TYPE (t))
 	  || !DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (t))
 	  && !var_in_constexpr_fn (t)
-	  && !dependent_type_p (TREE_TYPE (t)))
+	  && !type_dependent_expression_p (t))
 {
   if (flags & tf_error)
 non_const_var_error (t);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 15645b9..de2f6a4 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21369,6 +21369,14 @@ type_dependent_expression_p (tree expression)
   && DECL_INITIAL (expression))
return true;
 
+  /* A variable template specialization is type-dependent if it has any
+ dependent template arguments.  */
+  if (VAR_P (expression)
+  && DECL_LANG_SPECIFIC (expression)
+  && DECL_TEMPLATE_INFO (expression)
+  && variable_template_p (DECL_TI_TEMPLATE (expression)))
+return any_dependent_template_arguments_p (DECL_TI_ARGS (expression));
+
   if (TREE_TYPE (expression) == unknown_type_node)
 {
   if (TREE_CODE (expression) == ADDR_EXPR)
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ21.C b/gcc/testsuite/g++.dg/cpp1y/var-templ21.C
new file mode 100644
index 000..a7b0899
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ21.C
@@ -0,0 +1,25 @@
+// PR c++/64455
+// { dg-do compile { target c++14 } }
+
+template
+constexpr bool IsType = true;
+
+template  struct Test
+{
+};
+
+template 
+struct Test
+{
+typedef T type;
+};
+
+template
+struct X {
+typedef typename Test,T>::type type;
+};
+
+int main()
+{
+   X::type t;
+}

commit 33dba2339488931a8630a2414be1d9d4604370e8
Author: jason 
Date:   Tue Jan 6 20:44:59 2015 +

	* parser.c (cp_parser_nested_name_specifier_opt): Diagnose invalid
	template-ids.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219269 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 22dff06..5c23a36 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -5435,6 +5435,46 @@ cp_parser_nested_name_specifier_opt (cp_parser *parser,
 	  cp_lexer_consume_token (parser->lexer);
 	}
 
+	  if (cp_lexer_next_token_is (parser->lexer, CPP_TEMPLATE_ID)
+	  && cp_lexer_nth_token_is (parser->lexer, 2, CPP_SCOPE))
+	{
+	  /* If we have a non-type template-id followed by ::, it can't
+		 possibly be valid.  */
+	  token = cp_lexer_peek_token (parser->lexer);
+	  tree tid = token->u.tree_check_value->value;
+	  if (TREE_CODE (tid) == TEMPLATE_ID_EXPR
+		  && TREE_CODE (TREE_OPERAND (tid, 0)) != IDENTIFIER_NODE)
+		{
+		  tree tmpl = NULL_TREE;
+		  if (is_overloaded_fn (tid))
+		{
+		  tree fns = get_fns (tid);
+		  if (!OVL_CHAIN (fns))
+			tmpl = OVL_CURRENT (fns);
+		  error_at (token->location, "function template-id %qD "
+"in nested-name-specifier", tid);
+		}
+		  else
+		{
+		  /* Variable template.  */
+		  tmpl = TREE_OPERAND (tid, 0);
+		  gcc_assert (variable_template_p (tmpl));
+		  error_at (token->location, "variable template-id %qD "
+"in nested-name-specifier", tid);
+		}
+		  if (tmpl)
+		inform (DECL_SOURCE_LOCATION (tmpl),
+			"%qD declared here", tmpl);
+
+		  parser->scope = error_mark_node;
+		  error_p = true;
+		  /* As below.  */
+		  success = true;
+		  cp_lexer_consume_token (parser->lexer);
+		  cp_lexer_consume_token (parser->lexer);
+		}
+	}
+
 	  if (cp_parser_uncommitted_to_tentative_parse_p (parser))
 	break;
 	  /* If the next token is an identifier, and the one after
diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ20.C b/gcc/testsuite/g++.dg/cpp1y/var-templ20.C
new file mode 100644
index 000..38bd370
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/var-templ20.C
@@ -0,0 +1,12 @@
+// { dg-do compile { target c++14 } }
+
+template  struct Sink {};
+template  void fn();
+template  T var = T();
+
+template  void f()
+{
+  Sink::value>();		// { dg-error "function" }
+  Sink::value>();	// { dg-error "variable" }
+}
+// { dg-prune-output "template argument" }

C++ PATCH for c++/64487 (offsetof in templates)

[Jason Merrill]

The existing code was assuming that offsetof will always be fully 
instantiated if it goes through tsubst at all.  In general this is an 
invalid assumption; we need to deal with partial instantiation in 
still-dependent context.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit fbbb80c79e464f12ee0977190189384b3ab9e429
Author: jason 
Date:   Tue Jan 6 20:44:46 2015 +

	PR c++/64487
	* semantics.c (finish_offsetof): Handle templates here.
	* parser.c (cp_parser_builtin_offsetof): Not here.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219267 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 52234de..22dff06 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -8729,15 +8729,7 @@ cp_parser_builtin_offsetof (cp_parser *parser)
 }
 
  success:
-  /* If we're processing a template, we can't finish the semantics yet.
- Otherwise we can fold the entire expression now.  */
-  if (processing_template_decl)
-{
-  expr = build1 (OFFSETOF_EXPR, size_type_node, expr);
-  SET_EXPR_LOCATION (expr, loc);
-}
-  else
-expr = finish_offsetof (expr, loc);
+  expr = finish_offsetof (expr, loc);
 
  failure:
   parser->integral_constant_expression_p = save_ice_p;
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 551bad1..4365a53 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3870,6 +3870,15 @@ finish_bases (tree type, bool direct)
 tree
 finish_offsetof (tree expr, location_t loc)
 {
+  /* If we're processing a template, we can't finish the semantics yet.
+ Otherwise we can fold the entire expression now.  */
+  if (processing_template_decl)
+{
+  expr = build1 (OFFSETOF_EXPR, size_type_node, expr);
+  SET_EXPR_LOCATION (expr, loc);
+  return expr;
+}
+
   if (TREE_CODE (expr) == PSEUDO_DTOR_EXPR)
 {
   error ("cannot apply % to destructor %<~%T%>",
diff --git a/gcc/testsuite/g++.dg/template/offsetof3.C b/gcc/testsuite/g++.dg/template/offsetof3.C
new file mode 100644
index 000..b173746
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/offsetof3.C
@@ -0,0 +1,18 @@
+// PR c++/64487
+
+struct foo {
+  int member;
+};
+
+template < int N>
+struct bar {};
+
+template 
+struct qux {
+static bar static_member;
+};
+
+template 
+bar qux::static_member;
+
+int main() { }

C++ PATCH for c++/64496 (lambda in local class)

[Jason Merrill]

In this testcase the compiler is confused by the local class and thinks 
that the lambda is in the context of the enclosing function.  Fixed by 
recognizing when a lambda is directly within a local class.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit f5ba54d8bcbd15d6d9519b0140a5e430e9822dcb
Author: jason 
Date:   Tue Jan 6 20:44:39 2015 +

	PR c++/64496
	* semantics.c (process_outer_var_ref): Diagnose lambda in local
	class NSDMI.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219266 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 44d9a2e..551bad1 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3141,8 +3141,12 @@ process_outer_var_ref (tree decl, tsubst_flags_t complain)
 while (context != containing_function
 	   && LAMBDA_FUNCTION_P (containing_function))
   {
-	lambda_expr = CLASSTYPE_LAMBDA_EXPR
-	  (DECL_CONTEXT (containing_function));
+	tree closure = DECL_CONTEXT (containing_function);
+	lambda_expr = CLASSTYPE_LAMBDA_EXPR (closure);
+
+	if (TYPE_CLASS_SCOPE_P (closure))
+	  /* A lambda in an NSDMI (c++/64496).  */
+	  break;
 
 	if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr)
 	== CPLD_NONE)
@@ -3172,7 +3176,19 @@ process_outer_var_ref (tree decl, tsubst_flags_t complain)
   else if (lambda_expr)
 {
   if (complain & tf_error)
-	error ("%qD is not captured", decl);
+	{
+	  error ("%qD is not captured", decl);
+	  tree closure = LAMBDA_EXPR_CLOSURE (lambda_expr);
+	  if (LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr)
+	  == CPLD_NONE)
+	inform (location_of (closure),
+		"the lambda has no capture-default");
+	  else if (TYPE_CLASS_SCOPE_P (closure))
+	inform (0, "lambda in local class %q+T cannot "
+		"capture variables from the enclosing context",
+		TYPE_CONTEXT (closure));
+	  inform (input_location, "%q+#D declared here", decl);
+	}
   return error_mark_node;
 }
   else
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi7.C b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi7.C
new file mode 100644
index 000..30595ef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi7.C
@@ -0,0 +1,25 @@
+// PR c++/64496
+// { dg-do compile { target c++11 } }
+
+template  class B;
+template 
+struct B { template  B(F); };
+template 
+template 
+B::B(F) {}
+
+int
+main()
+{
+  int a;
+  struct A			// { dg-message "lambda in local class" }
+  {
+B l = [=] {
+  a;			// { dg-error "not captured" }
+};
+  };
+  [] {// { dg-message "capture-default" }
+a;// { dg-error "not captured" }
+  };
+  A t;
+}

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump]

On Jan 5, 2015, at 5:06 PM, Bernd Edlinger  wrote:
> 
> I tried to elaborate your idea a bit, and used proper atomics.
> It is necessary that the logic of the step function is completely invisible 
> to tsan.

> Therefore it should not call sleep,

Again, sleep can’t fix race conditions, so therefore tsan can never use it as 
an indication that no race exists.  If it ever did, that would be a bug.  The 
only case where that would not be true, would be a hard real time analysis 
verifier, and, when we get one, sleep can be so modified.

> because that can be intercepted, even if the code is not instrumented.

I don’t see the relevance.

> Unfortunately there is no __attribute__((no_sanitize_thread))

So, is that any harder to add then:

diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index ce141b6..58bdc9e 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -766,6 +766,9 @@ const struct attribute_spec c_common_attribute_table[] =
   { "no_sanitize_address",0, 0, true, false, false,
  handle_no_sanitize_address_attribute,
  false },
+  { "no_sanitize_thread", 0, 0, true, false, false,
+ handle_no_sanitize_address_attribute,
+ false },
   { "no_sanitize_undefined",  0, 0, true, false, false,
  handle_no_sanitize_undefined_attribute,
  false },
diff --git a/gcc/tsan.c b/gcc/tsan.c
index 678fcdc..cafb150 100644
--- a/gcc/tsan.c
+++ b/gcc/tsan.c
@@ -758,7 +758,9 @@ public:
   opt_pass * clone () { return new pass_tsan (m_ctxt); }
   virtual bool gate (function *)
 {
-  return (flag_sanitize & SANITIZE_THREAD) != 0;
+  return ((flag_sanitize & SANITIZE_THREAD) != 0
+ && !lookup_attribute ("no_sanitize_thread",
+DECL_ATTRIBUTES (current_function_decl)));
 }
 
   virtual unsigned int execute (function *) { return tsan_pass (); }
@@ -798,7 +800,9 @@ public:
   /* opt_pass methods: */
   virtual bool gate (function *)
 {
-  return (flag_sanitize & SANITIZE_THREAD) != 0 && !optimize;
+  return ((flag_sanitize & SANITIZE_THREAD) != 0 && !optimize
+ && !lookup_attribute ("no_sanitize_thread",
+   DECL_ATTRIBUTES (current_function_decl)));
 }
 
   virtual unsigned int execute (function *) { return tsan_pass (); }


?  Doesn’t look to be much an issue, but, I’m not a tsan code-gen person, so 
they might have to weigh in.

> So some tests start to fail.
> 
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O0  execution test
> FAIL: g++.dg/tsan/aligned_vs_unaligned_race.C   -O2  execution test

I don’t see this when I do this:

__attribute__((no_sanitize_thread))
void step (int i)
{
  while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1) ;
  __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
}

to step.

Any issues just adding no_sanitize_thread to let us do what we want to do?

And the last point, should we add a sched_yield or a pthread_yield to the busy 
loop to be nice:

__attribute__((no_sanitize_thread))
void step (int i)
{
  while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1)
sched_yield ();
  __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
}

?  One a single core, this seems like it would run faster.

Re: [PATCH][6/n] Merge from match-and-simplify, make forwprop fold all stmts

[H.J. Lu]

On Wed, Nov 5, 2014 at 12:25 AM, Zhenqiang Chen  wrote:
> The patch leads to big regression for float operators on target without hard
> fpu support due to register shuffle.
>
> Please refer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743 for more
> detail.
>
> Thanks!
> -Zhenqiang
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Jeff Law
>> Sent: Saturday, October 25, 2014 1:48 AM
>> To: Richard Biener; gcc-patches@gcc.gnu.org
>> Cc: Jakub Jelinek
>> Subject: Re: [PATCH][6/n] Merge from match-and-simplify, make forwprop
>> fold all stmts
>>
>> On 10/24/14 07:16, Richard Biener wrote:
>> >
>> > This patch makes GIMPLE forwprop fold all statements, following
>> > single-use SSA edges only (as suggested by Jeff and certainly how this
>> > will regress the least until we replace manual simplification code
>> > that does not restrict itself this way).
>> >
>> > forwprop is run up to 4 times at the moment (once only for -Og, not at
>> > all for -O0), which still seems reasonable.  IMHO the forwprop pass
>> > immediately after inlining is somewhat superfluous, it was added there
>> > just for its ADDR_EXPR propagation.  We should eventually split this
>> > pass into two.
>> >
>> > Note that just folding what we propagated into (like the SSA
>> > propagators do during substitute-and-fold phase) will miss cases where
>> > we propagate into a stmt feeding the one we could simplify.  Unless we
>> > always fold all single-use (and their use) stmts we have to fold
>> > everything from time to time.  Changing how / when we fold stuff is
>> > certainly sth to look after with fold_stmt now being able to follow
>> > SSA edges.
>> >
>> > Bootstrapped on x86_64-unknown-linux-gnu, testing still in progress.
>> >
>> >  From earlier testing I remember I need to adjust a few testcases that
>> > don't expect the early folding - notably two strlenopt cases
>> > (previously XFAILed but then PASSed again).
>> >
>> > I also expect to massage the single-use heuristic as I get to merging
>> > the patterns I added for the various forwprop manual pattern matchings
>> > to trunk (a lot of them do not restrict themselves this way).
>> >
>> > Does this otherwise look ok?
>> >
>> > Thanks,
>> > Richard.
>> >
>> > 2014-10-24  Richard Biener  
>> >
>> > * tree-ssa-forwprop.c: Include tree-cfgcleanup.h and
> tree-into-ssa.h.
>> > (lattice): New global.
>> > (fwprop_ssa_val): New function.
>> > (fold_all_stmts): Likewise.
>> > (pass_forwprop::execute): Finally fold all stmts.
>> Seems reasonable.  After all, we can iterate on the single-use heuristic.
>>
>

This also caused:

//gcc.gnu.org/bugzilla/show_bug.cgi?id=64511



-- 
H.J.

Re: Housekeeping work in backends.html

[Sandra Loosemore]

On 01/05/2015 04:15 PM, Eric Botcazou wrote:

Hi,

the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the
'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh
still use define_peephole) and removes trailing spaces.

OK to commit?

Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).


I think that for nios2 the correct entry is probably "SCpd", but the 
descriptions of some of the things in the table are too terse for me to 
be 100% sure that's correct.  E.g., the nios2 architecture doesn't 
include the concept of "condition codes" at all, so how many registers 
they might occupy seems irrelevant.  And, I think the "S" (no free 
simulator) situation will probably be resolved soon, and it's hardly a 
property of either the architecture or the GCC port


-Sandra

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump]

On Jan 6, 2015, at 9:45 AM, Bernd Edlinger  wrote:
> I tried your suggestion now, and it seems to work. (on a  4-way core AMD64 
> laptop)
> 
> Would you prefer this over adding a sleep in Thread1, which I posted 
> previously?

The problem with the patch is there is nothing in the patch that makes it work. 
 You merely lower the odds of it failing.  The point of addressing the problem, 
and the problem is, this test case randomly fails, is to change the test case, 
so that it is impossible by design for the test case to ever fail.  In my 
version of the fix, I think it can't fail.

Re: [PATCH], rs6000, PR 64505 -- Fix issue with -m32 -mpowerpc64

[David Edelsohn]

On Mon, Jan 5, 2015 at 7:50 PM, Michael Meissner
 wrote:
> This patch fixes PR 64505, which is an issue that one of the users of the
> Advance Toolchain found where -m32 -mpowerpc64 generated an insn not found
> message in some cases.  I traced this down to rs6000_secondary_reload
> generating a reload helper that uses a DImode scratch register, when in this
> case, it should use a SImode scratch register.
>
> The attached patch fixes the problem, and causes no regressions under a 
> PowerPC
> 64-bit big endian Linux system (which also tests the 32-bit code).  Is it ok
> to install in the trunk?  Since the change occurs within code that I recently
> modified for the upper register support, a companion patch will need to be
> developed for the 4.8/4.9 branches.
>
> I think the patch is safe, but -m32 -mpowerpc64 is not legitimate for the 
> Linux
> environment.  As I recall, Darwin running on PowerPC's is the only system that
> allowed that combination.  I have added several people to the To: list of this
> mail whom David says may have done something with Darwin and PowerPC.  If so,
> and if you still have a system, it would be appreciated to see if these 
> patches
> are ok.
>
> [gcc]
> 2015-01-05  Michael Meissner  
>
> PR target/64505
> * config/rs6000/rs6000.c (rs6000_secondary_reload): Return the
> correct reload handler if -m32 -mpowerpc64 is used.
>
> [gcc/testsuite]
> 2015-01-05  Michael Meissner  
>
> PR target/64505
> * gcc.target/powerpc/pr64505.c: New file to test -m32 -mpowerpc64
> fix is correct.

This patch is okay.

Thanks, David

[debug-early] remove deferred_asm_name

[Aldy Hernandez]

As discussed in previous threads, we need to get rid of 
deferred_asm_name (and limbo nodes, etc) as part of the debug-early work.


The original patch for deferred_asm_name came in Alex's patch here:

https://gcc.gnu.org/ml/gcc-patches/2009-06/msg00030.html

One alternative to avoid this mechanism would be to to provide a non 
destructive decl_assembler_name() variant that would just return the 
mangled name, but without setting the .assembler_name field and 
triggering the template instantiation Alex speaks of.  I had a patch for 
this, but Jason was skeptical that the instantiation was still 
happening.  At Jason's request, I have removed deferred_asm_name 
altogether, and tested it by a full bootstrap on _mainline_.


Unless someone can come up with a testcase for the instantiation 
problem, I am going to commit this to the branch within a day or two.


Jason/Richi: Does this patch look reasonable?

Thanks.
Aldy
commit 4c3da3f77a9a996179ee2b9f05b89d02fa103c95
Author: Aldy Hernandez 
Date:   Tue Jan 6 11:14:07 2015 -0800

* dwarf2out.c: Remove deferred_asm_name.
(add_linkage_name): Same.
(dwarf2out_finish): Same.
(dwarf2out_c_finalize): Same.
(move_linkage_attr): Remove.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 9d60d88..e3ccda2 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -2785,10 +2785,6 @@ static GTY(()) comdat_type_node *comdat_type_list;
 /* A list of DIEs with a NULL parent waiting to be relocated.  */
 static GTY(()) limbo_die_node *limbo_die_list;
 
-/* A list of DIEs for which we may have to generate
-   DW_AT_{,MIPS_}linkage_name once their DECL_ASSEMBLER_NAMEs are set.  */
-static GTY(()) limbo_die_node *deferred_asm_name;
-
 struct dwarf_file_hasher : ggc_hasher
 {
   typedef const char *compare_type;
@@ -17007,22 +17003,9 @@ add_linkage_name (dw_die_ref die, tree decl)
   && (TREE_CODE (decl) == FUNCTION_DECL || TREE_CODE (decl) == VAR_DECL)
   && TREE_PUBLIC (decl)
   && !(TREE_CODE (decl) == VAR_DECL && DECL_REGISTER (decl))
-  && die->die_tag != DW_TAG_member)
-{
-  /* Defer until we have an assembler name set.  */
-  if (!DECL_ASSEMBLER_NAME_SET_P (decl))
-   {
- limbo_die_node *asm_name;
-
- asm_name = ggc_cleared_alloc ();
- asm_name->die = die;
- asm_name->created_for = decl;
- asm_name->next = deferred_asm_name;
- deferred_asm_name = asm_name;
-   }
-  else if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
-   add_linkage_attr (die, decl);
-}
+  && die->die_tag != DW_TAG_member
+  && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
+add_linkage_attr (die, decl);
 }
 
 /* Add a DW_AT_name attribute and source coordinate attribute for the
@@ -23597,37 +23580,6 @@ comdat_type_hasher::equal (const value_type 
*type_node_1,
 DWARF_TYPE_SIGNATURE_SIZE));
 }
 
-/* Move a DW_AT_{,MIPS_}linkage_name attribute just added to dw_die_ref
-   to the location it would have been added, should we know its
-   DECL_ASSEMBLER_NAME when we added other attributes.  This will
-   probably improve compactness of debug info, removing equivalent
-   abbrevs, and hide any differences caused by deferring the
-   computation of the assembler name, triggered by e.g. PCH.  */
-
-static inline void
-move_linkage_attr (dw_die_ref die)
-{
-  unsigned ix = vec_safe_length (die->die_attr);
-  dw_attr_node linkage = (*die->die_attr)[ix - 1];
-
-  gcc_assert (linkage.dw_attr == DW_AT_linkage_name
- || linkage.dw_attr == DW_AT_MIPS_linkage_name);
-
-  while (--ix > 0)
-{
-  dw_attr_node *prev = &(*die->die_attr)[ix - 1];
-
-  if (prev->dw_attr == DW_AT_decl_line || prev->dw_attr == DW_AT_name)
-   break;
-}
-
-  if (ix != vec_safe_length (die->die_attr) - 1)
-{
-  die->die_attr->pop ();
-  die->die_attr->quick_insert (ix, linkage);
-}
-}
-
 /* Helper function for resolve_addr, mark DW_TAG_base_type nodes
referenced from typed stack ops and count how often they are used.  */
 
@@ -24873,23 +24825,6 @@ dwarf2out_finish (const char *filename)
   resolve_addr (comp_unit_die ());
   move_marked_base_types ();
 
-  for (node = deferred_asm_name; node; node = node->next)
-{
-  tree decl = node->created_for;
-  /* When generating LTO bytecode we can not generate new assembler
- names at this point and all important decls got theirs via
-free-lang-data.  */
-  if (((!flag_generate_lto && !flag_generate_offload)
-  || DECL_ASSEMBLER_NAME_SET_P (decl))
- && DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
-   {
- add_linkage_attr (node->die, decl);
- move_linkage_attr (node->die);
-   }
-}
-
-  deferred_asm_name = NULL;
-
   /* Walk through the list of incomplete types again, trying once more to
  emit full debugging info for them.  */
   retry_incomplete_types ();
@@ -25231,7 +25166,6 @@ dwarf2out_c_finalize (void)

Re: [wwwdocs] Add news entry for Visium port

[Jeff Law]

On 01/06/15 04:57, Eric Botcazou wrote:

OK to commit?

-- Eric Botcazou


p.diff


Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.946
diff -u -p -r1.946 index.html
--- index.html  23 Dec 2014 18:44:10 -  1.946
+++ index.html  6 Jan 2015 11:55:54 -
@@ -52,6 +52,11 @@ mission statement.

  

+VISIUMcore support
+[2015-01-06]
+A port for the VISIUMcore architecture has been contributed by AdaCore
+on behalf of Controls and Data Services.
+
  GCC 5 C++14 language feature-complete
  [2014-12-23]
  Support for all C++14 language

Yes, this is good.

jeff

Re: [PATCH], rs6000, PR 64505 -- Fix issue with -m32 -mpowerpc64

[Michael Meissner]

On Mon, Jan 05, 2015 at 09:31:52PM -0600, Segher Boessenkool wrote:
> On Mon, Jan 05, 2015 at 07:50:33PM -0500, Michael Meissner wrote:
> > This patch fixes PR 64505, which is an issue that one of the users of the
> > Advance Toolchain found where -m32 -mpowerpc64 generated an insn not found
> > message in some cases.  I traced this down to rs6000_secondary_reload
> > generating a reload helper that uses a DImode scratch register, when in this
> > case, it should use a SImode scratch register.
> 
> That looks correct.
> 
> > I think the patch is safe, but -m32 -mpowerpc64 is not legitimate for the 
> > Linux
> > environment.

Yep, but even so, the compiler should not throw an insn not found error.

> The high halves of the registers are clobbered by some signal things.
> It works without problems otherwise; you can run the testsuite just fine
> with -m32 -mpowerpc64.
> 
> > + /* -m32 -mpowerpc64 needs to use a 32-bit scratch register.  */
> >   if (in_p)
> > -   sri->icode = CODE_FOR_reload_di_load;
> > +   sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_load
> > + : CODE_FOR_reload_di_load);
> >   else
> > -   sri->icode = CODE_FOR_reload_di_store;
> > +   sri->icode = ((TARGET_32BIT) ? CODE_FOR_reload_si_store
> > + : CODE_FOR_reload_di_store);
> 
> You really like parentheses do you?  :-)  You could drop them all...

The outer parenthesis is so that auto indent under emacs properly aligns the
code.  The parenthesis around the test for ?: is more of a style issue.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Fix up DSE - PR middle-end/64388, target/55023

[Jakub Jelinek]

On Tue, Jan 06, 2015 at 12:07:17PM -0500, John David Anglin wrote:
> On 1/6/2015 9:08 AM, Jakub Jelinek wrote:
> >@@ -2527,7 +2518,13 @@ scan_insn (bb_info_t bb_info, rtx_insn *
> >  const_call ? "const" : "memset", INSN_UID (insn));
> >   /* See the head comment of the frame_read field.  */
> >-  if (reload_completed)
> >+  if (reload_completed
> >+  /* Tail calls are storing their arguments using
> >+ arg poinnter.  If it is a frame pointer on the target,
> Typo.

Consider it fixed in my copy.

> >+ even before reload we need to kill frame pointer based
> >+ stores.  */
> >+  || (SIBLING_CALL_P (insn)
> >+  && HARD_FRAME_POINTER_IS_ARG_POINTER))
> > insn_info->frame_read = true;
> 
> I had tested this hunk before, without the
> "HARD_FRAME_POINTER_IS_ARG_POINTER"
> addition, on 32-bit hppa and it resolved the original test case.

Jakub

Re: [C PATCH] Make -Wdiv-by-zero work even for const ints (PR c/64440)

[Joseph Myers]

On Tue, 6 Jan 2015, Marek Polacek wrote:

> Currently the C FE's -Wdiv-by-zero warns only for INTEGER_CSTs,
> unlike C++, which can also handle const ints (yes, different
> constant expression rules).  But since it's easy to warn for
> consts in the C FE as well, and we already warn for shifts
> with const ints, I think we can go with the following.  The PR
> is a request for this.
> 
> Bootstrapped/regtested on {x86_64,ppc64}-linux, ok for trunk?

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Go patch committed: Don't initialize zero-sized fields in constructors

[Ian Lance Taylor]

This patch by Chris Manghane skips initializing zero-sized fields in
constructor expressions.  Initializing them tends to lead into GIMPLE
errors when using map composite literals.  Note that zero-sized fields
are useful in maps, but of course the compiler should not crash.  This
is http://golang.org/issue/9406 .  Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

2015-01-06  Chris Manghane  

* go-gcc.cc (constructor_expression): Don't initialize zero-sized
fields, just evaluate the values for side effects.
Index: go-gcc.cc
===
--- go-gcc.cc   (revision 219261)
+++ go-gcc.cc   (working copy)
@@ -1656,6 +1656,7 @@ Gcc_backend::constructor_expression(Btyp
   vec *init;
   vec_alloc(init, vals.size());
 
+  tree sink = NULL_TREE;
   bool is_constant = true;
   tree field = TYPE_FIELDS(type_tree);
   for (std::vector::const_iterator p = vals.begin();
@@ -1669,6 +1670,17 @@ Gcc_backend::constructor_expression(Btyp
   || TREE_TYPE(val) == error_mark_node)
 return this->error_expression();
 
+  if (int_size_in_bytes(TREE_TYPE(field)) == 0)
+   {
+ // GIMPLE cannot represent indices of zero-sized types so
+ // trying to construct a map with zero-sized keys might lead
+ // to errors.  Instead, we evaluate each expression that
+ // would have been added as a map element for its
+ // side-effects and construct an empty map.
+ append_to_statement_list(val, &sink);
+ continue;
+   }
+
   constructor_elt empty = {NULL, NULL};
   constructor_elt* elt = init->quick_push(empty);
   elt->index = field;
@@ -1681,7 +1693,9 @@ Gcc_backend::constructor_expression(Btyp
   tree ret = build_constructor(type_tree, init);
   if (is_constant)
 TREE_CONSTANT(ret) = 1;
-
+  if (sink != NULL_TREE)
+ret = fold_build2_loc(location.gcc_location(), COMPOUND_EXPR,
+ type_tree, sink, ret);
   return this->make_expression(ret);
 }
 

[C PATCH] Make -Wdiv-by-zero work even for const ints (PR c/64440)

[Marek Polacek]

Currently the C FE's -Wdiv-by-zero warns only for INTEGER_CSTs,
unlike C++, which can also handle const ints (yes, different
constant expression rules).  But since it's easy to warn for
consts in the C FE as well, and we already warn for shifts
with const ints, I think we can go with the following.  The PR
is a request for this.

Bootstrapped/regtested on {x86_64,ppc64}-linux, ok for trunk?

2015-01-06  Marek Polacek  

PR c/64440
* c-common.c (c_fully_fold_internal): Warn for division and modulo
if orig_op1 isn't INTEGER_CST, op1 is INTEGER_CST and is zero.

* gcc.dg/pr64440.c: New test.
* c-c++-common/pr56607.c: Don't limit dg-warnings to C++.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 4d9dd4d..df4fddd 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1364,6 +1364,17 @@ c_fully_fold_internal (tree expr, bool in_init, bool 
*maybe_const_operands,
 ? G_("left shift count >= width of type")
 : G_("right shift count >= width of type")));
}
+  if ((code == TRUNC_DIV_EXPR
+  || code == CEIL_DIV_EXPR
+  || code == FLOOR_DIV_EXPR
+  || code == EXACT_DIV_EXPR
+  || code == TRUNC_MOD_EXPR)
+ && TREE_CODE (orig_op1) != INTEGER_CST
+ && TREE_CODE (op1) == INTEGER_CST
+ && (TREE_CODE (TREE_TYPE (orig_op0)) == INTEGER_TYPE
+ || TREE_CODE (TREE_TYPE (orig_op0)) == FIXED_POINT_TYPE)
+ && TREE_CODE (TREE_TYPE (orig_op1)) == INTEGER_TYPE)
+   warn_for_div_by_zero (loc, op1);
   goto out;
 
 case INDIRECT_REF:
diff --git gcc/testsuite/c-c++-common/pr56607.c 
gcc/testsuite/c-c++-common/pr56607.c
index d7faa81..ba13956 100644
--- gcc/testsuite/c-c++-common/pr56607.c
+++ gcc/testsuite/c-c++-common/pr56607.c
@@ -12,7 +12,7 @@ int
 f2 (void)
 {
   const int x = sizeof (char) - 1;
-  return 1 / x;/* { dg-warning "division by 
zero" "" { target c++ } } */
+  return 1 / x;/* { dg-warning "division by 
zero" } */
 }
 
 int
@@ -25,5 +25,5 @@ int
 f4 (void)
 {
   const int x = sizeof (int) / 3 - 1;
-  return 1 / x;/* { dg-warning "division by 
zero" "" { target c++ } } */
+  return 1 / x;/* { dg-warning "division by 
zero" } */
 }
diff --git gcc/testsuite/gcc.dg/pr64440.c gcc/testsuite/gcc.dg/pr64440.c
index e69de29..f9cc46d 100644
--- gcc/testsuite/gcc.dg/pr64440.c
+++ gcc/testsuite/gcc.dg/pr64440.c
@@ -0,0 +1,15 @@
+/* PR c/64440 */
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+int
+foo (int x)
+{
+  const int y = 0;
+  int r = 0;
+  r += x / y; /* { dg-warning "division by zero" } */
+  r += x / 0; /* { dg-warning "division by zero" } */
+  r += x % y; /* { dg-warning "division by zero" } */
+  r += x % 0; /* { dg-warning "division by zero" } */
+  return r;
+}

Marek

Re: [Patch docs 1/5] Update the first section of md.texi

[Joseph Myers]

On Tue, 6 Jan 2015, James Greenhalgh wrote:

> > -The @file{.md} file for a target machine contains a pattern for each
> > -instruction that the target machine supports (or at least each instruction
> > -that is worth telling the compiler about).  It may also contain comments.
> > -A semicolon causes the rest of the line to be a comment, unless the 
> > semicolon
> > -is inside a quoted string.
> 
> A detailed description of the syntax of a .md file does not belong in an
> introduction. It is a deficiency of this patch set that this text is not
> added back elsewhere. Do you have any suggestions of where the text could
> sensibly go?

A section that describes the lexical structure and syntax of .md files?

> > @@ -54,50 +54,60 @@ See the next chapter for information on the C header 
> > file.
> >  @node Overview
> >  @section Overview of How the Machine Description is Used
> >  
> > -There are three main conversions that happen in the compiler:
> > +There are four main conversions that happen in the compiler:
> 
> The previous text is inaccurate.

It would seem better not to give a specific number (just as we've tried to 
keep down the number of references in the web pages to a particular 
version control system).

> I prefer the text below. We lose "without regard for the RTL template or
> operand constraints", but this is contradictory anyway, as the RTL template
> is used when expanding a define_insn.

I believe the point of "without regard for the RTL template or operand 
constraints" is that when e.g. expanding addition of two SImode values, 
the RTL template from the addsi3 pattern is inserted blindly, even if that 
RTL looks nothing like RTL for an addition; nothing looks for an (add:SI) 
pattern, or generates such RTL if it's not what the RTL for addsi3 looks 
like.

I should point out, if giving paragraph-by-paragraph rationale, that *each 
revision of the patch* needs to give the paragraph-by-paragraph rationale 
corresponding to that revision of the patch - that a piece passed over for 
one revision by one reviewer may be reviewed in more detail later or by 
another reviewer.  This may be easier with a finer-grained division of the 
patch submission.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

[Lynn A. Boger]

Sorry, hold off on this one for now.  I missed the update to 
libgo/go/reflect/all_test.go for ppc64 and ppc64le in this patch and 
when changed to actually test these goarch values it is failing.


On 01/06/2015 09:37 AM, Lynn A. Boger wrote:
Add support for reflection for gccgo in gcc 4.9.  This is not a 
backport because reflection support in gcc trunk is done using FFI. 
Bootstrap built and tested on ppc64, ppc64le.


2015-01-06Lynn Boger 

* libgo/Makefile.am:  Build the new files for libgo reflection 
support on ppc64, ppc64le

* libgo/Makefile.in:  same
* libgo/go/reflect/makefunc.go:  Invoke reflection functions for 
ppc64, ppc64le

* libgo/go/reflect/makefunc_ppc.c:  makeFuncStub for ppc64, ppc64le
* libgo/go/reflect/makefuncgo_ppc.go:  MakeFuncStubGo and argument 
handling for ppc64, ppc64le

Re: [Patch docs 0/5] Update some of md.texi

[Joseph Myers]

On Tue, 6 Jan 2015, James Greenhalgh wrote:

> > and  "Update text." is thoroughly unhelpful as a ChangeLog entry to
> > explain the intent of the changes.
> 
> Well, indeed, but ChangeLog entries have always been a
> thoroughly unhelpful "what changed" rather than "why did it
> change". (grep ": Update\." gcc/ChangeLog*) !

That should be for cases where it's e.g. a completely mechanical change 
following from a more fully described change to a file listed earlier in 
the ChangeLog entry.  For this sort of documentation patch, "what changed" 
should be more specific (e.g. if you're updating the description of passes 
to refer to gimplification then say so in the ChangeLog entry).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [C PATCH] Don't accept awkward flexarr member initialization (PR c/64417)

[Joseph Myers]

On Tue, 6 Jan 2015, Marek Polacek wrote:

> 2015-01-06  Marek Polacek  
> 
>   PR c/64417
> c/
>   * c-typeck.c (process_init_element): Disallow initialization of
>   a flexible array member with a string constant if the structure
>   is in an array.
> testsuite/
>   * gcc.c-torture/compile/pr28865.c: Add dg-errors.
>   * gcc.dg/pr64417.c: New test.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Housekeeping work in backends.html

[Jeff Law]

On 01/05/15 16:15, Eric Botcazou wrote:

Hi,

the attached patch removes obsolete ports (c4x, m68hc11 and ms1), toggles the
'p' letter and adjust accordingly (only avr, fr30, m68k, mcore, rs6000 and sh
still use define_peephole) and removes trailing spaces.

OK to commit?

Some ports are missing (lm32, moxie, nios2, nvptx, rl78, rx) so the relevant
maintainers are CCed (see 6.3.9 Anatomy of a Target Back End in the doc).

This is fine.

I might claim updating this shouldn't ever require a review :-)

jeff

Re: Patch ping and question about copyright assignment

[Joseph Myers]

On Tue, 6 Jan 2015, Mikhail Maltsev wrote:

> Hi, all!
> I'm pinging about this patch:
> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html (PR c/48956)
> I know that maybe it's too early for sending a ping (less than 2
> weeks), but I also have a question regarding my patch:
> Is this patch considered small enough to be accepted without copyright
> assignment? If it is not, I need some instructions about signing such
> an assignment.

I think this needs an assignment.  As a new feature it would also best be 
considered after GCC 5 branches rather than while trunk is in bug-fix 
mode.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Fix for PR ipa/64503

[Uros Bizjak]

On Tue, Jan 6, 2015 at 6:49 PM, Martin Liška  wrote:
> Hello.
>
> There's suggested patch for PR ipa/64503 that was tested on x86_64 and it
> works.
> I would like to ask Uros to test it on an aplha machine before we install
> the patch.

Yes, this works for me on all IPA tests that were failing previously [1].

I am restarting the bootstrap + regtest, it will take ~10 hours, but I
don't expect any surprises there.

[1] https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00400.html

Thanks,
Uros.

[PATCH] Fix for PR ipa/64503

[Martin Liška]

Hello.

There's suggested patch for PR ipa/64503 that was tested on x86_64 and it works.
I would like to ask Uros to test it on an aplha machine before we install the 
patch.

Thanks,
Martin
>From d4738c61467e53d04b295cfc029ab89707ac29ce Mon Sep 17 00:00:00 2001
From: mliska 
Date: Tue, 6 Jan 2015 12:25:51 +0100
Subject: [PATCH] Fix for ipa/PR64503

gcc/ChangeLog:

2015-01-06  Martin Liska  

	PR ipa/64503
	* sreal.c (sreal::dump): Change unsigned format to signed for
	m_exp value.
	(sreal::to_double): Replace exp2 with scalbln.
---
 gcc/sreal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/sreal.c b/gcc/sreal.c
index 82ebcb8..622fc2d 100644
--- a/gcc/sreal.c
+++ b/gcc/sreal.c
@@ -58,7 +58,7 @@ along with GCC; see the file COPYING3.  If not see
 void
 sreal::dump (FILE *file) const
 {
-  fprintf (file, "(%" PRIu64 " * 2^%d)", m_sig, m_exp);
+  fprintf (file, "(%" PRIi64 " * 2^%d)", m_sig, m_exp);
 }
 
 DEBUG_FUNCTION void
@@ -122,7 +122,7 @@ sreal::to_double () const
 {
   double val = m_sig;
   if (m_exp)
-val *= exp2 (m_exp);
+val = scalbln (val, m_exp);
   return val;
 }
 
-- 
2.1.2

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

> Date: Tue, 6 Jan 2015 10:16:33 +0100
> From: ja...@redhat.com
> To: bernd.edlin...@hotmail.de
> CC: mikest...@comcast.net; hjl.to...@gmail.com; gcc-patches@gcc.gnu.org; 
> dvyu...@google.com
> Subject: Re: [PATCH] Fix sporadic failure in 
> g++.dg/tsan/aligned_vs_unaligned_race.C
>
> On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
>> Hi Mike,
>>
>> after some hours of sleep I realized that your step function can do 
>> something very interesting,
>> (which you already requested previously):
>>
>> That is: create a race condition that is _always_ at 100% missed by tsan:
>>
>> cat lib.c
>> /* { dg-do compile } */
>> /* { dg-options "-O2 -fno-sanitize=all" } */
>>
>> static volatile int serial = 0;
>>
>> void step (int i)
>> {
>>   while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
>>   __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
>> }
>
> Such busy waiting is not very CPU time friendly in the testsuite, especially
> if you have just a single HW thread.
> If libtsan is not fixed not to be so racy, perhaps instead of all the sleeps
> we could arrange (on x86_64-linux, which is the only target supporting tsan
> right now) to make sure the thread runs on the same core/hw thread as the
> initial thread using pthread_[gs]etaffinity_np/pthread_attr_setaffinity_np ?
> Does tsan then always report the races when the threads can't run
> concurrently?
>
> Jakub

I tried your suggestion now, and it seems to work. (on a  4-way core AMD64 
laptop)

Would you prefer this over adding a sleep in Thread1, which I posted previously?




2015-01-06  Bernd Edlinger  

    * g++.dg/tsan/aligned_vs_unaligned_race.C: Fixed sporadic failure.


Index: aligned_vs_unaligned_race.C
===
--- aligned_vs_unaligned_race.C    (revision 219198)
+++ aligned_vs_unaligned_race.C    (working copy)
@@ -1,5 +1,7 @@
 /* { dg-shouldfail "tsan" } */
+/* { dg-additional-options "-pthread" } */
 #include 
+#include 
 #include 
 #include 
 
@@ -19,6 +21,12 @@ void *Thread2(void *x) {
 }
 
 int main() {
+  /* Run this test on a single CPU, to make it somewhat easier for tsan to
+ detect the race condition.  */
+  cpu_set_t s;
+  CPU_ZERO(&s);
+  CPU_SET(0, &s);
+  pthread_setaffinity_np(pthread_self(), sizeof(s), &s);
   pthread_t t[2];
   pthread_create(&t[0], NULL, Thread1, NULL);
   pthread_create(&t[1], NULL, Thread2, NULL);



Thanks,
Bernd.
  

Re: Re: [Patch docs 0/5] Update some of md.texi

[Sandra Loosemore]

On Tue, 6 Jan 2015, James Greenhalgh wrote:


On Tue, Jan 06, 2015 at 02:56:58PM +, Joseph Myers wrote:

On Tue, 6 Jan 2015, James Greenhalgh wrote:


I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.
  * Update some K&R C and make it use GNU-style.

I've split the patch to a 5-patch series, roughly covering one section
in each.


It would be much more reviewable if the patches were split logically -
each addressing only one of the five issues you mention above - rather
than physically.


That is rather difficult to tease out of a documentation patch without
ending up with a very deep patch stack. Of course such a request is
possible, but often the partial change makes little sense or improvement
without rewriting an entire section, and the burden of making the
intermediary changes read well makes the process of rewriting documentation
exceedingly laborious. Splitting to this granularity essentially requires
a per-paragraph justification.

In reality, a per-paragraph justification of my changes will be easier
for me to provide than a deep patch set. I'll try to find some time one
evening this week to "review" my patches to give this context, if that
would be acceptable.

Hopefully I'll find a few more areas where the text can be improved
along the way!


FWIW, I've had the same dilemma with edits to the GCC user documentation 
-- it's too easy to spend a few hours going through the document and end 
up with a gigantic patch that is totally unreviewable (because nobody 
really wants to take the time to go through tedious mechanical changes 
and nobody can identify the substantive changes mixed in with them or 
reconstruct your logic for making them).  I've concluded that the best 
way is *not* to try to maintain a big patch stack, but just to make 
multiple passes through the document to fix different types of problems 
incrementally.  E.g. address markup and grammar issues separately from 
rewrites of a whole section, in particular. I have a notepad where I've 
jotted down some things I've identified that are in need of fixing while 
I've been working on other things in invoke.texi, but no patches beyond 
the ones I've already posted and committed.


From time to time I've wondered if we might not be better off moving 
towards something like the Wikipedia model for maintaining the GNU 
documentation (where everyone can make or revert changes and editors are 
encouraged to make changes boldly), but WP's tools are better suited for 
that model than Texinfo, patches, and SVN.  I do think that taking a 
more lenient view of "obvious fixes" for documentation than for code 
changes is appropriate, though, since bad doc changes can simply be 
reverted and are unlikely to break GCC or hold up other developers' work 
meanwhile.  It also sometimes (often?) takes months to get code patches 
reviewed and such a heavyweight process for documentation changes would 
only discourage volunteers from undertaking such work as they have time.


-Sandra

Re: [patch] Fix ICE on unaligned record field

[Eric Botcazou]

Martin,

> I suppose that could be done by something like the following, which I
> have tested only very mildly so far, in particular I have not double
> checked that get_inner_reference is cfun-agnostic.

The patch introduces no regressions on x86-64/Linux and makes the testcase 
(gnat.dg/specs/pack12.ads attached to the first message) pass.

Do you plan to install it (along with the testcase)?

> 2014-12-03  Martin Jambor  
> 
>   * tree-sra.c (ipa_sra_check_caller_data): New type.
>   (has_caller_p): Removed.
>   (ipa_sra_check_caller): New function.
>   (ipa_sra_preliminary_function_checks): Use it.

-- 
Eric Botcazou

Re: [PATCH] Fix up DSE - PR middle-end/64388, target/55023

[John David Anglin]

On 1/6/2015 9:08 AM, Jakub Jelinek wrote:

@@ -2527,7 +2518,13 @@ scan_insn (bb_info_t bb_info, rtx_insn *
 const_call ? "const" : "memset", INSN_UID (insn));
  
  	  /* See the head comment of the frame_read field.  */

- if (reload_completed)
+ if (reload_completed
+ /* Tail calls are storing their arguments using
+arg poinnter.  If it is a frame pointer on the target,

Typo.

+even before reload we need to kill frame pointer based
+stores.  */
+ || (SIBLING_CALL_P (insn)
+ && HARD_FRAME_POINTER_IS_ARG_POINTER))
insn_info->frame_read = true;
  


I had tested this hunk before, without the 
"HARD_FRAME_POINTER_IS_ARG_POINTER"

addition, on 32-bit hppa and it resolved the original test case.

Thanks,
Dave

--
John David Anglindave.ang...@bell.net

Re: [Patch docs 1/5] Update the first section of md.texi

[James Greenhalgh]

As requested, please find a paragraph-by-paragraph justification for
the changes in this patch below.

I hope this aids review.

Of particular interest for this patch is the removal of the text
describing the semicolon for a comment syntax. I believe that a
description of the syntax of a .md file does not belong in the
introduction. I don't have a good suggestion as to where it should
move to.

Thanks,
James

On Tue, Jan 06, 2015 at 11:21:38AM +, James Greenhalgh wrote:
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index 7f0426c..0277f14 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -7,39 +7,39 @@
>  @chapter Machine Descriptions
>  @cindex machine descriptions
>  
> -A machine description has two parts: a file of instruction patterns
> -(@file{.md} file) and a C header file of macro definitions.
> +A machine description has two parts: one or more files describing the
> +instructions available on the target (@file{.md} files) and one or more
> +C/C++ source files implementing target hooks and macros.  These are
> +described in the next chapter (@pxref{Target Macros}).

The original text was inaccurate. .md files can be included in one
another, so it is wrong to say "a file". Real-world backends are not
just C header files of macro definitions.

Rather than just mentioning the next chapter, cross-reference it.

> -The @file{.md} file for a target machine contains a pattern for each
> -instruction that the target machine supports (or at least each instruction
> -that is worth telling the compiler about).  It may also contain comments.
> -A semicolon causes the rest of the line to be a comment, unless the semicolon
> -is inside a quoted string.

A detailed description of the syntax of a .md file does not belong in an
introduction. It is a deficiency of this patch set that this text is not
added back elsewhere. Do you have any suggestions of where the text could
sensibly go?

> -See the next chapter for information on the C header file.

Moved above.

> +This chapter describes the @file{.md} files for a target machine.  These
> +contain the instruction patterns which are used by the compiler when
> +expanding gimple to RTL, during the RTL optimization passes, and when
> +emitting assembler code.

New text. Give a high level overview of what is in an md file and why
we want it.

>  
>  @menu
>  * Overview::How the machine description is used.
>  * Patterns::How to write instruction patterns.
>  * Example:: An explained example of a @code{define_insn} pattern.
> -* RTL Template::The RTL template defines what insns match a pattern.
> +* RTL Template::The RTL template defines which insns may match a
> +pattern.

s/what/which/ -- This reads better to me
s/match/may match/ -- Many things can result in an RTL Template not
matching; pattern ordering, predicates, failing conditions, etc.

>  * Output Template:: The output template says how to make assembler code
> -from such an insn.
> +from an insn matched to an instruction pattern.

The previous text did not make sense. "such an insn" is not bound to
anything if I am reading the contents non-linearly (as I am likely to do).

>  * Output Statement::For more generality, write C code to output
>  the assembler code.
> -* Predicates::  Controlling what kinds of operands can be used
> -for an insn.
> +* Predicates::  Controlling which kinds of operands can be used
> +when matching an insn to an instruction pattern.

s/what/which/ -- Reads better to me.

Add text qualifying when predicates are used - predicates can't be used
to instruct register allocation after pattern matching, they are only
used in pattern matching.

>  * Constraints:: Fine-tuning operand selection.
>  * Standard Names::  Names mark patterns to use for code generation.
>  * Pattern Ordering::When the order of patterns makes a difference.
>  * Dependent Patterns::  Having one pattern may make you need another.
>  * Jump Patterns::   Special considerations for patterns for jump insns.
>  * Looping Patterns::How to define patterns for special looping insns.
> -* Insn Canonicalizations::Canonicalization of Instructions
> +* Insn Canonicalizations::Canonicalization of instructions

We don't use title case elsewhere in the descriptions.

>  * Expander Definitions::Generating a sequence of several RTL insns
>  for a standard operation.
> -* Insn Splitting::  Splitting Instructions into Multiple Instructions.
> -* Including Patterns::  Including Patterns in Machine Descriptions.
> +* Insn Splitting::  Splitting insns into multiple insns.
> +* Including Patterns::  Including patterns in machine descriptions.

Insn splitting acts on insns (a compiler concept) not instructions (a
machine concept).

We don't use title cas

[PATCH 2/2, libgo] Backport recover fix for gccgo to gcc 4.9

[Lynn A. Boger]

This is a backport to gcc 4.9 of the following change: 
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00660.html.  The original 
patch had changes required for use with the FFI reflection support.  
Since FFI is not used for reflection in gcc 4.9 those changes were omitted.


2015-01-06Lynn Boger 

* libgo/runtime/go-defer.c
* libgo/runtime/go-panic.h
* libgo/go-recover.c

Thanks

Index: libgo/runtime/go-defer.c
===
--- libgo/runtime/go-defer.c	(revision 218817)
+++ libgo/runtime/go-defer.c	(working copy)
@@ -82,6 +82,6 @@ __go_set_defer_retaddr (void *retaddr)
 
   g = runtime_g ();
   if (g->defer != NULL)
-g->defer->__retaddr = retaddr;
+g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
   return 0;
 }
Index: libgo/runtime/go-panic.h
===
--- libgo/runtime/go-panic.h	(revision 218817)
+++ libgo/runtime/go-panic.h	(working copy)
@@ -38,6 +38,12 @@ extern void __go_print_string (struct String);
 
 extern struct __go_empty_interface __go_recover (void);
 
+extern _Bool __go_can_recover (void *);
+
+extern void __go_makefunc_can_recover (void *retaddr);
+
+extern void __go_makefunc_returning (void);
+
 extern void __go_unwind_stack (void);
 
 #endif /* !defined(LIBGO_GO_PANIC_H) */
Index: libgo/runtime/go-recover.c
===
--- libgo/runtime/go-recover.c	(revision 218817)
+++ libgo/runtime/go-recover.c	(working copy)
@@ -9,6 +9,36 @@
 #include "go-panic.h"
 #include "go-defer.h"
 
+/* If the top of the defer stack can be recovered, then return it.
+   Otherwise return NULL.  */
+
+static struct __go_defer_stack *
+current_defer ()
+{
+  G *g;
+  struct __go_defer_stack *d;
+
+  g = runtime_g ();
+
+  d = g->defer;
+  if (d == NULL)
+return NULL;
+
+  /* The panic which would be recovered is the one on the top of the
+ panic stack.  We do not want to recover it if that panic was on
+ the top of the panic stack when this function was deferred.  */
+  if (d->__panic == g->panic)
+return NULL;
+
+  /* The deferred thunk will call _go_set_defer_retaddr.  If this has
+ not happened, then we have not been called via defer, and we can
+ not recover.  */
+  if (d->__retaddr == NULL)
+return NULL;
+
+  return d;
+}
+
 /* This is called by a thunk to see if the real function should be
permitted to recover a panic value.  Recovering a value is
permitted if the thunk was called directly by defer.  RETADDR is
@@ -16,79 +46,127 @@
__go_can_recover--this is, the thunk.  */
 
 _Bool
-__go_can_recover (const void *retaddr)
+__go_can_recover (void *retaddr)
 {
-  G *g;
   struct __go_defer_stack *d;
   const char* ret;
   const char* dret;
-  Location loc;
+  Location locs[16];
   const byte *name;
+  intgo len;
+  int n;
+  int i;
+  _Bool found_ffi_callback;
 
-  g = runtime_g ();
-
-  d = g->defer;
+  d = current_defer ();
   if (d == NULL)
 return 0;
 
-  /* The panic which this function would recover is the one on the top
- of the panic stack.  We do not want to recover it if that panic
- was on the top of the panic stack when this function was
- deferred.  */
-  if (d->__panic == g->panic)
-return 0;
+  ret = (const char *) __builtin_extract_return_addr (retaddr);
 
-  /* D->__RETADDR is the address of a label immediately following the
- call to the thunk.  We can recover a panic if that is the same as
- the return address of the thunk.  We permit a bit of slack in
- case there is any code between the function return and the label,
- such as an instruction to adjust the stack pointer.  */
-
-  ret = (const char *) retaddr;
-
-#ifdef __sparc__
-  /* On SPARC the address we get, from __builtin_return_address, is
- the address of the call instruction.  Adjust forward, also
- skipping the delayed instruction following the call.  */
-  ret += 8;
-#endif
-
   dret = (const char *) d->__retaddr;
   if (ret <= dret && ret + 16 >= dret)
 return 1;
 
-  /* If the function calling recover was created by reflect.MakeFunc,
- then RETADDR will be somewhere in libffi.  Our caller is
- permitted to recover if it was called from libffi.  */
-  if (!d->__makefunc_can_recover)
-return 0;
+  /* On some systems, in some cases, the return address does not work
+ reliably.  See http://gcc.gnu.org/PR60406.  If we are permitted
+ to call recover, the call stack will look like this:
+   __go_panic, __go_undefer, etc.
+   thunk to call deferred function (calls __go_set_defer_retaddr)
+   function that calls __go_can_recover (passing return address)
+   __go_can_recover
+ Calling runtime_callers will skip the thunks.  So if our caller's
+ caller starts with __go, then we are permitted to call
+ recover.  */
 
-  if (runtime_callers (2, &loc, 1) < 1)
+  if (runtime_callers (1, &locs[0], 2) < 2)
 

[PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9

[Lynn A. Boger]

Add support for reflection for gccgo in gcc 4.9.  This is not a backport 
because reflection support in gcc trunk is done using FFI. Bootstrap 
built and tested on ppc64, ppc64le.


2015-01-06Lynn Boger 

* libgo/Makefile.am:  Build the new files for libgo reflection 
support on ppc64, ppc64le

* libgo/Makefile.in:  same
* libgo/go/reflect/makefunc.go:  Invoke reflection functions for 
ppc64, ppc64le

* libgo/go/reflect/makefunc_ppc.c:  makeFuncStub for ppc64, ppc64le
* libgo/go/reflect/makefuncgo_ppc.go:  MakeFuncStubGo and argument 
handling for ppc64, ppc64le



Index: libgo/Makefile.am
===
--- libgo/Makefile.am	(revision 219198)
+++ libgo/Makefile.am	(working copy)
@@ -925,11 +925,25 @@ go_reflect_makefunc_file = \
 go_reflect_makefunc_s_file = \
 	go/reflect/makefunc_386.S
 else
+if LIBGO_IS_PPC64
+go_reflect_makefunc_file = \
+	go/reflect/makefuncgo_ppc.go
+go_reflect_makefunc_s_file = \
+	go/reflect/makefunc_ppc.c
+else
+if LIBGO_IS_PPC64LE
+go_reflect_makefunc_file = \
+	go/reflect/makefuncgo_ppc.go
+go_reflect_makefunc_s_file = \
+	go/reflect/makefunc_ppc.c
+else
 go_reflect_makefunc_file =
 go_reflect_makefunc_s_file = \
 	go/reflect/makefunc_dummy.c
 endif
 endif
+endif
+endif
 
 go_reflect_files = \
 	go/reflect/deepequal.go \
Index: libgo/Makefile.in
===
--- libgo/Makefile.in	(revision 219198)
+++ libgo/Makefile.in	(working copy)
@@ -1097,7 +1097,13 @@ go_path_files = \
 	go/path/match.go \
 	go/path/path.go
 
-@LIBGO_IS_386_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_file = 
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_FALSE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_file = 
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_TRUE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_file = \
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_TRUE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefuncgo_ppc.go
+
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64_TRUE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_file = \
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64_TRUE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefuncgo_ppc.go
+
 @LIBGO_IS_386_TRUE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_file = \
 @LIBGO_IS_386_TRUE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefuncgo_386.go
 
@@ -1104,9 +1110,15 @@ go_path_files = \
 @LIBGO_IS_X86_64_TRUE@go_reflect_makefunc_file = \
 @LIBGO_IS_X86_64_TRUE@	go/reflect/makefuncgo_amd64.go
 
-@LIBGO_IS_386_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_s_file = \
-@LIBGO_IS_386_FALSE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefunc_dummy.c
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_FALSE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_s_file = \
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_FALSE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefunc_dummy.c
 
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_TRUE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_s_file = \
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64LE_TRUE@@LIBGO_IS_PPC64_FALSE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefunc_ppc.c
+
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64_TRUE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_s_file = \
+@LIBGO_IS_386_FALSE@@LIBGO_IS_PPC64_TRUE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefunc_ppc.c
+
 @LIBGO_IS_386_TRUE@@LIBGO_IS_X86_64_FALSE@go_reflect_makefunc_s_file = \
 @LIBGO_IS_386_TRUE@@LIBGO_IS_X86_64_FALSE@	go/reflect/makefunc_386.S
 
Index: libgo/go/reflect/makefunc.go
===
--- libgo/go/reflect/makefunc.go	(revision 219198)
+++ libgo/go/reflect/makefunc.go	(working copy)
@@ -52,7 +52,7 @@ func MakeFunc(typ Type, fn func(args []Value) (res
 	}
 
 	switch runtime.GOARCH {
-	case "amd64", "386":
+	case "amd64", "386", "ppc64", "ppc64le":
 	default:
 		panic("reflect.MakeFunc not implemented for " + runtime.GOARCH)
 	}
@@ -91,7 +91,7 @@ func makeMethodValue(op string, v Value) Value {
 	}
 
 	switch runtime.GOARCH {
-	case "amd64", "386":
+	case "amd64", "386", "ppc64", "ppc64le":
 	default:
 		panic("reflect.makeMethodValue not implemented for " + runtime.GOARCH)
 	}
@@ -138,7 +138,7 @@ func makeValueMethod(v Value) Value {
 	}
 
 	switch runtime.GOARCH {
-	case "amd64", "386":
+	case "amd64", "386", "ppc64", "ppc64le":
 	default:
 		panic("reflect.makeValueMethod not implemented for " + runtime.GOARCH)
 	}
Index: libgo/go/reflect/makefunc_ppc.c
===
--- libgo/go/reflect/makefunc_ppc.c	(revision 0)
+++ libgo/go/reflect/makefunc_ppc.c	(working copy)
@@ -0,0 +1,102 @@
+// Copyright 2015 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+#include "runtime.h"
+#include "go-panic.h"
+
+extern void MakeFuncStubGo(void *, void *) asm ("reflect.MakeFuncStubGo");
+
+/* Structure to store all registers used for paramete

Re: [Patch docs 0/5] Update some of md.texi

[James Greenhalgh]

On Tue, Jan 06, 2015 at 02:56:58PM +, Joseph Myers wrote:
> On Tue, 6 Jan 2015, James Greenhalgh wrote:
> 
> > I was aiming to:
> > 
> >   * Remove outdated details of the compiler.
> >   * Remove long or obscure words that, while accurate, only served to
> > obfuscate a simple idea.
> >   * Refer to similar things in a consistent fashion - in particular
> > trying to keep consistent use of "insn" and "pattern".
> >   * Remove superflous examples, or waffling.
> >   * Update some K&R C and make it use GNU-style.
> > 
> > I've split the patch to a 5-patch series, roughly covering one section
> > in each.
> 
> It would be much more reviewable if the patches were split logically - 
> each addressing only one of the five issues you mention above - rather 
> than physically.

That is rather difficult to tease out of a documentation patch without
ending up with a very deep patch stack. Of course such a request is
possible, but often the partial change makes little sense or improvement
without rewriting an entire section, and the burden of making the
intermediary changes read well makes the process of rewriting documentation
exceedingly laborious. Splitting to this granularity essentially requires
a per-paragraph justification.

In reality, a per-paragraph justification of my changes will be easier
for me to provide than a deep patch set. I'll try to find some time one
evening this week to "review" my patches to give this context, if that
would be acceptable.

Hopefully I'll find a few more areas where the text can be improved
along the way!

> and  "Update text." is thoroughly unhelpful as a ChangeLog entry to
> explain the intent of the changes.

Well, indeed, but ChangeLog entries have always been a
thoroughly unhelpful "what changed" rather than "why did it
change". (grep ": Update\." gcc/ChangeLog*) !

Thanks,
James

[PATCH 0/2] Add reflection support for ppc64, ppc64le to gcc 4.9

[Lynn A. Boger]

Please add the following pair of patches to gcc 4.9.  These two patches add
 reflection support for ppc64 & ppc64le to gccgo in gcc 4.9, along with 
a fix for recover that is needed once the reflection support is in 
place.   A bootstrap

build and testing was done on ppc64 & ppc64le.

Changes include:
0001:  Reflection support in libgo for ppc64 & ppc64le.  This is not a
backport because in gcc trunk reflection is done using FFI.

0002:  Backport of a fix for the recover.go testcase which is needed once
reflection support is in place for ppc64 & ppc64le.

[Patch, Fortran, F03] PR 64508: interface check missing for procedure pointer component as actual argument

[Janus Weil]

Hi all,

here is a patch which adds an interface check for procedure pointer
components as acual arguments. Such a check is there already for
ordinary procedures and procedure pointers, but missing for PPCs. It
checks the interface of the actual argument versus the interface of
the dummy procedure, according to the usual rules.

Regtested on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus



2015-01-06  Janus Weil  

PR fortran/64508
* interface.c (compare_parameter): Interface check for
procedure-pointer component as actual argument.

2015-01-06  Janus Weil  

PR fortran/64508
* gfortran.dg/proc_ptr_comp_41.f90: New.
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (Revision 219261)
+++ gcc/fortran/interface.c (Arbeitskopie)
@@ -1922,6 +1922,8 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
 {
   gfc_ref *ref;
   bool rank_check, is_pointer;
+  char err[200];
+  gfc_component *ppc;
 
   /* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
  procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -1942,7 +1944,6 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
 
   if (actual->ts.type == BT_PROCEDURE)
 {
-  char err[200];
   gfc_symbol *act_sym = actual->symtree->n.sym;
 
   if (formal->attr.flavor != FL_PROCEDURE)
@@ -1976,6 +1977,19 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
   return 1;
 }
 
+  ppc = gfc_get_proc_ptr_comp (actual);
+  if (ppc)
+{
+  if (!gfc_compare_interfaces (formal, ppc->ts.interface, ppc->name, 0, 1,
+  err, sizeof(err), NULL, NULL))
+   {
+ if (where)
+   gfc_error ("Interface mismatch in dummy procedure %qs at %L: %s",
+  formal->name, &actual->where, err);
+ return 0;
+   }
+}
+
   /* F2008, C1241.  */
   if (formal->attr.pointer && formal->attr.contiguous
   && !gfc_is_simply_contiguous (actual, true))
! { dg-do compile }
!
! PR 64508: [F03] interface check missing for procedure pointer component as actual argument
!
! Contributed by Janus Weil 

  TYPE :: parent
  END TYPE

  TYPE, EXTENDS(parent) :: extension
procedure(extension_proc), pointer :: ppc
  END TYPE

  CLASS(extension), ALLOCATABLE :: x
  CALL some_proc(x%ppc)   !  { dg-error "Interface mismatch in dummy procedure" }

contains

  SUBROUTINE parent_proc(arg)
CLASS(parent), INTENT(IN) :: arg
  END SUBROUTINE

  SUBROUTINE extension_proc(arg)
CLASS(extension), INTENT(IN) :: arg
  END SUBROUTINE


  SUBROUTINE some_proc(proc)
PROCEDURE(parent_proc) :: proc
TYPE(Parent) :: a
CALL proc(a)
  END SUBROUTINE

end

Re: [Patch docs 0/5] Update some of md.texi

[Joseph Myers]

On Tue, 6 Jan 2015, James Greenhalgh wrote:

> I was aiming to:
> 
>   * Remove outdated details of the compiler.
>   * Remove long or obscure words that, while accurate, only served to
> obfuscate a simple idea.
>   * Refer to similar things in a consistent fashion - in particular
> trying to keep consistent use of "insn" and "pattern".
>   * Remove superflous examples, or waffling.
>   * Update some K&R C and make it use GNU-style.
> 
> I've split the patch to a 5-patch series, roughly covering one section
> in each.

It would be much more reviewable if the patches were split logically - 
each addressing only one of the five issues you mention above - rather 
than physically.  As is, I have no idea of the motivation of each of the 
changes made by each patch (and, as applicable, the rationale for 
considering the change to be (a) correct, (b) not removing any useful 
information (for example, the first patch appears to remove the only 
documentation of .md comment syntax, but there is no discussion of this 
point anywhere in the write-up of that patch), (c) an improvement), and 
"Update text." is thoroughly unhelpful as a ChangeLog entry to explain the 
intent of the changes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all

[Segher Boessenkool]

On Tue, Jan 06, 2015 at 01:04:29PM +0100, Eric Botcazou wrote:
> > I normally build with --disable-libsanitizer, because the sanitizers
> > testresults are very unreproducable, so just annoying noise.  This however
> > makes most (all?) ubsan testcases fail, since they want to load a shared
> > library that does not exist.
> 
> Same here, but I also have the problem with tsan testcases.

That already exited early for me because -ltsan couldn't be found.
Probably because I started using --disable-libsanitizer before tsan
existed, so it cannot be found in my install dir (which is the _old_
version in any case, I didn't run "make install" yet, but it is
still searching there for the compile test).


Segher

[PATCH] Fix up DSE - PR middle-end/64388, target/55023

[Jakub Jelinek]

Hi!

On Mon, Jan 05, 2015 at 10:31:17PM +0100, Jakub Jelinek wrote:
> Or you could e.g. do the
>   if (HARD_FRAME_POINTER_IS_ARG_POINTER
>   && !reload_completed
>   && SIBLING_CALL_P (insn))
> { add_wild_read (bb_info); return; }
> case first, then compute const_call and memset_call,
>   if (const_call || memset_call)
> { current_big_block }
>   else if (reload_completed && SIBLING_CALL_P (insn))
> add_wild_read (bb_info);
>   else
> add_non_frame_wild_read (bb_info);
> 
> That way, you would not punish const/memset calls unnecessarily after reload
> when they are sibling calls.

So what about this way?  Even for the HARD_FRAME_POINTER_IS_ARG_POINTER
before reload case, there is no reason for wild read IMHO, just setting
frame_read should do all that is necessary.  Bootstrapped/regtested on
x86_64-linux and i686-linux, tested on the pr55023 testcase with cross
to hppa-linux.  Ok for trunk?

2015-01-06  Jakub Jelinek  

PR target/55023
PR middle-end/64388
* dse.c (struct insn_info): Mention frame_read set also
before reload for tail calls on some targets.
(scan_insn): Revert 2014-12-22 change.  Set frame_read
also before reload for tail calls if
HARD_FRAME_POINTER_IS_ARG_POINTER.  Call add_wild_read
instead of add_non_frame_wild_read for non-const/memset
tail calls after reload.

--- gcc/dse.c.jj2015-01-05 22:41:19.0 +0100
+++ gcc/dse.c   2015-01-06 11:39:39.450832915 +0100
@@ -371,9 +371,11 @@ struct insn_info
either stack pointer or hard frame pointer based.  This means
that we have no other choice than also killing all the frame
pointer based stores upon encountering a const function call.
- This field is set after reload for const function calls.  Having
- this set is less severe than a wild read, it just means that all
- the frame related stores are killed rather than all the stores.  */
+ This field is set after reload for const function calls and before
+ reload for const tail function calls on targets where arg pointer
+ is the frame pointer.  Having this set is less severe than a wild
+ read, it just means that all the frame related stores are killed
+ rather than all the stores.  */
   bool frame_read;
 
   /* This field is only used for the processing of const functions.
@@ -2483,17 +2485,6 @@ scan_insn (bb_info_t bb_info, rtx_insn *
 
   insn_info->cannot_delete = true;
 
-  /* Arguments for a sibling call that are pushed to memory are passed
-using the incoming argument pointer of the current function.  These
-may or may not be frame related depending on the target.  Since
-argument pointer related stores are not currently tracked, we treat
-a sibling call as though it does a wild read.  */
-  if (SIBLING_CALL_P (insn))
-   {
- add_wild_read (bb_info);
- return;
-   }
-
   /* Const functions cannot do anything bad i.e. read memory,
 however, they can read their parameters which may have
 been pushed onto the stack.
@@ -2527,7 +2518,13 @@ scan_insn (bb_info_t bb_info, rtx_insn *
 const_call ? "const" : "memset", INSN_UID (insn));
 
  /* See the head comment of the frame_read field.  */
- if (reload_completed)
+ if (reload_completed
+ /* Tail calls are storing their arguments using
+arg poinnter.  If it is a frame pointer on the target,
+even before reload we need to kill frame pointer based
+stores.  */
+ || (SIBLING_CALL_P (insn)
+ && HARD_FRAME_POINTER_IS_ARG_POINTER))
insn_info->frame_read = true;
 
  /* Loop over the active stores and remove those which are
@@ -2601,7 +2598,11 @@ scan_insn (bb_info_t bb_info, rtx_insn *
}
}
}
-
+  else if (SIBLING_CALL_P (insn) && reload_completed)
+   /* Arguments for a sibling call that are pushed to memory are passed
+  using the incoming argument pointer of the current function.  After
+  reload that might be (and likely is) frame pointer based.  */
+   add_wild_read (bb_info);
   else
/* Every other call, including pure functions, may read any memory
that is not relative to the frame.  */


Jakub

Re: [PATCH] Don't make all MEM_REFs with TREE_READONLY arguments TREE_READONLY (PR sanitizer/64336)

[Jakub Jelinek]

On Wed, Dec 17, 2014 at 03:28:15PM +0100, Richard Biener wrote:
> On Wed, 17 Dec 2014, Jakub Jelinek wrote:
> 
> > Hi!
> > 
> > MEM_REF (the only tcc_reference code with 2 operands) has TREE_READONLY set
> > whenever all the arguments are TREE_READONLY, which is wrong, if the
> > pointer/reference is read-only, it doesn't say anything about whether
> > what it points to is also read-only.
> > 
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> > trunk?
> 
> Thinking about this some more I think that we should instead do sth like
> 
>   read_only = 1;
>   side_effects = TREE_SIDE_EFFECTS (t);
> 
>   if (code == MEM_REF)
>{
>  if (TREE_CODE (arg0) == ADDR_EXPR)
>{
>  tree t = arg0;
>  PROCESS_ARG (0);
>}
>  else
>read_only = 0;

This doesn't work, PROCESS_ARG among other things assigns the arguments,
computing the flags is just one thing.  So the above would crash if arg0 is
NULL (also happens), and if it is ADDR_EXPR would attempt to assign
TREE_OPERANDS (arg0, 0) = arg0; and otherwise leave the argument NULL.

Here is a new version of the patch, the flags should be preinitialized to
0 by make_node_stat, so can be assigned for *MEM_REFs only if arg0 is
ADDR_EXPR, 0 is right otherwise for both flags.  In generic code MEM_REF
is the only 2 operand tcc_reference, but C++ FE has some further ones,
so I need to keep the old TREE_THIS_VOLATILE assignment.  There are no
5 operand tcc_references beyond TARGET_MEM_REF, but I'd keep it this way
as is anyway.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2015-01-06  Jakub Jelinek  

PR sanitizer/64336
* tree.c (build2_stat): Fix up initialization of TREE_READONLY
and TREE_THIS_VOLATILE for MEM_REFs.
(build5_stat): Fix up initialization of TREE_READONLY and
TREE_THIS_VOLATILE for TARGET_MEM_REFs.

--- gcc/tree.c.jj   2015-01-05 13:07:15.0 +0100
+++ gcc/tree.c  2015-01-06 12:33:46.466016025 +0100
@@ -4358,12 +4358,24 @@ build2_stat (enum tree_code code, tree t
   PROCESS_ARG (0);
   PROCESS_ARG (1);
 
-  TREE_READONLY (t) = read_only;
-  TREE_CONSTANT (t) = constant;
   TREE_SIDE_EFFECTS (t) = side_effects;
-  TREE_THIS_VOLATILE (t)
-= (TREE_CODE_CLASS (code) == tcc_reference
-   && arg0 && TREE_THIS_VOLATILE (arg0));
+  if (code == MEM_REF)
+{
+  if (arg0 && TREE_CODE (arg0) == ADDR_EXPR)
+   {
+ tree o = TREE_OPERAND (arg0, 0);
+ TREE_READONLY (t) = TREE_READONLY (o);
+ TREE_THIS_VOLATILE (t) = TREE_THIS_VOLATILE (o);
+   }
+}
+  else
+{
+  TREE_READONLY (t) = read_only;
+  TREE_CONSTANT (t) = constant;
+  TREE_THIS_VOLATILE (t)
+   = (TREE_CODE_CLASS (code) == tcc_reference
+  && arg0 && TREE_THIS_VOLATILE (arg0));
+}
 
   return t;
 }
@@ -4458,9 +4470,19 @@ build5_stat (enum tree_code code, tree t
   PROCESS_ARG (4);
 
   TREE_SIDE_EFFECTS (t) = side_effects;
-  TREE_THIS_VOLATILE (t)
-= (TREE_CODE_CLASS (code) == tcc_reference
-   && arg0 && TREE_THIS_VOLATILE (arg0));
+  if (code == TARGET_MEM_REF)
+{
+  if (arg0 && TREE_CODE (arg0) == ADDR_EXPR)
+   {
+ tree o = TREE_OPERAND (arg0, 0);
+ TREE_READONLY (t) = TREE_READONLY (o);
+ TREE_THIS_VOLATILE (t) = TREE_THIS_VOLATILE (o);
+   }
+}
+  else
+TREE_THIS_VOLATILE (t)
+  = (TREE_CODE_CLASS (code) == tcc_reference
+&& arg0 && TREE_THIS_VOLATILE (arg0));
 
   return t;
 }


Jakub

Re: [patch] New std::string implementation

[Jonathan Wakely]

On 06/01/15 13:29 +0100, Rainer Orth wrote:

Jonathan Wakely  writes:


Drat, I even tried to avoid that conflict, but apparently I thought
the letter that comes after 'n' is 'n'!

Does this fix it?

--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
  std::locale::none*;
  std::locale::numeric*;
-  std::locale::[A-Zn-z]*;
+  std::locale::[A-Zo-z]*;
  std::locale::_[A-Ha-z]*;
  std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;


it does indeed.


Thanks for checking it. Tested x86_64-linux and committed to trunk.


commit e25934d17d4bb1c06bd76e923569a00ad0e66a18
Author: Jonathan Wakely 
Date:   Tue Jan 6 11:03:31 2015 +

	* config/abi/pre/gnu.ver: Fix version conflict for std::locale::name().

diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index e680e99..7bb65e9 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
 # std::locale::name();
   std::locale::none*;
   std::locale::numeric*;
-  std::locale::[A-Zn-z]*;
+  std::locale::[A-Zo-z]*;
   std::locale::_[A-Ha-z]*;
   std::locale::_Impl::[A-Za-z]*;
 # std::locale::_Impl::_M_[A-Za-z]*;

[C PATCH] Don't accept awkward flexarr member initialization (PR c/64417)

[Marek Polacek]

This PR shows that the C FE accepts an invalid code, where
a flexible array member is being initialized with a string
constant, but the structure with the flexible array member
is in an array.  GNU extension that allows initialization
of a flexible array members is a little bit of a gray area,
since we allow it even in some cases where the struct with
the flexible array member is not a top-level object, e.g.
struct in an union.  But an array with entries of different
size Just Can't Be Right.  Hopefully no existing code relies
on this "feature" (glibc should be ok).

Note that in
struct S { int x; char y[]; };
struct S s[] = { { 1, { 'a', '\0' } } };
struct S s2[] = { { 1, "a" } };
we already reject 's', but not 's2'.  I think we should eventually
also reject e.g.
struct A { int a; char b[]; };
struct B { struct A a; int i; };
struct B b = { { 1, "abc" }, 2 };
because the structure 'a' is not at the end of struct B.

Bootstrapped/regtested on {ppc64,x86_64}-linux, ok for trunk?

2015-01-06  Marek Polacek  

PR c/64417
c/
* c-typeck.c (process_init_element): Disallow initialization of
a flexible array member with a string constant if the structure
is in an array.
testsuite/
* gcc.c-torture/compile/pr28865.c: Add dg-errors.
* gcc.dg/pr64417.c: New test.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 0db43cc..38ba9b8 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -8809,6 +8809,33 @@ process_init_element (location_t loc, struct c_expr 
value, bool implicit,
  break;
}
 
+ /* Error for initialization of a flexible array member with
+a string constant if the structure is in an array.  E.g.:
+struct S { int x; char y[]; };
+struct S s[] = { { 1, "foo" } };
+is invalid.  */
+ if (string_flag
+ && fieldcode == ARRAY_TYPE
+ && constructor_depth > 1
+ && TYPE_SIZE (fieldtype) == NULL_TREE
+ && DECL_CHAIN (constructor_fields) == NULL_TREE)
+   {
+ bool in_array_p = false;
+ for (struct constructor_stack *p = constructor_stack;
+  p && p->type; p = p->next)
+   if (TREE_CODE (p->type) == ARRAY_TYPE)
+ {
+   in_array_p = true;
+   break;
+ }
+ if (in_array_p)
+   {
+ error_init (loc, "initialization of flexible array "
+ "member in a nested context");
+ break;
+   }
+   }
+
  /* Accept a string constant to initialize a subarray.  */
  if (value.value != 0
  && fieldcode == ARRAY_TYPE
diff --git gcc/testsuite/gcc.c-torture/compile/pr28865.c 
gcc/testsuite/gcc.c-torture/compile/pr28865.c
index aa6ae07..ef0eba54 100644
--- gcc/testsuite/gcc.c-torture/compile/pr28865.c
+++ gcc/testsuite/gcc.c-torture/compile/pr28865.c
@@ -5,12 +5,12 @@ struct var_len
 };
 
 /* Note - strictly speaking this array declaration is illegal
-   since each element has a variable length.  GCC allows it
-   (for the moment) because it is used in existing code, such
-   as glibc.  */
+   since each element has a variable length.  We used to allow
+   this because it was used in existing code.
+   Since PR64417 we reject this code.  */
 static const struct var_len var_array[] = 
 {
-  { 1, "Long exposure noise reduction" },
-  { 2, "Shutter/AE lock buttons" },
-  { 3, "Mirror lockup" }
+  { 1, "Long exposure noise reduction" }, /* { dg-error "initialization of 
flexible array member" } */
+  { 2, "Shutter/AE lock buttons" }, /* { dg-error "initialization of flexible 
array member" } */
+  { 3, "Mirror lockup" } /* { dg-error "initialization of flexible array 
member" } */
 };
diff --git gcc/testsuite/gcc.dg/pr64417.c gcc/testsuite/gcc.dg/pr64417.c
index e69de29..15a336d 100644
--- gcc/testsuite/gcc.dg/pr64417.c
+++ gcc/testsuite/gcc.dg/pr64417.c
@@ -0,0 +1,16 @@
+/* PR c/64417 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+struct foo { int x; char y[]; };
+struct bar { struct foo f; };
+struct baz { struct bar b; };
+
+struct foo a1 = { 1, "abc" };
+struct foo a2 = { 1, { "abc" } };
+struct foo b1[] = { { 1, "abc" } }; /* { dg-error "initialization of flexible 
array member" } */
+struct foo b2[] = { { 1, { "abc" } } }; /* { dg-error "initialization of 
flexible array member" } */
+struct bar c1[] = { { { 1, "abc" } } }; /* { dg-error "initialization of 
flexible array member" } */
+struct bar c2[] = { { { 1, { "abc" } } } }; /* { dg-error "initialization of 
flexible array member" } */
+struct baz d1[] = { { { { 1, "abc" } } } }; /* { dg-error "initialization of 
flexible array member" } */
+struct baz d2[] = { { { { 1, { "abc" } } } } }; /* { dg-error "initialization 
of flexible array member" } */

Marek

[MIPS] Update the ZC constraint for MIPSR6 and use it

[Matthew Fortune]

Update the ZC constraint for MIPSR6 to allow it to be used as the memory
operand for implementations of atomic operations.  Also switch the internal
implementation of atomic operations to use ZC instead of ZR.

This fix accurately describes the memory constraints for the LL and SC
instructions.  An offset can therefore be used to access a data item
(ie. %lo ()) rather than always having to load the address into a
register.  Tested for mips32r2, mips32r6 and micromips.

gcc/

* config/mips/constraints.md (ZC): Add support for R6 LL/SC
offsets.
(ZD): Update to use ISA_HAS_PREF_LL_SC_9BIT.
* config/mips/mips.h (ISA_HAS_PREFETCH_9BIT): Rename to...
(ISA_HAS_PREF_LL_SC_9BIT): ... this. New macro.
* config/mips/sync.md (sync_compare_and_swap): Use ZC
instead of ZR for the memory operand of LL/SC.
(compare_and_swap_12, sync_add): Likewise.
(sync__12, sync_old__12): Likewise.
(sync_new__12, sync_nand_12): Likewise.
(sync_old_nand_12, sync_new_nand_12): Likewise.
(sync_sub, sync_old_add): Likewise.
(sync_old_sub, sync_new_add): Likewise.
(sync_new_sub, sync_): Likewise.
(sync_old_, sync_new_"): Likewise.
(sync_nand, sync_old_nand): Likewise.
(sync_new_nand, sync_lock_test_and_set): Likewise.
(test_and_set_12, atomic_compare_and_swap): Likewise.
(atomic_exchange_llsc, atomic_fetch_add_llsc): Likewise.
* doc/md.texi (ZC): Update description.

OK to commit?

Thanks,
Matthew

---
 gcc/config/mips/constraints.md | 14 ++--
 gcc/config/mips/mips.h |  4 ++--
 gcc/config/mips/sync.md| 50 +-
 gcc/doc/md.texi|  8 +++
 4 files changed, 37 insertions(+), 39 deletions(-)

diff --git a/gcc/config/mips/constraints.md b/gcc/config/mips/constraints.md
index 816880c..f5f257d 100644
--- a/gcc/config/mips/constraints.md
+++ b/gcc/config/mips/constraints.md
@@ -309,23 +309,23 @@ (define_constraint "Yx"
(match_operand 0 "low_bitmask_operand"))
 
 (define_memory_constraint "ZC"
-  "When compiling microMIPS code, this constraint matches a memory operand
-   whose address is formed from a base register and a 12-bit offset.  These
-   operands can be used for microMIPS instructions such as @code{ll} and
-   @code{sc}.  When not compiling for microMIPS code, @code{ZC} is
-   equivalent to @code{R}."
+  "A memory operand whose address is formed by a base register and offset
+   that is suitable for use in instructions with the same addressing mode
+   as @code{ll} and @code{sc}."
   (and (match_code "mem")
(if_then_else
 (match_test "TARGET_MICROMIPS")
 (match_test "umips_12bit_offset_address_p (XEXP (op, 0), mode)")
-(match_test "mips_address_insns (XEXP (op, 0), mode, false)"
+(if_then_else (match_test "ISA_HAS_PREF_LL_SC_9BIT")
+  (match_test "mips_9bit_offset_address_p (XEXP (op, 0), mode)")
+  (match_test "mips_address_insns (XEXP (op, 0), mode, false)")
 
 (define_address_constraint "ZD"
   "An address suitable for a @code{prefetch} instruction, or for any other
instruction with the same addressing mode as @code{prefetch}."
(if_then_else (match_test "TARGET_MICROMIPS")
 (match_test "umips_12bit_offset_address_p (op, mode)")
- (if_then_else (match_test "ISA_HAS_PREFETCH_9BIT")
+ (if_then_else (match_test "ISA_HAS_PREF_LL_SC_9BIT")
(match_test "mips_9bit_offset_address_p (op, mode)")
(match_test "mips_address_insns (op, mode, false)"
 
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 9dad480..b608b17 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1089,8 +1089,8 @@ struct mips_cpu_info {
  || mips_isa_rev >= 1) \
 && !TARGET_MIPS16)
 
-/* ISA has data prefetch with limited 9-bit displacement.  */
-#define ISA_HAS_PREFETCH_9BIT  (mips_isa_rev >= 6)
+/* ISA has data prefetch, LL and SC with limited 9-bit displacement.  */
+#define ISA_HAS_PREF_LL_SC_9BIT(mips_isa_rev >= 6)
 
 /* ISA has data indexed prefetch instructions.  This controls use of
'prefx', along with TARGET_HARD_FLOAT and TARGET_DOUBLE_FLOAT.
diff --git a/gcc/config/mips/sync.md b/gcc/config/mips/sync.md
index cf6c05b..72d2fe4 100644
--- a/gcc/config/mips/sync.md
+++ b/gcc/config/mips/sync.md
@@ -59,7 +59,7 @@ (define_insn "*memory_barrier"
 ;; Can be removed in favor of atomic_compare_and_swap below.
 (define_insn "sync_compare_and_swap"
   [(set (match_operand:GPR 0 "register_operand" "=&d,&d")
-   (match_operand:GPR 1 "memory_operand" "+ZR,ZR"))
+   (match_operand:GPR 1 "memory_operand" "+ZC,ZC"))
(set (match_dup 1)
(unspec_volatile:GPR [(match_operand:GPR 2 "reg_or_0_operand" "dJ,dJ")
  (match_operand:G

Re: [patch] New std::string implementation

[Rainer Orth]

Jonathan Wakely  writes:

> Drat, I even tried to avoid that conflict, but apparently I thought
> the letter that comes after 'n' is 'n'!
>
> Does this fix it?
>
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -118,7 +118,7 @@ GLIBCXX_3.4 {
> # std::locale::name();
>   std::locale::none*;
>   std::locale::numeric*;
> -  std::locale::[A-Zn-z]*;
> +  std::locale::[A-Zo-z]*;
>   std::locale::_[A-Ha-z]*;
>   std::locale::_Impl::[A-Za-z]*;
> # std::locale::_Impl::_M_[A-Za-z]*;

it does indeed.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all

[Eric Botcazou]

> What errors do you get?  Just curious.

Something along of "cannot load libtsan.so.0" and this comes from PR 58867.

> That said, I think your patch is fine.

Thanks, installed after testing on x86-64/Linux.

-- 
Eric Botcazou

Re: [PATCH][SH] Check for 0 length with inlined strnlen builtin

[Christian Bruel]

Please use 'gen_cmpeqsi_t (len, const0_rtx)' for comparing a value
against zero instead of the bit test insn.


OK, also then OK to replace the other occurrences of the idiom for 
coding consistency ? (not sure if I could commit this as obvious ?).


Cheers

Christian




2015-01-08  Christian Bruel  

	* config/sh/sh-mem.cc (sh_expand_cmpnstr, sh_expand_setmem):
	 Use gen_cmpeqsi instead of gen_tstsi for comparing against 0.

Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc	(revision 219257)
+++ gcc/config/sh/sh-mem.cc	(working copy)
@@ -410,7 +410,7 @@
 	  else
 	{
 	  emit_insn (gen_addsi3 (lenw, lenw, GEN_INT (-1)));
-	  emit_insn (gen_tstsi_t (lenw, lenw));
+ emit_insn (gen_cmpeqsi_t (lenw, const0_rtx));
 	}
 
 	  jump = emit_jump_insn (gen_branch_false (L_loop_long));
@@ -531,7 +531,7 @@
   else
 {
   emit_insn (gen_addsi3 (len, len, GEN_INT (-1)));
-  emit_insn (gen_tstsi_t (len, len));
+  emit_insn (gen_cmpeqsi_t (len, const0_rtx));
 }
 
   jump = emit_jump_insn (gen_branch_false (L_loop_byte));
@@ -691,7 +691,7 @@
   else
 	{
 	  emit_insn (gen_addsi3 (lenw, lenw, GEN_INT (-1)));
-	  emit_insn (gen_tstsi_t (lenw, lenw));
+ emit_insn (gen_cmpeqsi_t (lenw, const0_rtx));
 	}
 
   emit_move_insn (dest, val);
@@ -728,7 +728,7 @@
   else
 {
   emit_insn (gen_addsi3 (len, len, GEN_INT (-1)));
-  emit_insn (gen_tstsi_t (len, len));
+  emit_insn (gen_cmpeqsi_t (len, const0_rtx));
 }
 
   val = gen_lowpart (QImode, val);

Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all

[Jakub Jelinek]

On Tue, Jan 06, 2015 at 01:04:29PM +0100, Eric Botcazou wrote:
> > I normally build with --disable-libsanitizer, because the sanitizers
> > testresults are very unreproducable, so just annoying noise.  This however
> > makes most (all?) ubsan testcases fail, since they want to load a shared
> > library that does not exist.
> 
> Same here, but I also have the problem with tsan testcases.
> 
> > gcc/testsuite/
> > * lib/ubsan-dg.exp (check_effective_target_fsanitize_undefined):
> > Check if testcases run without errors, not just if they compile.
> 
> I additionally need:
> 
> * lib/tsan-dg.exp (check_effective_target_fsanitize_thread):
> Check if testcases run without errors, not just if they compile.

What errors do you get?  Just curious.  That said, I think your patch is fine.

> --- lib/tsan-dg.exp   (revision 219217)
> +++ lib/tsan-dg.exp   (working copy)
> @@ -18,7 +18,7 @@
>  # code, 0 otherwise.
>  
>  proc check_effective_target_fsanitize_thread {} {
> -return [check_no_compiler_messages fsanitize_thread executable {
> +return [check_runtime fsanitize_thread {
>   int main (void) { return 0; }
>  } "-fsanitize=thread"]
>  }

Jakub

Re: [PATCH] ubsan: Do not run the testsuite if ubsan does not work at all

[Eric Botcazou]

> I normally build with --disable-libsanitizer, because the sanitizers
> testresults are very unreproducable, so just annoying noise.  This however
> makes most (all?) ubsan testcases fail, since they want to load a shared
> library that does not exist.

Same here, but I also have the problem with tsan testcases.

> gcc/testsuite/
>   * lib/ubsan-dg.exp (check_effective_target_fsanitize_undefined):
>   Check if testcases run without errors, not just if they compile.

I additionally need:

* lib/tsan-dg.exp (check_effective_target_fsanitize_thread):
Check if testcases run without errors, not just if they compile.


-- 
Eric BotcazouIndex: lib/tsan-dg.exp
===
--- lib/tsan-dg.exp	(revision 219217)
+++ lib/tsan-dg.exp	(working copy)
@@ -18,7 +18,7 @@
 # code, 0 otherwise.
 
 proc check_effective_target_fsanitize_thread {} {
-return [check_no_compiler_messages fsanitize_thread executable {
+return [check_runtime fsanitize_thread {
 	int main (void) { return 0; }
 } "-fsanitize=thread"]
 }

[wwwdocs] Add news entry for Visium port

[Eric Botcazou]

OK to commit?

-- 
Eric BotcazouIndex: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.946
diff -u -p -r1.946 index.html
--- index.html	23 Dec 2014 18:44:10 -	1.946
+++ index.html	6 Jan 2015 11:55:54 -
@@ -52,6 +52,11 @@ mission statement.
 
 
 
+VISIUMcore support
+[2015-01-06]
+A port for the VISIUMcore architecture has been contributed by AdaCore
+on behalf of Controls and Data Services.
+
 GCC 5 C++14 language feature-complete
 [2014-12-23]
 Support for all C++14 language

[Patch docs 5/5] Update "Predicates" from md.texi

[James Greenhalgh]

Hi,

This patch updates the predicates section from md.texi.

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.

OK?

Thanks,
James

---
2015-01-06  James Greenhalgh  

* doc/md.texi (Predicates): Update text.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 3b853c8..e1fd8c6 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -737,9 +737,8 @@ predicates used with @code{match_operand} have names that end in
 @samp{_operand}, and those used with @code{match_operator} have names
 that end in @samp{_operator}.
 
-All predicates are Boolean functions (in the mathematical sense) of
-two arguments: the RTL expression that is being considered at that
-position in the instruction pattern, and the machine mode that the
+Predicates take two arguments: the RTL expression that is being considered
+at that position in the instruction pattern, and the machine mode that the
 @code{match_operand} or @code{match_operator} specifies.  In this
 section, the first argument is called @var{op} and the second argument
 @var{mode}.  Predicates can be called from C as ordinary two-argument
@@ -747,39 +746,51 @@ functions; this can be useful in output templates or other
 machine-specific code.
 
 Operand predicates can allow operands that are not actually acceptable
-to the hardware, as long as the constraints give reload the ability to
-fix them up (@pxref{Constraints}).  However, GCC will usually generate
-better code if the predicates specify the requirements of the machine
-instructions as closely as possible.  Reload cannot fix up operands
-that must be constants (``immediate operands''); you must use a
-predicate that allows only constants, or else enforce the requirement
-in the extra condition.
+to the hardware, as long as the constraints can be fulfilled, perhaps by
+moving the operand between register classes, during register allocation
+(@pxref{Constraints}).  However, GCC will usually generate better code
+if the predicates specify the requirements of the machine instructions
+as closely as possible.
+
+It is an error for the contraints of an operand to be impossible to fulfil
+for operands which are valid for the predicate of the operand.  One such
+example would be the combination of a predicate allowing any operand,
+with a constraint requiring only immediate operands.  Here, the predicate
+may permit a register operand containing a non-constant value, which it would
+not be possible to convert to an immediate operand.
 
 @cindex predicates and machine modes
 @cindex normal predicates
 @cindex special predicates
-Most predicates handle their @var{mode} argument in a uniform manner.
-If @var{mode} is @code{VOIDmode} (unspecified), then @var{op} can have
-any mode.  If @var{mode} is anything else, then @var{op} must have the
-same mode, unless @var{op} is a @code{CONST_INT} or integer
-@code{CONST_DOUBLE}.  These RTL expressions always have
-@code{VOIDmode}, so it would be counterproductive to check that their
-mode matches.  Instead, predicates that accept @code{CONST_INT} and/or
-integer @code{CONST_DOUBLE} check that the value stored in the
-constant will fit in the requested mode.
-
-Predicates with this behavior are called @dfn{normal}.
-@command{genrecog} can optimize the instruction recognizer based on
-knowledge of how normal predicates treat modes.  It can also diagnose
-certain kinds of common errors in the use of normal predicates; for
-instance, it is almost always an error to use a normal predicate
-without specifying a mode.
-
-Predicates that do something different with their @var{mode} argument
-are called @dfn{special}.  The generic predicates
-@code{address_operand} and @code{pmode_register_operand} are special
-predicates.  @command{genrecog} does not do any optimizations or
-diagnosis when special predicates are used.
+@dfn{Normal} predicates are those for which the relationship between
+@var{mode} and @var{op} can be described in one of the following ways.
+
+@enumerate
+@item
+If @var{mode} is @code{VOIDmode} or is unspecified, then @var{op} can have
+any mode.
+
+@item
+If @var{mode} is a defined mode, then @var{op} must be of the same mode.
+
+@item
+If @var{op} is a @code{CONST_INT} or an integer @code{CONST_DOUBLE} RTL
+expression, @var{mode} can be any mode.  The predicate must itself
+check that the range of @var{mode} is sufficient to contain the value in
+@var{op}.
+@end enumerate
+
+Using normal predicates allows for additional optimization to be
+performed in the @command{genrecog} program.  This can result in a
+more efficient instruction recognizer.  @command{genrecog} is also able
+to diagnose common errors in the use of normal predicates, such as a
+missing @var{mode}.
+
+Predicates that do 

[Patch docs 3/5] Update "RTL Template" in md.texi

[James Greenhalgh]

Hi,

This patch updates the RTL Template section of md.texi.

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.

OK?

Thanks,
James

---
2015-01-06  James Greenhalgh  

* doc/md.texi (RTL Template): Update text.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index b852981..a589f5b 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -257,25 +257,23 @@ type of CPU for which code is being generated.
 @cindex recognizing insns
 @cindex insns, recognizing
 
-The RTL template is used to define which insns match the particular pattern
+The RTL template is used to define which insns match the pattern
 and how to find their operands.  For named patterns, the RTL template also
-says how to construct an insn from specified operands.
+defines how to construct an insn from specified operands.
 
-Construction involves substituting specified operands into a copy of the
-template.  Matching involves determining the values that serve as the
-operands in the insn being matched.  Both of these activities are
-controlled by special expression types that direct matching and
-substitution of the operands.
+Constructing an insn involves substituting specified operands into a
+copy of the template.  Matching an insn involves determining the values
+that serve as the operands in the insn being matched.  Both of these
+activities are controlled by the special RTL expressions described below.
 
 @table @code
 @findex match_operand
 @item (match_operand:@var{m} @var{n} @var{predicate} @var{constraint})
 This expression is a placeholder for operand number @var{n} of
-the insn.  When constructing an insn, operand number @var{n}
-will be substituted at this point.  When matching an insn, whatever
-appears at this position in the insn will be taken as operand
-number @var{n}; but it must satisfy @var{predicate} or this instruction
-pattern will not match at all.
+the instruction pattern.  When constructing RTL, operand number @var{n}
+will be substituted at this point.  When matching an insn, assuming the
+@var{predicate} is satisfied, whatever appears at this position in the
+insn will be taken as operand number @var{n}.
 
 Operand numbers must be chosen consecutively counting from zero in
 each instruction pattern.  There may be only one @code{match_operand}
@@ -286,15 +284,15 @@ used only in @code{match_dup} expressions have higher values than all
 other operand numbers.
 
 @var{predicate} is a string that is the name of a function that
-accepts two arguments, an expression and a machine mode.
-@xref{Predicates}.  During matching, the function will be called with
-the putative operand as the expression and @var{m} as the mode
-argument (if @var{m} is not specified, @code{VOIDmode} will be used,
+accepts two arguments, an expression and a machine mode
+(@pxref{Predicates}).  During matching, the function will be called
+with the operand as the expression and @var{m} as the mode
+argument (if @var{m} is not specified, then @code{VOIDmode} will be used,
 which normally causes @var{predicate} to accept any mode).  If it
 returns zero, this instruction pattern fails to match.
-@var{predicate} may be an empty string; then it means no test is to be
-done on the operand, so anything which occurs in this position is
-valid.
+
+@var{predicate} may be an empty string.  This represents a predicate for
+which any operand will be considered valid.
 
 Most of the time, @var{predicate} will reject modes other than @var{m}---but
 not always.  For example, the predicate @code{address_operand} uses
@@ -302,80 +300,89 @@ not always.  For example, the predicate @code{address_operand} uses
 Many predicates accept @code{const_int} nodes even though their mode is
 @code{VOIDmode}.
 
-@var{constraint} controls reloading and the choice of the best register
-class to use for a value, as explained later (@pxref{Constraints}).
-If the constraint would be an empty string, it can be omitted.
-
-People are often unclear on the difference between the constraint and the
-predicate.  The predicate helps decide whether a given insn matches the
-pattern.  The constraint plays no role in this decision; instead, it
-controls various decisions in the case of an insn which does match.
+@var{constraint} controls the best register class to use for a value,
+and therefore register allocation and reloading, as explained
+later (@pxref{Constraints}).  If the constraint would be an empty
+string, it can be omitted.
+
+In summary, the predicate is used to control whether the instruction
+pattern is a valid match for an insn.  The constraint is used to control
+register allocation decisions in the case of an instruction pattern which
+has already been matched to an insn.
+
+It is an error for 

[Patch docs 4/5] Update "Output Template/Statement" from md.texi

[James Greenhalgh]

Hi,

This patch updates the text in the "Output Template" and "Output
Statement" sections of md.texi.

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.

OK?

Thanks,
James

---
2015-01-06  James Greenhalgh  

* doc/md.texi (Output Template): Update text.
(Output Statement): Likewise.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index a589f5b..3b853c8 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -519,7 +519,7 @@ Like @code{match_op_dup}, but for @code{match_parallel} instead of
 @cindex percent sign
 The @dfn{output template} is a string which specifies how to output the
 assembler code for an instruction pattern.  Most of the template is a
-fixed string which is output literally.  The character @samp{%} is used
+fixed string which is output verbatim.  The character @samp{%} is used
 to specify where to substitute an operand; it can also be used to
 identify places where different variants of the assembler require
 different syntax.
@@ -528,9 +528,29 @@ In the simplest case, a @samp{%} followed by a digit @var{n} says to output
 operand @var{n} at that point in the string.
 
 @samp{%} followed by a letter and a digit says to output an operand in an
-alternate fashion.  Four letters have standard, built-in meanings described
-below.  The machine description macro @code{PRINT_OPERAND} can define
-additional letters with nonstandard meanings.
+alternate fashion.  Four letters and two punctuation characters have
+standard, built-in meanings described below.  The target macro
+@code{PRINT_OPERAND} can define additional letters or punctuation
+characters with nonstandard meanings.
+
+One use of nonstandard letters or punctuation following @samp{%} is to
+distinguish between different assembler dialects for the same machine.
+This is used in the m68k target to distinguish between Motorola and MIT
+assebler syntax.
+
+Motorola syntax requires periods in most opcode names, while MIT syntax
+does not. For example, the opcode @samp{movel} in MIT syntax is written as
+@samp{move.l} in Motorola syntax.  The same file of patterns is used for
+both kinds of output syntax, but the character sequence @samp{%.} is used
+in each place where Motorola syntax requires a period.  The
+@code{PRINT_OPERAND} macro is defined to ouput a period when compiling
+for the Motorola syntax, and to output nothing when compiling for the MIT
+syntax.
+
+Alternatively, if the target macro @code{ASSEMBLER_DIALECT} is defined,
+an output template of the form @samp{@{option0|option1|option2@}} can be
+used to output different variants of assembler language syntax
+(@pxref{Instruction Output}).
 
 @samp{%c@var{digit}} can be used to substitute an operand that is a
 constant value without the syntax that normally indicates an immediate
@@ -549,8 +569,8 @@ as if it were a memory reference.
 instruction.
 
 @samp{%=} outputs a number which is unique to each instruction in the
-entire compilation.  This is useful for making local labels to be
-referred to more than once in a single template that generates multiple
+entire compilation.  This is useful for creating local labels which may
+be referred to more than once in a single template that generates multiple
 assembler instructions.
 
 @samp{%} followed by a punctuation character specifies a substitution that
@@ -566,82 +586,68 @@ The template may generate multiple assembler instructions.  Write the text
 for the instructions, with @samp{\;} between them.
 
 @cindex matching operands
-When the RTL contains two operands which are required by constraint to match
-each other, the output template must refer only to the lower-numbered operand.
-Matching operands are not always identical, and the rest of the compiler
-arranges to put the proper RTL expression for printing into the lower-numbered
-operand.
-
-One use of nonstandard letters or punctuation following @samp{%} is to
-distinguish between different assembler languages for the same machine; for
-example, Motorola syntax versus MIT syntax for the 68000.  Motorola syntax
-requires periods in most opcode names, while MIT syntax does not.  For
-example, the opcode @samp{movel} in MIT syntax is @samp{move.l} in Motorola
-syntax.  The same file of patterns is used for both kinds of output syntax,
-but the character sequence @samp{%.} is used in each place where Motorola
-syntax wants a period.  The @code{PRINT_OPERAND} macro for Motorola syntax
-defines the sequence to output a period; the macro for MIT syntax defines
-it to do nothing.
+When the RTL contains two operands which are required by their constraints
+to match each other, the output template must refer only to the
+lower-numbered operand.  Matching operands are not always identical,
+a

[Patch docs 0/5] Update some of md.texi

[James Greenhalgh]

Hi,

I was recently stuck on a flight and flicking through md.texi, when
I realised some of it was rather outdated. Consequently, I thought
I would have a go at updating it, and while I was there, clean up some
of the style issues I've spotted over the last few years.

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.
  * Update some K&R C and make it use GNU-style.

I've split the patch to a 5-patch series, roughly covering one section
in each.

There is probably much more that I can do to clean these up, and of
course there is the rest of the file to do... If this work is useful,
I'm happy to keep going over the next couple of weekends.

I've read through the output in info and a web browser, and I couldn't
spot any major formatting errors.

OK?

Thanks,
James

---
James Greenhalgh (5):
  [Patch docs 1/5] Update the first section of md.texi
  [Patch docs 2/5] Update "Instruction Patterns" in md.texi
  [Patch docs 3/5] Update "RTL Template" in md.texi
  [Patch docs 4/5] Update "Output Template/Statement" from md.texi
  [Patch docs 5/5] Update "Predicates" from md.texi

[Patch docs 2/5] Update "Instruction Patterns" in md.texi

[James Greenhalgh]

Hi,

This patch updates the second section of md.texi - "Everything about
Patterns".

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.

OK?

Thanks,
James

---
2015-01-06  James Greenhalgh  

* doc/md.texi (Instruction Patterns): Update text.
(Example): Update text.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 0277f14..b852981 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -115,85 +115,98 @@ emit the final assembly code.  For this purpose, names are ignored.  All
 @cindex instruction patterns
 
 @findex define_insn
-Each instruction pattern contains an incomplete RTL expression, with pieces
-to be filled in later, operand constraints that restrict how the pieces can
-be filled in, and an output pattern or C code to generate the assembler
-output, all wrapped up in a @code{define_insn} expression.
+A @code{define_insn} expression is used to define instruction patterns
+to which insns may be matched.  A @code{define_insn} expression contains
+an incomplete RTL expression, with pieces to be filled in later, operand
+constraints that restrict how the pieces can be filled in, and an output
+template or C code to generate the assembler output.
 
-A @code{define_insn} is an RTL expression containing four or five operands:
+A @code{define_insn} contains either four or five components:
 
 @enumerate
 @item
-An optional name.  The presence of a name indicate that this instruction
-pattern can perform a certain standard job for the RTL-generation
-pass of the compiler.  This pass knows certain names and will use
-the instruction patterns with those names, if the names are defined
-in the machine description.
-
-The absence of a name is indicated by writing an empty string
-where the name should go.  Nameless instruction patterns are never
-used for generating RTL code, but they may permit several simpler insns
-to be combined later on.
-
-Names that are not thus known and used in RTL-generation have no
-effect; they are equivalent to no name at all.
+The @dfn{insn name}: When expanding from gimple to RTL, and when performing
+optimizations, the compiler looks for patterns with certain names,
+collectively known as the standard pattern names (@pxref{Standard Names}).
+The target-independent infrastructure in the compiler which references
+these names is generally accessed through the interfaces defined
+in @code{optabs.c}.
+
+Names that are not listed as one of the standard pattern names are not
+used directly by the target-independent code.  However, machine
+descriptions may themselves make use of named patterns in
+@code{define_expand} or @code{define_split} expressions.
+
+It is also possible to define a nameless instruction pattern.  This uses
+an empty string in place of the name.  Nameless instruction patterns cannot
+be used when generating RTL code, but they may be matched against during
+the combine and split passes of the compiler.
+
+Where names are given to instruction patterns, these must be unique
+in the machine description file.
 
 For the purpose of debugging the compiler, you may also specify a
 name beginning with the @samp{*} character.  Such a name is used only
-for identifying the instruction in RTL dumps; it is entirely equivalent
-to having a nameless pattern for all other purposes.
+for identifying the instruction in RTL dumps; it is equivalent to having
+a nameless pattern for all other purposes.  Names beginning with the
+@samp{*} character are not required to be unique.
 
 @item
-The @dfn{RTL template} (@pxref{RTL Template}) is a vector of incomplete
-RTL expressions which show what the instruction should look like.  It is
-incomplete because it may contain @code{match_operand},
+The @dfn{RTL template}: This is a vector of incomplete RTL expressions
+which describe the semantics of the instruction (@pxref{RTL Template}).
+It is incomplete because it may contain @code{match_operand},
 @code{match_operator}, and @code{match_dup} expressions that stand for
 operands of the instruction.
 
-If the vector has only one element, that element is the template for the
-instruction pattern.  If the vector has multiple elements, then the
-instruction pattern is a @code{parallel} expression containing the
-elements described.
+If the vector has multiple elements, the RTL template is treated as a
+@code{parallel} expression.
 
 @item
 @cindex pattern conditions
 @cindex conditions, in patterns
-A condition.  This is a string which contains a C expression that is
-the final test to decide whether an insn body matches this pattern.
+The condition: This is a string which contains a C expression.  When the
+compiler attempts to match RTL against a pattern, the condition is
+evaluated.  If the cond

[Patch docs 1/5] Update the first section of md.texi

[James Greenhalgh]

Hi,

This patch updates the introduction to, and first section of, md.texi.

I was aiming to:

  * Remove outdated details of the compiler.
  * Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
  * Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of "insn" and "pattern".
  * Remove superflous examples, or waffling.

OK?

Thanks,
James

---
2015-01-06  James Greenhalgh  

* doc/md.texi (Machine Descriptions): Update text.
(menu): Likewise.
(Overview): Likewise.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 7f0426c..0277f14 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -7,39 +7,39 @@
 @chapter Machine Descriptions
 @cindex machine descriptions
 
-A machine description has two parts: a file of instruction patterns
-(@file{.md} file) and a C header file of macro definitions.
+A machine description has two parts: one or more files describing the
+instructions available on the target (@file{.md} files) and one or more
+C/C++ source files implementing target hooks and macros.  These are
+described in the next chapter (@pxref{Target Macros}).
 
-The @file{.md} file for a target machine contains a pattern for each
-instruction that the target machine supports (or at least each instruction
-that is worth telling the compiler about).  It may also contain comments.
-A semicolon causes the rest of the line to be a comment, unless the semicolon
-is inside a quoted string.
-
-See the next chapter for information on the C header file.
+This chapter describes the @file{.md} files for a target machine.  These
+contain the instruction patterns which are used by the compiler when
+expanding gimple to RTL, during the RTL optimization passes, and when
+emitting assembler code.
 
 @menu
 * Overview::How the machine description is used.
 * Patterns::How to write instruction patterns.
 * Example:: An explained example of a @code{define_insn} pattern.
-* RTL Template::The RTL template defines what insns match a pattern.
+* RTL Template::The RTL template defines which insns may match a
+pattern.
 * Output Template:: The output template says how to make assembler code
-from such an insn.
+from an insn matched to an instruction pattern.
 * Output Statement::For more generality, write C code to output
 the assembler code.
-* Predicates::  Controlling what kinds of operands can be used
-for an insn.
+* Predicates::  Controlling which kinds of operands can be used
+when matching an insn to an instruction pattern.
 * Constraints:: Fine-tuning operand selection.
 * Standard Names::  Names mark patterns to use for code generation.
 * Pattern Ordering::When the order of patterns makes a difference.
 * Dependent Patterns::  Having one pattern may make you need another.
 * Jump Patterns::   Special considerations for patterns for jump insns.
 * Looping Patterns::How to define patterns for special looping insns.
-* Insn Canonicalizations::Canonicalization of Instructions
+* Insn Canonicalizations::Canonicalization of instructions
 * Expander Definitions::Generating a sequence of several RTL insns
 for a standard operation.
-* Insn Splitting::  Splitting Instructions into Multiple Instructions.
-* Including Patterns::  Including Patterns in Machine Descriptions.
+* Insn Splitting::  Splitting insns into multiple insns.
+* Including Patterns::  Including patterns in machine descriptions.
 * Peephole Definitions::Defining machine-specific peephole optimizations.
 * Insn Attributes:: Specifying the value of attributes for generated insns.
 * Conditional Execution::Generating @code{define_insn} patterns for
@@ -54,50 +54,60 @@ See the next chapter for information on the C header file.
 @node Overview
 @section Overview of How the Machine Description is Used
 
-There are three main conversions that happen in the compiler:
+There are four main conversions that happen in the compiler:
 
 @enumerate
 
 @item
-The front end reads the source code and builds a parse tree.
+The front end reads the source code and converts it to an intermediate,
+front end specific, tree based representation.
 
 @item
-The parse tree is used to generate an RTL insn list based on named
-instruction patterns.
+This tree based representation is lowered (gimplified) to a gimple
+representation.
 
 @item
-The insn list is matched against the RTL templates to produce assembler
-code.
+The gimple representation is transformed (expanded) to an RTL
+representation.  This RTL representation is a doubly-linked chain of
+objects called insns, known as the insn list.
+
+@item
+The insn list is optimized, and the optimized insn list is matched
+against @code{define_insn} instruction

Re: [patch] New std::string implementation

[Jonathan Wakely]

On 06/01/15 10:52 +0100, Rainer Orth wrote:

Unfortunately, this patch broke Solaris bootstrap with /bin/ld:
libstdc++.so fails to link with

ld: fatal: libstdc++-symbols.ver-sun: 5383: symbol 
'std::locale::name[abi:cxx11]() const': symbol version conflict

l.5383 has

   ##_ZNKSt6locale4nameB5cxx11Ev (glob)
   _ZNKSt6locale4nameB5cxx11Ev;

i.e.

   # std::locale::name() returning new std::string

in GLIBCXX_3.4.21 vs.

 ##std::locale::[A-Zn-z]* (cxx)
 _ZNKSt6locale4nameB5cxx11Ev;

in GLIBCXX_3.4.


Drat, I even tried to avoid that conflict, but apparently I thought
the letter that comes after 'n' is 'n'!

Does this fix it?

--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -118,7 +118,7 @@ GLIBCXX_3.4 {
# std::locale::name();
  std::locale::none*;
  std::locale::numeric*;
-  std::locale::[A-Zn-z]*;
+  std::locale::[A-Zo-z]*;
  std::locale::_[A-Ha-z]*;
  std::locale::_Impl::[A-Za-z]*;
# std::locale::_Impl::_M_[A-Za-z]*;

Hmm, I think the [A-Zo-z] glob depends on the locale's collation
order, maybe it should be just [o-z] since we don't have any symbols
matching std::locale::[A-Z]* anyway. That's something else to clean up
later.

[Ada] Remove unreachable code in Freeze_Array_Type

[Arnaud Charlet]

In the Alias_Atomic_Check block, Complain_CS has these lines:

if Known_Static_Esize (Ctyp) then
   Error_Msg_N
 ("incorrect component size for "
  & T & " components", Clause);
   Error_Msg_Uint_1 := Esize (Ctyp);
   Error_Msg_N
 ("\only allowed value is^", Clause);

else
   Error_Msg_N
 ("component size cannot be given for "
  & T & " components", Clause);
end if;

but Complain_CS can only be invoked if Known_Static_Esize (Ctyp) is true, so 
the above test is always true and the 'else' arm unreachable.

No functional changes.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Eric Botcazou  

* freeze.adb (Freeze_Array_Type) : Remove always
true test and unreachable 'else' arm.

Index: freeze.adb
===
--- freeze.adb  (revision 219253)
+++ freeze.adb  (working copy)
@@ -2450,27 +2450,18 @@
   Get_Attribute_Definition_Clause
 (FS, Attribute_Component_Size);
 
-if Known_Static_Esize (Ctyp) then
-   Error_Msg_N
- ("incorrect component size for "
-  & T & " components", Clause);
-   Error_Msg_Uint_1 := Esize (Ctyp);
-   Error_Msg_N
- ("\only allowed value is^", Clause);
+Error_Msg_N
+  ("incorrect component size for "
+   & T & " components", Clause);
+Error_Msg_Uint_1 := Esize (Ctyp);
+Error_Msg_N
+  ("\only allowed value is^", Clause);
 
-else
-   Error_Msg_N
- ("component size cannot be given for "
-  & T & " components", Clause);
-end if;
-
  else
 Error_Msg_N
   ("cannot pack " & T & " components",
Get_Rep_Pragma (FS, Name_Pack));
  end if;
-
- return;
   end Complain_CS;
 
   --  Start of processing for Alias_Atomic_Check

[Ada] Handle Str'Last = Positive'Last in Text_IO.Get routines

[Arnaud Charlet]

The Get routines in Text_IO that take a string argument were behaving
incorrectly when From'Last = Positive'Last. This is a very bizarre case
which probably will never occur in practice, but it leads to undefined
behavior (one possibility is a confusing raise of Data_Error). It is not
worth worrying about handling this "properly", but this change ensures
that a Program_Error exception with a clear message is raised in this
unusual situation:

 1. with Ada.Text_IO; use Ada.Text_IO;
 2. procedure TextIOLast is
 3.package IO is new Integer_IO (Integer);
 4.use IO;
 5.Str : string (Integer'Last .. Integer'Last) := "5";
 6.N : Integer;
 7.P : Positive;
 8. begin
 9.Get (Str, N, P);
10. end;

This program now terminates with the message:

raised PROGRAM_ERROR : Ada.Text_IO.Generic_Aux.String_Skip:
string upper bound is Positive'Last, not supported

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* a-wtgeau.adb, a-ztgeau.adb, a-tigeau.adb (String_Skip): Raise PE if
Str'Last = Positive'Last.

Index: a-wtgeau.adb
===
--- a-wtgeau.adb(revision 219191)
+++ a-wtgeau.adb(working copy)
@@ -484,6 +484,19 @@
 
procedure String_Skip (Str : String; Ptr : out Integer) is
begin
+  --  Routines calling String_Skip malfunction if Str'Last = Positive'Last.
+  --  It's too much trouble to make this silly case work, so we just raise
+  --  Program_Error with an appropriate message. We raise Program_Error
+  --  rather than Constraint_Error because we don't want this case to be
+  --  converted to Data_Error.
+
+  if Str'Last = Positive'Last then
+ raise Program_Error with
+   "string upper bound is Positive'Last, not supported";
+  end if;
+
+  --  Normal case where Str'Last < Positive'Last
+
   Ptr := Str'First;
 
   loop
Index: a-tigeau.adb
===
--- a-tigeau.adb(revision 219191)
+++ a-tigeau.adb(working copy)
@@ -443,6 +443,19 @@
 
procedure String_Skip (Str : String; Ptr : out Integer) is
begin
+  --  Routines calling String_Skip malfunction if Str'Last = Positive'Last.
+  --  It's too much trouble to make this silly case work, so we just raise
+  --  Program_Error with an appropriate message. We raise Program_Error
+  --  rather than Constraint_Error because we don't want this case to be
+  --  converted to Data_Error.
+
+  if Str'Last = Positive'Last then
+ raise Program_Error with
+   "string upper bound is Positive'Last, not supported";
+  end if;
+
+  --  Normal case where Str'Last < Positive'Last
+
   Ptr := Str'First;
 
   loop
Index: a-ztgeau.adb
===
--- a-ztgeau.adb(revision 219191)
+++ a-ztgeau.adb(working copy)
@@ -484,6 +484,19 @@
 
procedure String_Skip (Str : String; Ptr : out Integer) is
begin
+  --  Routines calling String_Skip malfunction if Str'Last = Positive'Last.
+  --  It's too much trouble to make this silly case work, so we just raise
+  --  Program_Error with an appropriate message. We raise Program_Error
+  --  rather than Constraint_Error because we don't want this case to be
+  --  converted to Data_Error.
+
+  if Str'Last = Positive'Last then
+ raise Program_Error with
+   "string upper bound is Positive'Last, not supported";
+  end if;
+
+  --  Normal case where Str'Last < Positive'Last
+
   Ptr := Str'First;
 
   loop

Re: [patch] New std::string implementation

[Rainer Orth]

Jonathan Wakely  writes:

> The powerpc64 ICE is fixed, so I'm committing the std::string ABI
> transition patch.
>
> This replaces our venerable Copy-on-Write std::string with a
> C++11-conforming* Small-String Optimized std::__cxx11::string.
>
> (* It's not quite 100% conforming, as it's missing some allocator
> features.  Of course. Always with the allocators. But that's only a
> small fix to make next week.)
[...]
> Target maintainers will see a *lot* of new exports at the latest
> symbol version if they generate a new baseline-symbols.txt file. I
> suggest waiting and doing that nearer the end of stage 3 in case there
> are any fixes needed after this change.
>
> Bootstrapped and tested in various configurations on x86_64-linux and
> powerpc64-linux.

Unfortunately, this patch broke Solaris bootstrap with /bin/ld:
libstdc++.so fails to link with

ld: fatal: libstdc++-symbols.ver-sun: 5383: symbol 
'std::locale::name[abi:cxx11]() const': symbol version conflict

l.5383 has

##_ZNKSt6locale4nameB5cxx11Ev (glob)
_ZNKSt6locale4nameB5cxx11Ev;

i.e.

# std::locale::name() returning new std::string

in GLIBCXX_3.4.21 vs.

  ##std::locale::[A-Zn-z]* (cxx)
  _ZNKSt6locale4nameB5cxx11Ev;

in GLIBCXX_3.4.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[Ada] Rework the initialization/finalization of the runtime.

[Arnaud Charlet]

A new routine named __gnat_runtime_initialize is introduced to initialize
the runtime and another one to finalize it. Code from __gnat_finalize have
been moved to __gnat_runtime_initialize when it applies. This makes a C
main calling adainit() and adafinal() as documented behave as if the
main was in Ada.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Pascal Obry  

* adaint.c (ProcListEvt): Set to NULL.
* rtinit.c: New file.
(__gnat_rt_init_count): New reference counter set to 0.
(__gnat_runtime_initialize): Move code here from __gnat_initialize when
this code is actually needed for the runtime initialization. This
routine returns immediately if the initialization has already been done.
* final.c: Revert previous change.
* rtfinal.c: New file.
(__gnat_runtime_finalize)[Win32]: Add finalization of the critical
section and event. The default version of this routine is empty (except
for the reference counting code). This routine returns immediately if
some others libraries are referencing the runtime.
* bindgen.adb (Gen_Adainit): Generate call to Runtime_Initialize
remove circuitry to initialize the signal handler as this is
now done by the runtime initialization routine.
(Gen_Adafinal): Generate call to Runtime_Finalize.
* gnat_ugn.texi: Update documentation about concurrency and
initialization/finalization of the run-time.

Index: rtfinal.c
===
--- rtfinal.c   (revision 0)
+++ rtfinal.c   (revision 0)
@@ -0,0 +1,89 @@
+/
+ *  *
+ * GNAT COMPILER COMPONENTS *
+ *  *
+ *  R T F I N A L   *
+ *  *
+ *  C Implementation File   *
+ *  *
+ * Copyright (C) 2014-2015, Free Software Foundation, Inc.  *
+ *  *
+ * GNAT is free software;  you can  redistribute it  and/or modify it under *
+ * terms of the  GNU General Public License as published  by the Free Soft- *
+ * ware  Foundation;  either version 3,  or (at your option) any later ver- *
+ * sion.  GNAT is distributed in the hope that it will be useful, but WITH- *
+ * OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY *
+ * or FITNESS FOR A PARTICULAR PURPOSE. *
+ *  *
+ * As a special exception under Section 7 of GPL version 3, you are granted *
+ * additional permissions described in the GCC Runtime Library Exception,   *
+ * version 3.1, as published by the Free Software Foundation.   *
+ *  *
+ * You should have received a copy of the GNU General Public License and*
+ * a copy of the GCC Runtime Library Exception along with this program; *
+ * see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see*
+ * .  *
+ *  *
+ * GNAT was originally developed  by the GNAT team at  New York University. *
+ * Extensive contributions were provided by Ada Core Technologies Inc.  *
+ *  *
+ /
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+extern void __gnat_runtime_finalize (void);
+
+/* This routine is called at the extreme end of execution of an Ada program
+   (the call is generated by the binder). The standard routine does nothing
+   at all, the intention is that this be replaced by system specific code
+   where finalization is required.
+
+   Note that __gnat_runtime_initialize() is called in adafinal()   */
+
+extern int __gnat_rt_init_count;
+/*  see initialize.c  */
+
+#if defined (__MINGW32__)
+#include "mingw32.h"
+#include 
+
+extern CRITICAL_SECTION ProcListCS;
+extern HANDLE ProcListEvt;
+
+void
+__gnat_runtime_finalize (void)
+{
+  /*  decrement the reference counter */
+
+  __gnat_rt_init_count--;
+
+  /*  if still some referenced return now */
+  if (__gnat_rt_init_count > 0)
+return;
+
+  /* delete critical section and event handle used for the
+ processes chain list */
+  DeleteCriticalSection(&ProcListCS);

Re: [PATCH][SH] Check for 0 length with inlined strnlen builtin

[Oleg Endo]

On Tue, 2015-01-06 at 10:28 +0100, Christian Bruel wrote:
> Hello,
> 
> We should not enter the first iteration when length is 0. Testcase 
> attached. Difficult to reduce because register allocation generated 
> accidentally the correct return value.
> 
> testsuite OK
> 
> OK for 4.9 and trunk ?

In your patch:

+  emit_insn (gen_tstsi_t (len, len));

Please use 'gen_cmpeqsi_t (len, const0_rtx)' for comparing a value
against zero instead of the bit test insn.  Otherwise, I think it's OK
for trunk and 4.9.

Cheers,
Oleg

[PATCH][ARM][PING] __ARM_FP & __ARM_NEON_FP defined when -march=armv7-m

[Mantas Mikaitis]

Ping and changelog spaces removed.

Thank you,
Mantas M.

On 18/11/14 11:58, Richard Earnshaw wrote:

On 18/11/14 11:30, Mantas Mikaitis wrote:

Incorrect predefinitions for certain target architectures. E.g. arm7-m
does not contain NEON but the defintion __ARM_NEON_FP was switched on.
Similarly with armv6 and even armv2.

This patch fixes the predefines for each of the different chips
containing certain types of the FPU implementations.

Tests:

Tested on arm-none-linux-gnueabi and arm-none-linux-gnueabihf without
any new regression.

Manually compiled for various targets and all correct definitions were
present.

Is this patch ok for trunk?

Mantas

gcc/Changelog:

   * config/arm/arm.h (TARGET_NEON_FP): Removed conditional definition, 
define to zero if !TARGET_NEON.
 (TARGET_CPU_CPP_BUILTINS): Added second condition before defining 
__ARM_FP macro.


ARM_DEFS.patch


diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ff4ddac..325fea9 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -118,7 +118,7 @@ extern char arm_arch_name[];
if (TARGET_VFP) \
  builtin_define ("__VFP_FP__");  \
\
-   if (TARGET_ARM_FP)  \
+   if (TARGET_ARM_FP && !TARGET_SOFT_FLOAT)\

Wouldn't it be better to factor this into TARGET_ARM_FP?  It seems odd
that that macro returns a set of values based on something completely
unavailable for the current compilation.  That would also then mirror
the behaviour of TARGET_NEON_FP (see below) and make the internal macros
more consistent.

R.


Thank you. Patch updated.

Ok for trunk?

Mantas M.

gcc/Changelog

2014-12-03  Mantas Mikaits  

  * config/arm/arm.h (TARGET_NEON_FP): Removed conditional definition, 
define to zero if !TARGET_NEON.
(TARGET_ARM_FP): Added !TARGET_SOFT_FLOAT into the conditional 
definition.

gcc/testsuite/ChangeLog:

  * gcc.target/arm/macro_defs0.c: New test.
  * gcc.target/arm/macro_defs1.c: New test.
  * gcc.target/arm/macro_defs2.c: New test.














diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ff4ddac..7d4cc39 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2343,17 +2343,17 @@ extern int making_const_table;
point types.  Where bit 1 indicates 16-bit support, bit 2 indicates
32-bit support, bit 3 indicates 64-bit support.  */
 #define TARGET_ARM_FP			\
-  (TARGET_VFP_SINGLE ? 4		\
-  		 : (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0))
+  (!TARGET_SOFT_FLOAT ? (TARGET_VFP_SINGLE ? 4		\
+			: (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \
+		  : 0)
 
 
 /* Set as a bit mask indicating the available widths of floating point
types for hardware NEON floating point.  This is the same as
TARGET_ARM_FP without the 64-bit bit set.  */
-#ifdef TARGET_NEON
-#define TARGET_NEON_FP		\
-  (TARGET_ARM_FP & (0xff ^ 0x08))
-#endif
+#define TARGET_NEON_FP \
+  (TARGET_NEON ? (TARGET_ARM_FP & (0xff ^ 0x08)) \
+	   : 0)
 
 /* The maximum number of parallel loads or stores we support in an ldm/stm
instruction.  */
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs0.c b/gcc/testsuite/gcc.target/arm/macro_defs0.c
new file mode 100644
index 000..198243e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs0.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-march=*" } {"-march=armv7-m"} } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
+/* { dg-options "-march=armv7-m -mcpu=cortex-m3 -mfloat-abi=soft -mthumb" } */
+
+#ifdef __ARM_FP
+#error __ARM_FP should not be defined
+#endif
+
+#ifdef __ARM_NEON_FP
+#error __ARM_NEON_FP should not be defined
+#endif
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs1.c b/gcc/testsuite/gcc.target/arm/macro_defs1.c
new file mode 100644
index 000..075b71b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-march=*" } { "-march=armv6-m" } } */
+/* { dg-options "-march=armv6-m -mthumb" } */
+
+#ifdef __ARM_NEON_FP
+#error __ARM_NEON_FP should not be defined
+#endif
+
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs2.c b/gcc/testsuite/gcc.target/arm/macro_defs2.c
new file mode 100644
index 000..9a96042
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv7ve -mcpu=cortex-a15 -mfpu=neon-vfpv4" } */
+/* { dg-add-options arm_neon } */
+/* { dg-require-effective-target arm_neon_ok } */
+
+#ifndef __ARM_NEON_FP
+#error  __ARM_NEON_FP is not defined but should be
+#endif
+
+#ifndef __ARM_FP
+#error  __ARM_FP is not defined but should be
+#endif
+
+

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

On Tue, 6 Jan 2015 10:16:33, Jakub Jelinek wrote:
>
> On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
>> Hi Mike,
>>
>> after some hours of sleep I realized that your step function can do 
>> something very interesting,
>> (which you already requested previously):
>>
>> That is: create a race condition that is _always_ at 100% missed by tsan:
>>
>> cat lib.c
>> /* { dg-do compile } */
>> /* { dg-options "-O2 -fno-sanitize=all" } */
>>
>> static volatile int serial = 0;
>>
>> void step (int i)
>> {
>>   while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
>>   __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
>> }
>
> Such busy waiting is not very CPU time friendly in the testsuite, especially
> if you have just a single HW thread.

and in real-time environment, without time-slicing it is even a deadlock...

plus, I need to compile this helper with different options, that can be solved,
but currently I see no example where something like that was ever done.

> If libtsan is not fixed not to be so racy, perhaps instead of all the sleeps
> we could arrange (on x86_64-linux, which is the only target supporting tsan
> right now) to make sure the thread runs on the same core/hw thread as the
> initial thread using pthread_[gs]etaffinity_np/pthread_attr_setaffinity_np ?
> Does tsan then always report the races when the threads can't run
> concurrently?
>

Probably yes, but there can be no guarantees.  Even a single core can
be interrupted.

I think we can live with sleep(1) in aligned_vs_unaligned.C,
failure of that test will be very very unlikely as well.

.. and if we find a way how to do this custom buiild step in the test suite,
it would be good as a XFAIL test, that reminds us of the racy nature of libtsan.


Bernd.

> Jakub
  

[PATCH][ARM][PING] __ARM_FP & __ARM_NEON_FP defined when -march=armv7-m

[Mantas Mikaitis]

 Ping.

Thank you,
Mantas M.

On 18/11/14 11:58, Richard Earnshaw wrote:

On 18/11/14 11:30, Mantas Mikaitis wrote:

Incorrect predefinitions for certain target architectures. E.g. arm7-m
does not contain NEON but the defintion __ARM_NEON_FP was switched on.
Similarly with armv6 and even armv2.

This patch fixes the predefines for each of the different chips
containing certain types of the FPU implementations.

Tests:

Tested on arm-none-linux-gnueabi and arm-none-linux-gnueabihf without
any new regression.

Manually compiled for various targets and all correct definitions were
present.

Is this patch ok for trunk?

Mantas

gcc/Changelog:

   * config/arm/arm.h (TARGET_NEON_FP): Removed conditional definition, 
define to zero if !TARGET_NEON.
 (TARGET_CPU_CPP_BUILTINS): Added second condition before defining 
__ARM_FP macro.


ARM_DEFS.patch


diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ff4ddac..325fea9 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -118,7 +118,7 @@ extern char arm_arch_name[];
if (TARGET_VFP) \
  builtin_define ("__VFP_FP__");  \
\
-   if (TARGET_ARM_FP)  \
+   if (TARGET_ARM_FP && !TARGET_SOFT_FLOAT)\

Wouldn't it be better to factor this into TARGET_ARM_FP?  It seems odd
that that macro returns a set of values based on something completely
unavailable for the current compilation.  That would also then mirror
the behaviour of TARGET_NEON_FP (see below) and make the internal macros
more consistent.

R.


Thank you. Patch updated.

Ok for trunk?

Mantas M.

gcc/Changelog

2014-12-03  Mantas Mikaits  

* config/arm/arm.h (TARGET_NEON_FP): Removed conditional definition, 
define to zero if !TARGET_NEON.
   (TARGET_ARM_FP): Added !TARGET_SOFT_FLOAT into the conditional 
definition.

gcc/testsuite/ChangeLog:

* gcc.target/arm/macro_defs0.c: New test.
 * gcc.target/arm/macro_defs1.c: New test.
 * gcc.target/arm/macro_defs2.c: New test.





diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index ff4ddac..7d4cc39 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2343,17 +2343,17 @@ extern int making_const_table;
point types.  Where bit 1 indicates 16-bit support, bit 2 indicates
32-bit support, bit 3 indicates 64-bit support.  */
 #define TARGET_ARM_FP			\
-  (TARGET_VFP_SINGLE ? 4		\
-  		 : (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0))
+  (!TARGET_SOFT_FLOAT ? (TARGET_VFP_SINGLE ? 4		\
+			: (TARGET_VFP_DOUBLE ? (TARGET_FP16 ? 14 : 12) : 0)) \
+		  : 0)
 
 
 /* Set as a bit mask indicating the available widths of floating point
types for hardware NEON floating point.  This is the same as
TARGET_ARM_FP without the 64-bit bit set.  */
-#ifdef TARGET_NEON
-#define TARGET_NEON_FP		\
-  (TARGET_ARM_FP & (0xff ^ 0x08))
-#endif
+#define TARGET_NEON_FP \
+  (TARGET_NEON ? (TARGET_ARM_FP & (0xff ^ 0x08)) \
+	   : 0)
 
 /* The maximum number of parallel loads or stores we support in an ldm/stm
instruction.  */
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs0.c b/gcc/testsuite/gcc.target/arm/macro_defs0.c
new file mode 100644
index 000..198243e
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs0.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-march=*" } {"-march=armv7-m"} } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-mfloat-abi=*" } { "-mfloat-abi=soft" } } */
+/* { dg-options "-march=armv7-m -mcpu=cortex-m3 -mfloat-abi=soft -mthumb" } */
+
+#ifdef __ARM_FP
+#error __ARM_FP should not be defined
+#endif
+
+#ifdef __ARM_NEON_FP
+#error __ARM_NEON_FP should not be defined
+#endif
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs1.c b/gcc/testsuite/gcc.target/arm/macro_defs1.c
new file mode 100644
index 000..075b71b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-skip-if "avoid conflicting multilib options"
+   { *-*-* } { "-march=*" } { "-march=armv6-m" } } */
+/* { dg-options "-march=armv6-m -mthumb" } */
+
+#ifdef __ARM_NEON_FP
+#error __ARM_NEON_FP should not be defined
+#endif
+
diff --git a/gcc/testsuite/gcc.target/arm/macro_defs2.c b/gcc/testsuite/gcc.target/arm/macro_defs2.c
new file mode 100644
index 000..9a96042
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/macro_defs2.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv7ve -mcpu=cortex-a15 -mfpu=neon-vfpv4" } */
+/* { dg-add-options arm_neon } */
+/* { dg-require-effective-target arm_neon_ok } */
+
+#ifndef __ARM_NEON_FP
+#error  __ARM_NEON_FP is not defined but should be
+#endif
+
+#ifndef __ARM_FP
+#error  __ARM_FP is not defined but should be
+#endif
+
+

[Ada] Preliminary work for new restriction No_Use_Of_Entity

[Arnaud Charlet]

This checkin is preliminary work for a new restriction No_Use_Of_Entity.
No test needed, since no external effect yet!

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* namet.ads: Document use of Boolean2 for No_Use_Of_Entity.
* restrict.ads (No_Use_Of_Entity): New table.
* sem_prag.adb (Process_Restrictions_Or_Restriction_Warnings):
Ignore No_Use_Of_Entity (will be processed in parser).
* snames.ads-tmpl: Add entry for Name_No_Use_Of_Entity.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 219230)
+++ sem_prag.adb(working copy)
@@ -8857,7 +8857,7 @@
   raise Pragma_Exit;
end if;
 
---  Case of No_Specification_Of_Aspect => Identifier.
+--  Case of No_Specification_Of_Aspect => aspect-identifier
 
 elsif Id = Name_No_Specification_Of_Aspect then
declare
@@ -8877,6 +8877,8 @@
   end if;
end;
 
+--  Case of No_Use_Of_Attribute => attribute-identifier
+
 elsif Id = Name_No_Use_Of_Attribute then
if Nkind (Expr) /= N_Identifier
  or else not Is_Attribute_Name (Chars (Expr))
@@ -8887,6 +8889,15 @@
   Set_Restriction_No_Use_Of_Attribute (Expr, Warn);
end if;
 
+--  Case of No_Use_Of_Entity => fully-qualified-name. Note that the
+--  parser already processed this case commpletely, including error
+--  checking and making an entry in the No_Use_Of_Entity table.
+
+elsif Id = Name_No_Use_Of_Entity then
+   null;
+
+--  Case of No_Use_Of_Pragma => pragma-identifier
+
 elsif Id = Name_No_Use_Of_Pragma then
if Nkind (Expr) /= N_Identifier
  or else not Is_Pragma_Name (Chars (Expr))
Index: restrict.ads
===
--- restrict.ads(revision 219191)
+++ restrict.ads(working copy)
@@ -51,8 +51,8 @@
--  set from package Standard by the processing in Targparm.
 
Restriction_Profile_Name : array (All_Restrictions) of Profile_Name;
-   --  Entries in this array are valid only if the corresponding restriction
-   --  in Restrictions set. The value is the corresponding profile name if the
+   --  Entries in this array are valid only if the corresponding restriction in
+   --  Restrictions is set. The value is the corresponding profile name if the
--  restriction was set by a Profile or Profile_Warnings pragma. The value
--  is No_Profile in all other cases.
 
@@ -148,6 +148,10 @@
   SPARK_05   => True,
   others => False);
 
+   --
+   -- No_Dependences Table --
+   --
+
--  The following table records entries made by Restrictions pragmas
--  that specify a parameter for No_Dependence. Each such pragma makes
--  an entry in this table.
@@ -179,6 +183,43 @@
  Table_Increment  => 200,
  Table_Name   => "Name_No_Dependences");
 
+   
+   -- No_Use_Of_Entity Table --
+   
+
+   --  The following table records entries made by Restrictions pragmas
+   --  that specify a parameter for No_Use_Of_Entity. Each such pragma makes
+   --  an entry in this table.
+
+   --  Note: we have chosen to implement this restriction in the "syntactic"
+   --  form, where we allow arbitrary fully qualified names to be specified.
+
+   type NE_Entry is record
+  Entity : Node_Id;
+  --  The entity parameter from the No_Use_Of_Entity pragma. This is in
+  --  the form of a selected component, since that is the way the parser
+  --  processes it, and we don't further analyze it.
+
+  Warn : Boolean;
+  --  True if from Restriction_Warnings, False if from Restrictions
+
+  Profile : Profile_Name;
+  --  Set to name of profile from which No_Use_Of_Entity entry came, or to
+  --  No_Profile if a pragma Restriction set the No_Use_Of_Entity entry.
+   end record;
+
+   package No_Use_Of_Entity is new Table.Table (
+ Table_Component_Type => NE_Entry,
+ Table_Index_Type => Int,
+ Table_Low_Bound  => 0,
+ Table_Initial=> 200,
+ Table_Increment  => 200,
+ Table_Name   => "Name_No_Use_Of_Entity");
+
+   --  Note that in addition to making an entry in this table, we also set the
+   --  Boolean2 flag of the Name_Table entry for the simple name of the entity.
+   --  This is used to avoid most useless searches of this table.
+
-
-- Subprograms --
-
Index: namet.ads
===
--- namet.ads   (revision 219231)
+++ namet.ads   (working copy)

[Ada] SCOs: handle the Short_Circuit_And_Or pragma

[Arnaud Charlet]

This change ensures that "and" and "or" operators affected by the
Short_Circuit_And_Or pragma are considered as part of SCO decisions,
just like the "and then" and "or else" operators.

The following compilation must produce a decision SCO as shown:

$ gcc -c -fdump-scos cc4.adb
$ grep ^CX cc4.ali
CX |4:21 &4:14 c4:12-4:12 c4:18-4:18 &4:31 !4:25 c4:29-4:29 c4:35-4:35

pragma Short_Circuit_And_Or;
function CC4 (A, B, C : Boolean) return Boolean is
begin
   return (A and B) or (not A and C);  -- # eval
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Pierre-Marie Derodat  

* scos.ads: Update documentation about the SCO table build
process and about table records format.
* par_sco.ads (SCO_Record): Rename to SCO_Record_Raw.
(SCO_Record_Filtered): New procedure.
(Set_SCO_Logical_Operator): New procedure.
(dsco): Update documentation.
* par_sco.adb: Update library-level comments.
(SCO_Generation_State_Type): New type.
(SCO_Generation_State): New variable.
(SCO_Raw_Table): New package instanciation.
(Condition_Pragma_Hash_Table): Rename to SCO_Raw_Hash_Table.
("<"): New.
(Tristate): New type.
(Is_Logical_Operator): Return Tristate and update documentation.
(Has_Decision): Update call to Is_Logical_Operator and complete
documentation.
(Set_Table_Entry): Rename to Set_Raw_Table_Entry, update
comment, add an assertion for state checking and change
references to SCO_Table into SCO_Raw_Table.
(dsco): Refactor to dump the raw and the filtered tables.
(Process_Decisions.Output_Decision_Operand): Handle putative
short-circuit operators.
(Process_Decisions.Output_Element): Update references
to Set_Table_Entry and to Condition_Pragma_Hash_Table.
(Process_Decisions.Process_Decision_Operand): Update call
to Is_Logical_Operator.
(Process_Decisions.Process_Node): Handle putative short-circuit
operators and change references to
SCO_Table into SCO_Raw_Table.
(SCO_Output): Add an assertion
for state checking and remove code that used to stamp out SCO entries.
(SCO_Pragma_Disabled): Change reference to SCO_Table
into SCO_Raw_Table.
(SCO_Record): Rename to SCO_Record_Raw,
add an assertion for state checking and change references
to SCO_Table into SCO_Raw_Table.
(Set_SCO_Condition): Add an assertion for state checking, update
references to Condition_Pragma_Hash_Table and change references to
SCO_Table into SCO_Raw_Table.
(Set_SCO_Pragma_Enabled): Add an assertion for state checking and
change references to SCO_Table into SCO_Raw_Table.
(Set_SCO_Logical_Operator): New procedure.
(Traverse_Declarations_Or_Statements.Set_Statement_Entry): Update
references to Set_Table_Entry and to Condition_Pragma_Hash_Table.
(SCO_Record_Fildered): New procedure.
* gnat1drv.adb (Gnat1drv): Invoke the SCO filtering pass.
* lib-writ.adb (Write_ALI): Invoke the SCO filtering pass and
output SCOs.
* par-load.adb (Load): Update reference to SCO_Record.
* par.adb (Par): Update reference to SCO_Record.
* put_scos.adb (Put_SCOs): Add an assertion to check that no
putative SCO condition reaches this end.
* sem_ch10.adb (Analyze_Proper_Body): Update reference to SCO_Record.
* sem_res.adb (Resolve_Logical_Op): Validate putative SCOs
when corresponding to an "and"/"or" operator affected by the
Short_Circuit_And_Or pragma.

Index: par_sco.adb
===
--- par_sco.adb (revision 219191)
+++ par_sco.adb (working copy)
@@ -44,9 +44,45 @@
 
 with GNAT.HTable;  use GNAT.HTable;
 with GNAT.Heap_Sort_G;
+with GNAT.Table;
 
 package body Par_SCO is
 
+   --
+   -- First-pass SCO table --
+   --
+
+   --  The Short_Circuit_And_Or pragma enables one to use AND and OR operators
+   --  in source code while the ones used with booleans will be interpreted as
+   --  their short circuit alternatives (AND THEN and OR ELSE). Thus, the true
+   --  meaning of these operators is known only after the semantic analysis.
+
+   --  However, decision SCOs include short circuit operators only. The SCO
+   --  information generation pass must be done before expansion, hence before
+   --  the semantic analysis. Because of this, the SCO information generation
+   --  is done in two passes.
+
+   --  The first one (SCO_Record_Raw, before semantic analysis) completes the
+   --  SCO_Raw_Table assuming all AND/OR operators are short circuit ones.
+   --  Then, the semantic analysis determines which operators are promoted to
+   --  short circuit ones. Finally, the second pass (SCO_Record_Filtered)
+   --  translates the SCO

[PATCH][SH] Check for 0 length with inlined strnlen builtin

[Christian Bruel]

Hello,

We should not enter the first iteration when length is 0. Testcase 
attached. Difficult to reduce because register allocation generated 
accidentally the correct return value.


testsuite OK

OK for 4.9 and trunk ?

Christian

2015-01-08  Christian Bruel  

	PR target/64507
	* config/sh/sh-mem.cc (sh_expand_cmpnstr): Check 0 length.

2015-01-08  Christian Bruel  

	PR target/64507
	* gcc.target/sh/pr64507.c: New test.

Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc	(revision 219182)
+++ gcc/config/sh/sh-mem.cc	(working copy)
@@ -1,5 +1,5 @@
 /* Helper routines for memory move and comparison insns.
-   Copyright (C) 2013-2014 Free Software Foundation, Inc.
+   Copyright (C) 2013-2015 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -421,6 +421,7 @@
 	  /* end loop.  Reached max iterations.  */
 	  if (sbytes == 0)
 	{
+	  emit_insn (gen_subsi3 (operands[0], tmp1, tmp2));
 	  jump = emit_jump_insn (gen_jump_compact (L_return));
 	  emit_barrier_after (jump);
 	}
@@ -496,6 +497,13 @@
   jump = emit_jump_insn (gen_jump_compact( L_end_loop_byte));
   emit_barrier_after (jump);
 }
+  else
+{
+  emit_insn (gen_tstsi_t (len, len));
+  emit_move_insn (operands[0], const0_rtx);
+  jump = emit_jump_insn (gen_branch_true (L_return));
+  add_int_reg_note (jump, REG_BR_PROB, prob_unlikely);
+}
 
   addr1 = adjust_automodify_address (addr1, QImode, s1_addr, 0);
   addr2 = adjust_automodify_address (addr2, QImode, s2_addr, 0);
@@ -536,10 +544,10 @@
 emit_insn (gen_zero_extendqisi2 (tmp2, gen_lowpart (QImode, tmp2)));
   emit_insn (gen_zero_extendqisi2 (tmp1, gen_lowpart (QImode, tmp1)));
 
-  emit_label (L_return);
-
   emit_insn (gen_subsi3 (operands[0], tmp1, tmp2));
 
+  emit_label (L_return);
+
   return true;
 }
 
Index: gcc/testsuite/gcc.target/sh/pr64507.c
===
--- gcc/testsuite/gcc.target/sh/pr64507.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr64507.c	(working copy)
@@ -0,0 +1,25 @@
+/* Check that the __builtin_strnlen returns 0 with with 
+   non-constant 0 length.  */
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+extern int snprintf(char *, int, const char *, ...);
+extern void abort (void);
+
+int main()
+ {
+   int i;
+   int cmp = 0;
+   char buffer[1024];
+   const char* s = "the string";
+
+   snprintf(buffer, 4, "%s", s);
+
+   for (i = 1; i < 4; i++)
+ cmp += __builtin_strncmp(buffer, s, i - 1);
+
+  if (cmp)
+abort();
+
+  return 0;
+}

[Ada] Function in RCI cannot have anonymous access result

[Arnaud Charlet]

Enforce rule from E.2.3(14/3): the return type of an RCI function
must support external streaming; per 13.13.2(52/3) an anonymous access
type does not support external streaming.

The following code is illegal and must be rejected:

$ gcc -c rci_func_return_anon_access.adb
rci_func_return_anon_access.ads:3:04: function in RCI unit cannot
   have access result

package rci_func_return_anon_access is
   pragma Remote_Call_Interface;
   function F return access Integer;
end rci_func_return_anon_access;
package body rci_func_return_anon_access is
   X : aliased Integer;

   function F return access Integer is
   begin
  return X'Access;
   end F;
end rci_func_return_anon_access;

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Thomas Quinot  

* sem_cat.adb (In_RCI_Declaration): Remove unnecessary
parameter and rename to...
(In_RCI_Visible_Declarations): Fix handling of private part of nested
package.
(Validate_RCI_Subprogram_Declaration): Reject illegal function
returning anonymous access in RCI unit.

Index: sem_cat.adb
===
--- sem_cat.adb (revision 219191)
+++ sem_cat.adb (working copy)
@@ -86,10 +86,10 @@
--  Return True if the entity or one of its subcomponents does not support
--  external streaming.
 
-   function In_RCI_Declaration (N : Node_Id) return Boolean;
-   --  Determines if a declaration is  within the visible part of a Remote
-   --  Call Interface compilation unit, for semantic checking purposes only
-   --  (returns false within an instance and within the package body).
+   function In_RCI_Visible_Declarations return Boolean;
+   --  Determines if the visible part of a remote call interface library unit
+   --  is being compiled, for semantic checking purposes (returns False within
+   --  an instance and within the package body).
 
function In_RT_Declaration return Boolean;
--  Determines if current scope is within the declaration of a Remote Types
@@ -544,31 +544,40 @@
   return Is_Pure (Current_Scope);
end In_Pure_Unit;
 
-   
-   -- In_RCI_Declaration --
-   
+   -
+   -- In_RCI_Visible_Declarations --
+   -
 
-   function In_RCI_Declaration (N : Node_Id) return Boolean is
-  Unit_Entity : constant Entity_Id := Current_Scope;
+   function In_RCI_Visible_Declarations return Boolean is
+  Unit_Entity : Entity_Id := Current_Scope;
   Unit_Kind   : constant Node_Kind :=
   Nkind (Unit (Cunit (Current_Sem_Unit)));
 
begin
-  --  There are no restrictions on the private part or body
-  --  of an RCI unit.
+  --  There are no restrictions on the private part or body of an RCI unit
 
-  return Is_Remote_Call_Interface (Unit_Entity)
+  if not (Is_Remote_Call_Interface (Unit_Entity)
 and then Is_Package_Or_Generic_Package (Unit_Entity)
 and then Unit_Kind /= N_Package_Body
-and then List_Containing (N) =
-   Visible_Declarations (Package_Specification (Unit_Entity))
-and then not In_Package_Body (Unit_Entity)
-and then not In_Instance;
+and then not In_Instance)
+  then
+ return False;
+  end if;
 
-  --  What about the case of a nested package in the visible part???
-  --  This case is missed by the List_Containing check above???
-   end In_RCI_Declaration;
+  while Unit_Entity /= Standard_Standard loop
+ if In_Private_Part (Unit_Entity) then
+return False;
+ end if;
 
+ Unit_Entity := Scope (Unit_Entity);
+  end loop;
+
+  --  Here if in RCI declaration, and not in private part of any open
+  --  scope.
+
+  return True;
+   end In_RCI_Visible_Declarations;
+
---
-- In_RT_Declaration --
---
@@ -1371,7 +1380,7 @@
   --  The visible part of an RCI library unit must not contain the
   --  declaration of a variable (RM E.1.3(9))
 
-  elsif In_RCI_Declaration (N) then
+  elsif In_RCI_Visible_Declarations then
  Error_Msg_N ("visible variable not allowed in 'R'C'I unit", N);
 
   --  The visible part of a Shared Passive library unit must not contain
@@ -1609,7 +1618,7 @@
   --1. from Analyze_Subprogram_Declaration.
   --2. from Validate_Object_Declaration (access to subprogram).
 
-  if not (Comes_From_Source (N) and then In_RCI_Declaration (N)) then
+  if not (Comes_From_Source (N) and then In_RCI_Visible_Declarations) then
  return;
   end if;
 
@@ -1652,12 +1661,10 @@
 
--  Report error only if declaration is in source program
 
-   if Comes_From_Source
- (Defining_Entity (Specification (N)))
-   then
+   if Comes_From_Source (Id) then
   Erro

[Ada] improve front-end floating point attributes computation

[Arnaud Charlet]

The internal tree nodes for the standard Ada floating point types are
derived from back-end information provided via a type registration hook.
 
The registration is performed by the set_targ elaboration code, constructing
the FPT_Mode_Table which cstand.Create_Standard scans later on to construct
front-end type nodes.
 
But downstream within the compiler, the Standard type nodes aren't the only
source of information regarding floating point types: the ttypes package is
also used for this purpose in many places.
 
The two sources of information (ttypes' exposed values and attributes in tree
nodes for standard floating types) have to agree. A range of bad things might
happen otherwise.
 
Now it turns out that the Set_Targ functions used to initialize ttypes for
floating point values don't use the FPT_Mode_Table at all. They resort to gigi
functions conveying back-end attributes instead.
 
Keeping the two in sync is a pain, in particular when it comes to
Long_Long_Float. The gigi code resorts to the WIDEST_HARDWARE_FP_SIZE macro
which is not so well defined, and the get_target_long_double_size function
doesn't compute what the name implies.
 
This patch is a first step towards fixing this by providing a common ground to
initialize both ttypes and the front-end nodes from the FPT_Mode_Table.
 
The basic idea is to generalize what cstand.Create_Float_Types does: refer to
specific C (back-end) types to initialize the Ada type nodes. 

No functional change. This allows removing code in gigi, which will be done
as a separate patch.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Olivier Hainque  

* set_targ.ads (C_Type_For): New function. Return the name of
a C type supported by the back-end and suitable as a basis to
construct the standard Ada floating point type identified by
the T parameter. This is used as a common ground to feed both
ttypes values and the GNAT tree nodes for the standard floating
point types.
* set_targ.adb (Long_Double_Index): The index at which "long
double" gets registered in the FPT_Mode_Table. This is useful to
know whether we have a "long double" available at all and get at
it's characteristics without having to search the FPT_Mode_Table
when we need to decide which C type should be used as the
basis for Long_Long_Float in Ada.
(Register_Float_Type): Fill Long_Double_Index.
(FPT_Mode_Index_For): New function. Return the index in
FPT_Mode_Table that designates the entry corresponding to the
provided C type name.
(FPT_Mode_Index_For): New function. Return the index in
FPT_Mode_Table that designates the entry for a back-end type
suitable as a basis to construct the standard Ada floating point
type identified by the input T parameter.
(elaboration code): Register_Back_End_Types unconditionally,
so C_Type_For can operate regardless of -gnateT. Do it
early so we can query it for the floating point sizes, via
FPT_Mode_Index_For. Initialize Float_Size, Double_Size and
Long_Double_Size from the FPT_Mode_Table, as cstand will do.
* cstand.adb (Create_Float_Types): Use C_Type_For to determine
which C type should be used as the basis for the construction
of the Standard Ada floating point types.
* get_targ.ads (Get_Float_Size, Get_Double_Size,
Get_Long_Double_Size): Remove.
* get_targ.adb: Likewise.

Index: get_targ.adb
===
--- get_targ.adb(revision 219191)
+++ get_targ.adb(working copy)
@@ -126,42 +126,6 @@
   return C_Get_Long_Long_Size;
end Get_Long_Long_Size;
 
-   
-   -- Get_Float_Size --
-   
-
-   function Get_Float_Size return Pos is
-  function C_Get_Float_Size return Pos;
-  pragma Import (C, C_Get_Float_Size,
-"get_target_float_size");
-   begin
-  return C_Get_Float_Size;
-   end Get_Float_Size;
-
-   -
-   -- Get_Double_Size --
-   -
-
-   function Get_Double_Size return Pos is
-  function C_Get_Double_Size return Pos;
-  pragma Import (C, C_Get_Double_Size,
-"get_target_double_size");
-   begin
-  return C_Get_Double_Size;
-   end Get_Double_Size;
-
-   --
-   -- Get_Long_Double_Size --
-   --
-
-   function Get_Long_Double_Size return Pos is
-  function C_Get_Long_Double_Size return Pos;
-  pragma Import (C, C_Get_Long_Double_Size,
-"get_target_long_double_size");
-   begin
-  return C_Get_Long_Double_Size;
-   end Get_Long_Double_Size;
-
--
-- Get_Pointer_Size --
--
Index: get_targ.ads
===

[Ada] Document recognition of : in place of #

[Arnaud Charlet]

This adds an RM reference to J.2 for the run-time routines that allow
colon as a replacement for hash in based notation. Comment changes
only, no external effect, so no test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* s-valllu.adb, a-tiinau.adb, a-timoau.adb, a-ztinau.adb, a-ztmoau.adb,
s-valuns.adb, s-valrea.adb, a-wtflau.adb, a-tiflau.adb, a-ztflau.adb,
a-wtinau.adb, a-wtmoau.adb: Document recognition of : in place of #.

Index: s-valllu.adb
===
--- s-valllu.adb(revision 219191)
+++ s-valllu.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2014, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -119,9 +119,10 @@
 
   Ptr.all := P;
 
-  --  Deal with based case
+  --  Deal with based case. We recognize either the standard '#' or the
+  --  allowed alternative replacement ':' (see RM J.2(3)).
 
-  if P < Max and then (Str (P) = ':' or else Str (P) = '#') then
+  if P < Max and then (Str (P) = '#' or else Str (P) = ':') then
  Base_Char := Str (P);
  P := P + 1;
  Base := Uval;
Index: a-tiinau.adb
===
--- a-tiinau.adb(revision 219191)
+++ a-tiinau.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2009, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2014, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -166,7 +166,8 @@
 
   if Loaded then
 
- --  Deal with based literal (note : is ok replacement for #)
+ --  Deal with based literal. We recognize either the standard '#' or
+ --  the allowed alternative replacement ':' (see RM J.2(3)).
 
  Load (File, Buf, Ptr, '#', ':', Loaded);
 
Index: a-timoau.adb
===
--- a-timoau.adb(revision 219191)
+++ a-timoau.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2009, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2014, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -173,6 +173,10 @@
   Load_Digits (File, Buf, Ptr, Loaded);
 
   if Loaded then
+
+ --  Deal with based case. We recognize either the standard '#' or the
+ --  allowed alternative replacement ':' (see RM J.2(3)).
+
  Load (File, Buf, Ptr, '#', ':', Loaded);
 
  if Loaded then
Index: a-ztinau.adb
===
--- a-ztinau.adb(revision 219191)
+++ a-ztinau.adb(working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2009, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2014, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -165,6 +165,10 @@
   Load_Digits (File, Buf, Ptr, Loaded);
 
   if Loaded then
+
+ --  Deal with based case. 

[Ada] Changes to SPARK RM 7.1.3(11)

[Arnaud Charlet]

This patch implements a side effect of SPARK RM rule 7.1.3(11) which implies
that an effectively volatile formal parameter of mode out cannot be read.


-- Source --


--  async_writers_out.ads

package Async_Writers_Out with SPARK_Mode is
   type Volat_Array is array (1 .. 5) of Integer with Volatile;

   type Volat_Rec is record
  Id : Integer := 0;
   end record with Volatile;

   procedure Error_1 (Result : out Volat_Array);
   procedure Error_2 (Result : out Volat_Rec);
   procedure OK_1;
   procedure OK_2;
end Async_Writers_Out;

--  async_writers_out.adb

package body Async_Writers_Out with SPARK_Mode is
   Obj_1 : Volat_Array with Async_Readers, Async_Writers;
   Obj_2 : Volat_Rec   with Async_Readers, Async_Writers;

   procedure Reference_1 (Result : out Volat_Array);
   procedure Reference_2 (Result : out Volat_Rec);

   procedure Error_1 (Result : out Volat_Array) is
  Comp : constant Integer := Result (3); --  ERROR
   begin
  Result (1) := 1 + Result (5);  --  ERROR
   end Error_1;

   procedure Error_2 (Result : out Volat_Rec) is
  Comp : constant Integer := Result.Id;  --  ERROR
   begin null; end Error_2;

   procedure OK_1 is
   begin
  Reference_1 (Obj_1);   --  OK
   end OK_1;

   procedure OK_2 is
   begin
  Reference_2 (Obj_2);   --  OK
   end OK_2;

   procedure Reference_1 (Result : out Volat_Array) is
   begin null; end Reference_1;

   procedure Reference_2 (Result : out Volat_Rec) is
   begin null; end Reference_2;
end Async_Writers_Out;


-- Compilation and output --


$ gcc -c async_writers_out.adb
async_writers_out.adb:9:34: illegal reading of volatile "out" parameter
async_writers_out.adb:11:25: volatile object cannot appear in this context
  (SPARK RM 7.1.3(13))
async_writers_out.adb:15:34: illegal reading of volatile "out" parameter

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Hristian Kirtchev  

* sem_res.adb (Is_Assignment_Or_Object_Expression): New routine.
(Resolve_Actuals): An effectively volatile out
parameter cannot act as an in or in out actual in a call.
(Resolve_Entity_Name): An effectively volatile out parameter
cannot be read.

Index: sem_res.adb
===
--- sem_res.adb (revision 219230)
+++ sem_res.adb (working copy)
@@ -4250,14 +4250,25 @@
end if;
 
--  In Ada 83 we cannot pass an OUT parameter as an IN or IN OUT
-   --  actual to a nested call, since this is case of reading an
-   --  out parameter, which is not allowed.
+   --  actual to a nested call, since this constitutes a reading of
+   --  the parameter, which is not allowed.
 
-   if Ada_Version = Ada_83
- and then Is_Entity_Name (A)
+   if Is_Entity_Name (A)
  and then Ekind (Entity (A)) = E_Out_Parameter
then
-  Error_Msg_N ("(Ada 83) illegal reading of out parameter", A);
+  if Ada_Version = Ada_83 then
+ Error_Msg_N
+   ("(Ada 83) illegal reading of out parameter", A);
+
+  --  An effectively volatile OUT parameter cannot act as IN or
+  --  IN OUT actual in a call (SPARK RM 7.1.3(11)).
+
+  elsif SPARK_Mode = On
+and then Is_Effectively_Volatile (Entity (A))
+  then
+ Error_Msg_N
+   ("illegal reading of volatile OUT parameter", A);
+  end if;
end if;
 end if;
 
@@ -5444,8 +5455,8 @@
  N_Unchecked_Type_Conversion)
then
   Error_Msg_N
-("(Ada 83) fixed-point operation "
- & "needs explicit conversion", N);
+("(Ada 83) fixed-point operation needs explicit "
+ & "conversion", N);
end if;
 
--  The expected type is "any real type" in contexts like
@@ -6886,6 +6897,12 @@
--  Used to resolve identifiers and expanded names
 
procedure Resolve_Entity_Name (N : Node_Id; Typ : Entity_Id) is
+  function Is_Assignment_Or_Object_Expression
+(Context : Node_Id;
+ Expr: Node_Id) return Boolean;
+  --  Determine whether node Context denotes an assignment statement or an
+  --  object declaration whose expression is node Expr.
+
   function Is_OK_Volatile_Context
 (Context : Node_Id;
  Obj_Ref : Node_Id) return Boolean;
@@ -6893,6 +6910,48 @@
   --  (as defined in SPARK RM 7.1.3(13)) where volatile reference 

[Ada] Use of incomplete types in invariant and predicate expressions.

[Arnaud Charlet]

An incomplete type may appear in the profile of a subprogram used in a
predicate for the type. Analysis of the constructed predicate function will
include a call to the subprogram, and an actual of the full type will be
resolved against an actual of the incomplete view. This patch handles this
construction properly.

Compiling

   gcc -c -gnatc invariant_question.ads

must yield:

invariant_question.ads:12:27: warning:
 predicate check includes a function call that requires a predicate check
invariant_question.ads:12:27: warning: this will result in infinite recursion

---
package Invariant_Question
is

   type Record_T;

   function Is_Valid (X : Record_T) return Boolean;

   type Record_T is record
  X : Boolean;
  Y : Boolean;
   end record with
 Dynamic_Predicate => Is_Valid (Record_T);

end Invariant_Question;

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Ed Schonberg  

* sem_ch4.adb (Analyze_One_Call): If formal has an incomplete
type and actual has the corresponding full view, there is no
error, but a case of use of incomplete type in a predicate or
invariant expression.

Index: sem_ch4.adb
===
--- sem_ch4.adb (revision 219191)
+++ sem_ch4.adb (working copy)
@@ -3195,6 +3195,18 @@
   Next_Actual (Actual);
   Next_Formal (Formal);
 
+   --  For an Ada 2012 predicate or invariant, a call may mention
+   --  an incomplete type, while resolution of the corresponding
+   --  predicate function may see the full view, as a consequence
+   --  of the delayed resolution of the corresponding expressions.
+
+   elsif Ekind (Etype (Formal)) = E_Incomplete_Type
+ and then Full_View (Etype (Formal)) = Etype (Actual)
+   then
+  Set_Etype (Formal, Etype (Actual));
+  Next_Actual (Actual);
+  Next_Formal (Formal);
+
else
   if Debug_Flag_E then
  Write_Str (" type checking fails in call ");

[Ada] Add additional Boolean fields to Name Table info

[Arnaud Charlet]

This is an internal change to create two new Boolean Name_Table
info fields. No external effect, no test.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* exp_util.adb: Change name Name_Table_Boolean to
Name_Table_Boolean1.
* namet.adb: Change name Name_Table_Boolean to Name_Table_Boolean1
Introduce Name_Table_Boolean2/3.
* namet.ads: Change name Name_Table_Boolean to Name_Table_Boolean1
Introduce Name_Table_Boolean2/3.
* par-ch13.adb: Change name Name_Table_Boolean to
Name_Table_Boolean1.

Index: exp_util.adb
===
--- exp_util.adb(revision 219222)
+++ exp_util.adb(working copy)
@@ -2963,7 +2963,7 @@
   --  If parser detected no address clause for the identifier in question,
   --  then the answer is a quick NO, without the need for a search.
 
-  if not Get_Name_Table_Boolean (Chars (Id)) then
+  if not Get_Name_Table_Boolean1 (Chars (Id)) then
  return Empty;
   end if;
 
Index: par-ch13.adb
===
--- par-ch13.adb(revision 219191)
+++ par-ch13.adb(working copy)
@@ -741,7 +741,7 @@
 if Attr_Name = Name_Address
   and then Nkind (Prefix_Node) = N_Identifier
 then
-   Set_Name_Table_Boolean (Chars (Prefix_Node), True);
+   Set_Name_Table_Boolean1 (Chars (Prefix_Node), True);
 end if;
  end loop;
 
@@ -771,7 +771,7 @@
 --  Mark occurrence of address clause (used to optimize performance
 --  of Exp_Util.Following_Address_Clause).
 
-Set_Name_Table_Boolean (Chars (Identifier_Node), True);
+Set_Name_Table_Boolean1 (Chars (Identifier_Node), True);
 
  --  RECORD follows USE (Record Representation Clause)
 
Index: namet.adb
===
--- namet.adb   (revision 219230)
+++ namet.adb   (working copy)
@@ -705,16 +705,36 @@
   end loop;
end Get_Name_String_And_Append;
 
-   
-   -- Get_Name_Table_Boolean --
-   
+   -
+   -- Get_Name_Table_Boolean1 --
+   -
 
-   function Get_Name_Table_Boolean (Id : Name_Id) return Boolean is
+   function Get_Name_Table_Boolean1 (Id : Name_Id) return Boolean is
begin
   pragma Assert (Id in Name_Entries.First .. Name_Entries.Last);
-  return Name_Entries.Table (Id).Boolean_Info;
-   end Get_Name_Table_Boolean;
+  return Name_Entries.Table (Id).Boolean1_Info;
+   end Get_Name_Table_Boolean1;
 
+   -
+   -- Get_Name_Table_Boolean2 --
+   -
+
+   function Get_Name_Table_Boolean2 (Id : Name_Id) return Boolean is
+   begin
+  pragma Assert (Id in Name_Entries.First .. Name_Entries.Last);
+  return Name_Entries.Table (Id).Boolean2_Info;
+   end Get_Name_Table_Boolean2;
+
+   -
+   -- Get_Name_Table_Boolean3 --
+   -
+
+   function Get_Name_Table_Boolean3 (Id : Name_Id) return Boolean is
+   begin
+  pragma Assert (Id in Name_Entries.First .. Name_Entries.Last);
+  return Name_Entries.Table (Id).Boolean3_Info;
+   end Get_Name_Table_Boolean3;
+
-
-- Get_Name_Table_Byte --
-
@@ -933,7 +953,9 @@
   Name_Len  => Short (Name_Len),
   Byte_Info => 0,
   Int_Info  => 0,
-  Boolean_Info  => False,
+  Boolean1_Info => False,
+  Boolean2_Info => False,
+  Boolean3_Info => False,
   Name_Has_No_Encodings => False,
   Hash_Link => No_Name));
 
@@ -1037,7 +1059,9 @@
  Name_Has_No_Encodings => False,
  Int_Info  => 0,
  Byte_Info => 0,
- Boolean_Info  => False));
+ Boolean1_Info => False,
+ Boolean2_Info => False,
+ Boolean3_Info => False));
 
  --  Set corresponding string entry in the Name_Chars table
 
@@ -1262,7 +1286,9 @@
  Name_Len  => 1,
  Byte_Info => 0,
  Int_Info  => 0,
- Boolean_Info  => False,
+ Boolean1_Info => False,
+ Boolean2_Info => False,
+ Boolean3_Info => False,
  Name_Has_No_Encodings => True,
  Hash_Link => No_Name));
 
@@ -1300,16 +1326,36 @@
   Store_Encoded_Character (C);
end Set_Character_Literal_Name;
 
-   
-   -- Set_Name_Table_Boolean --
-   
+   -

Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Jakub Jelinek]

On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
> Hi Mike,
> 
> after some hours of sleep I realized that your step function can do something 
> very interesting,
> (which you already requested previously):
> 
> That is: create a race condition that is _always_ at 100% missed by tsan:
> 
> cat lib.c
> /* { dg-do compile } */
> /* { dg-options "-O2 -fno-sanitize=all" } */
>  
> static volatile int serial = 0;
>  
> void step (int i)
> {
>   while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
>   __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
> }

Such busy waiting is not very CPU time friendly in the testsuite, especially
if you have just a single HW thread.
If libtsan is not fixed not to be so racy, perhaps instead of all the sleeps
we could arrange (on x86_64-linux, which is the only target supporting tsan
right now) to make sure the thread runs on the same core/hw thread as the
initial thread using pthread_[gs]etaffinity_np/pthread_attr_setaffinity_np ?
Does tsan then always report the races when the threads can't run
concurrently?

Jakub

[Ada] Fix bad error message for No_Elaboration_Code_All

[Arnaud Charlet]

This fixes a problem in the diagnostic for violation of the restriction
No_Elaboration_Code_All. In some cases, the location of the restriction
incorrectly points to the pragma in system.ads. The following test should
compile as shown whether or not there is a NECA pragma in System.

 1. pragma Restrictions (No_Elaboration_Code);
 2. package TestNECAMsg is
 3.type Empty is interface;
|
>>> violation of restriction
"No_Elaboration_Code" at line 1

 4. end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* sem_prag.adb (Analyze_Pragma, case No_Elaboration_Code_All):
Do not set restriction No_Elaboration_Code unless the pragma
appears in the main unit).

Index: sem_prag.adb
===
--- sem_prag.adb(revision 219227)
+++ sem_prag.adb(working copy)
@@ -16783,9 +16783,11 @@
 
 Set_No_Elab_Code_All (Current_Sem_Unit);
 
---  Set restriction No_Elaboration_Code
+--  Set restriction No_Elaboration_Code if this is the main unit
 
-Set_Restriction (No_Elaboration_Code, N);
+if Current_Sem_Unit = Main_Unit then
+   Set_Restriction (No_Elaboration_Code, N);
+end if;
 
 --  If we are in the main unit or in an extended main source unit,
 --  then we also add it to the configuration restrictions so that

[Ada] Make sure we check divide by zero for fixed-point divide case

[Arnaud Charlet]

On some targets, the compiler does not generate a required divide by
zero check for the case of fixed-point operands. This was noticed in
the context of the second division function in Ada.Real_Time, but is
a quite general problem. The following program:

 1. function DivCTest return Duration is
 2.type Time_Span is new Duration;
 3.function f (X : Time_Span; Y : Integer) return Time_Span is
 4.   pragma Unsuppress (Overflow_Check);
 5.   pragma Unsuppress (Division_Check);
 6.begin
 7.   return Time_Span (Duration (X) / Y);
 8.end;
 9. begin
10.return Duration (f (10.0, 0));
11. end;

should generate an exception on all targets. On native platforms
the output will be:

raised CONSTRAINT_ERROR : divctest.adb:6 divide by zero

Note: on some targets notably Windows, this message is obtained
without this fix, since the back end can in fact correctly handle
the generated division by zero, but this is not true on all targets.

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* exp_ch4.adb (Expand_N_Op_Divide): Generate explicit divide by
zero check for fixed-point case if Backend_Divide_Checks_On_Target
is False.

Index: exp_ch4.adb
===
--- exp_ch4.adb (revision 219191)
+++ exp_ch4.adb (working copy)
@@ -6701,6 +6701,26 @@
 
   if Is_Fixed_Point_Type (Typ) then
 
+ --  Deal with divide-by-zero check if back end cannot handle them
+ --  and the flag is set indicating that we need such a check. Note
+ --  that we don't need to bother here with the case of mixed-mode
+ --  (Right operand an integer type), since these will be rewritten
+ --  with conversions to a divide with a fixed-point right operand.
+
+ if Do_Division_Check (N)
+   and then not Backend_Divide_Checks_On_Target
+   and then not Is_Integer_Type (Rtyp)
+ then
+Set_Do_Division_Check (N, False);
+Insert_Action (N,
+  Make_Raise_Constraint_Error (Loc,
+Condition =>
+  Make_Op_Eq (Loc,
+Left_Opnd  => Duplicate_Subexpr_Move_Checks (Ropnd),
+Right_Opnd => Make_Real_Literal (Loc, Ureal_0)),
+  Reason  => CE_Divide_By_Zero));
+ end if;
+
  --  No special processing if Treat_Fixed_As_Integer is set, since
  --  from a semantic point of view such operations are simply integer
  --  operations and will be treated that way.

RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Bernd Edlinger]

Hi Mike,

after some hours of sleep I realized that your step function can do something 
very interesting,
(which you already requested previously):

That is: create a race condition that is _always_ at 100% missed by tsan:

cat lib.c
/* { dg-do compile } */
/* { dg-options "-O2 -fno-sanitize=all" } */
 
static volatile int serial = 0;
 
void step (int i)
{
  while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
  __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
}

cat tiny_race.c 
/* { dg-shouldfail "tsan" } */

#include 

void step(int);

int Global;

void *Thread1(void *x) {
  step (1);
  Global = 42;
  step (3);
  return x;
}

int main() {
  pthread_t t;
  pthread_create(&t, 0, Thread1, 0);
  step (2);
  Global = 43;
  step (4);
  pthread_join(t, 0);
  return Global;
}

/* { dg-output "WARNING: ThreadSanitizer: data race.*(\n|\r\n|\r)" } */



Bernd.
  

[Ada] Add warning for Suppress (Elaboration_Check) in SPARK

[Arnaud Charlet]

This adds an additional warning message for Suppress (Elaboration_Check)
in SPARK mode:

The following is compiled with -gnatj55

 1. pragma SPARK_Mode (On);
 2. package SupEcheck is
 3.pragma Suppress (Elaboration_Check);
|
>>> warning: Suppress of Elaboration_Check
ignored in SPARK, elaboration checking
rules are statically enforced (SPARK RM
7.7)

 4.X : Integer;
 5. end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Robert Dewar  

* sem_prag.adb (Process_Suppress_Unsuppress): Add extra warning
for ignoring pragma Suppress (Elaboration_Check) in SPARK mode.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 219222)
+++ sem_prag.adb(working copy)
@@ -9050,7 +9050,9 @@
 
  if C = Elaboration_Check and then SPARK_Mode = On then
 Error_Pragma_Arg
-  ("Suppress of Elaboration_Check ignored in SPARK??", Arg1);
+  ("Suppress of Elaboration_Check ignored in SPARK??",
+   "\elaboration checking rules are statically enforced "
+   & "(SPARK RM 7.7)", Arg1);
  end if;
 
  --  One-argument case

[Ada] Missing error on access type conversion

[Arnaud Charlet]

When the target of a type conversion is an access to an interface type
and the operand is not an access type but a tagged object which covers
the target interface the frontend does not report an error. After this
patch the compiler reports the missing error:

package Speaker is
   type Root is interface;
   procedure speak(this : Root) is abstract;

   type T_Ptr_All is access all Root'Class;

   type T is new Root with null record;
   overriding procedure speak(this : T);
end Speaker;

with Speaker; use Speaker;
package Factory_Play is
   procedure Dummy;
end Factory_Play;

package body Factory_Play is
   instance1 : aliased T;
   ref1 : constant Speaker.T_Ptr_All :=
Speaker.T_Ptr_All(instance1);   -- ERROR
   procedure Dummy is begin null; end;
end Factory_Play;

Command: gcc -c factory_play.adb
Output:
factory_play.adb:4:31: must be an access-to-object type

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Javier Miranda  

* sem_res.adb (Valid_Conversion): Restrict the checks on anonymous
access types whose target type is an interface type to operands
that are access types; required to report an error when the
operand is not an access type.

Index: sem_res.adb
===
--- sem_res.adb (revision 219222)
+++ sem_res.adb (working copy)
@@ -99,10 +99,10 @@
--  a component of a discriminated type (record or concurrent type).
 
procedure Check_For_Visible_Operator (N : Node_Id; T : Entity_Id);
-   --  Given a node for an operator associated with type T, check that
-   --  the operator is visible. Operators all of whose operands are
-   --  universal must be checked for visibility during resolution
-   --  because their type is not determinable based on their operands.
+   --  Given a node for an operator associated with type T, check that the
+   --  operator is visible. Operators all of whose operands are universal must
+   --  be checked for visibility during resolution because their type is not
+   --  determinable based on their operands.
 
procedure Check_Fully_Declared_Prefix
  (Typ  : Entity_Id;
@@ -258,8 +258,8 @@
 
procedure Set_String_Literal_Subtype (N : Node_Id; Typ : Entity_Id);
--  The String_Literal_Subtype is built for all strings that are not
-   --  operands of a static concatenation operation. If the argument is
-   --  not a N_String_Literal node, then the call has no effect.
+   --  operands of a static concatenation operation. If the argument is not
+   --  a N_String_Literal node, then the call has no effect.
 
procedure Set_Slice_Subtype (N : Node_Id);
--  Build subtype of array type, with the range specified by the slice
@@ -429,11 +429,12 @@
  elsif Nkind (P) = N_Index_Or_Discriminant_Constraint then
 
 --  The following check catches the unusual case where a
---  discriminant appears within an index constraint that is part of
---  a larger expression within a constraint on a component, e.g. "C
---  : Int range 1 .. F (new A(1 .. D))". For now we only check case
---  of record components, and note that a similar check should also
---  apply in the case of discriminant constraints below. ???
+--  discriminant appears within an index constraint that is part
+--  of a larger expression within a constraint on a component,
+--  e.g. "C : Int range 1 .. F (new A(1 .. D))". For now we only
+--  check case of record components, and note that a similar check
+--  should also apply in the case of discriminant constraints
+--  below. ???
 
 --  Note that the check for N_Subtype_Declaration below is to
 --  detect the valid use of discriminants in the constraints of a
@@ -12093,8 +12094,9 @@
   --  Ada 2005 (AI-251): Anonymous access types where target references an
   --  interface type.
 
-  elsif Ekind_In (Target_Type, E_General_Access_Type,
-   E_Anonymous_Access_Type)
+  elsif Is_Access_Type (Opnd_Type)
+and then Ekind_In (Target_Type, E_General_Access_Type,
+E_Anonymous_Access_Type)
 and then Is_Interface (Directly_Designated_Type (Target_Type))
   then
  --  Check the static accessibility rule of 4.6(17). Note that the

Re: [PATCH] -f{no-sanitize,{,no-}sanitize-recover}=all support

[Dodji Seketeli]

Jakub Jelinek  writes:

> On Mon, Jan 05, 2015 at 10:40:37PM +0100, Jakub Jelinek wrote:
>> > Are there any doc updates that need to happen as a result of this patch?
>> > Patch itself is fine for the trunk, just want to make sure the doc side is
>> > good too.
>> 
>> You're right, I'll add documentation tomorrow and repost the patch.
>
> Make that tonight ;), here it is.  I also found a bug in the
> -fsanitize=float-cast-overflow documentation and -f{,no-}sanitize-recover
> and fixed that too to much the implementation.
>
> Ok?

[...]

>
> 2015-01-05  Jakub Jelinek  
>
>   * opts.c (common_handle_option): Add support for
>   -fno-sanitize=all and -f{,no-}sanitize-recover=all.
>   * doc/invoke.texi: Document -fno-sanitize=all,
>   -f{,no-}sanitize-recover=all.  Document that
>   -fsanitize=float-cast-overflow is not enabled
>   by -fsanitize=undefined.  Fix up documentation
>   of -f{,no-}sanitize-recover.
>
>   * c-c++-common/asan/sanitize-all-1.c: New test.
>   * c-c++-common/ubsan/sanitize-all-1.c: New test.
>   * c-c++-common/ubsan/sanitize-all-2.c: New test.
>   * c-c++-common/ubsan/sanitize-all-3.c: New test.
>   * c-c++-common/ubsan/sanitize-all-4.c: New test.

This is OK.  Thanks!

-- 
Dodji

[Ada] Bump copyright year

[Arnaud Charlet]

Committed on trunk.

* gnatvsn.ads: Bump copyright year.

Index: gnatvsn.ads
===
--- gnatvsn.ads (revision 219191)
+++ gnatvsn.ads (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2014, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2015, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -92,7 +92,7 @@
Verbose_Library_Version : constant String := "GNAT Lib v" & Library_Version;
--  Version string stored in e.g. ALI files
 
-   Current_Year : constant String := "2014";
+   Current_Year : constant String := "2015";
--  Used in printing copyright messages
 
 end Gnatvsn;

[Ada] New directories in project path for gnatls --RTS=

[Arnaud Charlet]

Two new directories are added in the project path, when gnatls is invoked
with --RTS=, just before the two directories for the target.
When the runtime is a single name, the directories are:
  ///lib/gnat
  ///share/gpr
Otherwise, the runtime directory is either an absolute path or a path
relative to the current working directory and the two added directories
are:
  /lib/gnat
  /share/gpr

Tested on x86_64-pc-linux-gnu, committed on trunk

2015-01-06  Vincent Celier  

* gnatls.adb (Search_RTS): Invoke Initialize_Default_Project_Path
with the runtime name.
* prj-env.adb (Initialize_Default_Project_Path): When both
Target_Name and Runtime_Name are not empty string, add to the
project path the two directories .../lib/gnat and .../share/gpr
related to the runtime.
* prj-env.ads (Initialize_Default_Project_Path): New String
parameter Runtime_Name, defaulted to the empty string.

Index: gnatls.adb
===
--- gnatls.adb  (revision 219191)
+++ gnatls.adb  (working copy)
@@ -1225,6 +1225,10 @@
   if Src_Path /= null and then Lib_Path /= null then
  Add_Search_Dirs (Src_Path, Include);
  Add_Search_Dirs (Lib_Path, Objects);
+ Initialize_Default_Project_Path
+   (Prj_Path,
+Target_Name => Sdefault.Target_Name.all,
+Runtime_Name => Name);
  return;
   end if;
 
@@ -1237,7 +1241,9 @@
   --  Try to find the RTS on the project path. First setup the project path
 
   Initialize_Default_Project_Path
-(Prj_Path, Target_Name => Sdefault.Target_Name.all);
+(Prj_Path,
+ Target_Name => Sdefault.Target_Name.all,
+ Runtime_Name => Name);
 
   Rts_Full_Path := Get_Runtime_Path (Prj_Path, Name);
 
Index: prj-env.adb
===
--- prj-env.adb (revision 219191)
+++ prj-env.adb (working copy)
@@ -1873,8 +1873,9 @@
-
 
procedure Initialize_Default_Project_Path
- (Self: in out Project_Search_Path;
-  Target_Name : String)
+ (Self : in out Project_Search_Path;
+  Target_Name  : String;
+  Runtime_Name : String := "")
is
   Add_Default_Dir : Boolean := Target_Name /= "-";
   First   : Positive;
@@ -1894,6 +1895,24 @@
   --  The path name(s) of directories where project files may reside.
   --  May be empty.
 
+  Prefix : String_Ptr;
+  Runtime : String_Ptr;
+
+  procedure Add_Target;
+
+  procedure Add_Target is
+  begin
+ Add_Str_To_Name_Buffer
+   (Path_Separator & Prefix.all & Target_Name);
+
+ --  Note: Target_Name has a trailing / when it comes from
+ --  Sdefault.
+
+ if Name_Buffer (Name_Len) /= '/' then
+Add_Char_To_Name_Buffer (Directory_Separator);
+ end if;
+  end Add_Target;
+
begin
   if Is_Initialized (Self) then
  return;
@@ -2051,73 +2070,81 @@
   --  Set the initial value of Current_Project_Path
 
   if Add_Default_Dir then
- declare
-Prefix : String_Ptr;
+ if Sdefault.Search_Dir_Prefix = null then
 
- begin
-if Sdefault.Search_Dir_Prefix = null then
+--  gprbuild case
 
-   --  gprbuild case
+Prefix := new String'(Executable_Prefix_Path);
 
-   Prefix := new String'(Executable_Prefix_Path);
+ else
+Prefix := new String'(Sdefault.Search_Dir_Prefix.all
+  & ".." & Dir_Separator
+  & ".." & Dir_Separator
+  & ".." & Dir_Separator
+  & ".." & Dir_Separator);
+ end if;
 
-else
-   Prefix := new String'(Sdefault.Search_Dir_Prefix.all
- & ".." & Dir_Separator
- & ".." & Dir_Separator
- & ".." & Dir_Separator
- & ".." & Dir_Separator);
-end if;
+ if Prefix.all /= "" then
+if Target_Name /= "" then
 
-if Prefix.all /= "" then
-   if Target_Name /= "" then
+   if Runtime_Name /= "" then
+  if Base_Name (Runtime_Name) = Runtime_Name then
 
-  --  $prefix/$target/lib/gnat
+ --  $prefix/$target/$runtime/lib/gnat
+ Add_Target;
+ Add_Str_To_Name_Buffer
+   (Runtime_Name & Directory_Separator &
+  "lib" & Directory_Separator & "gnat");
 
-  Add_Str_To_Name_Buffer
-(Path_Separator & Prefix.all & Target_Name);
+ --  $prefix/$target/$runtime/share/gpr
+  

Re: Patch ping

[Jakub Jelinek]

On Mon, Jan 05, 2015 at 10:39:03PM +0100, Jakub Jelinek wrote:
> > >http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html
> > >   - -fsanitize=vptr support
> > How is this different from vtable pointer verification that we already
> > support?  Is there some reason we can't just use that instead?
> 
> I don't now the current vtable pointer verification too much, but my
> understanding of it is that it is hardly usable, because e.g. it requires
> libstdc++ to be rebuilt with the verification enabled, otherwise you can't
> verify stuff, and that means a performance penalty even for code you don't
> want to verify.  Unlike that, -fsanitize=vptr is lightweight, and you only
> rebuild with it what you want and can have other code kept as is, not
> recompiled.

Also, it seems to verify significantly less than -fsanitize=vptr does,
only method calls, while -fsanitize=vptr also verifies member accesses
and downcasts/upcasts.

Jakub