[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #15 from Jonathan Wakely  ---
thanks - closing then

[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi

[amker at gcc dot gnu.org]

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

--- Comment #8 from amker at gcc dot gnu.org ---
Oh, missed messages.  Will look into it.

[Bug c++/66150] [C++11] cv-qualifiers on function types are not ignored.

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
But the static_assert passes, doesn't that mean the cv-qualifier is ignored?

[Bug fortran/66155] New: Macro not replaced after multi-line string constant

[elias.assmann at gmail dot com]

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

Bug ID: 66155
   Summary: Macro not replaced after multi-line string constant
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: elias.assmann at gmail dot com
  Target Milestone: ---

The following program

#define foo "x"
program test
  implicit none

  print*, 'bla&
   bla'//foo
end program test

yields the compiler error

$ gfortran try.F90 
try.F90:6.16:

   bla'//foo
1
Error: Symbol 'foo' at (1) has no IMPLICIT type

So maybe this should be considered a cpp bug instead?  I am posting it here
because I do not know cpp too well, and the problem is definitely
Fortran-related.  In any case, the preprocessor prints

$ gfortran -E try.F90
# 1 "try.F90"
# 1 ""
# 1 "try.F90"

program test
  implicit none

  print*, 'bla&
   bla'//foo
end program test

I find the same result with all of the following versions:

gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 
gcc version 4.1.2 20080704 (Red Hat 4.1.2-52)
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) 
gcc version 5.1.0 (GCC) 
g

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
This has nothing to do with libstdc++, the std::call_once code is identical on
x86 and ppc, and you get the same behaviour with pthreads, so it should be
reported to glibc instead.

#include 
#include 

pthread_once_t flag_ = PTHREAD_ONCE_INIT;

int call_count = 0;
extern "C" void func_() {
  printf("Inside func_ call_count %d\n", call_count);
  if (++call_count < 2)
throw 0;
}
int main() {
  printf("Before calling call_once flag_: %d\n", *(int*)&flag_);
  try {
pthread_once(&flag_, func_);
  } catch(...) {
printf("Inside catch all excepton flag_: %d\n", *(int*)&flag_);
  }
  printf("before the 2nd call to call_once flag_: %d\n", *(int*)&flag_);
  pthread_once(&flag_, func_);
}

[Bug rtl-optimization/66156] New: [msp430] wrong code generated with -O2 -mlarge (zero extension HI -> SI)

[ronald.wahl at raritan dot com]

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

Bug ID: 66156
   Summary: [msp430] wrong code generated with -O2 -mlarge (zero
extension HI -> SI)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ronald.wahl at raritan dot com
  Target Milestone: ---

Created attachment 35544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35544&action=edit
C file that is miscompiled

The attached C file is miscompiled by msp-gcc-elf when compiled with
"-mlarge -O2". I see this problem with the current source bundle from TI
as well as current gcc trunk.

The problem is that R13 (containing "val") is prematurely
cleared by a zero_extendhisi2 insn:

; R12 contains pointer to "array"
; R13 contains "val"
PUSHM.A #1, R10
PUSHM.A #3, R8
; end of prologue
MOVAR12, R8
CMPX.W  #0, &g_flag { JEQ   .L2
MOVX&g_second, R12
ADDAR12, R12
ADDAR8, R12
MOV.W   @R12, R12

MOV.W   #0,R13 ; < R13 clobbered (by zero_extendhisi2 (insn 12))

MOV.W   R12, R10
MOV.W   R13, R11
MOVX.W  &g_sum, R14
MOVX.W  &g_sum+2, R15
SUBXR10, R14 { SUBCXR11, R15
.L3:
MOV.W   R13, R6 ; < R13 used after it was clobbered

MOV.W   #0,R7
MOV.W   R6, R10
MOV.W   R7, R11
.L4:
MOVX.W  #1, &g_flag
ADD R10, R14 ; cy
ADDCR11, R15
MOVX&g_first, R12
ADDAR12, R12
ADDAR8, R12

MOV.W   R13, @R12 ; < R13 used after it was clobbered

CMPX.W  #0, &g_flag { JEQ   .L4
MOVX.W  R14, &g_sum
MOVX.W  R15, &g_sum+2
; start of epilogue
POPM.A  #3, r8
POPM.A  #1, r10
RETA
.L2:
MOVX.W  &g_sum, R14
MOVX.W  &g_sum+2, R15
BRA #.L3

In msp430.md there is a zero_extendhisi2 isnsn defined as follows:

  ;; Look for cases where integer/pointer conversions are suboptimal due
  ;; to missing patterns, despite us not having opcodes for these
  ;; patterns.  Doing these manually allows for alternate optimization
  ;; paths.
  (define_insn "zero_extendhisi2"
[(set (match_operand:SI 0 "nonimmediate_operand" "=rm")
  (zero_extend:SI (match_operand:HI 1 "nonimmediate_operand" "0")))]
"msp430x"
"MOV.W\t#0,%H0"
  )

The purpose seems to be in-place zero-extending an operand.

The problem happens during reload right after IRA. During IRA insn 12
(zero_extendhisi2) has r42 as input and r43 as output. Furthermore r39
contains "val". IRA assigns:
r39 -> r13 (HI)
r42 -> r12 (HI)
r43 -> r10 (SI)

But during reload the "zero_extendhisi2" insn defined in msp430.md matches
and zero extends R12 (i.e. clears R13) instead of R10.

Commenting out the insn in msp430.md or adding reload_completed constraint
fixes the issue but may raise the issues again why this insns was defined -
whatever these are.

So what's going on here?

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[paolo.carlini at oracle dot com]

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

--- Comment #7 from Paolo Carlini  ---
First blush I'm wondering if in this specific case we couldn't forward from
dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
regression and would allow us to adopt immediately Manuel' patch.

[Bug libstdc++/66157] New: bits/random.tcc compiler error when using -fno-for-scope

[luca.stoppa at bbh dot com]

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

Bug ID: 66157
   Summary: bits/random.tcc compiler error when using
-fno-for-scope
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luca.stoppa at bbh dot com
  Target Milestone: ---

Created attachment 35545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35545&action=edit
That example won't compile

Compiling a minimal example (empty main) that includes  will result
into a compilation error.

g++ -std=c++14 -fno-for-scope m.cpp

/opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/bits/random.tcc: In member
function âvoid std::seed_seq::generate(_RandomAccessIterator,
_RandomAccessIterator)â:
/opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/bits/random.tcc:3444:19: error:
redeclaration of âstd::size_t __kâ
   for (size_t __k = __m; __k < __m + __n; ++__k)
   ^
/opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/bits/random.tcc:3422:19: note:
âstd::size_t __kâ previously declared here
   for (size_t __k = 0; __k < __m; ++__k)

I have checked the newest libstdc++ source code and the but is still there.
I would like to know whether
- "-fno-for-scope" is still a supported flag for c++11/14/1y, in that case I
believe I hit an implementation error. In case you decide this is really an
error the fix is really easy: __k should be changed to __k1 in the first loop,
__k2 in the second loop, and so on.
- if it is not supported, I think the gcc documentation should be updated.

Testcases:
g++ -std=c++11 -fno-for-scope m.cpp won't compile
g++ -std=c++14 -fno-for-scope m.cpp won't compile
g++ -std=c++1y -fno-for-scope m.cpp won't compile

when removing -fno-for-scope everything is fine.

Thanks,
Luca

[Bug middle-end/66134] [CHKP] ICE: Unable to coalesce ssa_names 18 and 17 which are marked as MUST COALESCE

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri May 15 09:38:44 2015
New Revision: 223215

URL: https://gcc.gnu.org/viewcvs?rev=223215&root=gcc&view=rev
Log:
gcc/

PR middle-end/66134
* tree-chkp.c (chkp_get_orginal_bounds_for_abnormal_copy): New.
(chkp_maybe_copy_and_register_bounds): Don't copy abnormal copy.

gcc/testsuite/

PR middle-end/66134
* gcc.target/i386/mpx/pr66134.c: New test.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch segfaults in operand::gen_transform (gcc/hash-table.h:223)

[dougmencken at gmail dot com]

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

--- Comment #8 from Douglas Mencken  ---
Created attachment 35546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35546&action=edit
linker output for genmatch

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #1 from Peter Boyle  ---
Created attachment 35547
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35547&action=edit
unprocessed source code.

[Bug c++/66150] [C++11] cv-qualifiers on function types are not ignored.

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #2 from Daniel Krügler  ---
I tested various versions of gcc and couldn't find one where the test failed,
so I cannot find evidence for the assertion expressed by the submitter.

[Bug c++/66150] [C++11] cv-qualifiers on function types are not ignored.

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #3 from Harald van Dijk  ---
The static_assert fails with clang though. Perhaps you tested both GCC and
clang, and ended up reporting it on the wrong bug tracker?

[Bug fortran/66158] New: Use DO loop constraints for optimizing bounds checking

[tkoenig at gcc dot gnu.org]

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

Bug ID: 66158
   Summary: Use DO loop constraints for optimizing bounds checking
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

For the code

real, dimension(10) :: a
...
do i=1,10
  a(i) = a(i) + 3.
end do

we can prove that there is no possible bounds checking violation,
and the compiler should not insert code to do so. It is more tricky with

do i=1,10
  a(i)  = a(i) + 3.
  call foo(i)
end do

Sure, it is illegal to change i, but the whole point of bounds checking
is to catch buggy programs, so we should not eliminate the checks there.

Also, the code we generate ourselves, such as for inline matmul, we
can easily prove that no bounds check occurs.

If somebody does strange things like equivalencing a DO loop variable,
we should also be prepared for the worst.

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Paolo Carlini from comment #7)
> First blush I'm wondering if in this specific case we couldn't forward from
> dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
> regression and would allow us to adopt immediately Manuel' patch.

I could simply do

if (DECL_P(expr)) error("%qD") else error("%qE")

but I was trying to avoid %qE because I think pretty-printing user coded
expressions is something we should always avoid since they usually do not come
out as written by the user.

I would prefer to print:

error: invalid use of non-static member function 'void (Local::*ptr)()'

which tells the user that ->*ptr is a pointer to member-function.

[Bug target/66140] ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |4.9.3

--- Comment #2 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01396.html

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[ubizjak at gmail dot com]

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

--- Comment #41 from Uroš Bizjak  ---
The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it was
a GCC favicon.

[Bug target/66140] ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1

[dhowells at redhat dot com]

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

--- Comment #3 from dhowells at redhat dot com  ---
The compiler works now, thanks!

[Bug c++/66159] New: bogus warning for alias-declaration using elaborated-type-specifier

[redi at gcc dot gnu.org]

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

Bug ID: 66159
   Summary: bogus warning for alias-declaration using
elaborated-type-specifier
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct X { };

typedef struct ::X x1;

using x2 = struct ::X;


t.cc:5:21: warning: declaration ‘struct X’ does not declare anything
 using x2 = struct ::X;
 ^

The two forms should be equivalent.

[Bug fortran/50221] Allocatable string length fails with array assignment

[arjen.markus895 at gmail dot com]

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

Arjen Markus  changed:

   What|Removed |Added

 CC||arjen.markus895 at gmail dot 
com

--- Comment #4 from Arjen Markus  ---
I had a probably related failure with the following program using 4.9.2 under
Cygwin. 

The program:

! chk_alloc_string.f90 --
! Check if allocatable-length strings work in principle
!
program chk_alloc_string
implicit none

character(len=:), dimension(:), allocatable :: strings
integer :: i

allocate( character(10):: strings(1:3) )

!strings = [ "A", "C", "ABCDE", "V" ]
strings = [ character(len=4) :: "A", "C", "ABCDE", "V" ]

write(*,*) len(strings(1)), size(strings)
write(*,'(a)') strings
end program chk_alloc_string

The output:

   4   4
ACAV
CAV 
AV  
V

where I expected:
   4   4
A
C
ABCD
V

[Bug c++/66160] New: gcc-5.1.0 fails with "lambda-expression in unevaluated context" where gcc-4.9.2 succeeds

[tgard at opentext dot com]

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

Bug ID: 66160
   Summary: gcc-5.1.0 fails with "lambda-expression in unevaluated
context" where gcc-4.9.2 succeeds
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tgard at opentext dot com
  Target Milestone: ---

gcc-5.1.0 fails with "lambda-expression in unevaluated context" where gcc-4.9.2
succeeds

c++ -std=c++11 -c bug.cxx -o bug.o
bug.cxx:12:63: error: lambda-expression in unevaluated context
   typedef typename std::remove_reference::type
CharT;
   ^
bug.cxx:
#include 
typedef wchar_t CharT;
typedef std::string String;
template 
struct Example
{
struct ExampleProxy
{
typedef typename std::remove_reference::type CharT;
};
};

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /builds/gbgbuild/bld/gcc/gcc-5.1.0/configure
--prefix=/usr/local/gcc-5.1.0 --enable-languages=c,c++ --enable-threads
--enable-libsanitizer=no
Thread model: posix
gcc version 5.1.0 (GCC)

It seems possible the second of the patches here is incorrect:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01362.html

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[nszabolcs at gmail dot com]

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

--- Comment #2 from Szabolcs Nagy  ---
the posix standard does not seem to disallow \n in the replacement string so i
think freebsd sed should be fixed (or report the bug to the austingroup).

meanwhile i will prepare a fix for this in gcc.

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[emaste at freebsd dot org]

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

--- Comment #3 from Ed Maste  ---
> the posix standard does not seem to disallow \n in the replacement string so 
> i think freebsd sed should be fixed (or report the bug to the austingroup).

I can't find language that specifies sed must interpret escape sequences in the
replacement string. Anyway, it does seem like it would be a useful thing for
BSD sed to handle, but it's what we've got today. I also just confirmed that
sed on OS X behaves the same way.

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

--- Comment #42 from Frédéric Buclin  ---
(In reply to Uroš Bizjak from comment #41)
> The GCC bugzilla favicon now shows generic Bugzilla favicon. Previously, it
> was a GCC favicon.

Fixed

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

[LpSolit at netscape dot net]

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

Frédéric Buclin  changed:

   What|Removed |Added

  Attachment #35409|0   |1
is obsolete||

--- Comment #43 from Frédéric Buclin  ---
Created attachment 35548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35548&action=edit
GCC patch for 5.0, v4

With GCC favicon.

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[luca.stoppa at bbh dot com]

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

--- Comment #2 from Luca Stoppa  ---
I'm sorry, what do you mean with "don't do that"?

Can you please tell me whether c++11/14 with -fno-for-scope is supported?

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|major   |minor

--- Comment #1 from Jonathan Wakely  ---
Don't do that then.

[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-15
 Ever confirmed|0   |1

--- Comment #4 from Richard Earnshaw  ---
According to:

http://pubs.opengroup.org/onlinepubs/009695399/utilities/sed.html

[In a replacement] the meaning of a '\' immediately followed by any character
other than '&', '\', a digit, or the delimiter character used for this command,
is unspecified.

So I think that rules out all the normal escaped characters.

[Bug c++/66161] New: gcc silent about type incompleteness in error message

[tromey at gcc dot gnu.org]

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

Bug ID: 66161
   Summary: gcc silent about type incompleteness in error message
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

This source is distilled from a more complicated real-world
case that arose in https://bugzilla.mozilla.org/show_bug.cgi?id=1165184

class Base { };

class Incomplete; // : public Base

template
Base* blah_cast(T *arg) { return arg; }

Base* function(Incomplete *arg)
{
  return blah_cast(arg);
}


Compiling this yields:

pokyo. g++ -c s.cc
s.cc: In instantiation of ‘Base* blah_cast(T*) [with T = Incomplete]’:
s.cc:10:23:   required from here
s.cc:6:34: error: cannot convert ‘Incomplete*’ to ‘Base*’ in return
 Base* blah_cast(T *arg) { return arg; }
  ^


In this case it is obvious that Incomplete is an incomplete type.
However, in the real-world code this is far from obvious.

I think it would be handy if gcc printed something like
"note: type 'Incomplete' is incomplete at this point; missing include?".

[Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #5 from Ramana Radhakrishnan  ---
(In reply to vekumar from comment #4)
> (In reply to ktkachov from comment #3)
> > Venkat, are you planning to submit this patch to gcc-patches?
> > Also, does this mean we can remove the patterns that do arith+shift using
> > MULT rtxes? (like *adds__multp2)
> 
> Hi Kyrill, 
> 
> Yes I am planing to submit the patch. But before that I need to test by
> putting some assert and check if *adds__multp2 and similar
> patterns are not used anymore.

So this is a regression on GCC 6. what's holding up pushing this patch onto
gcc-patches@ ?

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ramana at gcc dot gnu.org

--- Comment #10 from Ramana Radhakrishnan  ---
assigned to Venkat.

[Bug tree-optimization/65068] Improve rewriting for address type induction variables in IVOPT

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/65225] [AArch64] Various aarch64_rtx_costs improvements

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-15
 CC||ramana at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Presumably yours ?

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
Bug 64835 depends on bug 66015, which changed state.

Bug 66015 Summary: align directives not propagated after __attribute__ 
((__optimize__ ("O2")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66015

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/66015] align directives not propagated after __attribute__ ((__optimize__ ("O2")))

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.2

--- Comment #5 from Ramana Radhakrishnan  ---
Fixed - presumably.

[Bug target/65225] [AArch64] Various aarch64_rtx_costs improvements

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #1)
> Presumably yours ?

Yes, and I think it's fixed. At least all the important aarch64 patches are in
with.
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00013.html is still waiting
though

[Bug target/64783] -march=armv8.1-a should be supported

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ramana at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mwahab at gcc dot 
gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
Assigned to Matthew as he's looking into this.

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The option works exactly as documented, and can be used freely with your own
code if you need to compile old code. Obviously if you include any code you
didn't write (such as standard library headers) then the option might cause
problems.

I don't think it is important to support that pre-standard dialect in C++11
library headers (it's definitely not "major" severity!)

Why do you need to use the option? Why can't you write standard-conforming C++?

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[luca.stoppa at bbh dot com]

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

--- Comment #4 from Luca Stoppa  ---
It is a very very very... old application written like 20 years ago.
Anyway, we'll try to remove that option from our build process.

Thanks for your answer.

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[luca.stoppa at bbh dot com]

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

--- Comment #5 from Luca Stoppa  ---
I think you can close this "bug".

[Bug c++/66150] [C++11] cv-qualifiers on function types are not ignored.

[eric at efcs dot ca]

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

Eric Fiselier  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Fiselier  ---
Woops... Everybody is right. GCC correctly handled this code. I'm not sure how
I came to think this was failing.

Sorry.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[andrey.vul at gmail dot com]

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

--- Comment #2 from Andrey V  ---
Replacing throw/try/catch with longjmp/setjmp for non-returning function exit,
like so:

#include 
#include 
#include 

pthread_once_t flag_ = PTHREAD_ONCE_INIT;

int call_count = 0;
jmp_buf catch_;

void func_() {
  printf("Inside func_ call_count %d\n", call_count);
  if (++call_count < 2)
longjmp(catch_, 1);
}
int main() {
  int signo;
  printf("Before calling call_once flag_: %d\n", *(int*)&flag_);
  signo = setjmp(catch_);
  if (!signo)
pthread_once(&flag_, func_);
  else
printf("Inside catch all excepton flag_: %d\n", *(int*)&flag_);
  printf("before the 2nd call to call_once flag_: %d\n", *(int*)&flag_);
  pthread_once(&flag_, func_);
}

, the invalid behavior isn't triggered.
It appears that pthread_once doesn't take kindly to exceptions in the
once_func.

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Paolo Carlini from comment #7)
> > First blush I'm wondering if in this specific case we couldn't forward from
> > dump_decl to dump_expr and just print ‘l->*ptr’. AFAICS, wouldn't be a
> > regression and would allow us to adopt immediately Manuel' patch.
> 
> I could simply do
> 
> if (DECL_P(expr)) error("%qD") else error("%qE")

Sure.

> but I was trying to avoid %qE because I think pretty-printing user coded
> expressions is something we should always avoid since they usually do not
> come out as written by the user.

In general, I know that ;)

> I would prefer to print:
> 
> error: invalid use of non-static member function 'void (Local::*ptr)()'
> 
> which tells the user that ->*ptr is a pointer to member-function.

But the error message is about l->*ptr, not about ptr per se. Thus I think that
in such cases using dump_type (or %qT at the call site) on TREE_TYPE (t)
(TREE_TYPE (expr)) should be Ok.

[Bug c++/66161] gcc silent about type incompleteness in error message

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
   Target Milestone|--- |5.0

--- Comment #1 from Jonathan Wakely  ---
This is fixed in 5.1

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

[Bug c++/13981] Give message about incomplete class that might be implicitly upcasted.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #9 from Jonathan Wakely  ---
*** Bug 66161 has been marked as a duplicate of this bug. ***

[Bug target/66049] [6 regression] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.

[vekumar at gcc dot gnu.org]

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

--- Comment #6 from vekumar at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #5)
> (In reply to vekumar from comment #4)
> > (In reply to ktkachov from comment #3)
> > > Venkat, are you planning to submit this patch to gcc-patches?
> > > Also, does this mean we can remove the patterns that do arith+shift using
> > > MULT rtxes? (like *adds__multp2)
> > 
> > Hi Kyrill, 
> > 
> > Yes I am planing to submit the patch. But before that I need to test by
> > putting some assert and check if *adds__multp2 and similar
> > patterns are not used anymore.
> 
> So this is a regression on GCC 6. what's holding up pushing this patch onto
> gcc-patches@ ?

GCC bootstrap and regression testing completed. I am doing SPEC 2006 INT run
just to make sure no surprises. will post it in a day or two.

[Bug ada/66162] New: Bug box compiling Ada.Finalization with -gnatc

[simon at pushface dot org]

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

Bug ID: 66162
   Summary: Bug box compiling Ada.Finalization with -gnatc
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---

Created attachment 35549
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35549&action=edit
Reproducer (to be gnatchopped)

I’ve built GCC 5.1.0 for arm-eabi (over x86_64-apple-darwin13), and while
adding finalization to my RTS I got the following bug box while compiling
a-finali.ads. This doesn’t happen when compiling fully (fails, of course):

$ gprbuild -c -u -f -P build_runtime.gpr a-finali.adb
build_runtime.gpr:1:09: warning: there are no Asm_Cpp sources in this project
arm-eabi-gcc -c -gnatpgn -gnatqQ -nostdinc -ffunction-sections -fdata-sections
-g -Og a-finali.ads
cannot generate code for file a-finali.ads (package spec)
gprbuild: *** compilation phase failed

FAILURE:

gprbuild -c -u -f -gnatc -p
-P/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/build_runtime.gpr
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/a-finali.ads
build_runtime.gpr:1:09: warning: there are no Asm_Cpp sources in this project
arm-eabi-gcc -c -gnatpgn -gnatqQ -nostdinc -ffunction-sections -fdata-sections
-g -Og -gnatc a-finali.ads
+===GNAT BUG DETECTED==+
| 5.1.0 (arm-eabi) Constraint_Error erroneous memory access|
| Error detected at a-finali.ads:70:4  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/system.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/a-finali.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/ada.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/s-finroo.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/a-tags.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/s-stoele.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/interfac.ads
/Users/simon/stm32f4-gnat-rts/stm32f429i-disco-rtos/adainclude/a-stream.ads

compilation abandoned
gprbuild: *** compilation phase failed

[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
(In reply to Laurent Chardon from comment #4)
> Thanks for the fix. If I may suggest a modification of the testcase in order
> to check also when there are no blanks between the & and !. I know in
> Fortran it shouldn't matter, but I don't see any harm in making sure... 

Good idea, will do. Just waiting for approval to commit.

[Bug tree-optimization/66163] New: [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

Bug ID: 66163
   Summary: [6 Regression] Not working Firefox built with LTO
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: hubicka at ucw dot cz
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

I've just built FF with LTO and -O3 and the browser is unable to render a
complex page. Unfortunately that's an error in MessageChannel, can't catch it
in gdb:

###!!! [Parent][MessageChannel] Error: Channel error: cannot send/recv

Starting from r222054, where following hunk is responsible for the error:

+  /* THIS argument of method is always non-NULL.  */
+  if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE
+  && arg == DECL_ARGUMENTS (current_function_decl)
+  && flag_delete_null_pointer_checks)
+return true;

As I added dump for cases where we return, it's more than 100k occurrences.
Any idea Honza how to isolate the issue?

Thanks,
Martin

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This really sounds like a bug in Firefox. This argument is not valid to be
null. Hmm, I suspect there should be an undefined sanitizer that should be
added to catch this case if not already there.

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #6 from Andreas Schwab  ---
If you want to compile old C++ you should use an old C++ standard.

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Andrew Pinski from comment #1)
> This really sounds like a bug in Firefox. This argument is not valid to be
> null. Hmm, I suspect there should be an undefined sanitizer that should be
> added to catch this case if not already there.

Well, I can try to update my Firefox tree to verify that the issue still
persists. I'm wondering how can call a class method having this == NULL?

Are you talking about ubsan?

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Paolo Carlini from comment #9)
> But the error message is about l->*ptr, not about ptr per se. 

Yes, but the location should already point to l->*ptr. I'm thinking in cases
such as:

struct Local
{
  void f();
  int z;
};

Local *l;
void (Local::*j)();
int Local::*i;
decltype((l->*j)) x;

where printing "invalid use of non-static member function 'void (Local::*j)()'"
seems more useful than "invalid use of non-static member function 'l->*j'" in
order to spot the typo (i vs j).

> that in such cases using dump_type (or %qT at the call site) on TREE_TYPE
> (t) (TREE_TYPE (expr)) should be Ok.

Yes!

@@ -1826,11 +1826,16 @@ invalid_nonstatic_memfn_p (tree expr, ts
   if (is_overloaded_fn (expr) && !really_overloaded_fn (expr))
 expr = get_first_fn (expr);
   if (DECL_NONSTATIC_MEMBER_FUNCTION_P (expr))
 {
   if (complain & tf_error)
-error ("invalid use of non-static member function");
+   {
+ if (DECL_P (expr))
+   error_at (loc, "invalid use of non-static member function %qD",
expr);
+ else
+   error_at (loc, "invalid use of non-static member function %qT",
TREE_TYPE (expr));
+   }
   return true;
 }
   return false;
 }


prints:

test.cc:10:17: error: invalid use of non-static member function ‘void
(Local::)()’
 decltype((l->*j)) x;
 ^

which looks fine to me, except for the column location, but that seems harder
to fix.

We could also print a "note: declared here" to be extra helpful, but I'll leave
that to whoever gets to finish this ;-)

[Bug tree-optimization/64454] optimize (x%5)%5

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
Author: glisse
Date: Fri May 15 17:34:15 2015
New Revision: 223221

URL: https://gcc.gnu.org/viewcvs?rev=223221&root=gcc&view=rev
Log:
2015-05-15  Marc Glisse  

PR tree-optimization/64454
gcc/
* match.pd ((X % Y) % Y, (X % Y) < Y): New patterns.
(-1 - A -> ~A): Remove unnecessary condition.
gcc/testsuite/
* gcc.dg/modmod.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/modmod.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug c++/66130] "invalid use of non-static member function" message could be clearer

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot com|
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #11 from Paolo Carlini  ---
Agreed, thanks Manuel. I can handle this, send the complete patch to the
mailing list for review. I think that in the second case it would be more
correct to tweak the error message a bit, and actually say "invalid use of
non-static member function of type %qT", instead of just "... function %qT".

[Bug tree-optimization/64454] optimize (x%5)%5

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Marc Glisse  ---
One last thing that would have been nice: in VRP, if the range of X is included
in [10,14], X%5 can be simplified to X-10. But it is probably not worth the
trouble.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
On Power, both glibc and AIX pthread_once behave the same way: i.e., they fail
to clear the once flag on exception.  The test case below mimics glibc's
pthread_once and demonstrates the root cause of the problem: the cancellation
handler is not invoked when an exception is thrown unless the
pthread_cleanup_push/pop macros are compiled in C++ code. Simply recompiling
glibc's pthread_once.c using a C++ compiler (and adding the apprpriate extern
"C" decoration) should fix it.

Until it's fixed, as a workaround, it seems that libstdc++ could clear the flag
when an exception is thrown before propagating it out of call_once.

$ cat t.c && gcc -O2 -Wall -c -fasynchronous-unwind-tables -g t.c && g++ -DMAIN
-O2 -Wall t.o -pthread t.c && ./a.out 
#include 
#include 

extern int n;

#if MAIN

extern "C" void foo () { throw 0; }
extern "C" void bar (void (*)());

int main () {
try {
bar (foo);
}
catch (...) {
printf ("caught exception: pthread cleanup handler %sinvoked\n",
n ? "" : "not ");
}

return n == 1 ? 0 : 1;
}

#else

int n;
#if __cplusplus
extern "C" {
#endif

static void cleanup (void *arg) { ++n; }

void bar (void (*pf)(void)) {
pthread_cleanup_push (cleanup, 0);
pf ();
pthread_cleanup_pop (0);
}

#if __cplusplus
}
#endif

#endif
caught exception: pthread cleanup handler not invoked

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[miyuki at gcc dot gnu.org]

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

--- Comment #12 from miyuki at gcc dot gnu.org ---
Author: miyuki
Date: Fri May 15 18:02:50 2015
New Revision: 223223

URL: https://gcc.gnu.org/viewcvs?rev=223223&root=gcc&view=rev
Log:
PR c/48956

gcc/c-family/
* c-common.c (int_safely_convertible_to_real_p): Define.
(unsafe_conversion_p): Check conversions involving complex types.
(conversion_warning): Add new warning message for conversions which
discard imaginary component.
* c-common.h: (enum conversion_safety): Add new enumerator for such
conversions.

gcc/testsuite/
* gcc.dg/Wconversion-complex-c99.c: New test.
* gcc.dg/Wconversion-complex-gnu.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wconversion-complex-c99.c
trunk/gcc/testsuite/gcc.dg/Wconversion-complex-gnu.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/64454] optimize (x%5)%5

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Marc Glisse from comment #12)
> One last thing that would have been nice: in VRP, if the range of X is
> included in [10,14], X%5 can be simplified to X-10. But it is probably not
> worth the trouble.

It might also be useful if the range is [0,10] for x%5 to be simplified down to
just "t = x-5; x>=5?t:x;"  And yes this shows up in some places; mainly dealing
with character digit to number conversions.

[Bug tree-optimization/64454] optimize (x%5)%5

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #13)
> It might also be useful if the range is [0,10] for x%5 to be simplified down
> to just "t = x-5; x>=5?t:x;"

(I assume you meant [0,9])
I agree, but the profitability is less obvious with branches/cmov.

> And yes this shows up in some places; mainly
> dealing with character digit to number conversions.

I expect one of the most common cases to be a loop that does x=(x+1)%5; at each
iteration (so x is always in [0,4]), which can be rewritten as if(++x==5)x=0.

Maybe we could open a new PR for those...

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[manu at gcc dot gnu.org]

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

--- Comment #13 from Manuel López-Ibáñez  ---
(In reply to Mikhail Maltsev from comment #12)

Great! Please do not forget to close the bug (using your @gcc.gnu.org account).
I leave the honor to you. Perhaps even worth it to add this to
https://gcc.gnu.org/gcc-6/changes.html ;)

[Bug c/48956] -Wconversion should warn when a complex value is assigned to a real result

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||miyuki at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #14 from Mikhail Maltsev  ---
> I leave the honor to you.
Thanks ;).
Fixed for GCC 6.

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[luca.stoppa at bbh dot com]

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

--- Comment #7 from Luca Stoppa  ---
Well, even if my production code is 20 years old, the example I have attached
isn't. It is valid c++11/14 code. 

Would you call something like this "old c++ code"?

#include 

int main()
{
  std::vector v{1,2,3,4,5,6,7,8};
  int sum = 0;
  for (auto &x : v )
sum += x;
  for (auto &x : v)
sum *= 2;

  return 0;
}

I don't think so. 
Anyway, you should at least add a small note into the documentation that this
doesn't work anymore with the new standard.

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa

[hiraditya at msn dot com]

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

--- Comment #6 from AK  ---
Your patch did fix the problem. Thanks!

[Bug middle-end/66164] New: Strange behaviour calling functions with float as parameter

[d.a.gonzalez.marquez at gmail dot com]

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

Bug ID: 66164
   Summary: Strange behaviour calling functions with float as
parameter
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d.a.gonzalez.marquez at gmail dot com
  Target Milestone: ---

Created attachment 35550
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35550&action=edit
Source code for reproduce the bug

The following bug is for x86 architecture on a i386 compilation: -m32

I took a code that is part of an implementation of the libc. In order to obtain
a new one with some changes. The problem was that I found a bug. The code is
easy to follow:

It makes calls in this order: main ---> AUXsin ---> __sinf  --->
__ieee754_rem_pio2f

int main() {
float ra = AUXsin(100); 
return 0;
}

float AUXsin(float x) {
  return __sinf(x);
}

float __sinf(float x)
{
float y[2],z=0.0;
int32_t n, ix;
n = __ieee754_rem_pio2f(x,y);
return (float)n;
}

int32_t __ieee754_rem_pio2f(float x, float *y)
{
y[0] = 0.0;
return 0;
}

When the function __ieee754_rem_pio2f tries to read the parameter y, it finds
that the stack is:

esp - 4 |  
esp + 0 | return addr 
esp + 4 | value x
esp + 8 | value x
esp + 12 | pointer to y

The problem was that the function __sinf store a double on the stack for the x
value. And, when the function tries to read the pointer to y, it reads a wrong
value.

I attached a zip with the code to test.

Thanks in advance,
David

[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
Yes, ubsan should have flag to check that for methods the THIS parameter is
non-NULL and that all REFERENCE_TYPE parameters are non-NULL, too. It should be
easy excercise to get implemented :)

[Bug c++/66165] New: vect_transform_slp_perm_load: vec out of range ?

[dcb314 at hotmail dot com]

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

Bug ID: 66165
   Summary: vect_transform_slp_perm_load: vec out of range ?
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 35551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35551&action=edit
gzipped C++ source code

The attached code, when compiled by gcc trunk dated 20150513
and with flag -O3, says this:

$ ../results/bin/g++ -c -O3 bug206.cc
renderers/agg/src/agg_curves.cpp: In member function ‘unsigned int
mapserver::curve3_inc::vertex(double*, double*)’:
renderers/agg/src/agg_curves.cpp:101:14: internal compiler error: Segmentation
fault
0xd8357f crash_signal
../../src/trunk/gcc/toplev.c:380
0xfe20ad vec::operator[](unsigned int)
../../src/trunk/gcc/vec.h:736
0xfe20ad vec::operator[](unsigned int)
../../src/trunk/gcc/vec.h:1202
0xfe20ad vect_transform_slp_perm_load(_slp_tree*, vec, gimple_stmt_iterator*, int, _slp_instance*, bool)
../../src/trunk/gcc/tree-vect-slp.c:3292
0xfe4218 vect_supported_load_permutation_p
../../src/trunk/gcc/tree-vect-slp.c:1419
0xfe4218 vect_analyze_slp_instance
../../src/trunk/gcc/tree-vect-slp.c:1826
0xfe55b6 vect_analyze_slp(_loop_vec_info*, _bb_vec_info*, unsigned int)
../../src/trunk/gcc/tree-vect-slp.c:1896
0xfe5a63 vect_slp_analyze_bb_1
../../src/trunk/gcc/tree-vect-slp.c:2430
0xfe5a63 vect_slp_analyze_bb(basic_block_def*)
../../src/trunk/gcc/tree-vect-slp.c:2560
0xfe8eb2 execute
../../src/trunk/gcc/tree-vectorizer.c:662
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$

Line tree-vect-slp.c:3292 is

  i = SLP_TREE_LOAD_PERMUTATION (node)[k];

[Bug libstdc++/66157] bits/random.tcc compiler error when using -fno-for-scope

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I already said that it works fine with C++ code *you* write, in any standard
mode. But don't expect everyone else's C++ code (including standard library
headers) to follow the old pre-1998 rules.

If you use -fno-for-scope you are no longer compiling standard C++, you are
compiling some non-standard dialect. That has always been true, it's not new
for C++11.

[Bug rtl-optimization/66166] New: wrong code at -O1 and above on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 66166
   Summary: wrong code at -O1 and above on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux at -O1 and
above in both 32-bit and 64-bit modes. 

It also affects all earlier versions of GCC since at least 4.6. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC) 
$ 
$ gcc-trunk -O0 small.c; ./a.out
$ 
$ gcc-trunk -O1 small.c
$ ./a.out
Aborted (core dumped)
$ 


---


int a, b, e, c = 1;
const int d = 0;

int
fn1 (int p)
{
  if (a)
c = 0;
  for (; e < 2; e++)
{
  b = p;
  if (c)
p = 0;
}
  return 0;
}

int
main ()
{
  (a = 1) < ((fn1 (8) > 0) >= d);

  if (b != 8)
__builtin_abort ();

  return 0;
}

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-15
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Thanks, Martin. So maybe something like this:

--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -726,7 +738,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __set_once_functor_lock_ptr(&__functor_lock);
 #endif

+#ifdef __powerpc__
+  int __e;
+  __try {
+   __e = __gthread_once(&__once._M_once, &__once_proxy);
+  } __catch(...) {
+ __once._M_once = once_flag{}._M_once;
+ __throw_exception_again;
+  }
+#else
   int __e = __gthread_once(&__once._M_once, &__once_proxy);
+#endif

 #ifndef _GLIBCXX_HAVE_TLS
   if (__functor_lock)

[Bug ada/66167] New: Scalar Storage Order attribute has no effect on 2 dimensional arrays

[daniel.merrill at psware dot com]

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

Bug ID: 66167
   Summary: Scalar Storage Order attribute has no effect on 2
dimensional arrays
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.merrill at psware dot com
  Target Milestone: ---

running on a little endian machine with a scalar storage order of
High_Order_First does not byte swap the values when accessed through a 2
dimensional array i.e. type foo is array (foo_range, bar_range) of float. I can
provide an example program if that will help reproduce the issue. Thanks.

[Bug rtl-optimization/66168] New: ICE at -O3 in elimination_costs_in_insn, at reload1.c:3677

[su at cs dot ucdavis.edu]

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

Bug ID: 66168
   Summary: ICE at -O3 in elimination_costs_in_insn, at
reload1.c:3677
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.

This is a regression from 5.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150515 (experimental) [trunk revision 223211] (GCC) 
$ 
$ gcc-trunk -O2 -c small.c 
$ gcc-5.1 -O3 -c small.c
$ 
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:15:1: internal compiler error: in elimination_costs_in_insn, at
reload1.c:3677
 }
 ^
0xa660dc elimination_costs_in_insn
../../gcc-trunk/gcc/reload1.c:3674
0xa669aa calculate_elim_costs_all_insns()
../../gcc-trunk/gcc/reload1.c:1671
0x95637e ira_costs()
../../gcc-trunk/gcc/ira-costs.c:2238
0x9503c6 ira_build()
../../gcc-trunk/gcc/ira-build.c:3459
0x948714 ira
../../gcc-trunk/gcc/ira.c:5253
0x948714 execute
../../gcc-trunk/gcc/ira.c:5545
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


---


int a, b;

void
fn1 ()
{
  for (;;)
{
  for (b = 0; b < 3; b++)
{
  char e[2];
  char f = e[1];
  a ^= f ? 1 / f : 0; 
}
}
}

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #4)
> Thanks, Martin. So maybe something like this:

This happens on almost all non-x86 machines.  I tested it on aarch64 and we had
the same failure as powerpc.

[Bug ada/66167] Scalar Storage Order attribute has no effect on 2 dimensional arrays

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-15
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Confirmed, the implementation was not fully updated when the effect on nested
aggregates was reversed wrt the original specification...

[Bug ada/66167] Scalar Storage Order attribute has no effect on 2 dimensional arrays

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #2 from Eric Botcazou  ---
Fixing.

[Bug c++/66169] New: [c++-concepts] constraints on constructor are jammed with inherited copy/move constructors

[yingpo.liao at gmail dot com]

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

Bug ID: 66169
   Summary: [c++-concepts] constraints on constructor are jammed
with inherited copy/move constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yingpo.liao at gmail dot com
  Target Milestone: ---

[Bug middle-end/66164] Strange behaviour calling functions with float as parameter

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The program calls functions (__sinf and __ieee754_rem_pio2f) without declaring
them first.  Compiling with the -Wall option highlights the problem.  Once the
functions are declared before called the program runs succesffully to
completion.

[Bug c++/66169] [c++-concepts] constraints on constructor are jammed with inherited copy/move constructors

[yingpo.liao at gmail dot com]

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

--- Comment #1 from Ying-Po Liao  ---
The following example shows a Concept applied to the constructor of class A.
The compiler (r223061) will generate internal compiler error if A's subclass C
implements default behaviors of copy/move constructors in which base
constructor forwarding is placed. Note that this example only shows a copy
constructor version. However, it will work for any of these cases:

1) C's copy/move constructors do not forward to base class.
2) C's copy/move constructors are deleted.
3) Concept does not use "decltype()" to check things.

$ svn info

Path: .
Working Copy Root Path:
/Users/liao/Downloads/gcc-branch-c++-concepts/c++-concepts
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Relative URL: ^/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 223175
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 223061
Last Changed Date: 2015-05-12 07:21:04 -0500 (Tue, 12 May 2015)

$ cat main.cpp

#include 

template 
  concept bool Concept()
  {
return requires( R r ) {
  std::begin(r);
  std::end(r);
  requires __is_same_as( 
decltype(std::begin(r)), decltype(std::end(r)) );
};
  }

struct A
{
  A() = default;
  A( const A& ) = default;

  template 
explicit A( R&& r )
{}
};

struct C : A
{
  C() = default;
  C( const C& ) = default;
};

int main()
{
  C c;
  return 0;
}

$ g++ -std=c++1z main.cpp -o main

main.cpp: In substitution of ‘template  requires
predicate((Concept)()) A::A(R&&)  [with R = const A&]’:
main.cpp:24:8:   required from here
main.cpp:20:14: internal compiler error: in conjoin_constraints, at
cp/constraint.cc:89
 explicit A( R&& r )
  ^

main.cpp:20:14: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/66166] wrong code at -O1 and above on x86_64-linux-gnu

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
GCC 4.0 also aborts.

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[fxcoudert at gcc dot gnu.org]

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

--- Comment #21 from Francois-Xavier Coudert  ---
(In reply to Lawrence Velázquez from comment #20)
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01377.html

Quick review of the patch:

 - version_as_modern_macro(): you implement a specific behavior for major <= 9,
but it's necessary at all. Having major <= 9 is simply impossible (and Apple's
compiler rejects it). I'd say let's make things simpler anduse a format of
"%02lu%02lu%02lu" and always be 6 characters long.

 - version_as_legacy_macro(): same issue. Why do we need to handle major <= 9?
You have rejected this possibility in macosx_version_as_macro() anyway.
Simplify here also.

 - throughout the patch, writing things like "(int) sizeof "" - 1" or "char
result[sizeof ""]" when you could write "4" and "char result[4]" means
harder code to read, and no real benefit in terms of security or
maintainability (since you're duplicating stuff anyway).

 - in macosx_version_as_macro(), you say "Allow for future major numbers
greater than 10", but you actually reject them (and that's OK). Adjust the
comment.

 - later, "version_array[MAJOR] == 10" is guaranteed. Remove it.

 - in parse_version(), the string passed is guaranteed to be non-NULL. No need
to test it.

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org
  Known to fail||5.1.0

--- Comment #22 from mrs at gcc dot gnu.org  ---
Though I approved it on list, you should feel free to update with the review
points others have and post that version if you wish.

[Bug rtl-optimization/66166] wrong code at -O1 and above on x86_64-linux-gnu

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #2 from Mikhail Maltsev  ---
Why should not it abort? Suppose that RHS of the outermost comparison operator
is evaluated first. Then c = 1, e = 0, a = 0, p = 8. In the first iteration of
the loop p is assigned value 0, and b gets the same value. At -O0 LHS is
probably evaluated first (the order of evaluation is unspecified).

[Bug rtl-optimization/66166] wrong code at -O1 and above on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
No sequence point in assignment of a and the function call so it is
unspecified.  Which means both cases are "correct".

[Bug ipa/66004] [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/operators/values.cc

[hp at gcc dot gnu.org]

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

--- Comment #3 from Hans-Peter Nilsson  ---
Something supposedly very good happened recently, because:
r223225 18369501023

I'll just have to find out what caused that 50% cut!  The test-case is
unchanged.
If the cause is related to inlining heuristics, I'll close this PR for sure.

[Bug middle-end/66164] Strange behaviour calling functions with float as parameter

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-16
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Try compiling with -W -Wall because I think you are getting some undefined
behavior due to not having prototypes for some of the functions.

[Bug c++/66170] New: Bogus warning with -Wsign-conversion when using static_cast on an int

[yaghmour.shafik at gmail dot com]

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

Bug ID: 66170
   Summary: Bogus warning with -Wsign-conversion when using
static_cast on an int
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yaghmour.shafik at gmail dot com
  Target Milestone: ---

Given the following code:

#include 

int main()
{   
int length = 0;
size_t n;

n = static_cast(length) ; // Line 8
n = static_cast(length) * sizeof(int) ;
n = sizeof(int) * static_cast(length) ;   
n = sizeof(int) * static_cast(length) ; // Line 11

n = sizeof(int) * static_cast(length) ;   // Line 13
}

building with gcc 4.9.2 or greater using the following command line:

  g++ -Wsign-conversion 

generates the following warning on line 13:

  warning: conversion to 'long unsigned int' from 'int' may change the sign of
the result [-Wsign-conversion]

This looks like an error to me, the documentation for -Wsign-conversion says:

  An explicit cast silences the warning

and line 8 to line 11 are very similar but do not generate any warning.

Optimization level does not make a difference and -Wall -Wextra does not
indicate additional issues.

[Bug target/66171] New: [6 Regression]: gcc.target/cris/biap.c

[hp at gcc dot gnu.org]

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

Bug ID: 66171
   Summary: [6 Regression]: gcc.target/cris/biap.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: vekumar at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf

Before and including r222872, this test passed.
After and including r222878, this test fails:

Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.target/cris/cris.exp ...
FAIL: gcc.target/cris/biap.c scan-assembler addi
FAIL: gcc.target/cris/biap.c scan-assembler-not lsl

A qualified guess is that this is due to r222874.
See also PR37939, referenced in the test-case.

I'm logging this as target-specific and not a middle-end bug, as the canonical
RTL *is* shift, outside of a MEM.  More than one pattern to edit: besides
changing that multiplication to a shift that need to be taken care of with the
canonically stricter RTL, like the side-effect pattern has to be duplicated as
noted 6+ years ago in
.

(CC as FYI only.)

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[vq at larryv dot me]

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

--- Comment #23 from Lawrence Velázquez  ---
(In reply to Francois-Xavier Coudert from comment #21)
>  - version_as_legacy_macro(): same issue. Why do we need to handle major <=
> 9? You have rejected this possibility in macosx_version_as_macro() anyway.
> Simplify here also.

I don't see anything in version_as_legacy_macro() that specifically deals with
major <= 9. Could you point me to the offending code?

[Bug rtl-optimization/66168] ICE at -O3 in elimination_costs_in_insn, at reload1.c:3677

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-16
 CC||miyuki at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Mikhail Maltsev  ---
Confirmed. Started with r223113.

[Bug c++/66153] Internal compiler error in nested template function

[paboyle at ph dot ed.ac.uk]

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

--- Comment #2 from Peter Boyle  ---
p.s. in case anyone is wondering this recursive construct is 
a simplification of a construct I'm using in an expression
template framework, so this is not simply a convoluted test case.

Rather, I distilled the fail down to a small case from a much larger code.

[Bug c++/66173] New: -fno-threadsafe-statics suppresses guard functions but not guard variables

[eleventen at gmail dot com]

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

Bug ID: 66173
   Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eleventen at gmail dot com
  Target Milestone: ---

Created attachment 35553
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35553&action=edit
Source file demonstrating that the guard variable isn't suppressed.

The use of the -fno-threadsafe-statics eliminates the function references to
the guard functions,

__cxa_guard_acquire
__cxa_guard_release


but it doesn't eliminate the variables used to guard the initialization.  A
compiled version of the attached file using the g++ command line therein
generated no references to the guard functions, but the guard variable remains.

# nm -C guard | grep guard
00600a88 b guard variable for f()::a

[Bug c++/66172] New: -fno-threadsafe-statics suppresses guard functions but not guard variables

[eleventen at gmail dot com]

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

Bug ID: 66172
   Summary: -fno-threadsafe-statics suppresses guard functions but
not guard variables
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eleventen at gmail dot com
  Target Milestone: ---

The use of the -fno-threadsafe-statics eliminates the function references to
the guard functions,

__cxa_guard_acquire
__cxa_guard_release


but it doesn't eliminate the variables used to guard the initialization.  A
compiled version of the attached file using the g++ command line therein
generated no references to the guard functions, but the guard variable remains.

# nm -C guard | grep guard
00600a88 b guard variable for f()::a

--- Comment #1 from Marc Singer  ---
I neglected to include the version information:

# g++ --version
g++ (Debian 4.9.2-10) 4.9.2

[Bug c++/66173] -fno-threadsafe-statics suppresses guard functions but not guard variables

[eleventen at gmail dot com]

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

--- Comment #1 from Marc Singer  ---
I neglected to include information about the version of the compiler.  This is
a 64 bit compiler on amd64.

# g++ --version
g++ (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/66165] [6 Regression] vect_transform_slp_perm_load: vec out of range ?

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.2, 5.1.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2015-05-16
  Component|c++ |tree-optimization
 CC||miyuki at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|vect_transform_slp_perm_loa |[6 Regression]
   |d: vec out of range ?   |vect_transform_slp_perm_loa
   ||d: vec out of range ?

--- Comment #1 from Mikhail Maltsev  ---
Confirmed. Reduced testcase:

void foo(double *d, double *a)
{
d[0] += d[2];
d[1] += d[3];
d[2] += d[4];
d[3] += d[5];
a[0] = d[0];
a[1] = d[1];
}

Started with r222846.

[Bug c++/66172] -fno-threadsafe-statics suppresses guard functions but not guard variables

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
You need the variable even without thread safe ones because calling the
function twice means it gets initlized only once rather twice. There is no
other way around this because the variable only gets initialized if the
function is called.

[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Is there interesting in further backporting?

If not, I would close this as fixed.

[Bug fortran/55839] Inefficiency with array constructor

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #3 from Thomas Koenig  ---
No time at the moment, working on other stuff.

[Bug c++/66172] -fno-threadsafe-statics suppresses guard functions but not guard variables

[eleventen at gmail dot com]

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

--- Comment #3 from Marc Singer  ---
I've come to the same conclusion.  My hope was that I could eliminate the guard
and force the compiler to initialize block scoped statics at the start of
execution.  It looks like the standard stands in the way of this
simplification.

[Bug fortran/25714] concat of strings create an extra temporary variable

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #6 from Thomas Koenig  ---
Working on other stuff, unassigning for now.

[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #7 from Thomas Koenig  ---
Unassignming for the moment.