[Bug c++/85943] Template function permits derived class access to private base class static variable

[achuah at drwsg dot com]

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

Anthony Chuah  changed:

   What|Removed |Added

Summary|Template function permits   |Template function permits
   |outside access to private   |derived class access to
   |variable|private base class static
   ||variable

--- Comment #2 from Anthony Chuah  ---
Apologies for yet another edit: next time I'll make sure to have the
fully-written report before submitting.

The issue appears to be that GCC will permit a derived class access to a
private static variable of its base class.

Please use this repro example instead https://godbolt.org/g/A3zCLk, because it
has a listing of different test cases.

[Bug c++/85944] New: Address of member variable of temporary not considered constexpr at global scope

[david at doublewise dot net]

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

Bug ID: 85944
   Summary: Address of member variable of temporary not considered
constexpr at global scope
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

When compiling the following code in C++11, C++14, C++17, or C++2a with 8.1 or
trunk (not tested with earlier versions):


struct S {
int x = 0;
};

constexpr bool f(S const & s) {
return 
}

constexpr auto x = f(S{});




gcc gives this error message:


:6:12: error: '((&.S::x) != 0)' is not a constant expression

  return 

^

Compiler returned: 1





Putting the declaration of `x` inside a function rather than at global scope
fixes the error, as does creating a constexpr variable to store the result of
`S{}` and then passing that to `f`.

[Bug c++/85943] Template function permits outside access to private variable

[achuah at drwsg dot com]

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

--- Comment #1 from Anthony Chuah  ---
Clarifications:

This bug applies to static variables, not non-static ones.

Please use this example instead: https://godbolt.org/g/LzrzDj

[Bug target/85915] ABI incompatibility (multiple definition of `__x86_return_thunk') for static libraries, between GCC 7.3.0 and GCC >=7.4.0, caused by -mfunction-return=thunk

[Arfrever.FTA at GMail dot Com]

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

Arfrever Frehtes Taifersar Arahesis  changed:

   What|Removed |Added

Summary|ABI incompatibility |ABI incompatibility
   |(multiple definition of |(multiple definition of
   |`__x86_return_thunk')   |`__x86_return_thunk') for
   |between GCC 7.3.0 and GCC   |static libraries, between
   |>=7.4.0 caused by   |GCC 7.3.0 and GCC >=7.4.0,
   |-mfunction-return=thunk |caused by
   ||-mfunction-return=thunk

--- Comment #8 from Arfrever Frehtes Taifersar Arahesis  ---
It seems that this ABI incompatibility affects all static libraries, not just
libc_nonshared.a.

[Bug c++/85943] New: Template function permits outside access to private variable

[achuah at drwsg dot com]

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

Bug ID: 85943
   Summary: Template function permits outside access to private
variable
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: achuah at drwsg dot com
  Target Milestone: ---

This probably should be classified under meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002

See this example on Godbolt's compiler explorer: https://godbolt.org/g/skvWAt

If the accessing function were not a template function, then GCC correctly
prevents the private access.

If the private member was a function instead of a variable, then GCC correctly
prevents the private access, but only upon instantiation.

Note: in all of these cases, clang will not compile, regardless of whether
there's been an instantiation of the template.

Res: Site

[Michel]

Ol�, tudo bem ?

Voc� ainda tem interesse na cria��o do seu site e loja virtual ?



Att.

http://www.e-assis.com.br/?c=g...@gnu.org
Tel: (11) 2378-7244

[Bug fortran/85942] New: ICE with PDTs

[juergen.reuter at desy dot de]

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

Bug ID: 85942
   Summary: ICE with PDTs
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

The following code from c.l.f. thread from Sep 28, 2015. ("Vectors on everyday
physics") leads to an ICE with gfortran 9.0, but works without problems with
ifort 18 and 19, cf. code below.
The expected output would be:
  matrix mat_r4: kind =4
  matrix mat_r4: num cols =2
  matrix mat_r4: num rows =3
  a_r4 =1.00   2.00   3.00   4.00
   5.00   6.00
  matrix mat_r8: kind =8
  matrix mat_r8: num cols =4
  matrix mat_r8: num rows =4
  a_r8 =1.002.00 
   3.004.005.00 
   6.007.008.00 
   9.0010.011.0 
   12.013.014.0 
   15.016.0 


Code leading to the segfault:


module mykinds 
  use, intrinsic :: iso_fortran_env, only : i4 => int32, r4 => real32, r8 =>
real64 
  implicit none 
  private
  public :: i4, r4, r8
end module mykinds

module matrix
  use mykinds, only : r4, r8
  implicit none
  private

  type, public :: mat_t(k,c,r)
 private
 !.. type parameters
 integer, kind :: k = r4
 integer, len :: c = 1
 integer, len :: r = 1 
 !.. private by default
 !.. type data
 real(kind=k) :: m_a(c,r) 
  end type mat_t

  interface assignment(=)
 module procedure geta_r4
 module procedure seta_r4
 module procedure geta_r8
 module procedure seta_r8
 !.. additional bindings elided
  end interface assignment(=)

  public :: assignment(=)

contains

  subroutine geta_r4(a_lhs, t_rhs)   
real(r4), allocatable, intent(out) :: a_lhs(:,:)
class(mat_t(k=r4,c=*,r=*)), intent(in) :: t_rhs   
a_lhs = t_rhs%m_a
return 
  end subroutine geta_r4

  subroutine geta_r8(a_lhs, t_rhs) 
real(r8), allocatable, intent(out) :: a_lhs(:,:)
class(mat_t(k=r8,c=*,r=*)), intent(in) :: t_rhs
a_lhs = t_rhs%m_a
return 
  end subroutine geta_r8

  subroutine seta_r4(t_lhs, a_rhs) 
class(mat_t(k=r4,c=*,r=*)), intent(inout) :: t_lhs
real(r4), intent(in) :: a_rhs(:,:)
!.. checks on size elided
t_lhs%m_a = a_rhs
return 
  end subroutine seta_r4

  subroutine seta_r8(t_lhs, a_rhs) 
class(mat_t(k=r8,c=*,r=*)), intent(inout) :: t_lhs
real(r8), intent(in) :: a_rhs(:,:)
!.. checks on size elided
t_lhs%m_a = a_rhs
return 
  end subroutine seta_r8

end module matrix

program p  
  use mykinds, only : r4, r8
  use matrix, only : mat_t, assignment(=)  
  implicit none  
  type(mat_t(k=r4,c=:,r=:)), allocatable :: mat_r4
  type(mat_t(k=r8,c=:,r=:)), allocatable :: mat_r8  
  real(r4), allocatable :: a_r4(:,:)
  real(r8), allocatable :: a_r8(:,:)  
  integer :: N
  integer :: M
  integer :: i
  integer :: istat  
  N = 2
  M = 3
  allocate( mat_t(k=r4,c=N,r=M) :: mat_r4, stat=istat )
  if ( istat /= 0 ) then
 print *, " error allocating mat_r4: stat = ", istat
 stop
  end if  
  print *, " matrix mat_r4: kind = ", mat_r4%k
  print *, " matrix mat_r4: num cols = ", mat_r4%c
  print *, " matrix mat_r4: num rows = ", mat_r4%r  
  mat_r4 = reshape( [ (real(i, kind=mat_r4%k), i=1,N*M) ], [ N, M ] )  
  a_r4 = mat_r4
  print *, " a_r4 = ", a_r4  
  N = 4
  M = 4
  allocate( mat_t(k=r8,c=N,r=M) :: mat_r8, stat=istat )
  if ( istat /= 0 ) then
 print *, " error allocating mat_r4: stat = ", istat
 stop
  end if  
  print *, " matrix mat_r8: kind = ", mat_r8%k
  print *, " matrix mat_r8: num cols = ", mat_r8%c
  print *, " matrix mat_r8: num rows = ", mat_r8%r  
  mat_r8 = reshape( [ (real(i, kind=mat_r8%k), i=1,N*M) ], [ N, M ] )  
  a_r8 = mat_r8
  print *, " a_r8 = ", a_r8  
  deallocate( mat_r4, stat=istat )
  if ( istat /= 0 ) then
 print *, " error deallocating mat_r4: stat = ", istat
 stop
  end if  
  deallocate( mat_r8, stat=istat )
  if ( istat /= 0 ) then
 print *, " error deallocating mat_r4: stat = ", istat
 stop
  end if  
  stop  
end program p

[Bug target/85666] gcc-8.0.1 fails to build mmix target: gcc/libgcc/libgcc2.h:203:20: internal compiler error: in leaf_function_p, at final.c:4488

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #10)
> Created attachment 44180 [details]
> patch to mmix.c
> 
> Builds libgcc.  More late this weekend, I hope.

I now see the assertion in assemble_integer alluded to in comment #6 and have
to go chase that down.  Commenting out the gcc_assert is not an option.

Important, Please

[Tridip Acharya]

Hello,

Did you receive my previous email? 

Pls inform. 

Best regards, 
T. K Acharya

gcc-9-20180527 is now available

[gccadmin]

Snapshot gcc-9-20180527 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/9-20180527/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 260810

You'll find:

 gcc-9-20180527.tar.xzComplete GCC

  SHA256=2dd4561d7288f1296b44683240b0d0371bb4a8e560bca3e147089f47d3e05e3e
  SHA1=a67f60c5b5b4bc2ec920fa3cc207f9fd441f0bae

Diffs from 9-20180520 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[committed] Disable use of GNU-stack notes on hppa-linux

[John David Anglin]

The attached change disables the use of GNU-stack notes on hppa-linux.  
The Linux kernel
requires an executable stack for syscall restarts and signal returns.  
Enabling GNU-stack notes

breaks glibc signal handling.

Committed to trunk and gcc-8 branch.

Dave

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

2018-05-27  John David Anglin  

* config/pa/pa-linux.h (NEED_INDICATE_EXEC_STACK): Define to 0.

Index: config/pa/pa-linux.h
===
--- config/pa/pa-linux.h(revision 260792)
+++ config/pa/pa-linux.h(working copy)
@@ -142,5 +142,8 @@
 #define HAVE_sync_compare_and_swapsi 1
 #define HAVE_sync_compare_and_swapdi 1
 
+/* It's not possible to enable GNU_stack notes since the kernel needs
+   an executable stack for signal returns and syscall restarts.  */
+
 #undef NEED_INDICATE_EXEC_STACK
-#define NEED_INDICATE_EXEC_STACK 1
+#define NEED_INDICATE_EXEC_STACK 0

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Florian Weimer from comment #3)
> > (In reply to Uroš Bizjak from comment #1)
> > > Please also use -mincoming-stack-boundary=2 to tell the compiler about
> > > possible incoming stack (mis)alignment.
> > 
> > This does change the result; alignment is performed.  This is not
> > documented.  I'm not sure what the intent is here.
> > 
> > (In reply to Uroš Bizjak from comment #2)
> > > FYI, -mstackrealign applies only to main ().
> > 
> > I don't think this is true.  In the example, stack alignment is performed if
> > I use __m128 instead of __m64.
> 
> Let's add HJ to CC, maybe he can shed some light on this option.

I believe __m64 is 4-byte aligned.

[Bug target/69616] optimization of 8 movb

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Dup.

*** This bug has been marked as a duplicate of bug 22141 ***

[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||izaberina at gmail dot com

--- Comment #49 from ktkachov at gcc dot gnu.org ---
*** Bug 69616 has been marked as a duplicate of this bug. ***

[Bug target/69639] [6/7/8/9 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c

[pkoning at gcc dot gnu.org]

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

pkoning at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pkoning at gcc dot gnu.org

--- Comment #10 from pkoning at gcc dot gnu.org ---
I see this issue on my Mac (Mac OS 10.13.3, Apple LLVM version 9.1.0
(clang-902.0.39.1)).  It shows up both for the native (x86) target, and the
pdp11 target.

But the behavior is very strange.  If I create a new build directory,
configure, make, then try compiling limits-exprparens.c, it works fine.  If I
then rebuild some files -- for example, by "touch config//.h;
make" then the bug appears.  This strangeness is reproducible.  

What's stranger is that doing a "make distclean; configure... ; make" also
reproduces the problem; it doesn't make any sense for make distclean to be
different from starting with a new empty directory, but it is.

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Florian Weimer from comment #3)
> (In reply to Uroš Bizjak from comment #1)
> > Please also use -mincoming-stack-boundary=2 to tell the compiler about
> > possible incoming stack (mis)alignment.
> 
> This does change the result; alignment is performed.  This is not
> documented.  I'm not sure what the intent is here.
> 
> (In reply to Uroš Bizjak from comment #2)
> > FYI, -mstackrealign applies only to main ().
> 
> I don't think this is true.  In the example, stack alignment is performed if
> I use __m128 instead of __m64.

Let's add HJ to CC, maybe he can shed some light on this option.

[Bug target/69616] optimization of 8 movb

[me at xenu dot pl]

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

Tomasz Konojacki  changed:

   What|Removed |Added

 CC||me at xenu dot pl

--- Comment #4 from Tomasz Konojacki  ---
gcc 8.1 generates the following code:

f():
movq$0, tape(%rip)
ret
tape:
.zero   65536

I believe this ticket should be closed.

[Bug rtl-optimization/66152] suboptimal load bytes to stack

[me at xenu dot pl]

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

Tomasz Konojacki  changed:

   What|Removed |Added

 CC||me at xenu dot pl

--- Comment #3 from Tomasz Konojacki  ---
gcc 8.1 generates the following code:

bar():
movabsq $506097522914230528, %rax
subq$24, %rsp
leaq8(%rsp), %rdi
movq%rax, 8(%rsp)
callfoo(char*)
addq$24, %rsp
ret

I believe this ticket should be closed.

[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI

[jozef.l at mittosystems dot com]

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

Jozef Lawrynowicz  changed:

   What|Removed |Added

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

--- Comment #4 from Jozef Lawrynowicz  ---
Right, yes of course. Given that combine isn't at fault, I'll close this as
invalid, and submit a patch with the msp430 insn pattern fixed.

Thanks.

Re: Improve std::rotate usages

[François Dumont]

Still no chance to review it ?

I'd like this one to go in before submitting other algo related patches.

    * include/bits/stl_algo.h
    (__rotate(_Ite, _Ite, _Ite, forward_iterator_tag))
    (__rotate(_Ite, _Ite, _Ite, bidirectional_iterator_tag))
    (__rotate(_Ite, _Ite, _Ite, random_access_iterator_tag)): Move code 
duplication...

    (rotate(_Ite, _Ite, _Ite)): ...here.
    (__stable_partition_adaptive(_FIt, _FIt, _Pred, _Dist, _Pointer, 
_Dist)):

    Simplify rotate call.
    (__rotate_adaptive(_BIt1, _BIt1, _BIt1, _Dist, _Dist, _Bit2, _Dist)):
    Likewise.
    (__merge_without_buffer(_BIt, _BIt, _BIt, _Dist, _Dist, _Comp)):
    Likewise.

François

On 14/05/2018 22:14, François Dumont wrote:

Any feedback regarding this patch ?


On 02/05/2018 07:26, François Dumont wrote:

Hi

    std::rotate already returns the expected iterator so there is no 
need for calls to std::advance/std::distance.


Tested under Linux x86_64, ok to commit ?

François





diff --git a/libstdc++-v3/include/bits/stl_algo.h b/libstdc++-v3/include/bits/stl_algo.h
index e10a692..9c1b2d4 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -1245,11 +1245,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	 _ForwardIterator __last,
 	 forward_iterator_tag)
 {
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   _ForwardIterator __first2 = __middle;
   do
 	{
@@ -1290,11 +1285,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_function_requires(_Mutable_BidirectionalIteratorConcept<
   _BidirectionalIterator>)
 
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   std::__reverse(__first,  __middle, bidirectional_iterator_tag());
   std::__reverse(__middle, __last,   bidirectional_iterator_tag());
 
@@ -1328,11 +1318,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<
   _RandomAccessIterator>)
 
-  if (__first == __middle)
-	return __last;
-  else if (__last  == __middle)
-	return __first;
-
   typedef typename iterator_traits<_RandomAccessIterator>::difference_type
 	_Distance;
   typedef typename iterator_traits<_RandomAccessIterator>::value_type
@@ -1434,6 +1419,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __glibcxx_requires_valid_range(__first, __middle);
   __glibcxx_requires_valid_range(__middle, __last);
 
+  if (__first == __middle)
+	return __last;
+  else if (__last  == __middle)
+	return __first;
+
   return std::__rotate(__first, __middle, __last,
 			   std::__iterator_category(__first));
 }
@@ -1595,9 +1585,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	   __right_len,
 	   __buffer, __buffer_size);
 
-  std::rotate(__left_split, __middle, __right_split);
-  std::advance(__left_split, std::distance(__middle, __right_split));
-  return __left_split;
+  return std::rotate(__left_split, __middle, __right_split);
 }
 
   template
@@ -2396,11 +2384,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	return __last;
 	}
   else
-	{
-	  std::rotate(__first, __middle, __last);
-	  std::advance(__first, std::distance(__middle, __last));
-	  return __first;
-	}
+	return std::rotate(__first, __middle, __last);
 }
 
   /// This is a helper function for the merge routines.
@@ -2507,9 +2491,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 	  __len11 = std::distance(__first, __first_cut);
 	}
 
-  std::rotate(__first_cut, __middle, __second_cut);
-  _BidirectionalIterator __new_middle = __first_cut;
-  std::advance(__new_middle, std::distance(__middle, __second_cut));
+  _BidirectionalIterator __new_middle
+	= std::rotate(__first_cut, __middle, __second_cut);
   std::__merge_without_buffer(__first, __first_cut, __new_middle,
   __len11, __len22, __comp);
   std::__merge_without_buffer(__new_middle, __second_cut, __last,

[PATCH, committed] fix ICE in test suite on pdp11

[Paul Koning]

This cures an ICE caused by a wrong pattern that produces invalid 
register references.

gcc/ChangeLog

2018-05-27  Paul Koning  

* config/pdp11/pdp11.md (truncsihi2): Remove.
 
Index: config/pdp11/pdp11.md
===
--- config/pdp11/pdp11.md   (revision 260806)
+++ config/pdp11/pdp11.md   (revision 260807)
@@ -314,7 +314,6 @@
(match_operand:DI 1 "general_operand" "rN,g"))]
   ""
   "* return output_move_multiple (operands);"
-;; what's the mose expensive code - say twice movsi = 16
   [(set_attr "length" "16,32")])
 
 (define_insn "movsi"
@@ -322,8 +321,6 @@
(match_operand:SI 1 "general_operand" "rN,IJ,IJ,g"))]
   ""
   "* return output_move_multiple (operands);"
-;; what's the most expensive code ? - I think 8!
-;; we could split it up and make several sub-cases...
   [(set_attr "length" "4,6,8,16")])
 
 (define_insn "mov"
@@ -426,14 +423,6 @@
   [(set_attr "length" "0,2,4")])
 
 
-(define_expand "truncsihi2"
-  [(set (match_operand:HI 0 "nonimmediate_operand" "=g")
-   (subreg:HI 
- (match_operand:SI 1 "general_operand" "or")
-  0))]
-  ""
-  "")
-
 

 ;;- zero extension instructions
 

Re: Simplify _Rb_tree instantiation

[François Dumont]

On 25/05/2018 21:19, Ville Voutilainen wrote:

On 25 May 2018 at 22:16, Jonathan Wakely  wrote:

Why is this patch removing _Compare() calls? That changes the
initialization
of _Compare from value-initialization to default-initialization, which
is a breaking change.


The _Rb_tree_key_compare base class will still value-initialize it:

  _Rb_tree_key_compare()
  _GLIBCXX_NOEXCEPT_IF(
 is_nothrow_default_constructible<_Key_compare>::value)
  : _M_key_compare()
  { }

Okay, no problem then.

Now applied, note that I eventually restored the explicit calls to 
_M_t() in the template iterator range constructors. We didn't talk about 
it and there is also such a call for the default constructors in 
pre-c++11 mode so I prefered to keep consistency.


François

Re: virtual-stack-vars reference not resolved in vregs

[Paul Koning]

> On May 25, 2018, at 2:11 AM, Eric Botcazou  wrote:
> 
>> Is this something the back end is responsible for getting right, for example
>> via the machine description file?  If so, any hints where to start?
> 
> The SUBREG of MEM is invalid at this stage.

Thanks.  That pointed me to the problem: the .md file contained a 
define_expand for truncsihi2, which is not useful given that the word
length is 2.  Deleting it cured the problem.

paul

Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP

[Jeff Law]

On 05/26/2018 04:09 AM, Richard Sandiford wrote:
> Steve Ellcey  writes:
>> On Wed, 2018-05-16 at 22:11 +0100, Richard Sandiford wrote:
>>>  
>>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED is the only current way
>>> of saying that an rtl instruction preserves the low part of a
>>> register but clobbers the high part.  We would need something like
>>> Alan H's CLOBBER_HIGH patches to do it using explicit clobbers.
>>>
>>> Another approach would be to piggy-back on the -fipa-ra
>>> infrastructure
>>> and record that vector PCS functions only clobber Q0-Q7.  If -fipa-ra
>>> knows that a function doesn't clobber Q8-Q15 then that should
>>> override
>>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED.  (I'm not sure whether it does
>>> in practice, but it should :-)  And if it doesn't that's a bug that's
>>> worth fixing for its own sake.)
>>>
>>> Thanks,
>>> Richard
>>
>> Alan,
>>
>> I have been looking at your CLOBBER_HIGH patches to see if they
>> might be helpful in implementing the ARM SIMD Vector ABI in GCC.
>> I have also been looking at the -fipa-ra flag and how it works.
>>
>> I was wondering if you considered using the ipa-ra infrastructure
>> for the SVE work that you are currently trying to support with 
>> the CLOBBER_HIGH macro?
>>
>> My current thought for the ABI work is to mark all the floating
>> point / vector registers as caller saved (the lower half of V8-V15
>> are currently callee saved) and remove
>> TARGET_HARD_REGNO_CALL_PART_CLOBBERED.
>> This should work but would be inefficient.
>>
>> The next step would be to split get_call_reg_set_usage up into
>> two functions so that I don't have to pass in a default set of
>> registers.  One function would return call_used_reg_set by
>> default (but could return a smaller set if it had actual used
>> register information) and the other would return regs_invalidated
>> by_call by default (but could also return a smaller set).
>>
>> Next I would add a 'largest mode used' array to call_cgraph_rtl_info
>> structure in addition to the current function_used_regs register
>> set.
>>
>> Then I could turn the get_call_reg_set_usage replacement functions
>> into target specific functions and with the information in the
>> call_cgraph_rtl_info structure and any simd attribute information on
>> a function I could modify what registers are really being used/invalidated
>> without being saved.
>>
>> If the called function only uses the bottom half of a register it would not
>> be marked as used/invalidated.  If it uses the entire register and the
>> function is not marked as simd, then the register would marked as
>> used/invalidated.  If the function was marked as simd the register would not
>> be marked because a simd function would save both the upper and lower halves
>> of a callee saved register (whereas a non simd function would only save the
>> lower half).
>>
>> Does this sound like something that could be used in place of your 
>> CLOBBER_HIGH patch?
> 
> One of the advantages of CLOBBER_HIGH is that it can be attached to
> arbitrary instructions, not just calls.  The motivating example was
> tlsdesc_small_, which isn't treated as a call but as a normal
> instruction.  (And I don't think we want to change that, since it's much
> easier for rtl optimisers to deal with normal instructions compared to
> calls.  In general a call is part of a longer sequence of instructions
> that includes setting up arguments, etc.)
Yea.  I don't think we want to change tlsdesc*.  Representing them as
normal insns rather than calls seems reasonable to me.

Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
When we left things I think we were trying to decide between
CLOBBER_HIGH and clobbering the appropriate subreg.  The problem with
the latter is the dataflow we compute is inaccurate (overly pessimistic)
so that'd have to be fixed.

Jeff

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[fw at gcc dot gnu.org]

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

--- Comment #4 from Florian Weimer  ---
Unfortunately, -mincoming-stack-boundary=2 makes -mstackrealign useless because
now any leaf function realigns the stack.

The usual effect (no matter what the documentation says) is that -mstackrealign
prefers current ABI alignment, but at the same time makes the generate code
compatible with the original ABI, by realigning the stack if necessary (and
generally discouraging the use of vector instructions by disabling STV).

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[fw at gcc dot gnu.org]

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

--- Comment #3 from Florian Weimer  ---
(In reply to Uroš Bizjak from comment #1)
> Please also use -mincoming-stack-boundary=2 to tell the compiler about
> possible incoming stack (mis)alignment.

This does change the result; alignment is performed.  This is not documented. 
I'm not sure what the intent is here.

(In reply to Uroš Bizjak from comment #2)
> FYI, -mstackrealign applies only to main ().

I don't think this is true.  In the example, stack alignment is performed if I
use __m128 instead of __m64.

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
FYI, -mstackrealign applies only to main ().

[Bug target/85939] -mstackrealign does not realign stack with local __m64 variable

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Please also use -mincoming-stack-boundary=2 to tell the compiler about possible
incoming stack (mis)alignment.

Re: [PATCH,Fortran] Allow pointer initialization in DATA

[Jerry DeLisle]

On 05/24/2018 06:14 PM, Steve Kargl wrote:

The attach patch allows for pointer initialization in
a DATA statement per F2018.  Yes, it's weird that a
data-constant-object is not a named parameter.  The
'data-constant-object' is required to have the SAVE and
TARGET attribute.

Built and regression tested on x86_64-*-freebsd.
OK to commit?

PS: I'm sure Gerhard can break this.



OK and thanks for patch.

Jerry

[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
But this pattern:

(define_insn "zero_extendqisi2"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
(zero_extend:SI (subreg:HI (match_operand:QI 1 "nonimmediate_operand"
"rm") 0)))]

Is saying a zero_extend from HI to SI.  But not from QI to SI.  This is a
paradoxical subreg.

Re: [PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE

[Jozef Lawrynowicz]

On 27/05/18 14:19, Jozef Lawrynowicz wrote:
If the patch is acceptable, I would appreciate if someone would commit 
it for

me, as I don't have write access.


"msp430.md" in the ChangeLog entry should be "msp430.c".

[PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE

[Jozef Lawrynowicz]

Some users have a preference for declaring interrupt handlers as static
functions, as this enforces that interrupts should not be called directly (from
other source files at least).

This patch allows interrupt handlers to be declared as static and also fixes
an assertion failure when the interrupt attribute is written with the leading
and trailing underscores included in the name.

Successfully regtested gcc testsuite on trunk for msp430-elf in the
-mcpu=msp430x/-mlarge variation.

If the patch is acceptable, I would appreciate if someone would commit it for
me, as I don't have write access.

>From 18d1980bb4061cee9d97f2b7737af2dfd9e52c34 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Sun, 27 May 2018 12:55:41 +0100
Subject: [PATCH] MSP430: Allow interrupt handlers to be static and fix the
 __interrupt__ attribute causing an ICE

2018-05-27  Jozef Lawrynowicz  

	* gcc/config/msp430/msp430.md (msp430_attr): Allow interrupt handlers
	to be static and remove check on interrupt attribute name.

	gcc/testsuite/gcc.target/msp430/
	* function-attributes-4.c: New test.
	* static-interrupts.c: New test.

---
 gcc/config/msp430/msp430.c |  17 ++--
 .../gcc.target/msp430/function-attributes-4.c  | 111 +
 .../gcc.target/msp430/static-interrupts.c  |  26 +
 3 files changed, 144 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/function-attributes-4.c
 create mode 100644 gcc/testsuite/gcc.target/msp430/static-interrupts.c

diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index a8fed12..85626a2 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -1867,11 +1867,9 @@ msp430_attr (tree * node,
 {
   gcc_assert (DECL_P (* node));
 
+  /* Only the interrupt attribute takes an argument.  */
   if (args != NULL)
 {
-  /* Only the interrupt attribute takes an argument.  */
-  gcc_assert (TREE_NAME_EQ (name, ATTR_INTR));
-
   tree value = TREE_VALUE (args);
 
   switch (TREE_CODE (value))
@@ -1916,13 +1914,12 @@ msp430_attr (tree * node,
   if (TREE_CODE (TREE_TYPE (* node)) == FUNCTION_TYPE
 	  && ! VOID_TYPE_P (TREE_TYPE (TREE_TYPE (* node
 	message = "interrupt handlers must be void";
-
-  if (! TREE_PUBLIC (* node))
-	message = "interrupt handlers cannot be static";
-
-  /* Ensure interrupt handlers never get optimised out.  */
-  TREE_USED (* node) = 1;
-  DECL_PRESERVE_P (* node) = 1;
+  else
+	{
+	  /* Ensure interrupt handlers never get optimised out.  */
+	  TREE_USED (* node) = 1;
+	  DECL_PRESERVE_P (* node) = 1;
+	}
 }
   else if (TREE_NAME_EQ (name, ATTR_REENT))
 {
diff --git a/gcc/testsuite/gcc.target/msp430/function-attributes-4.c b/gcc/testsuite/gcc.target/msp430/function-attributes-4.c
new file mode 100644
index 000..07d13c9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/function-attributes-4.c
@@ -0,0 +1,111 @@
+/* { dg-do compile } */
+/* Check that the foo interrupt vectors aren't actually removed.  */
+/* { dg-final { scan-assembler-times "__interrupt_vector_foo" 2 } } */
+
+/* Check that warnings are emitted when attributes are used incorrectly and
+   that attributes are interpreted correctly whether leading and trailing
+   underscores are used or not.  */
+
+void __attribute__((__naked__,__reentrant__))
+fn1(void)
+{ /* { dg-warning "naked functions cannot be reentrant" } */
+}
+
+void __attribute__((naked,reentrant))
+fn2(void)
+{ /* { dg-warning "naked functions cannot be reentrant" } */
+}
+
+void __attribute__((__reentrant__,__naked__))
+fn3(void)
+{ /* { dg-warning "reentrant functions cannot be naked" } */
+}
+
+void __attribute__((reentrant,naked))
+fn4(void)
+{ /* { dg-warning "reentrant functions cannot be naked" } */
+}
+
+void __attribute__((__critical__,__reentrant__))
+fn5(void)
+{ /* { dg-warning "critical functions cannot be reentrant" } */
+}
+
+void __attribute__((critical,reentrant))
+fn6(void)
+{ /* { dg-warning "critical functions cannot be reentrant" } */
+}
+
+void __attribute__((__reentrant__,__critical__))
+fn7(void)
+{ /* { dg-warning "reentrant functions cannot be critical" } */
+}
+
+void __attribute__((reentrant,critical))
+fn8(void)
+{ /* { dg-warning "reentrant functions cannot be critical" } */
+}
+
+void __attribute__((__critical__,__naked__))
+fn9(void)
+{ /* { dg-warning "critical functions cannot be naked" } */
+}
+
+void __attribute__((critical,naked))
+fn10(void)
+{ /* { dg-warning "critical functions cannot be naked" } */
+}
+
+void __attribute__((__naked__,__critical__))
+fn11(void)
+{ /* { dg-warning "naked functions cannot be critical" } */
+}
+
+void __attribute__((naked,critical))
+fn12(void)
+{ /* { dg-warning "naked functions cannot be critical" } */
+}
+
+int __attribute__((interrupt))
+isr1 (void)
+{ /* { dg-warning "interrupt handlers must be void" } */
+}
+
+int __attribute__((__interrupt__))

[Bug objc/50909] Process "#pragma options align=reset" correctly on Mac OS X

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager  ---
(In reply to Rudolf from comment #12)
> This is still an issue... 7 YEARS LEATER!?
> 
> I tried to change the permission on USB.h just to get around this bug...
> 
> with something like this:
> #if defined(__clang__) || defined(__llvm__)
> #pragma options align=reset
> #else
> #pragma pack()
> #endif
> 
> but sadly could not do so atm.
> 
> I am using gcc 8.1.0. please fix this.

Maybe we could do that as a fixincludes until someone figures out how to code
support for the pragma properly

[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI

[jozef.l at mittosystems dot com]

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

--- Comment #2 from Jozef Lawrynowicz  ---
Created attachment 44192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44192=edit
correct assembly output

[Bug rtl-optimization/85941] Zero extend from QI->SI lost if QI is referred to via subreg:HI

[jozef.l at mittosystems dot com]

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

--- Comment #1 from Jozef Lawrynowicz  ---
Created attachment 44191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44191=edit
incorrect assembly output

[Bug rtl-optimization/85941] New: Zero extend from QI->SI lost if QI is referred to via subreg:HI

[jozef.l at mittosystems dot com]

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

Bug ID: 85941
   Summary: Zero extend from QI->SI lost if QI is referred to via
subreg:HI
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozef.l at mittosystems dot com
  Target Milestone: ---

Created attachment 44190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44190=edit
testcase

In the combine RTL stage,
(zero_extend:SI (subreg:HI (reg:QI 28) 0)))
becomes
(zero_extend:SI (reg:HI 12 R12)))
at -O1 and above.

A reduced test case based on pr39240.c is attached, observed with msp430-elf.
It fails on execution with current trunk as the necessary instruction to zero
extend R12 (AND #0xff, R12) is lost.

On native x86_64, a subreg expression is not used to reference the QI reg, so
this
problem isn't seen.

See zero_extendqisi2 in gcc/config/msp430/msp430.md:

(define_insn "zero_extendqisi2"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
(zero_extend:SI (subreg:HI (match_operand:QI 1 "nonimmediate_operand"
"rm") 0)))]

If the subreg:HI expression is removed from the insn pattern, the zero
extension
from QI->SI is present in the output assembly, and the test case executes
correctly:

(define_insn "zero_extendqisi2"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=r")
(zero_extend:SI (match_operand:QI 1 "nonimmediate_operand" "rm")))]

I am not aware of why the first pattern would be incorrect, so is this a bug in
combine rather than the insn pattern?

Observed with 7.3.1 and current trunk 9.0.0.

Re: Enabling -ftree-slp-vectorize on -O2/Os

[Allan Sandfeld Jensen]

On Sonntag, 27. Mai 2018 03:23:36 CEST Segher Boessenkool wrote:
> On Sun, May 27, 2018 at 01:25:25AM +0200, Allan Sandfeld Jensen wrote:
> > On Sonntag, 27. Mai 2018 00:05:32 CEST Segher Boessenkool wrote:
> > > On Sat, May 26, 2018 at 11:32:29AM +0200, Allan Sandfeld Jensen wrote:
> > > > I brought this subject up earlier, and was told to suggest it again
> > > > for
> > > > gcc 9, so I have attached the preliminary changes.
> > > > 
> > > > My studies have show that with generic x86-64 optimization it reduces
> > > > binary size with around 0.5%, and when optimizing for x64 targets with
> > > > SSE4 or better, it reduces binary size by 2-3% on average. The
> > > > performance changes are negligible however*, and I haven't been able
> > > > to
> > > > detect changes in compile time big enough to penetrate general noise
> > > > on
> > > > my platform, but perhaps someone has a better setup for that?
> > > > 
> > > > * I believe that is because it currently works best on non-optimized
> > > > code,
> > > > it is better at big basic blocks doing all kinds of things than
> > > > tightly
> > > > written inner loops.
> > > > 
> > > > Anythhing else I should test or report?
> > > 
> > > What does it do on other architectures?
> > 
> > I believe NEON would do the same as SSE4, but I can do a check. For
> > architectures without SIMD it essentially does nothing.
> 
> Sorry, I wasn't clear.  What does it do to performance on other
> architectures?  Is it (almost) always a win (or neutral)?  If not, it
> doesn't belong in -O2, not for the generic options at least.
> 
It shouldnt have any way of making slower code, so it is neutral or a win in 
performance, and similarly in code size, merged instructions means fewer 
instructions.

I never found a benchmark where it really made a measurable difference in 
performance, but I found many large binaries such as Qt or Chromium, where it 
made the binaries a few percent smaller.

Allan