Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand

[Pitchumani Sivanupandi]

On Wednesday 19 October 2016 07:51 PM, Georg-Johann Lay wrote:

On 17.10.2016 09:27, Pitchumani Sivanupandi wrote:

On Thursday 13 October 2016 08:42 PM, Georg-Johann Lay wrote:

On 13.10.2016 13:44, Pitchumani Sivanupandi wrote:

On Monday 26 September 2016 08:19 PM, Georg-Johann Lay wrote:

On 26.09.2016 15:19, Pitchumani Sivanupandi wrote:

Attached patch for PR71676 and PR71678.

PR71676 is for AVR target that generates wrong code when switch 
case index is

more than 16 bits.

Switch case index of larger than SImode are checked for out of 
range before
'casesi' expand. RTL expand of casesi gets index as SImode, but 
index is

compared in HImode and ignores upper 16bits.

Attached patch changes the expansion for casesi to make the index 
comparison

in SImode and code generation accordingly.

PR71678 is ICE because below pattern in 'casesi' is not recognized.
(set (reg:HI 47)
 (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0)
   (reg:HI 45)))

Fix of PR71676 avoids the above pattern as it changes the comparison
to SImode.


But this means that all comparisons are now performed in SImode 
which is a
great performance loss for most programs which will switch on 
16-bit values.


IMO we need a less intrusive (w.r.t. performance) approach.


Yes.

I tried to split 'casesi' into several based on case values so that 
compare is

done
in less expensive modes (i.e. QI or HI). In few cases it is not 
possible

without
SImode subtract/ compare.

Pattern casesi will have index in SI mode. So, out of range checks 
will be

expensive
as most common uses (in AVR) of case values will be in QI/HI mode.

e.g.
  if case values in QI range
if upper three bytes index is set
  goto out_of_range

offset = index - lower_bound (QImode)
if offset > case_range   (QImode)
  goto out_of_range
goto jump_table + offset

  else if case values in HI range
if index[2,3] is set
  goto out_of_range

offset = index - lower_bound (HImode)
if offset > case_range   (HImode)
  goto out_of_range
goto jump_table + offset

This modification will not work for the negative index values. 
Because code to

check
upper bytes of index will be expensive than the SImode subtract/ 
compare.


So, I'm trying to update fix to have SImode subtract/ compare if 
the case

values include
negative integers. For, others will try to optimize as mentioned 
above. Is that

approach OK?


But the above code will be executed at run time and add even more 
overhead,
or am I missing something?  If you conclude statically at expand 
time from
the case ranges then we might hit a similar problem as with the 
original

subreg computation.


No. Lower bound and case range are const_int_operand, known at 
compile time.


Yes, but if the range if form 10 to 90, say, then you still don't know 
whether HImode and QImode is appropriate or not which adds to code 
size and register pressure.


As I mentioned earlier, I am working on a different approach which 
would revert your changes:  The casesi is basically unaltered (except 
for operand clean-ups and avoidance of clobbering subregs).


The ups of my approach are:

* The original value is known and whether is is QI or HI.

* The signedness is known which allows to use the maximum range of
  QI resp. HI depending on the sign.

* Also works on negative values.

* All is done at compile time, no need for extra code.

* No intermediate 32-bit values, no unnecessary increase of reg pressure.

* Optimization can be switched off by -fdisable if desired.

* Result can be seen in dumps.

The downsides are:

* Also needs some lines of code (~400).

* Makes assumptions on the anatomy of the code, i.e. extension
  precedes casesi.

First we should decide which route to follow as the changes are 
conflicting each other.  I have not so much time to work on the stuff 
but the results are promising.  If you are interested in the changes, 
I can supply it but it's all still work in progress.


Ok. I'll put this patch on hold for now.
Please share if you have draft version of your fix is ready.

Thanks.

Regards,
Pitchumani

[Bug c++/78047] [7 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 39846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39846=edit
unreduced testcase

[Bug c++/78047] New: [7 Regression] Chromium apparently gets miscompiled

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047

Bug ID: 78047
   Summary: [7 Regression] Chromium apparently gets miscompiled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Chromium gets miscompiled with gcc trunk.

Bizarrely, it crashes when one tries to view Stroustrup's CppCon2016 keynote
on github:

https://github.com/CppCon/CppCon2016/blob/master/Keynotes/The%20Evolution%20of%20C++%20-%20Past,%20Present,%20and%20Future/The%20Evolution%20of%20C++%20-%20Past,%20Present,%20and%20Future%20-%20Bjarne%20Stroustrup%20-%20CppCon%202016.pdf

../../third_party/tcmalloc/chromium/src/tcmalloc.cc:289] Attempt to free
invalid pointer 0x5f0c76f0

Thread 1 "chrome" received signal SIGSEGV, Segmentation fault.
0x56028d00 in tcmalloc::Abort() ()
(gdb) bt
#0  0x56028d00 in tcmalloc::Abort() ()
#1  0x5602d1d5 in tcmalloc::Log(tcmalloc::LogMode, char const*, int,
tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem) ()
#2  0x5d00ee6f in tc_free ()
#3  0x57eb9b4c in GrResourceProvider::GrResourceProvider(GrGpu*,
GrResourceCache*, GrSingleOwner*) ()
#4  0x57e88345 in GrContext::initCommon(GrContextOptions const&) ()
#5  0x57e88734 in GrContext::Create(GrBackend, long) ()
...

I narrowed it down to a single function:

 23 __attribute__((optimize("-O1")))
 24 GrResourceProvider::GrResourceProvider(GrGpu* gpu, GrResourceCache* cache,
GrSingleOwner* owner)   
 25 : INHERITED(gpu, cache, owner) {
 26 GR_DEFINE_STATIC_UNIQUE_KEY(gQuadIndexBufferKey);   
 27 fQuadIndexBufferKey = gQuadIndexBufferKey;  
 28 } 

__attribute__((optimize("-O1"))) "fixes" the issue.

 33929 class SkOnce {   
 33930 public:  
 33931 constexpr SkOnce() = default;
 33932  
 33933 template  
 33934 void operator()(Fn&& fn, Args&&... args) {   
 33935 auto state = fState.load(std::memory_order_acquire); 
 33936  
 33937 if (state == Done) { 
 33938 return;  
 33939 }
 33940  
 33941  
 33942 if (state == NotStarted && fState.compare_exchange_strong(state,
Claimed,
 33943  
std::memory_order_relaxed)) {   
 33944  
 33945 fn(std::forward(args)...); 
 33946 return fState.store(Done, std::memory_order_release);
 33947 }
 33948  
 33949  
 33950  
 33951 while (fState.load(std::memory_order_acquire) != Done) { }   
 33952 }
 33953  
 33954 private: 
 33955 enum State : uint8_t { NotStarted, Claimed, Done};   
 33956 std::atomic fState{NotStarted}; 
 33957 };  

 34201 static inline void
gr_init_static_unique_key_once(SkAlignedSTStorage<1,GrUniqueKey>* keyStorage) { 
 34202 GrUniqueKey* key = new (keyStorage->get()) GrUniqueKey;  
 34203 GrUniqueKey::Builder builder(key, GrUniqueKey::GenerateDomain(), 0); 
 34204 } 

109423 static SkOnce gQuadIndexBufferKey_once;  
109424  
109425 GrResourceProvider::GrResourceProvider(GrGpu* gpu, 

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

--- Comment #5 from Bernd Edlinger  ---
(In reply to Wilco from comment #4)
> However dealing with partial overlaps is complex so maybe the best option
> would be to add alternatives to di3_neon to either allow full overlap
> "r 0 X X X" or no overlap " r X  X X". The shift code works with full
> overlap.

That sounds like a good idea.

Then this condition in di3_neon could go away too:

&& (!reg_overlap_mentioned_p (operands[0], operands[1])
|| REGNO (operands[0]) == REGNO (operands[1])))

PR53979: add transform (a ^ b) | a -> a | b

[Prathamesh Kulkarni]

Hi Richard,
The attached patch adds the transform (a ^ b) | a -> a | b suggested in PR53979.
Bootstrap+tested on x86_64-unknown-linux-gnu.
OK to commit ?

Thanks,
Prathamesh
2016-10-20  Prathamesh Kulkarni  

PR tree-optimization/53979
* match.pd ((a ^ b) | a -> a | b): New pattern.

testsuite/
* gcc.dg/pr53979-1.c: New test-case.
* gcc.dg/pr53979-2.c: Likewise.

diff --git a/gcc/match.pd b/gcc/match.pd
index b782a1e..7888459 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -541,6 +541,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (bit_ior:c (bit_and @0 INTEGER_CST@2) (bit_and (bit_not @0) INTEGER_CST@1))
  (if (wi::bit_not (@2) == @1)
   (bit_xor @0 @1)))
+
+/* PR53979: Transform ((a ^ b) | a) -> (a | b) */
+(simplify
+  (bit_ior:c (bit_xor:c @0 @1) @0)
+  (bit_ior @0 @1))
+
 /* Simplify (~X & Y) to X ^ Y if we know that (X & ~Y) is 0.  */
 #if GIMPLE
 (simplify
diff --git a/gcc/testsuite/gcc.dg/pr53979-1.c b/gcc/testsuite/gcc.dg/pr53979-1.c
new file mode 100644
index 000..aee54f5
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr53979-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-fdump-tree-gimple" } */
+
+unsigned f1(unsigned a, unsigned b)
+{
+  return (a ^ b) | a; 
+}
+
+/* { dg-final { scan-tree-dump "a | b" "gimple" } } */
diff --git a/gcc/testsuite/gcc.dg/pr53979-2.c b/gcc/testsuite/gcc.dg/pr53979-2.c
new file mode 100644
index 000..be2607a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr53979-2.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-forwprop-details" } */
+
+unsigned f(unsigned a, unsigned b)
+{
+  unsigned t1 = a ^ b;
+  unsigned t2 = t1 | a;
+  return t2;
+}
+
+/* { dg-final { scan-tree-dump "gimple_simplified to t2_\[0-9\] = 
a_\[0-9\]*\\(D\\) | b_\[0-9\]*\\(D\\)" "forwprop1" } } */

[Bug c++/78046] Unnecessary setne/testb instructions with temporary int brace-initialized in if statement

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78046

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Not a bug. Gcc -O0 is not something which is optimized for.

[Bug c++/78046] New: Unnecessary setne/testb instructions with temporary int brace-initialized in if statement

[jamespharvey20 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78046

Bug ID: 78046
   Summary: Unnecessary setne/testb instructions with temporary
int brace-initialized in if statement
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

A two-variable comparison

   int main() {
  int i{0};
  int j{0};
  if(i != j) {
  }
   }

And a one-variable comparison to a temporary

   int main() {
  int i{0};
  if(i != int{0}) {
  }
   }

Generate fairly similar assembly, as expected, using gcc -Wa,-adhln -g
source.cpp -O0 > source.s

The two-variable version creates assembly for the declaration and if statement
of:

   movl $0, -8(%rbp)
   movl -4(%rbp), %eax
   cmpl -8(), %eax

The temporary version generates assembly for the if statement and temporary of:

   movl $0, %eax
   cmpl -4(%rbp), %eax
   setne %al
   testb %al, %al

So, at least without optimization, they are (and should be) different in terms
of a stack variable vs a register temporary.

But, why I'm writing is the `setne` and `testb` instructions that appear there.

FWIW, clang assembles with the same difference for stack variable vs a register
temporary, but does NOT create add the `setne` and `testb` instructions.

Additionally, changing from using an `int` to a class, there aren't extra
`setne` and `testb` instructions.  The assembly of stack vs register variables
is effectively identical, just the order of two sets of `leaq` instructions is
reversed, as in:

   class foo {
   public:
  foo(int _x) : x{_x} { }
  int x;
  bool operator!=(const foo& other) { return x != other.x; }
   };

   int main() {
  foo i{0};
  if(i != foo{0}) {
  }
   }

[Bug c++/78045] New: Parsing error when creating temporary object with space in type name (unsigned int)

[jamespharvey20 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78045

Bug ID: 78045
   Summary: Parsing error when creating temporary object with
space in type name (unsigned int)
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamespharvey20 at gmail dot com
  Target Milestone: ---

For test code comparisons where the expected value can be constructed as a
temporary, I've been doing so.  This has really been for classes, but when I
tried it for `unsigned int` I ran into this bug.

In this test case, `i` is of course a substitute for the function being tested,
and `j` is the expected value.  This compiles and works fine:

   int main() {
  const int i{0};
  if(i != int{0}) {
 throw false;
  }
   }

Changing to an `unsigned int` fails:

   ...const unsigned int i{0};
  if(i != unsigned int{0})) {...

Giving:

   mine.cpp: In function ‘int main()’:
   mine.cpp:4:12: error: expected primary-expression before ‘unsigned’
   if(i != unsigned int{0}) {
   ^~~~
   mine.cpp:4:12: error: expected ‘)’ before ‘unsigned’

Unless the c++11 standard dictates only single word types may be made using
temporaries using initialization braces, I think the space is tripping up the
parsing.

[Bug c/61939] warn when __attribute__((aligned(x))) is ignored

[daniel.santos at pobox dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61939

--- Comment #2 from Daniel Santos  ---
(In reply to Vedran Miletic from comment #1)
> #include 
> #include 
> float f(std::vector& A, std::vector& B)
> {
>   __builtin_assume_aligned(A.data(), 64);
>   __builtin_assume_aligned(B.data(), 64);
>   return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
> }

You are doing it wrong. __builtin_assume_aligned() returns void* and you must
use it's return value for it to be effective. So your code should be something
like this:

float f(std::vector& A, std::vector& B)
{
  float *a_data = __builtin_assume_aligned(A.data(), 64);
  float *b_data = __builtin_assume_aligned(B.data(), 64);
  return std::inner_product(a_data, b_data, B.begin(), 0.f);
}

Of course, this assumes that the buffer that your vector<> implementation
supplies is 64 byte aligned.

Re: [RFC][IPA-VRP] ADDR_EXPR and nonnull

[kugan]

On 20/10/16 01:26, Jan Hubicka wrote:

Would excluding weak symbols (I believe I can check DECL_WEAK for this) good
enough. Or looking for acceptable subset would work?


I think we should add a symtab helper to tell if address_nonzero_p (if
that doesn't aleady exist).


We have node->nonzero_address()


Thanks for the pointer. Here is an attempt. Does this look OK?

+ if (TREE_CODE (arg) == ADDR_EXPR)
+   {
+ /* See if the AADR_EXPR is nonnull.  */
+ varpool_node *node = NULL;
+ tree base = TREE_OPERAND (arg, 0);
+ base = get_base_address (base);
+
+ if (decl_address_ip_invariant_p (base)
+ || !is_global_var (base))
+   {
+ /* If the symbol address is local or
+constant.  */
+ addr_nonzero = true;
+   }
+ else
+   {
+ /* If symbol address is nonzero_address.  */
+ node = varpool_node::get (base);
+ if (node && node->nonzero_address ())
+   addr_nonzero = true;
+   }
+   }

Attached patch passes bootstrap and regression testing on x86_64-linu-gnu.

Thanks,
Kugan



Honza


Richard.


Thanks,
Kugan



Richard.


Attached patch bootstraps and regression testing didn't introduce any new
regressions.

Thanks,
Kugan


gcc/ChangeLog:

2016-10-19  Kugan Vivekanandarajah  

* ipa-prop.c (ipa_compute_jump_functions_for_edge): Set
value range to nonull for ADDR_EXPR.

gcc/testsuite/ChangeLog:

2016-10-19  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp5.c: New test.
* gcc.dg/ipa/vrp6.c: New test.








--
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 353b638..affd8b9 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1670,9 +1670,35 @@ ipa_compute_jump_functions_for_edge (struct 
ipa_func_body_info *fbi,
 
   if (POINTER_TYPE_P (TREE_TYPE (arg)))
{
- if (TREE_CODE (arg) == SSA_NAME
- && param_type
- && get_ptr_nonnull (arg))
+ bool addr_nonzero = false;
+
+ if (TREE_CODE (arg) == ADDR_EXPR)
+   {
+ /* See if the AADR_EXPR is nonnull.  */
+ varpool_node *node = NULL;
+ tree base = TREE_OPERAND (arg, 0);
+ base = get_base_address (base);
+
+ if (decl_address_ip_invariant_p (base)
+ || !is_global_var (base))
+   {
+ /* If the symbol address is local or
+constant.  */
+ addr_nonzero = true;
+   }
+ else
+   {
+ /* If symbol address is nonzero_address.  */
+ node = varpool_node::get (base);
+ if (node && node->nonzero_address ())
+   addr_nonzero = true;
+   }
+   }
+
+ if ((TREE_CODE (arg) == SSA_NAME
+  && param_type
+  && get_ptr_nonnull (arg))
+ || addr_nonzero)
{
  jfunc->vr_known = true;
  jfunc->m_vr.type = VR_ANTI_RANGE;
diff --git a/gcc/testsuite/gcc.dg/ipa/vrp5.c b/gcc/testsuite/gcc.dg/ipa/vrp5.c
index e69de29..571798d 100644
--- a/gcc/testsuite/gcc.dg/ipa/vrp5.c
+++ b/gcc/testsuite/gcc.dg/ipa/vrp5.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-ipa-cp-details -fdump-tree-vrp1" } */
+
+static __attribute__((noinline, noclone))
+int foo (int *p)
+{
+  if (!p)
+return 0;
+  *p = 1;
+}
+
+struct st
+{
+  int a;
+  int b;
+};
+
+int arr1[10];
+int a;
+int bar (struct st *s)
+{
+  int arr2[10];
+  int b;
+  if (!s)
+return 0;
+  foo (>a);
+  foo ();
+  foo ();
+  foo ([1]);
+  foo ([1]);
+}
+
+/* { dg-final { scan-ipa-dump "Setting nonnull for 0" "cp" } } */
+/* { dg-final { scan-tree-dump-times "if" 1 "vrp1" } } */
diff --git a/gcc/testsuite/gcc.dg/ipa/vrp6.c b/gcc/testsuite/gcc.dg/ipa/vrp6.c
index e69de29..971db44 100644
--- a/gcc/testsuite/gcc.dg/ipa/vrp6.c
+++ b/gcc/testsuite/gcc.dg/ipa/vrp6.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-ipa-cp-details -fdump-tree-vrp1" } */
+
+static __attribute__((noinline, noclone))
+int foo (int *p)
+{
+  if (!p)
+return 0;
+  *p = 1;
+}
+
+struct st
+{
+  int a;
+  int b;
+};
+
+struct st s2;
+int a;
+int bar (struct st *s)
+{
+  struct st s3;
+  int b;
+  if (!s)
+return 0;
+  foo (>a);
+  foo ();
+  foo ();
+  foo ();
+  foo ();
+}
+
+/* { dg-final { scan-ipa-dump "Setting nonnull for 0" "cp" } } */
+/* { dg-final { scan-tree-dump-times "if" 1 "vrp1" } } */

[Bug tree-optimization/33784] Disabled -fipa-type-escape

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33784

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Andrew Pinski  ---
fipa-type-escape has since been removed .

Though I am thinking about bringing it back soon and will do much more of
testing it.

[Bug c++/78040] Missed mangled names of class methods in the translation unit dump

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78040

--- Comment #1 from Andrew Pinski  ---
-fdump-translation-unit is only useful for debugging GCC and that is it.  It is
not designed for some random person to use for their own purpose.

[Bug c++/78042] g++ does not select the corresponding overloads of abs() for long and long long

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78042

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
Invalid, you are calling abs and not std::abs.  There is (or was) a defect
report about C abs function being included in the global scope rather than just
in the std scope.

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[barannikov88 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918

Sergey Barannikov  changed:

   What|Removed |Added

 CC||barannikov88 at gmail dot com

--- Comment #4 from Sergey Barannikov  ---
This is the ABI problem. The search phase of the unwinding process cannot
distinguish between a case when a true handler found and a case when the search
process should stop, because it has reached a call site that must not pass the
exception through. In both cases _URC_HANDLER_FOUND is returned by the
personality routine, and the second phase of the unwinding process begins (the
actual unwinding).

There is another problem in LSDA format (in action table format to be precise).
Consider the following example:

void bad_guy() noexcept {
  try {
Foo foo;
throw 0;
  } catch (float) {
// Don't catch int.
  }
}

void level1() {
  bad_guy();
  throw "dead code";
}

int main() {
  try {
level1();
  } catch (const char *) {
  }
}

When you compile and run it you get:

Foo::Foo()
terminate called after throwing an instance of 'int'
Aborted (core dumped)


It works as expected. But (the funny thing) if you change "catch (const char
*)" in main to "catch (int)", you will get this:

Foo::Foo()
Foo::~Foo()
terminate called without an active exception
Aborted (core dumped)

This is because there is currently no way to represent a "Terminate" action in
the action table of LSDA. gcc represents it as a simply cleanup action, that
means that the unwinder does not stop at a noexcept function and continues
searching for a handler up the stack.
In the original example there is no handler for the exception thrown, and the
runtime terminates the program instantly (no stack unwinding done). When one
changes "catch (const char *)" to "catch (int)", the unwinder finds this
handler at the search phase and launches the second, unwinding, phase. The
unwinding process then destroys the local object "foo", checks the exception
type for matching "float", and falls into the code that calls std::terminate
when the matching fails. Since there is no __cxa_begin_catch prior to
std::terminate, we get the error message "terminate called without an active
exception" instead of correct "terminate called after throwing an instance of
'int'".

RTL frontend, insn recognition, and pointer equality

[David Malcolm]

I've updated the RTL frontend to the new "compact" dump format and have
it "mostly working", for some definition of that term [1].  I'm
focusing on the "__RTL" extension to cc1, rather than having a
true "rtl1" frontend.

I've run into an issue with insn recognition relating to pointer
equality of rtx.

I have a test case for "final", which contains this x86_64 code
(shown here in compact form):

  (cinsn (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)) "test.c":2
 (nil))

This fails inside "final" with:
gcc.dg/rtl/x86_64/final.c:130:1: error: unrecognizable insn:
(insn 5 4 6 2 (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)) -1
 (nil))

(the error message is showing the non-compact form of the
loaded insn).

The pertinent part of i386.md is this:

;; Do not schedule instructions accessing memory across this point.

(define_expand "memory_blockage"
  [(set (match_dup 0)
(unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]
  ""
{
  operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
  MEM_VOLATILE_P (operands[0]) = 1;
})

(define_insn "*memory_blockage"
  [(set (match_operand:BLK 0)
(unspec:BLK [(match_dup 0)] UNSPEC_MEMORY_BLOCKAGE))]
  ""
  ""
  [(set_attr "length" "0")])


If I run that directly in memory, the insn *is* recognized:

(gdb) call gen_memory_blockage ()
$19 = (insn 33 0 0 (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)) -1
 (nil))

(gdb) call recog_memoized ((rtx_insn *)$19)
$20 = 695
(gdb) call debug ($19)
(insn 33 0 0 (set (mem/v:BLK (scratch:DI) [0  A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
] UNSPEC_MEMORY_BLOCKAGE)) 695 {*memory_blockage}
 (nil))

By contrast, if I load the rtx from a dump file, the insn is
*not* recognized.

Stepping through insn-recog.c revealed the problem is that the
  (match_dup 0)
fails when run on a reconstructed-from-dump copy:

44388   case 17:
44389 if (GET_MODE (x2) != BLKmode)
44390   return -1;
44391 x3 = XVECEXP (x2, 0, 0);
44392 if (!rtx_equal_p (x3, operands[0]))
44393   return -1;
44394 return 695; /* *memory_blockage */

(gdb) call debug (x3)
(mem/v:BLK (scratch:DI) [0  A8])

(gdb) call debug (operands[0])
(mem/v:BLK (scratch:DI) [0  A8])

(gdb) p x3
$40 = (rtx) 0x719ee150
(gdb) p operands[0]
$41 = (rtx) 0x719ee120

(gdb) call rtx_equal_p ($40, $41)
$42 = 0

The issue is that on loading from a file, we have two distinct
  (scratch:DI)
rtx.

rtl.c:rtx_equal_p has:

case DEBUG_EXPR:
case VALUE:
case SCRATCH:
CASE_CONST_UNIQUE:
  return 0;

i.e. SCRATCH values always compare as non-equal, unless they
have pointer equality.

It works when built directly from insn-emit.c within gen_memory_blockage:

74308 emit_insn (gen_rtx_SET (operand0,
74309   gen_rtx_UNSPEC (BLKmode,
74310   gen_rtvec (1,
74311   copy_rtx (operand0)),
74312   17)));

since rtl.c:copy_rtx has:

case SCRATCH:
  /* SCRATCH must be shared because they represent distinct values.  */
  return orig;

So we have a case where a gen_* builds a pattern that contains a
graph, i.e. where a SCRATCH appears in two places:

(insn 5 4 6 2 (set (mem/v:BLK (scratch:DI) [0  A8])
   ^^
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0  A8])
^^
] UNSPEC_MEMORY_BLOCKAGE)) -1
 (nil))

and for which the recognizer will only recognize the insn
if that graph-like property is preserved: that we have pointer-equality
for the two (scratch:DI).

I'm wondering what the best course of action for the RTL frontend is.

Some ideas:

(a) dump the insn name even in compact mode, and do a string-match to
look it up when reading dumps.  This would isolate us somewhat from .md
file changes, but if we lose the memoized value, it can't be
re-recognized.  This feels like papering over the problem.

(b) for all codes for which rtx_equal_p requires pointer equality, add
some kind of extra ID to the dump, allowing the loader to reconstruct
the graph.  This could be the pointer itself:

  (scratch:DI [0x719ee150])
  (scratch:DI [ptr:0x719ee150])

or somesuch, but it would perhaps be better to use some kind of more
human-friendly ID e.g.

  (scratch:DI [ptr-idx: 42])

or similar, rather than subject ourselves to raw hex values.  Probably
need an extra flag to print-rtl.c, to avoid making the dumps more
verbose for everyone who doesn't want this (if so, does "compact" mode
need renaming...)

Or just do this for SCRATCH, maybe?

(c) some kind of special-casing?  

[PATCH] DWARF5 .debug_loclists support

[Jakub Jelinek]

Hi!

This patch adds .debug_loclists and .debug_loclists.dwo
support for -gdwarf-5 and -gdwarf-5 -gsplit-dwarf.
The decrease of section size from .debug_loc section to .debug_loclists
is really nice.

The patch doesn't handle -gdwarf-5 -gsplit-dwarf on targets where assembler
doesn't support .uleb128, because in that case we really can't use
DW_LLE_startx_length (no way to emit uleb128 region sizes - we don't have
accurate instruction length computations) - we should use DW_LLE_startx_endx
in that case, but would need .debug_addr entries not just for the region
starts, but ends.  Cary, could you resolve this incrementally (and, do you
plan to convert other -gsplit-dwarf support parts to DWARF 5 for -gdwarf-5)?

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

2016-10-20  Jakub Jelinek  

* dwarf2out.h (enum dw_val_class): Add dw_val_class_loclistsptr.
* dwarf2out.c (struct dw_loc_list_struct): Change emitted field
from bool to 1-bit uchar bitfield.  Add num_assigned and
offset_emitted bitfields.
(dw_val_equal_p): Compare v.val_lbl_id rather than v.val_unsigned
for dw_val_class_lineptr and dw_val_class_macptr.  Handle
dw_val_class_loclistsptr.
(new_addr_loc_descr): Fix up formatting.
(DEBUG_LOCLISTS_SECTION, DEBUG_DWO_LOCLISTS_SECTION): Define.
(add_AT_low_high_pc): Fix up formatting.
(add_AT_loclistsptr): New function.
(AT_lbl): Allow dw_val_class_loclistsptr.
(print_dw_val, attr_checksum, attr_checksum_ordered, same_dw_val_p):
Handle dw_val_class_loclistsptr.
(loc_list_idx): New variable.
(output_loclists_offsets): New function.
(size_of_die): For dw_val_class_loc_list -gsplit-dwarf -gdwarf-5
add size_of_uleb128 of the index.  Drop never used
dwarf_split_debug_info AT_index handling.  Handle
dw_val_class_loclistsptr.
(value_format): Return DW_FORM_loclistsx for dw_val_class_loc_list
if -gsplit-dwarf -gdwarf-5.  Handle dw_val_class_loclistsptr.
(output_loc_list): Handle DWARF 5 .debug_loclists* format.
(output_loc_list_offset): Handle -gsplit-dwarf -gdwarf-5
DW_FORM_loclistx indexes.
(output_attr_index_or_value): Fix up formatting.  Don't handle
dw_val_class_loc_list here.
(output_die): Formatting fixes.  Handle dw_val_class_loclistsptr.
For dw_val_class_loc_list call output_loc_list_offset rather than
output_attr_index_or_value.
(init_sections_and_labels): For -gdwarf-5 use .debug_loclists
or .debug_loclists.dwo section name for debug_loc_section.
(resolve_addr_in_expr): Formatting fix.
(index_location_lists): Likewise.
(assign_location_list_indexes): New function.
(dwarf2out_finish): If there are any location lists, for
-gsplit-dwarf -gdwarf-5 add DW_AT_loclists_base attribute.  Call
index_location_lists only if have_location_lists.  Call
assign_location_list_indexes for -gsplit-dwarf -gdwarf-5.  Emit
.debug_loclists{,.dwo} section header for -gdwarf-5, for -gdwarf-5
-gsplit-dwarf also emit offset table.

--- gcc/dwarf2out.h.jj  2016-10-18 08:17:19.0 +0200
+++ gcc/dwarf2out.h 2016-10-19 23:09:53.456786659 +0200
@@ -147,6 +147,7 @@ enum dw_val_class
   dw_val_class_lineptr,
   dw_val_class_str,
   dw_val_class_macptr,
+  dw_val_class_loclistsptr,
   dw_val_class_file,
   dw_val_class_data8,
   dw_val_class_decl_ref,
--- gcc/dwarf2out.c.jj  2016-10-19 14:37:23.0 +0200
+++ gcc/dwarf2out.c 2016-10-19 23:15:44.280352083 +0200
@@ -1279,7 +1279,13 @@ typedef struct GTY(()) dw_loc_list_struc
   bool resolved_addr;
   /* True if this list has been replaced by dw_loc_next.  */
   bool replaced;
-  bool emitted;
+  /* True if it has been emitted into .debug_loc* / .debug_loclists*
+ section.  */
+  unsigned char emitted : 1;
+  /* True if hash field is index rather than hash value.  */
+  unsigned char num_assigned : 1;
+  /* True if .debug_loclists.dwo offset has been emitted for it already.  */
+  unsigned char offset_emitted : 1;
   /* True if the range should be emitted even if begin and end
  are the same.  */
   bool force;
@@ -1367,8 +1373,6 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_unsigned_const:
 case dw_val_class_const:
 case dw_val_class_range_list:
-case dw_val_class_lineptr:
-case dw_val_class_macptr:
   /* These are all HOST_WIDE_INT, signed or unsigned.  */
   return a->v.val_unsigned == b->v.val_unsigned;
 
@@ -1381,6 +1385,9 @@ dw_val_equal_p (dw_val_node *a, dw_val_n
 case dw_val_class_fde_ref:
   return a->v.val_fde_index == b->v.val_fde_index;
 case dw_val_class_lbl_id:
+case dw_val_class_lineptr:
+case dw_val_class_macptr:
+case dw_val_class_loclistsptr:
 case dw_val_class_high_pc:
   return strcmp (a->v.val_lbl_id, 

[PATCH] DWARF5 .debug_line{,_str} support

[Jakub Jelinek]

Hi!

This patch adds support for DWARF5 .debug_line{,_str} section format,
though only if !DWARF2_ASM_LINE_DEBUG_INFO, because otherwise
.debug_line is emitted by the assembler.  For that we'll need some
coordination with gas, dunno if we want a new as directive for that,
or as command line switch, or perhaps key DWARF5 .debug_line on the
presence of .debug_line_str section (though the last one probably isn't a
good idea, because -gsplit-dwarf doesn't use .debug_line_str).

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

2016-10-20  Jakub Jelinek  

* dwarf2out.c (debug_line_str_section): New variable.
(debug_line_str_hash): Likewise.
(DEBUG_LINE_STR_SECTION): Define.
(set_indirect_string): Handle DW_FORM_line_strp like
DW_FORM_strp.
(find_string_form): Fix up formatting.
(size_of_die): Handle DW_FORM_line_strp like DW_FORM_strp.
Fix up indentation.
(output_die): Handle DW_FORM_line_strp.
(output_file_names): Add -gdwarf-5 support.
(output_line_info): Likewise.
(init_sections_and_labels): Initialize debug_line_str_section.
(output_indirect_string): Change 2nd argument from void *
to enum dwarf_form form, compare with form rather than
DW_FORM_strp.
(output_indirect_strings): Pass DW_FORM_strp to
output_indirect_string traversion.
(dwarf2out_finish): Output .debug_line_str strings.
(dwarf2out_c_finalize): Clear debug_line_str_section and
debug_line_str_hash.

--- gcc/dwarf2out.c.jj  2016-10-18 08:17:19.0 +0200
+++ gcc/dwarf2out.c 2016-10-19 14:37:23.945841924 +0200
@@ -167,6 +167,7 @@ static GTY(()) section *debug_loc_sectio
 static GTY(()) section *debug_pubnames_section;
 static GTY(()) section *debug_pubtypes_section;
 static GTY(()) section *debug_str_section;
+static GTY(()) section *debug_line_str_section;
 static GTY(()) section *debug_str_dwo_section;
 static GTY(()) section *debug_str_offsets_section;
 static GTY(()) section *debug_ranges_section;
@@ -225,6 +226,8 @@ struct indirect_string_hasher : ggc_ptr_
 
 static GTY (()) hash_table *debug_str_hash;
 
+static GTY (()) hash_table *debug_line_str_hash;
+
 /* With split_debug_info, both the comp_dir and dwo_name go in the
main object file, rather than the dwo, similar to the force_direct
parameter elsewhere but with additional complications:
@@ -232,8 +235,8 @@ static GTY (()) hash_tableform == DW_FORM_strp || node->form == DW_FORM_GNU_str_index)
+  if (node->form == DW_FORM_strp
+  || node->form == DW_FORM_line_strp
+  || node->form == DW_FORM_GNU_str_index)
 {
   gcc_assert (node->label);
   return;
@@ -4175,7 +4183,7 @@ find_string_form (struct indirect_string
  single module.  */
   if (DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
   || ((debug_str_section->common.flags & SECTION_MERGE) == 0
-  && (len - DWARF_OFFSET_SIZE) * node->refcount <= len))
+ && (len - DWARF_OFFSET_SIZE) * node->refcount <= len))
 return node->form = DW_FORM_string;
 
   set_indirect_string (node);
@@ -8500,10 +8508,10 @@ size_of_die (dw_die_ref die)
  break;
case dw_val_class_str:
   form = AT_string_form (a);
-  if (form == DW_FORM_strp)
+ if (form == DW_FORM_strp || form == DW_FORM_line_strp)
size += DWARF_OFFSET_SIZE;
- else if (form == DW_FORM_GNU_str_index)
-size += size_of_uleb128 (AT_index (a));
+ else if (form == DW_FORM_GNU_str_index)
+   size += size_of_uleb128 (AT_index (a));
  else
size += strlen (a->dw_attr_val.v.val_str->str) + 1;
  break;
@@ -9458,6 +9466,11 @@ output_die (dw_die_ref die)
a->dw_attr_val.v.val_str->label,
debug_str_section,
"%s: \"%s\"", name, AT_string (a));
+ else if (a->dw_attr_val.v.val_str->form == DW_FORM_line_strp)
+   dw2_asm_output_offset (DWARF_OFFSET_SIZE,
+  a->dw_attr_val.v.val_str->label,
+  debug_line_str_section,
+  "%s: \"%s\"", name, AT_string (a));
   else if (a->dw_attr_val.v.val_str->form == DW_FORM_GNU_str_index)
 dw2_asm_output_data_uleb128 (AT_index (a),
  "%s: \"%s\"", name, AT_string (a));
@@ -10429,8 +10442,18 @@ output_file_names (void)
 
   if (!last_emitted_file)
 {
-  dw2_asm_output_data (1, 0, "End directory table");
-  dw2_asm_output_data (1, 0, "End file name table");
+  if (dwarf_version >= 5)
+   {
+ dw2_asm_output_data (1, 0, "Directory entry format count");
+ dw2_asm_output_data_uleb128 (0, "Directories count");
+ dw2_asm_output_data (1, 0, "File name entry format count");
+ 

[committed] Fix bootstrap for hppa64-hpux11* on trunk

[John David Anglin]

The removal of the JCR_SECTION_NAME define in config/pa/pa64-hpux.h broke 
bootstrap on hppa64-hpux
with HP ld.  It exposed a header ordering issue building the crt* objects.  
EH_FRAME_SECTION was not
defined when pa64-hpux.h was included and as a result frame_dummy was not 
called.  This caused everything
which used the new libgcc to abort.

The problem was fixed by using the __LIBGCC_EH_FRAME_SECTION_NAME__ and
__LIBGCC_DTORS_SECTION_ASM_OP__ predefines.

I also moved three defines in gcc/config/pa/pa64-hpux.h to a new header file in 
libgcc.  These defines were only
used for building the crt* objects.

Tested on hppa64-hp-hpux11.11.  Committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-10-19  John David Anglin  

libgcc/
* config/pa/pa64-hpux-lib.h: New file.  
(EH_FRAME_SECTION_NAME): Rename to __LIBGCC_EH_FRAME_SECTION_NAME__.
(DTORS_SECTION_ASM_OP): Rename to __LIBGCC_DTORS_SECTION_ASM_OP__.
* config.host (tm_file): Add pa/pa64-hpux-lib.h to tm_file on
hppa*64*-*-hpux11*.
gcc/
* config/pa/pa64-hpux.h (PA_INIT_FRAME_DUMMY_ASM_OP): Move to
config/pa/pa64-hpux-lib.h.
(PA_CRTBEGIN_HACK): Likewise.
(DTOR_LIST_BEGIN): Likewise.

--- /dev/null   2016-10-19 17:08:27 +
+++ libgcc/config/pa/pa64-hpux-lib.h2016-10-17 18:52:38 +
@@ -0,0 +1,101 @@
+/* Definitions of target machine for GNU compiler, for HPs running
+   HP-UX using the 64bit runtime model.
+   Copyright (C) 1999-2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* We use DTOR_LIST_BEGIN to carry a bunch of hacks to allow us to use
+   the init and fini array sections with both the HP and GNU linkers.
+   The linkers setup the required dynamic entries in the dynamic segment
+   and the dynamic linker does the calls.  This approach avoids using
+   collect2.
+
+   The first hack is to implement __do_global_ctors_aux in crtbegin as
+   it needs to be the first entry in the init array so that it is called
+   last.  HP got the order of the init array backwards.  The DT_INIT_ARRAY
+   is supposed to be executed in the same order as the addresses appear in
+   the array.  DT_FINI_ARRAY is supposed to be executed in the opposite
+   order.
+
+   The second hack is a set of plabels to implement the effect of
+   CRT_CALL_STATIC_FUNCTION.  HP-UX 11 only supports DI_INIT_ARRAY and
+   DT_FINI_ARRAY and they put the arrays in .init and .fini, rather than
+   in .init_array and .fini_array.  The standard defines for .init and
+   .fini have the execute flag set.  So, the assembler has to be hacked
+   to munge the standard flags for these sections to make them agree
+   with what the HP linker expects.  With the GNU linker, we need to
+   used the .init_array and .fini_array sections.  So, we set up for
+   both just in case.  Once we have built the table, the linker does
+   the rest of the work.
+   The order is significant.  Placing __do_global_ctors_aux first in
+   the list, results in it being called last.  User specified initializers,
+   either using the linker +init command or a plabel, run before the
+   initializers specified here.  */
+
+/* We need to add frame_dummy to the initializer list if EH_FRAME_SECTION_NAME
+   is defined.  */
+#if defined(__LIBGCC_EH_FRAME_SECTION_NAME__)
+#define PA_INIT_FRAME_DUMMY_ASM_OP ".dword P%frame_dummy"
+#else
+#define PA_INIT_FRAME_DUMMY_ASM_OP ""
+#endif
+
+/* The following hack sets up the .init, .init_array, .fini and
+   .fini_array sections.  */
+#define PA_CRTBEGIN_HACK \
+asm (TEXT_SECTION_ASM_OP);  \
+static void __attribute__((used))   \
+__do_global_ctors_aux (void)\
+{   \
+  func_ptr *p = __CTOR_LIST__;  \
+  while (*(p + 1))  \
+p++;\
+  for (; *p != (func_ptr) -1; p--)  \
+(*p) ();\
+}   \
+  

Re: [patch] Fix PHI optimization issue with boolean types

[Eric Botcazou]

> Because BOOLEAN_TYPE types only have two values as documented in
> tree.def:
> 
> /* Boolean type (true or false are the only values).  Looks like an
>INTEGRAL_TYPE.  */
> DEFTREECODE (BOOLEAN_TYPE, "boolean_type", tcc_type, 0)

Yes, but on the other hand they have a precision and a range.

> There are not many references to BOOLEAN_TYPE in ada/gcc-interface
> thus it shouldn't be hard to change ... (looks like Ada might even prefer
> ENUMERAL_TYPE here).

It was like that originally (an ENUMERAL_TYPE) but this blocked LTO (well, 
cross-language LTO) exactly like the sizetype discrepancy, so I don't really 
feel like going back in time.

-- 
Eric Botcazou

Re: [PATCH v3] gcc/config/tilegx/tilegx.c (tilegx_function_profiler): Save r10 to stack before call mcount

[Jeff Law]

On 10/06/2016 07:53 AM, Chen Gang wrote:

Hello Maintainers:

Is this patch OK? Please help check it when you have time (at least for
me, it passes all related test and comparation).

And I shall continue to find and fix another issues about tilegx.

Thanks.

On 6/4/16 21:25, cheng...@emindsoft.com.cn wrote:

From: Chen Gang 

r10 may also be as parameter stack pointer for the nested function, so
need save it before call mcount.

Also clean up code: use '!' instead of "== 0" for checking
static_chain_decl and compute_total_frame_size.

2016-06-04  Chen Gang  

gcc/
PR target/71331
* config/tilegx/tilegx.c (tilegx_function_profiler): Save r10
to stack before call mcount.
(tilegx_can_use_return_insn_p): Clean up code.
So if I understand the tilegx architecture correctly, you're issuing the 
r10 save & sp adjustment as a bundle, and the restore & sp adjustment as 
a bundle.


The problem is the semantics of bunding on the tilegx effectively mean 
that all source operands are read in parallel, then all outputs occur in 
parallel.


So if we take the bundle

{addi sp,sp,-8 ; st sp, r10}

The address used for the st is the value of the stack pointer before the 
addi instruction.


Similarly for the restore r10 bundle.  The address used for the load is 
sp before adjustment.


Given my understanding of the tilegx bundling semantics, that seems wrong.

Jeff

[libgo] Remove unused declarations in runtime.h

[Eric Botcazou]

Hi,

linking any Go program on SPARC/Solaris with the GNU assembler and the Sun 
linker yields a warning:

ld: warning: relocation error: R_SPARC_UA32: file 
/sydney.a/users/botcazou/gcc-head/sparc-sun-
solaris2.10/./libgo/libgobegin.a(libgobegin_a-go-main.o): symbol 
runtime_startup_random_data: external symbolic relocation against non-
allocatable section .debug_info; cannot be processed at runtime: relocation 
ignored

It's because (almost) every C file in runtime/ includes runtime.h, which has 
these lines:

byte*  runtime_startup_random_data;
uint32 runtime_startup_random_data_len;
void   runtime_get_random_data(byte**, int32*);

which cause (almost) every object file to have the first 2 as common symbols 
and this runs afoul of some limitation of the Sun linker.  Now there seem to 
be no other references to these 3 objects in the libgo directory and removing 
them doesn't seem to change the behavior of the Go compiler so the attached 
patch does just that.

Tested on x86_64-suse-linux and SPARC/Solaris, OK for mainline?


2016-10-19  Eric Botcazou  

* runtime/runtime.h (runtime_startup_random_data): Delete.
(runtime_startup_random_data_len): Likewise.
(runtime_get_random_data): Likewise.

-- 
Eric BotcazouIndex: runtime/runtime.h
===
--- runtime/runtime.h	(revision 241326)
+++ runtime/runtime.h	(working copy)
@@ -220,10 +220,6 @@ extern bool runtime_copystack;
 #define USED(v)		((void) v)
 #define	ROUND(x, n)	(((x)+(n)-1)&~(uintptr)((n)-1)) /* all-caps to mark as macro: it evaluates n twice */
 
-byte*	runtime_startup_random_data;
-uint32	runtime_startup_random_data_len;
-void	runtime_get_random_data(byte**, int32*);
-
 enum {
 	// hashinit wants this many random bytes
 	HashRandomBytes = 32

Re: [PATCH] fix outstanding -Wformat-length failures (pr77735 et al.)

[Jeff Law]

On 10/17/2016 03:59 PM, Martin Sebor wrote:



On 10/17/2016 01:11 PM, Jeff Law wrote:

On 10/02/2016 02:10 PM, Martin Sebor wrote:

The attached patch fixes a number of outstanding test failures
and ILP32-related bugs in the gimple-ssa-sprintf pattch pointed
out in bug 77676 and 77735).  The patch also fixes c_strlen to
correctly handle wide strings (previously it accepted them but
treated them as nul-terminated byte sequences), and adjusts the
handling of "%a" to avoid assuming a specific number of decimal
digits (this is likely a defect in C11 that I'm pursuing with
WG14).

Tested on powerpc64le, i386, and x86_64.

There is one outstanding failure in the builtin-sprintf-warn-1.c
test on powerpc64le that looks like it might be due to the
printf_pointer_format target hook not having been set up entirely
correctly.  I'll look into that separately, along with pr77819.

Martin

gcc-77735.diff


PR middle-end/77735 - FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c

gcc/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* builtins.c (string_length): New function.
(c_strlen): Use string_length.  Correctly handle wide strings.
* gimple-ssa-sprintf.c (target_max_value, target_size_max): New
functions.
(target_int_max): Call target_max_value.
(format_result::knownrange): New data member.
(fmtresult::fmtresult): Define default constructor.
(format_integer): Use it and set format_result::knownrange.
Handle global constants.
(format_floating_max): Add third argument.
(format_floating): Recompute maximum value for %a for each argument.
(get_string_length): Use fmtresult default ctor.
(format_string): Set format_result::knownrange.
(format_directive): Check format_result::knownrange.
(add_bytes): Same.  Correct caret placement in diagnostics.
(pass_sprintf_length::compute_format_length): Set
format_result::knownrange.
(pass_sprintf_length::handle_gimple_call): Use target_size_max.

gcc/testsuite/ChangeLog:
2016-10-02  Martin Sebor  

PR middle-end/77735
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-2.c: Same.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Adjust/relax.
* gcc.dg/tree-ssa/builtin-sprintf-warn-4.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-6.c: XFAIL for LP64 only.
* gcc.dg/tree-ssa/builtin-sprintf.c: Add test cases.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 92f939e..410bbc3 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1281,9 +1330,9 @@ format_floating (const conversion_spec ,
int width, int prec)
 res.range.max = width;
 }

-  /* The argument is only considered bounded when the range of output
- bytes is exact.  */
-  res.bounded = res.range.min == res.range.max;
+  /* The argument is considered bounded when the output of a directive
+ is fully specified and the range of output bytes is exact.  */
+  // res.bounded &= res.range.min == res.range.max;

Did you mean to leave this commented out?


I'm pretty sure I didn't mean to leave the code commented out like
that.  I suspect I commented it out to confirm that it's not needed,
and forgot to remove it after it passed my testing.  Let me remove
it (and thanks for pointing it out!)


It looks like you're defining a constructor for "struct fmtresult".
Normally once we define a constructor we turn the underlying object into
a class.It appears that the constructor leaves argmin, argmax,
knownrange, bounded & constant uninitialized?  Am I missing something
here?


I added the default ctor to avoid having to explicitly clear the
members.  The member() syntax means to default-initialize them by
setting them to zero or null:

 struct fmtresult
 {
+  fmtresult ()
+  : argmin (), argmax (), knownrange (), bounded (), constant ()
+  {
+range.min = range.max = HOST_WIDE_INT_MAX;
+  }
+

Or did you have something else in mind?  (I want to leave the members
public so they can conveniently accessed.)

Ah, thanks for clarifying.







+  /* A plain '%c' directive.  Its ouput is excactly 1.  */

Typo for exactly.



Will fix.

With that and with the comment above removed, would like me to post
an updated patch or is it okay commit?
OK to commit after the fix in floating_format (assignment to 
res.bounded) and the commit fix.


jeff

[Bug c++/11407] [DR 115] Function cannot be resolved

[colu...@gmx-topmail.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407

Robert Haberlach  changed:

   What|Removed |Added

 CC||colu...@gmx-topmail.de

--- Comment #18 from Robert Haberlach  ---
This is not fixed:

template void g();

int i = sizeof();

fails with trunk.

[Bug fortran/78043] ICE in force_decl_die, at dwarf2out.c:23533

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78043

--- Comment #2 from Gerhard Steinmetz  
---
Code from comment 0 only ICEs in combination with option -g*.
Adding an output routine :

$ cat z3.f90
module m
   common /xc/ a
end
module m2
   use m
end
subroutine s(x)
   use m
   print *, a
   print *, x
end
program p
   use m2, only: z => a
   z = 1.0
   call s(z)
end

$ gfortran-7-20161016 z3.f90
$ a.out
   1.
   1.



Deleting one module layer produces no ICE at all :

$ cat z5.f90
module m2
   common /xc/ a
end
subroutine s(x)
   use m2
   print *, a
   print *, x
end
program p
   use m2, only: z => a
   z = 1.0
   call s(z)
end

$ gfortran-7-20161016 z5.f90
$ a.out
   1.
   1.

$ gfortran-7-20161016 -g z5.f90
$ a.out
   1.
   1.

Re: [PR other/70945] Handle function_glibc_finite_math in offloading

[Thomas Schwinge]

Hi!

On Sat, 21 May 2016 17:59:17 +0200, I wrote:
> As discussed in  "Offloading: compatibility
> of target and offloading toolchains", there are situations where we have
> to do more work to ensure compatibility between target and offloading
> toolchains.

The outcome of the discussion a few months ago has been that instead of
my proposed compiler patch, the "offloading port(s) of newlib [...]
should provide [a] translation layer from the host headers to the
offloading target functions".  We still plan to, but have not yet gotten
to spend time on that, unfortunately.

To at least support the following use case:

> The first thing I'm working on is math functions usage in offloaded
> regions.
> 
> Here is a first patch, addressing glibc's finite math optimizations: if
> -ffinite-math-only (as implied by -ffast-math, or -Ofast) is in effect,
> glibc's  is known to include  for "special
> entry points to use when the compiler got told to only expect finite
> results".  This divertes the math functions' assembler names from
> "[function]" to "__[function]_finite".  This, obviously, is incompatible
> with offloading targets that don't use glibc, and thus don't provide
> these "__[function]_finite" entry points.

..., I have now in r241355 committed my original patch to
gomp-4_0-branch, with an (incomplete) test case added:

commit 7e178f04bf6d692a17c4be4ff050da2d23a543e7
Author: tschwinge 
Date:   Wed Oct 19 21:24:37 2016 +

[PR other/70945] Handle function_glibc_finite_math in offloading

gcc/
PR other/70945
* targhooks.c (default_libc_has_function): Update comment.
* target.def (libc_has_function): Likewise.
* doc/tm.texi: Regenerate.
* coretypes.h (enum function_class): Add
function_glibc_finite_math.
* config/darwin.c (darwin_libc_has_function): Handle it.
* lto-streamer.h (enum lto_section_type): Rename
LTO_section_offload_table to LTO_section_offload_data.  Adjust all
users.
* lto-cgraph.c (void output_offload_data): New function, split out
of output_offload_tables.  Adjust all users.  Stream the target's
function_glibc_finite_math property.
(input_offload_data): New function, split out of
input_offload_tables.  Adjust all users.  Handle mismatch between
the target's and the offloading target's
function_glibc_finite_math property.
libgomp/
PR other/70945
* testsuite/libgomp.oacc-c-c++-common/pr70945-1.c: New file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@241355 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog.gomp |  20 ++
 gcc/config/darwin.c|   2 +
 gcc/coretypes.h|  11 +-
 gcc/doc/tm.texi|   2 +-
 gcc/lto-cgraph.c   | 181 +++-
 gcc/lto-streamer-out.c |   2 +-
 gcc/lto-streamer.h |   6 +-
 gcc/lto/lto.c  |   2 +-
 gcc/target.def |   2 +-
 gcc/targhooks.c|   2 +-
 libgomp/ChangeLog.gomp |   5 +
 .../libgomp.oacc-c-c++-common/pr70945-1.c  | 231 +
 12 files changed, 408 insertions(+), 58 deletions(-)

diff --git gcc/ChangeLog.gomp gcc/ChangeLog.gomp
index 04894b8..851da81 100644
--- gcc/ChangeLog.gomp
+++ gcc/ChangeLog.gomp
@@ -1,3 +1,23 @@
+2016-10-19  Thomas Schwinge  
+
+   PR other/70945
+   * targhooks.c (default_libc_has_function): Update comment.
+   * target.def (libc_has_function): Likewise.
+   * doc/tm.texi: Regenerate.
+   * coretypes.h (enum function_class): Add
+   function_glibc_finite_math.
+   * config/darwin.c (darwin_libc_has_function): Handle it.
+   * lto-streamer.h (enum lto_section_type): Rename
+   LTO_section_offload_table to LTO_section_offload_data.  Adjust all
+   users.
+   * lto-cgraph.c (void output_offload_data): New function, split out
+   of output_offload_tables.  Adjust all users.  Stream the target's
+   function_glibc_finite_math property.
+   (input_offload_data): New function, split out of
+   input_offload_tables.  Adjust all users.  Handle mismatch between
+   the target's and the offloading target's
+   function_glibc_finite_math property.
+
 2016-10-05  Nathan Sidwell  
 
* tree.h (OMP_CLAUSE_TILE_ITERVAR, OMP_CLAUSE_TILE_COUNT): New.
diff --git gcc/config/darwin.c gcc/config/darwin.c
index 0055d80..92fe3e5 100644
--- gcc/config/darwin.c
+++ gcc/config/darwin.c
@@ -3401,6 +3401,8 @@ darwin_libc_has_function (enum function_class fn_class)
   || 

[Bug other/70945] Offloading: compatibility of target and offloading toolchains

[tschwinge at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70945

--- Comment #6 from Thomas Schwinge  ---
Author: tschwinge
Date: Wed Oct 19 21:24:37 2016
New Revision: 241355

URL: https://gcc.gnu.org/viewcvs?rev=241355=gcc=rev
Log:
[PR other/70945] Handle function_glibc_finite_math in offloading

gcc/
PR other/70945
* targhooks.c (default_libc_has_function): Update comment.
* target.def (libc_has_function): Likewise.
* doc/tm.texi: Regenerate.
* coretypes.h (enum function_class): Add
function_glibc_finite_math.
* config/darwin.c (darwin_libc_has_function): Handle it.
* lto-streamer.h (enum lto_section_type): Rename
LTO_section_offload_table to LTO_section_offload_data.  Adjust all
users.
* lto-cgraph.c (void output_offload_data): New function, split out
of output_offload_tables.  Adjust all users.  Stream the target's
function_glibc_finite_math property.
(input_offload_data): New function, split out of
input_offload_tables.  Adjust all users.  Handle mismatch between
the target's and the offloading target's
function_glibc_finite_math property.
libgomp/
PR other/70945
* testsuite/libgomp.oacc-c-c++-common/pr70945-1.c: New file.

Added:
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/pr70945-1.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/config/darwin.c
branches/gomp-4_0-branch/gcc/coretypes.h
branches/gomp-4_0-branch/gcc/doc/tm.texi
branches/gomp-4_0-branch/gcc/lto-cgraph.c
branches/gomp-4_0-branch/gcc/lto-streamer-out.c
branches/gomp-4_0-branch/gcc/lto-streamer.h
branches/gomp-4_0-branch/gcc/lto/lto.c
branches/gomp-4_0-branch/gcc/target.def
branches/gomp-4_0-branch/gcc/targhooks.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug fortran/78021] [5/6/7 Regression] Wrong result with optimization on character constant

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78021

--- Comment #3 from Thomas Koenig  ---
This looks promising, modulo some line breaks:

Index: dependency.c
===
--- dependency.c(Revision 240928)
+++ dependency.c(Arbeitskopie)
@@ -226,10 +226,24 @@ gfc_dep_compare_functions (gfc_expr *e1, gfc_expr
  if ((args1->expr == NULL) ^ (args2->expr == NULL))
return -2;

- if (args1->expr != NULL && args2->expr != NULL
- && gfc_dep_compare_expr (args1->expr, args2->expr) != 0)
-   return -2;
+ if (args1->expr != NULL && args2->expr != NULL)
+   {
+ gfc_expr *e1, *e2;
+ e1 = args1->expr;
+ e2 = args2->expr;

+ if (gfc_dep_compare_expr (e1, e2) != 0)
+   return -2;
+
+ /* Special case: String arguments which compare equal can
+still have different lengths, which makes them different
calls.   */
+ 
+ if (e1->expr_type == EXPR_CONSTANT && e1->ts.type == BT_CHARACTER
+ && e2->expr_type == EXPR_CONSTANT && e2->ts.type ==
BT_CHARACTER
+ && e1->value.character.length != e2->value.character.length)
+   return -2;
+   }
+
  args1 = args1->next;
  args2 = args2->next;
}

[Bug libstdc++/56383] error with multiple enable_shared_from_this base classes

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56383

--- Comment #8 from Jonathan Wakely  ---
On trunk it's now also possible to mix std::enable_shared_from_this and
std::__enable_shared_from_this bases without a hard error:

struct A : std::enable_shared_from_this
{
void* a() { return shared_from_this().get(); }
};

struct B : std::__enable_shared_from_this
{
};

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Christophe Lyon]

On 19 October 2016 at 20:43, Aldy Hernandez  wrote:
>
>>> OK for the trunk whenever you're ready.
>>>
>>> jeff
>>
>>
>> You are too fast for me :-)
>> I do not have the build trees for all the configurations ready for
>> manual testing...
>> So, I just merged the initial patch and the 2nd one, and started
>> a validation job to make sure the 2nd patch fixes all the regressions
>> observed earlier.
>> It will take a few hours.
>
>
> There shouldn't be any problems that didn't surface in my cross build, since
> they are not execution tests, but compile tests.
>
> I have committed the patch.  If there any specific failures specific to your
> target, let me know and I'll address those separately.
>

Validation results of the 2 patches combined are OK.

Thanks

> Thanks.
> Aldy

Re: [PATCH] Make std::enable_shared_from_this cope with ambiguity

[Jonathan Wakely]

On 19/10/16 21:13 +0100, Jonathan Wakely wrote:

This patch does three things:

1. Refactor std::enable_shared_from_this support code.

Instead of several overloads of __enable_shared_from_this_helper
that contain the same code but operating on slightly different types
I've split it into two parts. Upcasting to an accessible+unambiguous
enable_shared_from_this base class is done by new functions found by
ADL, __enable_shared_from_this_base. That is called by a new
template function __shared_ptr::_M_enable_shared_from_this_with()
which actually does the enabling by calling _M_weak_assign.

Calls to _M_enable_shared_from_this_with(p) closely match the
wording from my https://wg21.link/p0033r1 paper ("enables
shared_from_this with p") and are constrained so they don't give an
error if the __enable_shared_from_this_base() call is ambiguous. We
already gracefully handled ambiguous std::enable_shared_from_this
bases (PR56383) but failed noisily if a type had a combination of
std::enable_shared_from_this, std::__enable_shared_from_this and
std::experimental::enable_shared_from_this bases. Now we treat those
combinations gracefully.

2. Change std::experimental::enable_shared_from_this bases to be
initialized independently of std::enable_shared_from_this bases.
It's now possible to have both, and for both to be enabled. See
enable_shared_from_this.cc which tests this.

The standard says we have to enable shared_from_this for types with
an accessible and unambiguous std::enable_shared_from_this base
class, and we should be able to do that even if the class also has
an experimental::enable_shared_from_this base class. Now we can.

Potentially we could do the same for std::__enable_shared_from_this,
but I'm happy for those bases to be considered ambiguous with
std::enable_shared_from_this.

3. Don't enable shared_from_this for arrays stored in
experimental::shared_ptr.  This matches the boost::shared_ptr
semantics, and I intend to propose this as a fix for C++17 too. It
doesn't make sense to treat the first element of an array specially
and enable shared_from_this for the first element only.


I forgot to say that 2. and 3. are appropriate for gcc-6-branch too,
as they only touch the experimental TS code.

Re: [PATCH] Make -Wint-in-bool-context warn on suspicious shift ops

[Jeff Law]

On 10/18/2016 12:14 PM, Bernd Edlinger wrote:

On 10/18/16 19:05, Joseph Myers wrote:

> On Tue, 18 Oct 2016, Bernd Edlinger wrote:
>

>> Hi,
>>
>> this restricts the -Wint-in-bool-context warning to signed shifts,
>> to reduce the number of false positives Markus reported yesterday.

>
> This patch seems to be missing testcases (that warned before the patch
> and don't warn after it).
>

Yes of course.

New patch, this time with a test case, compiled from the linux sample.

Bootstrapped and reg-tested as usual.
Is it OK for trunk?


Bernd.


patch-bool-context4.diff


c-family:
2016-10-17  Bernd Edlinger  

* c-common.c (c_common_truthvalue_conversion): Warn only for signed
integer shift ops in boolean context.

testsuite:
2016-10-17  Bernd Edlinger  

* c-c++-common/Wint-in-bool-context-2.c: New test.
Comment please in the code indicating why we're restricting this to 
signed shifts. I'm not entirely sure I agree with avoiding the 
warning for this case, but I'm not up for fighting about it.  So OK 
after adding the comment.


jeff

[PATCH] Make std::enable_shared_from_this cope with ambiguity

[Jonathan Wakely]

This patch does three things:

1. Refactor std::enable_shared_from_this support code.

 Instead of several overloads of __enable_shared_from_this_helper
 that contain the same code but operating on slightly different types
 I've split it into two parts. Upcasting to an accessible+unambiguous
 enable_shared_from_this base class is done by new functions found by
 ADL, __enable_shared_from_this_base. That is called by a new
 template function __shared_ptr::_M_enable_shared_from_this_with()
 which actually does the enabling by calling _M_weak_assign.

 Calls to _M_enable_shared_from_this_with(p) closely match the
 wording from my https://wg21.link/p0033r1 paper ("enables
 shared_from_this with p") and are constrained so they don't give an
 error if the __enable_shared_from_this_base() call is ambiguous. We
 already gracefully handled ambiguous std::enable_shared_from_this
 bases (PR56383) but failed noisily if a type had a combination of
 std::enable_shared_from_this, std::__enable_shared_from_this and
 std::experimental::enable_shared_from_this bases. Now we treat those
 combinations gracefully.

2. Change std::experimental::enable_shared_from_this bases to be
 initialized independently of std::enable_shared_from_this bases.
 It's now possible to have both, and for both to be enabled. See
 enable_shared_from_this.cc which tests this.

 The standard says we have to enable shared_from_this for types with
 an accessible and unambiguous std::enable_shared_from_this base
 class, and we should be able to do that even if the class also has
 an experimental::enable_shared_from_this base class. Now we can.

 Potentially we could do the same for std::__enable_shared_from_this,
 but I'm happy for those bases to be considered ambiguous with
 std::enable_shared_from_this.

3. Don't enable shared_from_this for arrays stored in
 experimental::shared_ptr.  This matches the boost::shared_ptr
 semantics, and I intend to propose this as a fix for C++17 too. It
 doesn't make sense to treat the first element of an array specially
 and enable shared_from_this for the first element only.


* include/backward/auto_ptr.h (__shared_ptr(auto_ptr&&)): Call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (__enable_shared_from_this_helper):
Remove overload for std::enable_shared_from_this..
(__enable_shared_from_this_base): Define friend function to select a
std::enable_shared_from_this base class.
* include/bits/shared_ptr_base.h (__enable_shared_from_this_helper):
Remove all overloads.
(__shared_ptr): Change all relevant constructors to call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
(__shared_ptr::__efst_base_t, __shared_ptr::__has_efst_base): Helpers
to detect accessible and unambiguous enable_shared_from_this bases.
(__shared_ptr::_M_enable_shared_from_this_with): New function to
replace __enable_shared_from_this_helper overloads.
(__enable_shared_from_this_helper): Remove overload for
std::__enable_shared_from_this.
(__enable_shared_from_this_base): Define friend function to select a
std::__enable_shared_from_this base class.
* include/experimental/bits/shared_ptr.h (experimental::shared_ptr):
Change relevant constructors to call _M_enable_shared_from_this_with.
(experimental::shared_ptr::__efst_base_t)
(experimental::shared_ptr::__has_efst_base): Helpers to detect
accessible and unambiguous enable_shared_from_this bases.
(experimental::shared_ptr::_M_enable_shared_from_this_with): Define.
(experimental::__enable_shared_from_this_helper): Remove overload for
std::experimental::enable_shared_from_this.
(experimental::__expt_enable_shared_from_this_base): Define friend
function to select a std::experimental::enable_shared_from_this base.
* testsuite/experimental/memory/shared_ptr/cons/
enable_shared_from_this.cc: New test.
* testsuite/experimental/memory/shared_ptr/cons/unique_ptr_ctor.cc:
Adjust expected behaviour for shared_ptr.

Tested powerpc64le-linux, comitted to trunk.


commit 83405dbeebb5487ae4745b2bdb2edd8f29414a07
Author: Jonathan Wakely 
Date:   Wed Oct 19 19:36:55 2016 +0100

Make std::enable_shared_from_this cope with ambiguity

* include/backward/auto_ptr.h (__shared_ptr(auto_ptr&&)): Call
_M_enable_shared_from_this_with instead of
__enable_shared_from_this_helper.
* include/bits/shared_ptr.h (__enable_shared_from_this_helper):
Remove overload for std::enable_shared_from_this..
(__enable_shared_from_this_base): Define friend function to select a
std::enable_shared_from_this base class.
* include/bits/shared_ptr_base.h (__enable_shared_from_this_helper):

Re: RFC [1/3] divmod transform v2

[Jeff Law]

On 10/15/2016 11:59 PM, Prathamesh Kulkarni wrote:

Hi,
After approval from Bernd Schmidt, I committed the patch to remove
optab functions for
sdivmod_optab and udivmod_optab in optabs.def, which removes the block
for divmod patch.

This patch is mostly the same as previous one, except it drops
targeting __udivmoddi4() because
it gave undefined reference link error for calling __udivmoddi4() on
aarch64-linux-gnu.
It appears aarch64 has hardware insn for DImode div, so __udivmoddi4()
isn't needed for the target
(it was a bug in my patch that called __udivmoddi4() even though
aarch64 supported hardware div).

However this makes me wonder if it's guaranteed that __udivmoddi4()
will be available for a target if it doesn't have hardware div and
divmod insn and doesn't have target-specific libfunc for
DImode divmod ? To be conservative, the attached patch doesn't
generate call to __udivmoddi4.

Passes bootstrap+test on x86_64-unknown-linux.
Cross-tested on arm*-*-*, aarch64*-*-*.
Verified that there are no regressions with SPEC2006 on
x86_64-unknown-linux-gnu.
OK to commit ?

Thanks,
Prathamesh


divmod-v2-3-main.txt


2016-10-15  Prathamesh Kulkarni  
Kugan Vivekanandarajah  
Jim Wilson  

* target.def: New hook expand_divmod_libfunc.
* doc/tm.texi.in: Add hook for TARGET_EXPAND_DIVMOD_LIBFUNC
* doc/tm.texi: Regenerate.
* internal-fn.def: Add new entry for DIVMOD ifn.
* internal-fn.c (expand_DIVMOD): New.
* tree-ssa-math-opts.c: Include optabs-libfuncs.h, tree-eh.h,
targhooks.h.
(widen_mul_stats): Add new field divmod_calls_inserted.
(target_supports_divmod_p): New.
(divmod_candidate_p): Likewise.
(convert_to_divmod): Likewise.
(pass_optimize_widening_mul::execute): Call
calculate_dominance_info(), renumber_gimple_stmt_uids() at
beginning of function. Call convert_to_divmod()
and record stats for divmod.
Starting with some high level design comments.  If these conflict with 
comments from others, let me know and we'll work through the issues.


I don't really like introducing code conditional on the target 
capabilities this early in the gimple optimization pipeline.


Would it be possible to always do the transformation to divmod in the 
gimple optimizers, regardless of the target capabilities.  Then in the 
gimple->RTL expanders make a final decision about divmod insn, libcall, 
or using div/mod insns?


That would move all the target dependencies out of the gimple optimizers 
and into the gimple->rtl expansion phase, which is the preferred place 
to start introducing this kind of target dependency.


With that background, I'm going to focus more on the identification of 
divmod opportunities than the expansion bits.





diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index a4a8e49..866c368 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -7078,6 +7078,11 @@ This is firstly introduced on ARM/AArch64 targets, 
please refer to
 the hook implementation for how different fusion types are supported.
 @end deftypefn

+@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (rtx @var{libfunc}, 
machine_mode @var{mode}, rtx @var{op0}, rtx @var{op1}, rtx *@var{quot}, rtx 
*@var{rem})
+Define this hook for enabling divmod transform if the port does not have
+hardware divmod insn but defines target-specific divmod libfuncs.
+@end deftypefn
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 265f1be..c4c387b 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -4890,6 +4890,8 @@ them: try the first ones in this list first.

 @hook TARGET_SCHED_FUSION_PRIORITY

+@hook TARGET_EXPAND_DIVMOD_LIBFUNC
+
 @node Sections
 @section Dividing the Output into Sections (Texts, Data, @dots{})
 @c the above section title is WAY too long.  maybe cut the part between
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 0b32d5f..42c6973 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -2207,6 +2207,53 @@ expand_ATOMIC_COMPARE_EXCHANGE (internal_fn, gcall *call)
   expand_ifn_atomic_compare_exchange (call);
 }

+/* Expand DIVMOD() using:

In general, we do not use () when referring to objects in comments.


+ a) optab handler for udivmod/sdivmod if it is available.
+ b) If optab_handler doesn't exist, generate call to
+target-specific divmod libfunc.  */
+
+static void
+expand_DIVMOD (internal_fn, gcall *call_stmt)
In general, don't use upper case for function names.  Lower case please. 
 But I believe we should be pushing all the expansion stuff into the 
gimple->rtl expansion code, so I haven't looked at this closely yet on 
the expectation it'll likely move.





diff 

[Bug target/78037] Incorrect code generated at optimization level -O2 for tzcnt and binary and

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78037

--- Comment #9 from Uroš Bizjak  ---
Created attachment 39845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39845=edit
Patch that introduces new builtins with UNSPEC_LZCNT and UNSPEC_TZCNT RTX
patterns

This patch introduces new builtins with UNSPEC_LZCNT and UNSPEC_TZCNT RTX
patterns.

The patch fails following tests:

FAIL: gcc.target/i386/bmi-4.c (test for excess errors)
FAIL: gcc.target/i386/bmi-5.c (test for excess errors)
FAIL: gcc.target/i386/bmi-6.c (test for excess errors)

These tests check that:

/* Test that a constant operand 0 to tzcnt gets folded.  */
extern void link_error(void);
int main()
{
  if (__tzcnt_u32(0) != 32)
link_error();
  return 0;
}

But unpatched gcc simply calls generic __builtin_ctz in the above case. This is
undefined behaviour, so it looks that the test works only by luck...

OTOH, we know that __tzcnt_* and __lzcnt_* builtin functions implement CTZ and
CLZ functionality with defined output for all input arguments. Instead of
simply removing mentioned tests, we can introduce certain constant-folding
functionality to ix86_fold_builtin that would handle constant arguments in a
__builtin_ctz/__builtin_clz way.

The patch is thoroughly tested and works OK (modulo testsuite failures
mentioned above), but I have no idea on how to implement tree-folding stuff. 

So, some kind soul that would take the patch from this point is most welcome.

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #7 from Andrew Pinski  ---
I am a bit shocked you are using ILP32 for aarch64 bare metal.  This is the
first time I have seen that.

[v3 PATCH] Do the operator= SFINAE in the return type for optional, not in the template parameters.

[Ville Voutilainen]

Tested on Linux-x64.

2016-10-19  Ville Voutilainen  

Do the operator= SFINAE in the return type for optional,
not in the template parameters.
* include/std/optional (operator=(_Up&&)): Move SFINAE
from template parameters to the return type.
(operator=(const optional<_Up>&)): Likewise.
(operator=(optional<_Up>&&)): Likewise.
diff --git a/libstdc++-v3/include/std/optional 
b/libstdc++-v3/include/std/optional
index 21210ab..f272876 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -568,15 +568,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 return *this;
   }
 
-  template, decay_t<_Up>>>,
-is_constructible<_Tp, _Up>,
-__not_<__and_,
-  is_same<_Tp, decay_t<_Up,
-is_assignable<_Tp&, _Up>>::value,
-  bool> = true>
-optional&
+  template
+enable_if_t<__and_<
+ __not_, decay_t<_Up>>>,
+ is_constructible<_Tp, _Up>,
+ __not_<__and_,
+   is_same<_Tp, decay_t<_Up,
+ is_assignable<_Tp&, _Up>>::value,
+   optional&>
 operator=(_Up&& __u)
 {
   if (this->_M_is_engaged())
@@ -587,16 +586,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return *this;
 }
 
-  template>,
-is_constructible<_Tp, const _Up&>,
-is_assignable<_Tp&, _Up>,
-__not_<__converts_from_optional<_Tp, _Up>>,
-__not_<__assigns_from_optional<_Tp, _Up>>
->::value,
-  bool> = true>
-optional&
+  template
+   enable_if_t<__and_<
+ __not_>,
+ is_constructible<_Tp, const _Up&>,
+ is_assignable<_Tp&, _Up>,
+ __not_<__converts_from_optional<_Tp, _Up>>,
+ __not_<__assigns_from_optional<_Tp, _Up>>
+ >::value,
+   optional&>
 operator=(const optional<_Up>& __u)
 {
   if (__u)
@@ -613,16 +611,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return *this;
 }
 
-  template>,
-is_constructible<_Tp, _Up>,
-is_assignable<_Tp&, _Up>,
-__not_<__converts_from_optional<_Tp, _Up>>,
-__not_<__assigns_from_optional<_Tp, _Up>>
->::value,
-  bool> = true>
-optional&
+  template
+   enable_if_t<__and_<
+ __not_>,
+ is_constructible<_Tp, _Up>,
+ is_assignable<_Tp&, _Up>,
+ __not_<__converts_from_optional<_Tp, _Up>>,
+ __not_<__assigns_from_optional<_Tp, _Up>>
+ >::value,
+   optional&>
 operator=(optional<_Up>&& __u)
 {
   if (__u)

[Bug middle-end/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c++ |middle-end

--- Comment #2 from Andrew Pinski  ---
There are already filed bug reports about false positive for this warning. 
This might be a dup of one of those.  

Also this warning is hard not to get false positives really for conditional
unitialized variables which is why the option was split into two.  One for the
hard for GCC to prove that it is not a false positive (-Wmaybe-uninitialized).

[Bug rtl-optimization/78038] [5/6/7 Regression] internal compiler error: in get_sub_rtx, at ree.c:655

[steffen-schmidt at siemens dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78038

--- Comment #6 from Steffen Schmidt  ---
(In reply to ktkachov)
> 
> By the way, the optimisation in which the ICE occurs is ree (redundant
> extension elimination). You can turn it off by adding -fno-ree to the flags.

Thanks a lot for the quick replies, I'll try switching off ree for the moment.

[Bug c++/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044

--- Comment #1 from Romain Geissler  ---
Created attachment 39844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39844=edit
test.i

[Bug c++/78044] New: -Wmaybe-uninitialized and -O2: false positive with boost::optional

[romain.geissler at amadeus dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044

Bug ID: 78044
   Summary: -Wmaybe-uninitialized and -O2: false positive with
boost::optional
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Created attachment 39843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39843=edit
test.cpp

Hi,

I am having a false positive when using -O2 and -Wmaybe-uninitialized with the
latest gcc 6 (g++ (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) from Fedora 24) with
boost::optional. Unfortunately my attempt to reduce the test case by trying to
extract the relevant boost parts failed.

Please find attached the reproducer test.cpp, that includes boost/optional.hpp
(tested with boost 1.60 and 1.61, I have a warning in both cases).

g++ -std=gnu++14 -O2 -Wall -c -o test.o test.cpp
test.cpp: In function 'void someFunction(const void*)':
test.cpp:22:16: warning: '*((void*)& aOptional +4)' may be used uninitialized
in this function [-Wmaybe-uninitialized]
 Optional_t aOptional;
^

In "someFunction()" the boost::optional value that is being passed and copied
is definitely not uninitialized.

You can also find attached the preprocessor output in test.i

Cheers,
Romain

[Bug c++/77474] sizeof and function template don't work properly together

[michele.caini at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77474

--- Comment #3 from Michele Caini  ---
The same applies using member function template.

[Bug fortran/78033] Internal Compiler Error in enforce_single_undo_checkpoint

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033

--- Comment #5 from Steve Kargl  ---
On Wed, Oct 19, 2016 at 04:17:34AM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78033
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to kargl from comment #1)
> > Reduced testcase.
> > 
> > function f(n, x)
> >integer, intent(in) :: n 
> >complex, intent(in) :: x(1:n)
> >real :: f
> >f = g([real(x(1:n)), aimag(x(1:n))])
> > end function f
> > 
> > If the array sections are removed in favor of the whole array,
> > the code compiles.
> 
> Even further reduction.
> 
> subroutine f(n, x)
>integer, intent(in) :: n 
>complex, intent(in) :: x(1:n)
>real :: y(2*n)
>y = [real(x(1:n), aimag(x(1:n))]
> end subroutine f
> 
> The constructor with array sections is going south.
> 

A even further reduced testcase.

subroutine f(n, x)
   integer, intent(in) :: n 
   complex, intent(in) :: x(1:n)
   real :: y(2*n)
   ! y = [ real(x)]  ! This works.
y = [ real(x(1:n))]  ! This fails.
end subroutine f

The REAL in the array constructor is confusing the mechanism
for looking for a typespeci, e.g., [ REAL :: x(1:n)]

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

On 10/19/2016 08:20 AM, Andreas Schwab wrote:

On Okt 19 2016, Jerry DeLisle  wrote:


Could you try compiling manually the failing test with gfortran -static
and then run it to see what happens.


That does not change anything.


Also what target is this failing on.


aarch64 and m68k.

Andreas.



Dominique has discovered my flaw, the integers are being used not initialized 
and can happen to be large negative values that need 11 bytes in the format to 
hold the values.


I will commit a change to the test case shortly.

Jerry

[Bug fortran/78043] ICE in force_decl_die, at dwarf2out.c:23533

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78043

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Related to/duplicate of pr50410? With the patch in pr50410 comment 8, I get the
error

Error: NULL() initialization expected in DATA statement for 'a' at (1)

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

OK for the trunk whenever you're ready.

jeff


You are too fast for me :-)
I do not have the build trees for all the configurations ready for
manual testing...
So, I just merged the initial patch and the 2nd one, and started
a validation job to make sure the 2nd patch fixes all the regressions
observed earlier.
It will take a few hours.


There shouldn't be any problems that didn't surface in my cross build, 
since they are not execution tests, but compile tests.


I have committed the patch.  If there any specific failures specific to 
your target, let me know and I'll address those separately.


Thanks.
Aldy

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67685

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Quickly investigating. In tsubst_requires_expr, we add to the local
specialization stack, which means that any local variables or parameters
referenced within the requires-expression will not be visible, which ultimately
causes undefined behavior in tsubst_copy.

Re: [PATCH] Implement P0084R2, Emplace return type, for C++17

[Jonathan Wakely]

On 17/10/16 12:56 +0100, Jonathan Wakely wrote:

In C++17 the emplace_front and emplace_back members return a
reference. There isn't a very neat way to implement this, so it's just
lots of conditional compilation.


This fixes a silly typo. Committed to trunk.



commit 688f5967dd566c56c01c710f2c1b49c56eabe123
Author: Jonathan Wakely 
Date:   Wed Oct 19 19:25:43 2016 +0100

Fix copy error in __gnu_debug::vector

	* include/debug/vector (__gnu_debug::vector::emplace_back): Fix return
	type.

diff --git a/libstdc++-v3/include/debug/vector b/libstdc++-v3/include/debug/vector
index b2d70bd..1b9e4a7 100644
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -479,7 +479,7 @@ namespace __debug
 
   template
 #if __cplusplus > 201402L
-	deque<_Tp, _Alloc>::reference
+	reference
 #else
 	void
 #endif

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915

--- Comment #5 from Bill Schmidt  ---
This is an example of a known limitation in SLSR.  The explanation is in
analyze_increments:

  /* FORNOW: If we need to add an initializer, give up if a cast from   
 the candidate's type to its stride's type can lose precision.  
 This could eventually be handled better by expressly retaining the 
 result of a cast to a wider type in the stride.  Example:  

   short int _1;
   _2 = (int) _1;   
   _3 = _2 * 10;
   _4 = x + _3;ADD: x + (10 * _1) : int 
   _5 = _2 * 15;
   _6 = x + _3;ADD: x + (15 * _1) : int 

 Right now replacing _6 would cause insertion of an initializer 
 of the form "short int T = _1 * 5;" followed by a cast to  
 int, which could overflow incorrectly.  Had we recorded _2 or  
 (int)_1 as the stride, this wouldn't happen.  However, doing   
 this breaks other opportunities, so this will require some 
 care.  */

In this case, we have "int" rather than "short int," and "int *" rather than
"int".  Assuming a 64-bit machine, casting from a 64-bit wrapping type to a
32-bit non-wrapping type isn't legal.

I need to look at the stride-selection logic again.  The various cast-sensitive
bits of this are tricky to get right.

[PATCH] Fix incorrect comment about std::auto_ptr

[Jonathan Wakely]

Pedro pointed out this comment isn't true, see LWG 463 for the reason
why (in short, it needs too many user-defined conversions).

* include/backward/auto_ptr.h (dauto_ptr): Correct comment about
conversions from auto_ptr rvalues to auto_ptr.
* testsuite/20_util/auto_ptr/assign_neg.cc: Remove redundant dg-error
directives that only match notes, not errors.

Tested powerpc64le-linux, committed to trunk.

commit 39d4ba1f2d08632e0f860fa28b3acfe844cd219d
Author: Jonathan Wakely 
Date:   Wed Oct 19 18:48:01 2016 +0100

Fix incorrect comment about std::auto_ptr

* include/backward/auto_ptr.h (dauto_ptr): Correct comment about
conversions from auto_ptr rvalues to auto_ptr.
* testsuite/20_util/auto_ptr/assign_neg.cc: Remove redundant dg-error
directives that only match notes, not errors.

diff --git a/libstdc++-v3/include/backward/auto_ptr.h 
b/libstdc++-v3/include/backward/auto_ptr.h
index bfd42d8..4dfc8cc 100644
--- a/libstdc++-v3/include/backward/auto_ptr.h
+++ b/libstdc++-v3/include/backward/auto_ptr.h
@@ -249,13 +249,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   /** 
*  @brief  Automatic conversions
*
-   *  These operations convert an %auto_ptr into and from an auto_ptr_ref
-   *  automatically as needed.  This allows constructs such as
+   *  These operations are supposed to convert an %auto_ptr into and from
+   *  an auto_ptr_ref automatically as needed.  This would allow
+   *  constructs such as
*  @code
*auto_ptr  func_returning_auto_ptr(.);
*...
*auto_ptr ptr = func_returning_auto_ptr(.);
*  @endcode
+   *
+   *  But it doesn't work, and won't be fixed. For further details see
+   *  http://cplusplus.github.io/LWG/lwg-closed.html#463
*/
   auto_ptr(auto_ptr_ref __ref) throw()
   : _M_ptr(__ref._M_ptr) { }
diff --git a/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc 
b/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
index 5e52ec4..22cc49e 100644
--- a/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc
@@ -47,6 +47,3 @@ main()
   test01();
   return 0;
 }
-// { dg-error "::auto_ptr|no known conversion" "" { target *-*-* } 136 } 
-// { dg-error "note" "" { target *-*-* } 154 }
-// { dg-error "::auto_ptr|no known conversion" "" { target *-*-* } 264 } 

Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result

[Andre Vehreschild]

Hi Paul,

I am not completely through with your patch, but what jumped into my eye was
that you copy ref in resolve_select_type and again in fixup_array_ref, when you
use it? May be I oversee something. You are more into this code. Is the double
copying necessary (line 49 and 82 as well as 95, respectively). IMHO the copy
in line 49 could be sufficient.

I look into it tomorrow more thoroughly. Please wait before submitting a new
version. May be I see something more :-)

So far, thanks for working on this.

Regards,
Andre

On Wed, 19 Oct 2016 09:28:39 +0200
Paul Richard Thomas  wrote:

> Dear Andre,
> 
> Following our exchange yesterday, I have eliminated the modification
> to trans_associate_var and have corrected the offending expressions in
> resolve.c(fixup_array_ref).
> 
> Please find attached the corrected patch.
> 
> Cheers
> 
> Paul
> 
> 2016-10-19  Paul Thomas  
> 
> PR fortran/69566
> * resolve.c (fixup_array_ref): New function.
> (resolve_select_type): Gather up the rank and array reference,
> if any, from the selector. Fix up the 'associate name' and the
> 'associate entities' as necessary.
> * trans-expr.c (gfc_conv_class_to_class): If the symbol backend
> decl is a FUNCTION_DECL, use the 'fake_result_decl' instead.
> 
> 2016-10-19  Paul Thomas  
> 
> PR fortran/69566
> * gfortran.dg/select_type_37.f03: New test.
> 
> On 18 October 2016 at 18:16, Andre Vehreschild  wrote:
> > Hi Paul,
> >  
> >> For reasons I don't understand, sometimes the expression type comes
> >> through as BT_DERIVED, whilst the symbol is BT_CLASS. I could repair
> >> this in resolve.c(fixup_array_ref) if you think that would be cleaner.  
> >
> > I think that I figured the rule:
> >
> > - when no _class-ref is present, then the type is BT_CLASS,
> > - as soon as a _class-ref is present the type is BT_DERIVED.
> >
> > There is an attr.is_class. Would that be an alternative? I don't know how
> > reliable it is set.
> >  
> >> > I am regression testing my polymorhpic class patch at the moment,
> >> > therefore I can't test.  
> >>
> >> OK - I can wait. I have quite a few other things to do :-(  
> >
> > I found an error in my patch that only manifests itself with an optimization
> > level great than 0. Now I am searching, never having done anything there.
> >
> > - Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: glibc test tst-thread_local1.cc fails to compile with latest GCC

[Andrew Pinski]

On Wed, Oct 19, 2016 at 10:45 AM, Ellcey, Steve  wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the 
> glibc testsuite now.  I ran into a couple of
> new warnings that I fixed (locally) and am now looking at 
> nptl/tst-thread_local1.cc which dies with:
>
> tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std’
>std::thread thr{[func] {func (nullptr);}};
>
> Does anyone know what is going on here?  If I compile a small test program:
>
> #include 
> int main(int, char **){
> std::thread tt;
> }
>
> With G++ 5.4 (using -std=c++11) this test program compiles. but with ToT GCC, 
> it dies with:
>
> g++ -std=c++11 thread.cc -lpthread -o x
> thread.cc: In function ‘int main(int, char**)’:
> thread.cc:5:5: error: ‘thread’ is not a member of ‘std’
>  std::thread tt;
>  ^~~
> thread.cc:5:5: note: suggested alternative: ‘fread’
>  std::thread tt;
>  ^~~
>  fread

I Just tested it with revision 241328 of GCC, it works ...

apinski@apinski-ss1:~/src/local4$ ./tools/bin/g++ t88.cc -std=c++11  -mabi=ilp32
apinski@apinski-ss1:~/src/local4$ ./a.out


Thanks,
Andrew

>
>
> Is there some C++ standard change that I am not aware of or some other header 
> file I need to include?
>
> Steve Ellcey

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Wed, 2016-10-19 at 19:22 +0200, Bernd Schmidt wrote:
> On 10/19/2016 07:19 PM, David Malcolm wrote:
> > I already dropped LABEL_NUSES in compact mode in r241120; I think
> > it's
> > possible to regenerate that information.
> > 
> > But how would we go about recreating the JUMP_LABEL data?  As far
> > as I
> > can tell, it can be set up by reorg.c:make_return_insns
> > via comparison against function_return_label and
> > function_simple_return_label, which are set up by find_end_label;
> > the
> > functions in question are non-trivial, and can lead to extra insns
> > being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which
> > has
> > similar state considerations.
> 
> I'd expect every return/simple_return insn to contain the
> corresponding 
> rtx code. mark_jump_label_1 has this, which supports the theory:
> 
>  case RETURN:
>  case SIMPLE_RETURN:
>if (is_target)
>  {
>gcc_assert (JUMP_LABEL (insn) == NULL || JUMP_LABEL (insn)
> == x);
>JUMP_LABEL (insn) = x;
>  }
>return;
> 
> This is called via mark_all_labels from rebuild_jump_labels_1, so it 
> should Just Work - in theory.
> 
> > It seems simpler to serialize this information.
> 
> Simpler, probably, but it would be nice to omit it if it really is 
> redundant.

Thanks, that gave me the pointer I needed.  I think it is indeed
redundant and I'll work on regenerating it in class function_reader.

[Bug fortran/78043] New: ICE in force_decl_die, at dwarf2out.c:23533

[gerhard.steinmetz.fort...@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78043

Bug ID: 78043
   Summary: ICE in force_decl_die, at dwarf2out.c:23533
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With valid code and option -g, ICEs down to at least 4.8 :


$ cat z1.f90
module m
   common /xc/ a
end
module m2
   use m
end
program p
   use m2, only: z => a
   z = 1.0
end


$ gfortran-7-20161016 -c z1.f90
$
$ gfortran-7-20161016 -g -c z1.f90
z1.f90:8:0:

use m2, only: z => a

internal compiler error: in force_decl_die, at dwarf2out.c:23533
0x8bb39f force_decl_die
../../gcc/dwarf2out.c:23533
0x8ce6ef dwarf2out_imported_module_or_decl_1
../../gcc/dwarf2out.c:24071
0x8d5cd4 dwarf2out_imported_module_or_decl
../../gcc/dwarf2out.c:24143
0x75483a gfc_trans_use_stmts
../../gcc/fortran/trans-decl.c:4882
0x7554c8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6431
0x6df570 translate_all_program_units
../../gcc/fortran/parse.c:5940
0x6df570 gfc_parse_file()
../../gcc/fortran/parse.c:6146
0x722652 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:198

glibc test tst-thread_local1.cc fails to compile with latest GCC

[Ellcey, Steve]

I have built the latest glibc sources with a ToT GCC and am trying to run the 
glibc testsuite now.  I ran into a couple of
new warnings that I fixed (locally) and am now looking at 
nptl/tst-thread_local1.cc which dies with:

tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std’
   std::thread thr{[func] {func (nullptr);}};

Does anyone know what is going on here?  If I compile a small test program:

#include 
int main(int, char **){
std::thread tt;
}

With G++ 5.4 (using -std=c++11) this test program compiles. but with ToT GCC, 
it dies with:

g++ -std=c++11 thread.cc -lpthread -o x
thread.cc: In function ‘int main(int, char**)’:
thread.cc:5:5: error: ‘thread’ is not a member of ‘std’
 std::thread tt;
 ^~~
thread.cc:5:5: note: suggested alternative: ‘fread’
 std::thread tt;
 ^~~
 fread


Is there some C++ standard change that I am not aware of or some other header 
file I need to include?

Steve Ellcey

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[wdijkstr at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

--- Comment #4 from Wilco  ---
(In reply to Bernd Edlinger from comment #3)
> (In reply to Wilco from comment #2)
> > (In reply to Bernd Edlinger from comment #1)
> > > some background about this bug can be found here:
> > > 
> > > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
> > 
> > The di3_neon pattern does not constrain the input not to overlap with
> > the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
> > does not handle partial overlaps. However it is feasible to fix that by
> > swapping the order for the various cases.
> 
> from di3_neon:
> 
> if (INTVAL (operands[2]) < 1)
>   {
> emit_insn (gen_movdi (operands[0], operands[1]));
> DONE;
>   }
> 
> Will the movdi pattern work with partial overlaps?
> It does basically this:
> 
>   emit_move_insn (gen_lowpart (SImode, operands[0]),
>   gen_lowpart (SImode, operands[1]));
>   emit_move_insn (gen_highpart (SImode, operands[0]),
>   gen_highpart (SImode, operands[1]));

I think it's OK - that code only triggers if a movdi has a physical register
that is not a valid DI register which is not the case we're dealing with. movdi
has a split that does check for partial overlap around line 5900 in arm.md:

  /* Handle a partial overlap.  */
  if (rtx_equal_p (operands[0], operands[3]))
 ...

However dealing with partial overlaps is complex so maybe the best option would
be to add alternatives to di3_neon to either allow full overlap "r 0 X X
X" or no overlap " r X  X X". The shift code works with full overlap.

Re: [Fortran, Patch, PR{43366, 57117, 61337, 61376}, v1] Assign to polymorphic objects.

[Andre Vehreschild]

Hi all,

attached is an enhanced version of the patch, which now catches all of the
testcases in the comments of pr61337. Thanks for reporting that I missed them,
Dominique.

For a detailed description see below. PR61337 needed just some more pre-code
joining and correct handling of class-typed array constructors.

Bootstraps and regtests ok on x86_64-linux/F23. Ok for trunk?

Regards,
Andre

On Thu, 13 Oct 2016 14:42:00 +0200
Andre Vehreschild  wrote:

> Hi all,
> 
> attached patch fixes the PRs (as to my knowledge):
> 
> PR43366 - [OOP][F08] Intrinsic assign to polymorphic variable
> PR57117 - [OOP] ICE for sourced allocation of a polymorphic entity using
> TRANSPOSE
> PR61337 - Wrong indexing and runtime crash with unlimited polymorphic array.
> PR61378 - Error using private statement in polymorphic derived type
> 
> The latter two are more or less fixed by accident or have been fixed by
> previous patches, but have not been identified as such. Anyway, they are fixed
> now and will be closed once the patch hits trunk.
> 
> As for PR43366: I did not indent to fix this one, but when going for PR57117 I
> once again stumbled over the deficiencies of gfc_trans_assigment's handling of
> class objects. Therefore I figured what would be needed to complete PR43366
> and this is it now. 
> 
> As for PR57117: The issue was that ALLOCATE () used gfc_copy_class_to_class ()
> when a class object was allocated. The function gfc_copy_class_to_class ()
> does not use the scalarizer correctly. I.e., a transpose of the source=
> expression would not be respected. I therefore decided to remove all this
> special casing for class objects in ALLOCATE () and let gfc_trans_assignment
> do the trick. This way ensuring, that any improvements of the scalarizer will
> benefit class objects, too. Unfortunately did this mean to add more logic to
> gfc_trans_assignment. While doing so, I learned that existing wrappers for
> class assignments were obsoleted by the work I did, so I removed them.
> 
> I tried to get rid of the malicious copy_class_to_class, too, but at the
> moment it is still used at one location where components of derived types are
> assigned. I was not bold enough to replace this occurrence with
> trans_assignment yet.
> 
> This patch shall make our lives easier, because now there is one routine to
> assign all sorts of objects and no special casing for class objects is needed
> anymore. I expect that some other parts of gfortran's code base may benefit
> from the changes and have their complexity reduced.
> 
> Bootstrapped and regtested ok on x86_64-linux/F23. Ok for trunk?
> 
> Regards,
>   Andre


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 


pr43366_v2.clog
Description: Binary data
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 85589ee..3803b88 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2359,6 +2359,10 @@ gfc_expr_attr (gfc_expr *e)
 	  attr.allocatable = CLASS_DATA (sym)->attr.allocatable;
 	}
 	}
+  else if (e->value.function.isym
+	   && e->value.function.isym->transformational
+	   && e->ts.type == BT_CLASS)
+	attr = CLASS_DATA (e)->attr;
   else
 	attr = gfc_variable_attr (e, NULL);
 
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 87178a4..3bb057d 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9834,10 +9834,6 @@ resolve_ordinary_assign (gfc_code *code, gfc_namespace *ns)
 		 "requires %<-frealloc-lhs%>", >where);
 	  return false;
 	}
-  /* See PR 43366.  */
-  gfc_error ("Assignment to an allocatable polymorphic variable at %L "
-		 "is not yet supported", >where);
-  return false;
 }
   else if (lhs->ts.type == BT_CLASS)
 {
@@ -10740,6 +10736,19 @@ start:
 	  break;
 
 	gfc_check_pointer_assign (code->expr1, code->expr2);
+
+	/* Assigning a class object always is a regular assign.  */
+	if (code->expr2->ts.type == BT_CLASS
+		&& !CLASS_DATA (code->expr2)->attr.dimension
+		&& !(UNLIMITED_POLY (code->expr2)
+		 && code->expr1->ts.type == BT_DERIVED
+		 && (code->expr1->ts.u.derived->attr.sequence
+			 || code->expr1->ts.u.derived->attr.is_bind_c))
+		&& !(gfc_expr_attr (code->expr1).proc_pointer
+		 && code->expr2->expr_type == EXPR_VARIABLE
+		 && code->expr2->symtree->n.sym->attr.flavor
+			== FL_PROCEDURE))
+	  code->op = EXEC_ASSIGN;
 	break;
 	  }
 
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 37cca79..c59e872 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -2292,7 +2292,8 @@ trans_array_constructor (gfc_ss * ss, locus * where)
 	type = build_pointer_type (type);
 }
   else
-type = gfc_typenode_for_spec (>ts);
+type = gfc_typenode_for_spec (expr->ts.type == BT_CLASS
+  ? _DATA (expr)->ts : >ts);
 
   /* See if the constructor determines the loop bounds.  */
   dynamic = false;
@@ -3036,50 +3037,57 @@ build_class_array_ref 

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

--- Comment #6 from Jeffrey A. Law  ---
So this is a very interesting little issue that highlights a deficiency in the 
semantics of __builtin_constant_p.

So prior to threading we have:

;;   basic block 4, loop depth 0, count 0, freq 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;pred:   2 [50.0%]  (TRUE_VALUE,EXECUTABLE)
;;3 [100.0%]  (FALLTHRU,EXECUTABLE)
  # iftmp.0_2 = PHI 
  b = iftmp.0_2;
  _1 = __builtin_constant_p (iftmp.0_2);
  if (_1 != 0)
goto ;
  else
goto ;
;;succ:   5 [54.0%]  (TRUE_VALUE,EXECUTABLE)
;;7 [46.0%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 5, loop depth 0, count 0, freq 5400, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED)
;;pred:   4 [54.0%]  (TRUE_VALUE,EXECUTABLE)
  if (iftmp.0_2 != 0)
goto ;
  else
goto ;
;;succ:   6 [36.6%]  (TRUE_VALUE,EXECUTABLE)
;;7 [63.4%]  (FALSE_VALUE,EXECUTABLE)

;;   basic block 6, loop depth 0, count 0, freq 1979, maybe hot
;;prev block 5, next block 7, flags: (NEW, REACHABLE, VISITED)
;;pred:   5 [36.6%]  (TRUE_VALUE,EXECUTABLE)
  ilog2_NaN ();

That's all fine and good.  Threading wants to lookup the value of iftmp.0_2 in
an attempt to eliminate the conditional in BB5.  And it finds that the path
3->4->5 will result in iftmp.0_2 having the value 1.  So it isolates that path.

After isolation things look  like this:

;;   basic block 3, loop depth 0
;;pred:   2
  # iftmp.0_8 = PHI <1(2)>
  b = iftmp.0_8;
  _10 = __builtin_constant_p (iftmp.0_8);
  if (_10 != 0)
goto ;
  else
goto ;
;;succ:   6
;;7

;;   basic block 4, loop depth 0
;;pred:   2
  # iftmp.0_2 = PHI 
  b = iftmp.0_2;
  _1 = __builtin_constant_p (iftmp.0_2);
  if (_1 != 0)
goto ;
  else
goto ;
;;succ:   5
;;7

;;   basic block 5, loop depth 0
;;pred:   4
  if (iftmp.0_2 != 0)
goto ;
  else
goto ;
;;succ:   6
;;7

;;   basic block 6, loop depth 0
;;pred:   5
;;3
  ilog2_NaN ();
;;succ:   7


Note how the path leading out of block 3 will never pass through the
conditional in block 5.  That's the primary effect of jump threading.


The most "obvious" interpretation is that "b" is not constant in this case at
the source level and thus __b_c_p must return zero.  But how does one deal with
cases where analysis such as VRP, CPROP, etc prove certain edges are not
executable and thus certain paths to a b_c_p call are eliminated and the
"obvious" non-constant b_c_p argument turns into a constant argument.  This
could happen virtually with any optimization that eliminates an edge in the
CFG.  Proving edge removal does not change the runtime result of a b_c_p call
is almost certainly akin to the halting problem.

Similarly such an interpretation would essentially mean that a block with a
b_c_p call can only be duplicated if we can prove that the original and
duplicate have the same runtime result as the original -- which we might be
able to prove in some cases, but the context necessary to do so is likely not
available in the places where we have to make that determination -- essentially
we'll likely have to disallow duplication of blocks with b_c_p.

I want folks to realize that the "obvious" interpretation may have very
significant secondary effects and may ultimately result in cases where we must
either totally cripple optimizers or declare that the "obvious" semantics
simply can't be supported.

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

--- Comment #3 from Bernd Edlinger  ---
(In reply to Wilco from comment #2)
> (In reply to Bernd Edlinger from comment #1)
> > some background about this bug can be found here:
> > 
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
> 
> The di3_neon pattern does not constrain the input not to overlap with
> the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
> does not handle partial overlaps. However it is feasible to fix that by
> swapping the order for the various cases.

from di3_neon:

if (INTVAL (operands[2]) < 1)
  {
emit_insn (gen_movdi (operands[0], operands[1]));
DONE;
  }

Will the movdi pattern work with partial overlaps?
It does basically this:

  emit_move_insn (gen_lowpart (SImode, operands[0]),
  gen_lowpart (SImode, operands[1]));
  emit_move_insn (gen_highpart (SImode, operands[0]),
  gen_highpart (SImode, operands[1]));

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[Bernd Schmidt]

On 10/19/2016 07:19 PM, David Malcolm wrote:

I already dropped LABEL_NUSES in compact mode in r241120; I think it's
possible to regenerate that information.

But how would we go about recreating the JUMP_LABEL data?  As far as I
can tell, it can be set up by reorg.c:make_return_insns
via comparison against function_return_label and
function_simple_return_label, which are set up by find_end_label; the
functions in question are non-trivial, and can lead to extra insns
being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which has
similar state considerations.


I'd expect every return/simple_return insn to contain the corresponding 
rtx code. mark_jump_label_1 has this, which supports the theory:


case RETURN:
case SIMPLE_RETURN:
  if (is_target)
{
  gcc_assert (JUMP_LABEL (insn) == NULL || JUMP_LABEL (insn) == x);
  JUMP_LABEL (insn) = x;
}
  return;

This is called via mark_all_labels from rebuild_jump_labels_1, so it 
should Just Work - in theory.



It seems simpler to serialize this information.


Simpler, probably, but it would be nice to omit it if it really is 
redundant.



Bernd

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Wed, 2016-10-19 at 16:41 +0200, Bernd Schmidt wrote:
> On 10/19/2016 04:35 PM, David Malcolm wrote:
> 
> > In r241120 I dropped all dumping of the JUMP_LABEL when adding the
> > "compact" mode.
> > 
> > I'm now running into an issue with this as I update the __RTL in
> > cc1
> > tests to use the new format, since various passes require the
> > JUMP_INSNs to have JUMP_LABEL data.
> 
> Isn't it possible to recreate these? In jump.c we have 
> rebuild_jump_labels, which looks like it'll also compute LABEL_NUSES 
> which I think we were considering dropping in the output.

I already dropped LABEL_NUSES in compact mode in r241120; I think it's
possible to regenerate that information.

But how would we go about recreating the JUMP_LABEL data?  As far as I
can tell, it can be set up by reorg.c:make_return_insns
via comparison against function_return_label and
function_simple_return_label, which are set up by find_end_label; the
functions in question are non-trivial, and can lead to extra insns
being emitted.  Also, in shrink-wrap.c:handle_simple_exit, which has
similar state considerations.

It seems simpler to serialize this information.

Or am I missing something?

Thanks
Dave

Re: [BUILDROBOT] ICE in altivec_init_builtins, at config/rs6000/rs6000.c:17547

[David Edelsohn]

Hi, JBG

Yes, this is a known problem with Kelvin's recent patch.

- David


On Wed, Oct 19, 2016 at 12:59 PM, Jan-Benedict Glaw  wrote:
> Hi!
>
> Building current GCC with current GCC (using config_list.mk) for
> --target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during 
> -fself-test,
> see build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643401 :
>
> [...]
> /scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/xgcc
>  
> -B/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/
>  -nostdinc -x c /dev/null -S -fself-test
> : internal compiler error: in altivec_init_builtins, at 
> config/rs6000/rs6000.c:17547
> 0xe4357a altivec_init_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:17547
> 0xe4357a rs6000_init_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:16823
> 0x640a20 c_define_builtins
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4027
> 0x640a20 c_common_nodes_and_builtins()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4495
> 0x593679 c_init_decl_processing()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-decl.c:4097
> 0x5e17e8 c_objc_common_init()
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-objc-common.c:58
> 0x58306f lang_dependent_init
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1775
> 0x58306f do_compile
> /scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1998
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[2]: *** [s-selftest] Error 1
>
>
> MfG, JBG
>
> --
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:   ...und wenn Du denkst, es geht nicht mehr,
> the second  :  kommt irgendwo ein Lichtlein her.

[BUILDROBOT] ICE in altivec_init_builtins, at config/rs6000/rs6000.c:17547

[Jan-Benedict Glaw]

Hi!

Building current GCC with current GCC (using config_list.mk) for
--target=rs6000-ibm-aix5.3.0, I noticed a gcc_unreachable() during -fself-test,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643401 :

[...]
/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/xgcc
 
-B/scratch/4/jbglaw/configlist/build/rs6000-ibm-aix5.3.0/build-gcc/mk/rs6000-ibm-aix5.3.0/./gcc/
 -nostdinc -x c /dev/null -S -fself-test
: internal compiler error: in altivec_init_builtins, at 
config/rs6000/rs6000.c:17547
0xe4357a altivec_init_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:17547
0xe4357a rs6000_init_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/config/rs6000/rs6000.c:16823
0x640a20 c_define_builtins
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4027
0x640a20 c_common_nodes_and_builtins()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c-family/c-common.c:4495
0x593679 c_init_decl_processing()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-decl.c:4097
0x5e17e8 c_objc_common_init()
/scratch/4/jbglaw/configlist/repos/gcc/gcc/c/c-objc-common.c:58
0x58306f lang_dependent_init
/scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1775
0x58306f do_compile
/scratch/4/jbglaw/configlist/repos/gcc/gcc/toplev.c:1998
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [s-selftest] Error 1


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   ...und wenn Du denkst, es geht nicht mehr,
the second  :  kommt irgendwo ein Lichtlein her.


signature.asc
Description: Digital signature

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915

--- Comment #4 from Bill Schmidt  ---
Something is causing us to hate the second case now, assigning "infinite" cost
to it:

Processing dependency tree rooted at 5.
Using existing initializer: _3 = -_2;

Increment vector:

  0  increment:   -8
 count:   1
 cost:-24
 initializer: _3

  1  increment:   -16
 count:   1
 cost:1000
 initializer:

Re: libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
 wrote:
> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
>> This patch to libgo copies the rdebug code from the Go 1.7 runtime to libgo.
>>
>> While we're at it, this updates the runtime/debug package, and starts
>> running its testsuite by default.  I'm not sure why runtime/debug was
>> not previously updated to 1.7.  Doing that led me to fix some minor
>> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> Not sure which of the merges broke it but I get
>
> ...
> rc/svn/trunk2/libgo/go/runtime/time.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
> error:integer constant overflow
>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>  ^
> make[4]: *** [runtime-go.lo] Error 1
>
> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
> SP4 which uses glibc 2.11.3.
>
> There is a missing space after 'error:' as well.

I don't see that missing space after "error:" either.  The code in
question winds up calling the GCC function error_at with "integer
constant overflow".  The Go frontend does not print the string
"error:" at all.

Ian

[Bug c/61939] warn when __attribute__((aligned(x))) is ignored

[rivanvx at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61939

Vedran Miletic  changed:

   What|Removed |Added

 CC||rivanvx at gmail dot com

--- Comment #1 from Vedran Miletic  ---
Confirmed still occurs in 6.2.1 on the following C++ code:

#include 
#include 
float f(std::vector& A, std::vector& B)
{
  __builtin_assume_aligned(A.data(), 64);
  __builtin_assume_aligned(B.data(), 64);
  return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
}

Compiled using -O3 -ffast-math -mavx2.

Re: [gofrontend-dev] Re: libgo patch committed: copy rdebug code from Go 1.7

[Ian Lance Taylor]

On Wed, Oct 19, 2016 at 6:23 AM, Richard Biener
 wrote:
> On Wed, Oct 19, 2016 at 3:17 PM, Ian Lance Taylor  wrote:
>> On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
>>  wrote:
>>> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor  wrote:
 This patch to libgo copies the rdebug code from the Go 1.7 runtime to 
 libgo.

 While we're at it, this updates the runtime/debug package, and starts
 running its testsuite by default.  I'm not sure why runtime/debug was
 not previously updated to 1.7.  Doing that led me to fix some minor
 aspects of runtime.Stack and the C function runtime/debug.readGCStats.

 Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
 to mainline.
>>>
>>> Not sure which of the merges broke it but I get
>>>
>>> ...
>>> rc/svn/trunk2/libgo/go/runtime/time.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
>>> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
>>> error:integer constant overflow
>>>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>>>  ^
>>> make[4]: *** [runtime-go.lo] Error 1
>>>
>>> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
>>> SP4 which uses glibc 2.11.3.
>>
>> Is this the 32-bit or 64-bit build?
>
> Hum, don't remember ...
>
>> What is the output of
>>
>> find x86_64-pc-linux-gnu -name runtime_sysinfo.go | xargs grep EPOLLET
>>
>> in your build directory?
>
> x86_64-pc-linux-gnu/32/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
> x86_64-pc-linux-gnu/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
>
> looks like the culprit.  All other _EPOLL* constants are positive

I have not been able to recreate the problem.  Perhaps the definition
of EPOLLET in your  file is different; on my system the
definition is

EPOLLET = 1u << 31

In any case, I have committed this patch which I believe will fix the
problem.  Bootstrapped and tested on x86_64-pc-linux-gnu on a system
that does not show the problem anyhow.

Ian

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[wdijkstr at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #2 from Wilco  ---
(In reply to Bernd Edlinger from comment #1)
> some background about this bug can be found here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html

The di3_neon pattern does not constrain the input not to overlap with
the output for immediate shifts, and the arm_emit_coreregs_64bit_shift code
does not handle partial overlaps. However it is feasible to fix that by
swapping the order for the various cases.

[Bug tree-optimization/71915] A missed opportunity for SLSR

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71915

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-19
 Ever confirmed|0   |1

--- Comment #3 from Bill Schmidt  ---
Confirmed.

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Kyrill Tkachov]

On 19/10/16 17:06, Bernd Edlinger wrote:

On 10/19/16 12:44, Christophe Lyon wrote:

On 19 October 2016 at 10:34, Kyrill Tkachov  wrote:

On 19/10/16 07:55, Christophe Lyon wrote:

On 18 October 2016 at 17:35, Christophe Lyon 
wrote:

On 18 October 2016 at 16:45, Bernd Edlinger 
wrote:

On 10/18/16 10:36, Christophe Lyon wrote:

I am seeing a lot of regressions since this patch was committed:

http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html

(you can click on "REGRESSED" to see the list of regressions, "sum"
and "log" to download
the corresponding .sum/.log)

Thanks,

Christophe


Oh, sorry, I have completely missed that.
Unfortunately I have tested one of the good combinations.

I have not considered the case that in and out could be
the same register.  But that happens here.


This should solve it.

Can you give it a try?


Sure, I have started the validations, it will take a few hours.


It looks OK, thanks.


Ok. Thanks for testing Christophe.
Sorry for not catching it in review.
Kyrill


Since it was painful to check that this 2nd patch fixed all the regressions
observed in all the configurations, I ran another validation with
the 2 patches combined, on top of r241272 to check the effect of the two
over the previous reference.

It turns out there is still a failure:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/241272-r241273-combined/report-build-info.html
gcc.c-torture/execute/pr34971.c   -O0  execution test
now fails on arm-none-linux-gnueabihf when using thumb mode, expect
when targeting cortex-a5.


Thanks Christophe, I looked in the test case,
and I think that is a pre-existing issue.

I can make the test case fail before my patch:

struct foo
{
unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
/* Build a rotate expression on a 40 bit argument.  */
if ((x.b<<9) + (x.b>>31) != res)
  abort ();
}

int main()
{
x.b = 0x010001;
test1(0x000202);
x.b = 0x01;
test1(0x02);
return 0;
}


fails with -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0
even before my patch.

before reload we have this insn:
(insn 19 18 20 2 (parallel [
  (set (reg:DI 113 [ _4 ])
  (lshiftrt:DI (reg:DI 112 [ _3 ])
  (const_int 31 [0x1f])))
  (clobber (scratch:SI))
  (clobber (scratch:SI))
  (clobber (scratch:DI))
  (clobber (reg:CC 100 cc))
  ]) "pr34971.c":11 1232 {lshrdi3_neon}


which is replaced to this insn:
(insn 19 18 20 2 (parallel [
  (set (reg:DI 1 r1 [orig:113 _4 ] [113])
  (lshiftrt:DI (reg:DI 0 r0 [orig:112 _3 ] [112])
  (const_int 31 [0x1f])))
  (clobber (scratch:SI))
  (clobber (scratch:SI))
  (clobber (scratch:DI))
  (clobber (reg:CC 100 cc))
  ]) "pr34971.c":11 1232 {lshrdi3_neon}
   (nil))

And now that is not supposed to happen, when this code
is executed for shifts by a constant less than 32:

emit_insn (SET (out_down, LSHIFT (code, in_down, amount)));
emit_insn (SET (out_down,
ORR (REV_LSHIFT (code, in_up, reverse_amount),
 out_down)));
emit_insn (SET (out_up, SHIFT (code, in_up, amount)));


out_down may not be the same hard register than in_up for this to work.

I opened a new BZ for this:
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

I am not sure if this is a LRA issue or if it can be handled in the
shift expansion.

Is the second patch good for trunk as it is?


Thanks for the investigation and the bug report.
The patch is ok.
Kyrill



Thanks
Bernd.

Re: [BUILDROBOT] s390.md:10630:9: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jeff Law]

On 10/19/2016 10:26 AM, Jan-Benedict Glaw wrote:

Hi!

I noticed that building for --target=s390-linux-gnu (via
config_list.mk) also hits the new fall-through checking code,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643406:

[...]
g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace   
-o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo 
insn-output.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md: In function 
‘const char* output_1786(rtx_def**, rtx_insn*)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10630:9: error: 
this statement may fall through [-Werror=implicit-fallthrough=]
 if (larl_operand (operands[0], Pmode))
 ^~
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10632:7: note: here
   default:
   ^~~
cc1plus: all warnings being treated as errors
Makefile:1097: recipe for target 'insn-output.o' failed
From reading the comments in that pattern, I think falling-through is 
safe and expected.  So just adding an appropriate fallthru comment 
should fix this.


jeff

[BUILDROBOT] s390.md:10630:9: error: this statement may fall through [-Werror=implicit-fallthrough=]

[Jan-Benedict Glaw]

Hi!

I noticed that building for --target=s390-linux-gnu (via
config_list.mk) also hits the new fall-through checking code,
see build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=643406:

[...]
g++ -fno-PIE -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos-configlist_mk/gcc/gcc 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/. 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../include 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I/home/jbglaw/repos-configlist_mk/gcc/gcc/../libbacktrace   
-o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo 
insn-output.c
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md: In function 
‘const char* output_1786(rtx_def**, rtx_insn*)’:
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10630:9: error: 
this statement may fall through [-Werror=implicit-fallthrough=]
 if (larl_operand (operands[0], Pmode))
 ^~
/home/jbglaw/repos-configlist_mk/gcc/gcc/config/s390/s390.md:10632:7: note: here
   default:
   ^~~
cc1plus: all warnings being treated as errors
Makefile:1097: recipe for target 'insn-output.o' failed


MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :   für unverkäufliche Produkte, oder? (#korsett, 20120821)


signature.asc
Description: Digital signature

Re: [tree-optimization/71947] Avoid unwanted propagations

[Jeff Law]

On 10/12/2016 09:00 AM, Georg-Johann Lay wrote:

On 10.10.2016 23:06, Jeff Law wrote:



So if we have an equality conditional between A & B, we record into our
const/copy tables A = B and B = A.

This helps us discover some of the more obscure equivalences. But it also
creates problems with an expression like

A ^ B

Where we might cprop the first operand generating

B ^ B

Then the second generating

B ^ A

ANd we've lost the folding opportunity.  At first I'd tried folding
after each
propagation step, but that turns into a bit of a nightmare because of
changes
in the underlying structure of the gimple statement and cycles that
may develop
if we re-build the operand cache after folding.

This approach is simpler and should catch all these cases for binary
operators.  We just track the last copy propagated argument and refuse to
ping-pong propagations.

It fixes the tests from 71947 and 77647 without regressing
(obviously). I've
included an xfailed test for a more complex situation that we don't
currently
handle (would require backtracking from the equality comparison
through the
logicals that feed the equality comparison).

Bootstrapped and regression tested on x86_64.  Applied to the trunk.

commit 6223e6e425b6de916f0330b9dbe5698765d4a73c
Author: law 
Date:   Mon Oct 10 20:40:59 2016 +

PR tree-optimization/71947
* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B,
then
B with A within a single statement.

PR tree-optimization/71947
* gcc.dg/tree-ssa/pr71947-1.c: New test.
* gcc.dg/tree-ssa/pr71947-2.c: New test.
* gcc.dg/tree-ssa/pr71947-3.c: New test.
* gcc.dg/tree-ssa/pr71947-4.c: New test.
* gcc.dg/tree-ssa/pr71947-5.c: New test.
* gcc.dg/tree-ssa/pr71947-6.c: New test.

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

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 1738bc7..16e25bf 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2016-10-10  Jeff Law  
+
+PR tree-optimization/71947
+* tree-ssa-dom.c (cprop_into_stmt): Avoid replacing A with B, then
+B with A within a single statement.
+
 2016-10-10  Bill Schmidt  

 PR tree-optimization/77824
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 04966cf..e31bcc6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,13 @@
+2016-10-10  Jeff Law  
+
+PR tree-optimization/71947
+* gcc.dg/tree-ssa/pr71947-1.c: New test.
+* gcc.dg/tree-ssa/pr71947-2.c: New test.
+* gcc.dg/tree-ssa/pr71947-3.c: New test.
+* gcc.dg/tree-ssa/pr71947-4.c: New test.
+* gcc.dg/tree-ssa/pr71947-5.c: New test.
+* gcc.dg/tree-ssa/pr71947-6.c: New test.
+
 2016-10-10  Thomas Koenig  

 PR fortran/77915
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
new file mode 100644
index 000..b033495
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+   int ret;
+
+   if (x == y)
+ ret = x ^ y;
+   else
+ ret = 1;
+
+   return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
+
+
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
new file mode 100644
index 000..de8f88b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-2.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+int f(int x, int y)
+{
+  int ret;
+  if (x == y)
+ret = x - y;
+  else
+ret = 1;
+
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
new file mode 100644
index 000..e79847f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-3.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+int f(int x, int y)
+{
+  int ret = 10;
+  if (x == y)
+ret = x  -  y;
+  return ret;
+}
+
+/* { dg-final { scan-tree-dump "Folded to: ret_\[0-9\]+ = 0;"  "dom2"
} } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
new file mode 100644
index 000..a881f0d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71947-4.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-vrp -fdump-tree-dom-details" } */
+
+
+
+static inline long load(long *p)
+{
+long ret;
+asm ("movq  %1,%0\n\t" : "=r" (ret) : "m" (*p));



Hi, shouldn't this test be restricted to target machines that understand
MOVQ?

Same 

Re: [tree-optimization/71947] Avoid unwanted propagations

[Jeff Law]

On 10/12/2016 08:36 AM, Christophe Lyon wrote:


It fixes the tests from 71947 and 77647 without regressing (obviously). I've
included an xfailed test for a more complex situation that we don't
currently handle (would require backtracking from the equality comparison
through the logicals that feed the equality comparison).


FWIW, this test is XPASS on arm-none-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:

Most likely branch-costing is the culprit.  Let me see what I can do...

jeff

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Christophe Lyon]

On 19 October 2016 at 17:55, Jeff Law  wrote:
> On 10/19/2016 09:32 AM, Aldy Hernandez wrote:
>>
>> On 10/19/2016 09:16 AM, Eric Botcazou wrote:

 m68k-suse-linux
>>>
>>>
>>> visium-elf too.
>>>
>>
>> The attached patch fixes the failures on m68k-suse-linux, visium-elf,
>> and arm-eabi.
>>
>> There were a few problems.
>>
>> One problem is that on lp64 targets (where sizeof(size_t) !=
>> sizeof(int)), the warning is slightly different-- and rightly so.  I
>> have updated the test to handle both warnings on the respective targets.
>>
>> The other problem is that the following snippet is incorrectly warning
>> on 32-bit targets:
>>
>>   if (n > 0 && n < 2000)
>> p = __builtin_alloca (n);
>>
>> Looking at the gimple it seems like another case of VRP failing to give
>> any range information whatsoever.  I have xfailed it as another case
>> where Andrew's upcoming work should theoretically fix this.  The test is
>> fine on 64-bit targets.
>>
>> Can y'all double check it on your respective targets as I only have a
>> crude cross build?
>
> OK for the trunk whenever you're ready.
>
> jeff

You are too fast for me :-)
I do not have the build trees for all the configurations ready for
manual testing...
So, I just merged the initial patch and the 2nd one, and started
a validation job to make sure the 2nd patch fixes all the regressions
observed earlier.
It will take a few hours.

Christophe

Re: [PATCH] Extend -Wint-in-bool-context to suspicious enum values (PR 77700)

[Markus Trippelsdorf]

On 2016.10.07 at 15:18 +, Bernd Edlinger wrote:
> Hi!
>
> This extends -Wint-in-bool-context to uses of enum values in boolean
> context, and fixes one place where accidentally an enum value was
> passed to a bool parameter.
>
> I excluded enum values 0 and 1 because that is used in
> gimple-ssa-strength-reduction.c, where we have enums
> which are passed in bool function arguments:
>
> enum stride_status
> {
>UNKNOWN_STRIDE = 0,
>KNOWN_STRIDE = 1
> };
>
> enum phi_adjust_status
> {
>NOT_PHI_ADJUST = 0,
>PHI_ADJUST = 1
> };
>
> enum count_phis_status
> {
>DONT_COUNT_PHIS = 0,
>COUNT_PHIS = 1
> };
>
> I would'nt use an enum in that way, but I think it is
> at least not completely wrong to do it like that...
>
>
> Unfortunately C is less strict with enum values, and from
> and enum we only see an integer value without an enum type
> in C.
>
> Therefore this warning does not work in C, only in C++.
> Also integer constants do not have a source location, so
> the displayed location is usually a bit vague.
> But I think it is still better than no warning at all.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

I came across an borderline example in Chromium today:

 62 enum FlushBehavior {
 63   // More bytes are coming, don't flush the codec.
 64   DoNotFlush = 0,
 65
 66   // A fetch has hit EOF. Some codecs handle fetches differently, for compat
 67   // reasons.
 68   FetchEOF,
 69
 70   // Do a full flush of the codec.
 71   DataEOF
 72 };
 73
 74 static_assert(!DoNotFlush, "DoNotFlush should be falsy");
 75 static_assert(FetchEOF, "FetchEOF should be truthy");
 76 static_assert(DataEOF, "DataEOF should be truthy");

../../third_party/WebKit/Source/wtf/text/TextCodec.h:76:51: warning: enum 
constant in boolean context [-Wint-in-bool-context]
 static_assert(DataEOF, "DataEOF should be truthy");
   ^

--
Markus

[Bug rtl-optimization/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

--- Comment #1 from Bernd Edlinger  ---
some background about this bug can be found here:

https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html

[Bug c++/78042] New: g++ does not select the corresponding overloads of abs() for long and long long

[dominik.muth at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78042

Bug ID: 78042
   Summary: g++ does not select the corresponding overloads of
abs() for long and long long
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominik.muth at gmx dot de
  Target Milestone: ---

// begin example file abs.cxx

#include 
#include 
#include 

int main() {
int myint = INT_MAX;
long mylong = LONG_MAX;
long long myllong = LLONG_MAX;
printf("%lu\n", sizeof(myint));
printf("%lu\n", sizeof(mylong));
printf("%lu\n", sizeof(myllong));
printf("%d\n", myint);
printf("%ld\n", mylong);
printf("%lld\n", myllong);
printf("%d\n", -abs(myint));
printf("%ld\n", -abs(mylong));
printf("%lld\n", -abs(myllong));
printf("%d\n", -abs(myint));
printf("%ld\n", -labs(mylong));
printf("%lld\n", -llabs(myllong));
}

// end example file abs.cxx

$ g++6 -Wall -Wextra -Wconversion -std=c++11 -o abs abs.cxx
abs.cxx: In function 'int main()':
abs.cxx:16:29: warning: conversion to 'int' from 'long int' may alter its value
[-Wconversion]
  printf("%ld\n", -abs(mylong));
 ^
abs.cxx:16:30: warning: format '%ld' expects argument of type 'long int', but
argument 2 has type 'int' [-Wformat=]
  printf("%ld\n", -abs(mylong));
  ^
abs.cxx:17:31: warning: conversion to 'int' from 'long long int' may alter its
value [-Wconversion]
  printf("%lld\n", -abs(myllong));
   ^
abs.cxx:17:32: warning: format '%lld' expects argument of type 'long long int',
but argument 2 has type 'int' [-Wformat=]
  printf("%lld\n", -abs(myllong));
^
$ ./abs
4
8
8
2147483647
9223372036854775807
9223372036854775807
-2147483647
4294967295
4294967295
-2147483647
-9223372036854775807
-9223372036854775807

Obviously int abs(int) is called here all the time. However I expect the
corresponding overloads to be selected according to
http://en.cppreference.com/w/cpp/numeric/math/abs.

$ g++6 -v
Using built-in specs.
COLLECT_GCC=g++6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc6/gcc/x86_64-portbld-freebsd11.0/6.2.0/lto-wrapper
Target: x86_64-portbld-freebsd11.0
Configured with: /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.2.0/configure
--with-build-config=bootstrap-debug --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc6
--libexecdir=/usr/local/libexec/gcc6 --program-suffix=6
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc6/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar
--enable-languages=c,c++,objc,fortran,java --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc6
--build=x86_64-portbld-freebsd11.0
Thread model: posix
gcc version 6.2.0 (FreeBSD Ports Collection) 

Note 1: The FreeBSD 11.0 system compiler behaves as expected:

$ clang++ -Wall -Wextra -Wconversion -std=c++11 -o abs abs.cxx
$ ./abs
4
8
8
2147483647
9223372036854775807
9223372036854775807
-2147483647
-9223372036854775807
-9223372036854775807
-2147483647
-9223372036854775807
-9223372036854775807

Note 2: arm-linux-gnueabihf-g++ version 4.8.4 (Ubuntu/Linaro
4.8.4-2ubuntu1~14.04.3) also FAILS to select the long long abs(long long)
overload.

Note 3: armv7l-unknown-linux-gnueabihf-g++ version 6.2.1 20160830 (GCC) also
FAILS to select the long long abs(long long) overload.

Note 4: aarch64--linux-android clang++ version 3.9.0 (tags/RELEASE_390/final)
also FAILS to select the long abs(long) and long long abs(long long) overloads.

Re: [PATCH] Reduce stack usage in sha512 (PR target/77308)

[Bernd Edlinger]

On 10/19/16 12:44, Christophe Lyon wrote:
> On 19 October 2016 at 10:34, Kyrill Tkachov  
> wrote:
>>
>> On 19/10/16 07:55, Christophe Lyon wrote:
>>>
>>> On 18 October 2016 at 17:35, Christophe Lyon 
>>> wrote:

 On 18 October 2016 at 16:45, Bernd Edlinger 
 wrote:
>
> On 10/18/16 10:36, Christophe Lyon wrote:
>>
>> I am seeing a lot of regressions since this patch was committed:
>>
>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/241273/report-build-info.html
>>
>> (you can click on "REGRESSED" to see the list of regressions, "sum"
>> and "log" to download
>> the corresponding .sum/.log)
>>
>> Thanks,
>>
>> Christophe
>>
> Oh, sorry, I have completely missed that.
> Unfortunately I have tested one of the good combinations.
>
> I have not considered the case that in and out could be
> the same register.  But that happens here.
>
>
> This should solve it.
>
> Can you give it a try?
>
 Sure, I have started the validations, it will take a few hours.

>>> It looks OK, thanks.
>>
>>
>> Ok. Thanks for testing Christophe.
>> Sorry for not catching it in review.
>> Kyrill
>>
>
> Since it was painful to check that this 2nd patch fixed all the regressions
> observed in all the configurations, I ran another validation with
> the 2 patches combined, on top of r241272 to check the effect of the two
> over the previous reference.
>
> It turns out there is still a failure:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/241272-r241273-combined/report-build-info.html
> gcc.c-torture/execute/pr34971.c   -O0  execution test
> now fails on arm-none-linux-gnueabihf when using thumb mode, expect
> when targeting cortex-a5.
>

Thanks Christophe, I looked in the test case,
and I think that is a pre-existing issue.

I can make the test case fail before my patch:

struct foo
{
   unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
   /* Build a rotate expression on a 40 bit argument.  */
   if ((x.b<<9) + (x.b>>31) != res)
 abort ();
}

int main()
{
   x.b = 0x010001;
   test1(0x000202);
   x.b = 0x01;
   test1(0x02);
   return 0;
}


fails with -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0
even before my patch.

before reload we have this insn:
(insn 19 18 20 2 (parallel [
 (set (reg:DI 113 [ _4 ])
 (lshiftrt:DI (reg:DI 112 [ _3 ])
 (const_int 31 [0x1f])))
 (clobber (scratch:SI))
 (clobber (scratch:SI))
 (clobber (scratch:DI))
 (clobber (reg:CC 100 cc))
 ]) "pr34971.c":11 1232 {lshrdi3_neon}


which is replaced to this insn:
(insn 19 18 20 2 (parallel [
 (set (reg:DI 1 r1 [orig:113 _4 ] [113])
 (lshiftrt:DI (reg:DI 0 r0 [orig:112 _3 ] [112])
 (const_int 31 [0x1f])))
 (clobber (scratch:SI))
 (clobber (scratch:SI))
 (clobber (scratch:DI))
 (clobber (reg:CC 100 cc))
 ]) "pr34971.c":11 1232 {lshrdi3_neon}
  (nil))

And now that is not supposed to happen, when this code
is executed for shifts by a constant less than 32:

   emit_insn (SET (out_down, LSHIFT (code, in_down, amount)));
   emit_insn (SET (out_down,
   ORR (REV_LSHIFT (code, in_up, reverse_amount),
out_down)));
   emit_insn (SET (out_up, SHIFT (code, in_up, amount)));


out_down may not be the same hard register than in_up for this to work.

I opened a new BZ for this:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

I am not sure if this is a LRA issue or if it can be handled in the
shift expansion.

Is the second patch good for trunk as it is?


Thanks
Bernd.

[Bug rtl-optimization/78041] New: Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041

Bug ID: 78041
   Summary: Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

This is a slightly modified test case:
gcc.c-torture/execute/pr34971.c

struct foo
{
  unsigned long long b:40;
} x;

extern void abort (void);

void test1(unsigned long long res)
{
  /* Build a rotate expression on a 40 bit argument.  */
  if ((x.b<<9) + (x.b>>31) != res)
abort ();
}

int main()
{
  x.b = 0x010001;
  test1(0x000202);
  x.b = 0x01;
  test1(0x02);
  return 0;
}


when compiled with these options it fails:

gcc -mcpu=cortex-a9 -mthumb -mfpu=neon-fp16 -O0

[Bug rtl-optimization/78029] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029

--- Comment #3 from Segher Boessenkool  ---
Kyrill: Anything inconsistent in the CFI will trigger the assert there,
it is most probably not the same bug.

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Jeff Law]

On 10/19/2016 09:32 AM, Aldy Hernandez wrote:

On 10/19/2016 09:16 AM, Eric Botcazou wrote:

m68k-suse-linux


visium-elf too.



The attached patch fixes the failures on m68k-suse-linux, visium-elf,
and arm-eabi.

There were a few problems.

One problem is that on lp64 targets (where sizeof(size_t) !=
sizeof(int)), the warning is slightly different-- and rightly so.  I
have updated the test to handle both warnings on the respective targets.

The other problem is that the following snippet is incorrectly warning
on 32-bit targets:

  if (n > 0 && n < 2000)
p = __builtin_alloca (n);

Looking at the gimple it seems like another case of VRP failing to give
any range information whatsoever.  I have xfailed it as another case
where Andrew's upcoming work should theoretically fix this.  The test is
fine on 64-bit targets.

Can y'all double check it on your respective targets as I only have a
crude cross build?

OK for the trunk whenever you're ready.

jeff

[Bug target/56676] unnecesary splitted load when using avx2

[rivanvx at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56676

Vedran Miletic  changed:

   What|Removed |Added

 CC||rivanvx at gmail dot com

--- Comment #5 from Vedran Miletic  ---
Confirmed still affecting GCC 6.2.1. Similar C++ example:

#include 
#include 
float f(std::vector& A, std::vector& B)
{
  return std::inner_product(A.begin(), A.end(), B.begin(), 0.f);
}

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

--- Comment #5 from Andrew Pinski  ---
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/461597.html

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Jeffrey A. Law from comment #3)
> If someone has a .i file for this issue, it'd be awful handy.

Well, see comment0:

markus@x4 linux % cat timekeeping.i
int a, b;
extern int ilog2_NaN(void);
void by(void) {
  int c = 1;
  b = a ?: c;
  __builtin_constant_p(b) ? b ? ilog2_NaN() : 0 : 0;
}

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> This fixes both tests on m68k.

Likewise on Visium.

-- 
Eric Botcazou

[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
If someone has a .i file for this issue, it'd be awful handy.

[Bug c++/61491] An explicit specialization of a member enumeration of a class template is rejected

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61491

--- Comment #4 from Paolo Carlini  ---
Resolving this requires some additional work beyond what I did back in 2015.
See:

  https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00781.html

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Andreas Schwab]

On Okt 19 2016, Aldy Hernandez  wrote:

> commit 32b629dcab7b78e8181146338c4b077f1d55a0bf
> Author: Aldy Hernandez 
> Date:   Wed Oct 19 11:24:44 2016 -0400
>
>   * gcc.dg/Walloca-1.c: Adjust test for !lp64 targets.
>   * gcc.dg/Walloca-2.c: Same.

This fixes both tests on m68k.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Eric Botcazou]

> I have committed the attached patch as mostly obvious :).

Thanks!

-- 
Eric Botcazou

Re: PING: new pass to warn on questionable uses of alloca() and VLAs

[Aldy Hernandez]

On 10/19/2016 09:16 AM, Eric Botcazou wrote:

m68k-suse-linux


visium-elf too.



The attached patch fixes the failures on m68k-suse-linux, visium-elf, 
and arm-eabi.


There were a few problems.

One problem is that on lp64 targets (where sizeof(size_t) != 
sizeof(int)), the warning is slightly different-- and rightly so.  I 
have updated the test to handle both warnings on the respective targets.


The other problem is that the following snippet is incorrectly warning 
on 32-bit targets:


  if (n > 0 && n < 2000)
p = __builtin_alloca (n);

Looking at the gimple it seems like another case of VRP failing to give 
any range information whatsoever.  I have xfailed it as another case 
where Andrew's upcoming work should theoretically fix this.  The test is 
fine on 64-bit targets.


Can y'all double check it on your respective targets as I only have a 
crude cross build?


Thanks.
Aldy
commit 32b629dcab7b78e8181146338c4b077f1d55a0bf
Author: Aldy Hernandez 
Date:   Wed Oct 19 11:24:44 2016 -0400

* gcc.dg/Walloca-1.c: Adjust test for !lp64 targets.
* gcc.dg/Walloca-2.c: Same.

diff --git a/gcc/testsuite/gcc.dg/Walloca-1.c b/gcc/testsuite/gcc.dg/Walloca-1.c
index 34a20c3..32e4ab8 100644
--- a/gcc/testsuite/gcc.dg/Walloca-1.c
+++ b/gcc/testsuite/gcc.dg/Walloca-1.c
@@ -23,7 +23,8 @@ void foo1 (size_t len, size_t len2, size_t len3)
   char *s = alloca (123);
   useit (s);   // OK, constant argument to alloca
 
-  s = alloca (num);// { dg-warning "large due to conversion" }
+  s = alloca (num);// { dg-warning "large due to conversion" "" { 
target lp64 } }
+  // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 26 }
   useit (s);
 
   s = alloca(9);   /* { dg-warning "is too large" } */
diff --git a/gcc/testsuite/gcc.dg/Walloca-2.c b/gcc/testsuite/gcc.dg/Walloca-2.c
index 284b34e..4695fda 100644
--- a/gcc/testsuite/gcc.dg/Walloca-2.c
+++ b/gcc/testsuite/gcc.dg/Walloca-2.c
@@ -8,7 +8,11 @@ g1 (int n)
 {
   void *p;
   if (n > 0 && n < 2000)
-p = __builtin_alloca (n);
+// FIXME: This is a bogus warning, and is currently happening on
+// 32-bit targets because VRP is not giving us any range info for
+// the argument to __builtin_alloca.  This should be fixed by the
+// upcoming range work.
+p = __builtin_alloca (n); // { dg-bogus "unbounded use of 'alloca'" "" { 
xfail { ! lp64 } } }
   else
 p = __builtin_malloc (n);
   f (p);
@@ -31,8 +35,9 @@ g3 (int n)
   void *p;
   if (n > 0 && n < 3000)
 {
-  p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" }
-  // { dg-message "note:.*argument may be as large as 2999" "note" { 
target *-*-* } 34 }
+  p = __builtin_alloca (n); // { dg-warning "'alloca' may be too large" "" 
{ target lp64} }
+  // { dg-message "note:.*argument may be as large as 2999" "note" { 
target lp64 } 38 }
+  // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } 38 }
 }
   else
 p = __builtin_malloc (n);

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Andreas Schwab]

On Okt 19 2016, Jerry DeLisle  wrote:

> Could you try compiling manually the failing test with gfortran -static
> and then run it to see what happens.

That does not change anything.

> Also what target is this failing on.

aarch64 and m68k.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Andreas Krebbel]

On 10/17/2016 09:29 PM, Andreas Krebbel1 wrote:
>> Here is a patch implementing what I think has been discussed in this 
> thread.
>>
>> OK?
> 
> Looks good to me.
> 
> Uli, do you agree with that change for S/390 or would you rather see us 
> fixing the float_t type definition in Glibc?

I had a discussion with Ulrich. He agrees with the current patch. So the patch 
is ok to apply.
Thanks for taking care of this (and being patient with me).

Also I will try to push forward changing float_t to float. Your patch does not 
make things worse and
should not make it harder to do the float_t switch in the future. For the 
float_t switch I will have
to check with the distro maintainers.

-Andreas-

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77993

--- Comment #6 from Eric Botcazou  ---
> Also, what configure comment, and you seem to have CFLAGS set during
> build?

Configure with: /work/botcazou/gcc-head/src/configure --build=powerpc-linux-gnu
--prefix=/work/botcazou/gcc-head/install_ppc
--with-gmp=/work/botcazou/support/ppc --with-mpfr=/work/botcazou/support/ppc
--with-mpc=/work/botcazou/support/ppc
--enable-languages=c,c++,objc,obj-c++,fortran,ada --enable-__cxa_atexit
--disable-nls --disable-libsanitizer

and just type 'make'.

[Bug c++/70909] Libiberty Demangler segfaults (4)

[palves at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909

Pedro Alves  changed:

   What|Removed |Added

 CC||palves at redhat dot com

--- Comment #3 from Pedro Alves  ---
These crashes are still plaguing GDB users, unfortunately.

Any chance the patches make it to trunk?

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Andreas Schwab]

On Okt 19 2016, Jerry DeLisle  wrote:

> The patch changes nothing related to any particular target. If I were to
> hazard a guess I would think the tests are linking against a wrong version
> of the library, the follow on patch (not yet committed) is bumping the
> libgfortran major version number.

There is only one version of the library, the one just built.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77993

--- Comment #5 from Segher Boessenkool  ---
Build, with what flags?

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77993

--- Comment #4 from Segher Boessenkool  ---
Also, what configure comment, and you seem to have CFLAGS set during
build?

[Bug bootstrap/77993] [7 regression] bootstrap failure on PowerPC/Linux

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77993

--- Comment #3 from Eric Botcazou  ---
> What bootstrap stage is failing here?

It's a simple build failure, just try to compile the preprocessed testcase.

Re: [patch, gfortran] PR48298 DTIO, implement size=

[Jerry DeLisle]

On 10/19/2016 04:04 AM, Andreas Schwab wrote:

At line 74 of file /opt/gcc/gcc-20161019/gcc/testsuite/gfortran.dg/dtio_17.f90 
(unit = 28, file = '/tmp/gfortrantmpQF10b7')
Fortran runtime error: Bad value during integer read

Error termination. Backtrace:
FAIL: gfortran.dg/dtio_17.f90   -O1  execution test

Andreas.



See my reply to Christophe post on arm aarch64.

Could you try compiling manually the failing test with gfortran -static and then 
run it to see what happens. Also what target is this failing on.


Jerry

[Bug target/77991] [5/6/7 Regression] ICE on x32 in plus_constant, at explow.c:87

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77991

Uroš Bizjak  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |5.5

--- Comment #8 from Uroš Bizjak  ---
Fixed everywhere.