[Bug fortran/66495] [5 Regression] Issue with same name for embedded function

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Dominique d'Humieres from comment #1)
> The ICE appeared between revisions r218570 (2014-12-10, no ICE) and r218658
> (2014-12-12, ICE), likely r218627 (pr44054) or a related commit.
> 
> This has been fixed between r223447 (2015-05-20, ICE) and r224148
> (2015-06-05, no ICE), likely r223614.

I don't have much free time to work on GCC. It would extremely useful if you
could tell me what exactly is causing the ICE. I may then figure out how it got
fixed in GCC 6 and whether it is possible to backport the fix. Unfortunately,
the changes in GCC 6 required some changes in the common diagnostics part that
I doubt are suited for backporting wholesale.

[Bug fortran/66495] [5 Regression] Issue with same name for embedded function

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  ---
Actually, looking at the output, it is surprising that this is caused by my
changes, since GCC 5 did not change errors that generate two locations. Perhaps
that is precisely the problem: The error "Procedure..." should use gfc_error_1
instead of gfc_error?

[Bug pch/65550] [4.8/4.9 Regression] ICE (segfault) with pch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
I suppose this is backportable to both 4.8 and 4.9.

[Bug target/62642] [4.8/4.9 Regression] x86 rdtsc is moved through barrier

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Vlad, do you think this is backportable to 4.9 and 4.8?

[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin13.3.0
   Host||x86_64-apple-darwin13.3.0
  Build||x86_64-apple-darwin13.3.0

--- Comment #1 from Jonathan Wakely  ---
configure:3462: /Users/jieyuandai/src/build/gcc/./gcc/xgcc
-B/Users/jieyuandai/src/build/gcc/./gcc/
-B/usr/local/x86_64-apple-darwin13.3.0/bin/
-B/usr/local/x86_64-apple-darwin13.3.0/lib/ -isystem
/usr/local/x86_64-apple-darwin13.3.0/include -isystem
/usr/local/x86_64-apple-darwin13.3.0/sys-include-o conftest -g -O2  
conftest.c  >&5
: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3465: $? = 1
configure:3653: checking for suffix of object files
configure:3675: /Users/jieyuandai/src/build/gcc/./gcc/xgcc
-B/Users/jieyuandai/src/build/gcc/./gcc/
-B/usr/local/x86_64-apple-darwin13.3.0/bin/
-B/usr/local/x86_64-apple-darwin13.3.0/lib/ -isystem
/usr/local/x86_64-apple-darwin13.3.0/include -isystem
/usr/local/x86_64-apple-darwin13.3.0/sys-include-c -g -O2  conftest.c >&5
: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3679: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3693: error: in
`/Users/jieyuandai/src/build/gcc/x86_64-apple-darwin13.3.0/libgcc':
configure:3696: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Less artificially looking testcase.

/* PR middle-end/63608 */

typedef long T;
typedef unsigned long U;
unsigned long a;

unsigned long
foo (int b)
{
  T c = 0;
  const U d = 2248593032UL;
  a = (c = +d) | (~4L & ~b);
  return c;
}

Testing the backport now, seems fold-const.c pretty much assumes everywhere
that if argN is INTEGER_CST, then argN == opN, but the missing NON_LVALUE_EXPR
case of course breaks this.  So, fixing it at the spots that just pass argN if
it is known to be INTEGER_CST is not really doable.
If the patch would be too dangerous (most likely is not), then another option
is just to fold NON_LVALUE_EXPR of INTEGER_CST to the INTEGER_CST.

[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-06-12
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Duplicate of pr66448? Which revision are you using?

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
There is some minimal support in -fsanitize=vptr, but that catches only
destructed objects with virtual methods (by disabling the clobbers and clearing
the vptr).
Other than that, this is something that is more in line with the address
sanitizer (which also has very limited support for file scope objects, but only
makes the objects unavailable during construction of each TU, so catches
constructor ordering issues within a single TU).  Other than that, the concept
of making a chunk of memory available at certain point and unavailable at
another point is something -fsanitize=address is able to do.  The question is
what can be done with operator new, e.g. if you have a char buffer in some
class and construct something else at that spot, then destructing it; reading
those bytes afterwards is supposedly UB, but storing there something say with
memcpy shouldn't be invalid.

[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  ---
Author: ramana
Date: Fri Jun 12 09:49:41 2015
New Revision: 224411

URL: https://gcc.gnu.org/viewcvs?rev=224411&root=gcc&view=rev
Log:
Use atomics in guard.cc.

This provides proper definitions for _GLIBCXX_READ_MEM_BARRIER and
_GLIBCXX_WRITE_MEM_BARRIER, rewrites the guards in terms of proper
atomic extensions and removes internal uses of
_GLIBCXX_READ_MEM_BARRIER and _GLIBCXX_WRITE_MEM_BARRIER and replaces
them with equivalent atomics.

2015-06-12  Ramana Radhakrishnan  

PR target/66200
PR c++/66192
* * config/cpu/generic/atomic_word.h (_GLIBCXX_READ_MEM_BARRIER):
Define
(_GLIBCXX_WRITE_MEM_BARRIER): Likewise
* include/bits/shared_ptr_base.h: Use ACQ_REL barrier.
* include/ext/atomicity.h: Likewise.
* include/tr1/shared_ptr.h: Likewise.
* libsupc++/guard.cc (__test_and_acquire): Rewrite with atomics.
Update comment.
(__set_and_release): Likewise.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc (test01): Adjust for
line numbers.
* testsuite/20_util/shared_ptr/cons/void_neg.cc: Likewise.
* testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc:
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/cpu/generic/atomic_word.h
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
trunk/libstdc++-v3/include/ext/atomicity.h
trunk/libstdc++-v3/include/tr1/shared_ptr.h
trunk/libstdc++-v3/libsupc++/guard.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc

[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

[ramana at gcc dot gnu.org]

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

--- Comment #6 from Ramana Radhakrishnan  ---
Author: ramana
Date: Fri Jun 12 09:49:41 2015
New Revision: 224411

URL: https://gcc.gnu.org/viewcvs?rev=224411&root=gcc&view=rev
Log:
Use atomics in guard.cc.

This provides proper definitions for _GLIBCXX_READ_MEM_BARRIER and
_GLIBCXX_WRITE_MEM_BARRIER, rewrites the guards in terms of proper
atomic extensions and removes internal uses of
_GLIBCXX_READ_MEM_BARRIER and _GLIBCXX_WRITE_MEM_BARRIER and replaces
them with equivalent atomics.

2015-06-12  Ramana Radhakrishnan  

PR target/66200
PR c++/66192
* * config/cpu/generic/atomic_word.h (_GLIBCXX_READ_MEM_BARRIER):
Define
(_GLIBCXX_WRITE_MEM_BARRIER): Likewise
* include/bits/shared_ptr_base.h: Use ACQ_REL barrier.
* include/ext/atomicity.h: Likewise.
* include/tr1/shared_ptr.h: Likewise.
* libsupc++/guard.cc (__test_and_acquire): Rewrite with atomics.
Update comment.
(__set_and_release): Likewise.
* testsuite/20_util/shared_ptr/cons/43820_neg.cc (test01): Adjust for
line numbers.
* testsuite/20_util/shared_ptr/cons/void_neg.cc: Likewise.
* testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc:
Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/cpu/generic/atomic_word.h
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
trunk/libstdc++-v3/include/ext/atomicity.h
trunk/libstdc++-v3/include/tr1/shared_ptr.h
trunk/libstdc++-v3/libsupc++/guard.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/void_neg.cc
   
trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820_neg.cc

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org
Version|4.5.0   |6.0

--- Comment #6 from alalaw01 at gcc dot gnu.org ---
Same problem on AArch64 (at -O3). We've decided the shift is to be done on
integers, widening the arguments and then truncating, before we hit the
vectorizer:

  int i;
  short unsigned int _4;
  int _5;
  int _8;
  short unsigned int _9;
  int pretmp_18;
  unsigned int ivtmp_21;
  unsigned int ivtmp_22;

  :
  pretmp_18 = (int) j_6(D);

  :
  # i_14 = PHI 
  # ivtmp_22 = PHI 
  _4 = b[i_14];
  _5 = (int) _4;
  _8 = _5 << pretmp_18;
  _9 = (short unsigned int) _8;
  a[i_14] = _9;
  i_11 = i_14 + 1;
  ivtmp_21 = ivtmp_22 - 1;
  if (ivtmp_21 == 0)

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  ---
I still see

FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O0  -fnext-runtime
(test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O0 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O1  -fnext-runtime
(test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O1 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2  -fnext-runtime
(test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O3 -fomit-frame-pointer
 -fnext-runtime (test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O3
-fomit-frame-pointer  -fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O3 -g  -fnext-runtime
(test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O3 -g 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -Os  -fnext-runtime
(test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -Os 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2 -flto
-flto-partition=none  -fnext-runtime (test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2 -flto
-flto-partition=none  -fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2 -flto 
-fnext-runtime (test for excess errors)
UNRESOLVED: obj-c++.dg/torture/strings/const-cfstring-1.mm   -O2 -flto 
-fnext-runtime compilation failed to produce executable

with the patches in comments 17 and 20. What am I missing?

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to alalaw01 from comment #6)
> Same problem on AArch64 (at -O3). We've decided the shift is to be done on
> integers, widening the arguments and then truncating, before we hit the
> vectorizer:

This is needed for correctness due to c/c++ promotion rules. 

> 
>   int i;
>   short unsigned int _4;
>   int _5;
>   int _8;
>   short unsigned int _9;
>   int pretmp_18;
>   unsigned int ivtmp_21;
>   unsigned int ivtmp_22;
> 
>   :
>   pretmp_18 = (int) j_6(D);
> 
>   :
>   # i_14 = PHI 
>   # ivtmp_22 = PHI 
>   _4 = b[i_14];
>   _5 = (int) _4;
>   _8 = _5 << pretmp_18;
>   _9 = (short unsigned int) _8;
>   a[i_14] = _9;
>   i_11 = i_14 + 1;
>   ivtmp_21 = ivtmp_22 - 1;
>   if (ivtmp_21 == 0)

[Bug tree-optimization/66510] [6 Regression] gcc.target/arm/pr53636.c FAILs after r224221

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
FTR, r224221 also caused following testsuite FAIL for x86:

FAIL: gcc.target/i386/pr61403.c scan-assembler blend

[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #24)
> I still see

> with the patches in comments 17 and 20. What am I missing?

IIRC, the patch at comment #17 includes the original "lazy creation" of the
external ref. which breaks objc++.

The DWARF fixes are now in trunk, and I have bootstrapped 244409 + comment #20
on darwin12 and x86-64-linux .. so should be posting it soon.

[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 12 10:26:05 2015
New Revision: 224415

URL: https://gcc.gnu.org/viewcvs?rev=224415&root=gcc&view=rev
Log:
PR libstdc++/66464
* src/c++11/codecvt.cc (codecvt_utf16_base::do_max_length):
Return 4 not 3.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/codecvt.cc

[Bug c++/66519] New: [C++14] ICE when using decltype to detect callable return type during SFINAE

[krzysztof.sinica at gmail dot com]

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

Bug ID: 66519
   Summary: [C++14] ICE when using decltype to detect callable
return type during SFINAE
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysztof.sinica at gmail dot com
  Target Milestone: ---

Created attachment 35769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35769&action=edit
Case source code

g++ fails to compile the attached source file in the '-std=c++14' mode. clang
3.6.0 works just fine and generates executable with expected behaviour.

GCC version: g++-5 (Ubuntu 5.1.0-0ubuntu11~14.04.1) 5.1.0

[Bug bootstrap/66508] Attempt to Compile gcc-6.0 on OSX 10.9.4 cause segmentation fault

[youfan.noey at gmail dot com]

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

--- Comment #3 from Fan You  ---
(In reply to Dominique d'Humieres from comment #2)
> Duplicate of pr66448? Which revision are you using?

Just updated and tried again, get the same result.

Revision: 224410

After changing

diff --git a/gcc/passes.c b/gcc/passes.c
index d3ffe33..1bc8a36 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -332,7 +332,7 @@ rest_of_decl_compilation (tree decl,
   */
   && !decl_function_context (decl)
   && !current_function_decl
-
+  && DECL_SOURCE_LOCATION (decl) != BUILTINS_LOCATION
   && !decl_type_context (decl))
 (*debug_hooks->early_global_decl) (decl);
 }

I get similar error as pr66448 

/Users/jieyuandai/src/gcc/gcc/dwarf2out.c:5693:1: error: ‘void
check_die(dw_die_ref)’ defined but not used [-Werror=unused-function]
 check_die (dw_die_ref die)
 ^
cc1plus: all warnings being treated as errors

Retry build with gcc-4.9.2 get the same results.

[Bug c++/66519] [C++14] ICE when using decltype to detect callable return type during SFINAE

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-12
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.2, 5.1.0, 6.0

[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 12 11:22:01 2015
New Revision: 224417

URL: https://gcc.gnu.org/viewcvs?rev=224417&root=gcc&view=rev
Log:
PR libstdc++/66464
* src/c++11/codecvt.cc (codecvt_utf16_base::do_max_length):
Return 4 not 3.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/src/c++11/codecvt.cc

[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Leo Carreon from comment #2)
> Just clarifying that my comments are to do with codecvt_utf16 and
> codecvt_utf8.
> 
> The way I understand it, codecvt_utf16 should be converting
> between UTF-16 and UCS-4.  UTF-16 uses 2 bytes for characters in the BMP
> (characters in the range 0x to 0x) and 4 bytes (surrogate pairs) for
> characters above the BMP (0x01 to 0x10).  UCS-4 uses 4 byte values. 
> Therefore, codecvt_utf16::max_length() should be returning 4 if
> the BOM is not taken into account.

Yes, that's now fixed.

> codecvt_utf8 converts between UTF-8 and UCS-4.  UTF-8 can use up
> to 4 bytes for characters up to the range 0x10.  Therefore,
> codecvt_utf8::max_length() should be returning 4 if the BOM is not
> taken into account.
> 
> As I said in my previous post, I'm not sure if the BOM should be accounted
> for in max_length().

I've raised that question with the C++ committee.

>  If I'm not mistaken, the purpose of this function is
> to allow a user to estimate how many bytes are required to fit a UCS-4
> string when converted to either UTF-16 or UTF-8.  And my guess, the BOM can
> be taken into account separately when doing the estimation.  For example,
> when wstring_convert estimates the length of the std::string to be generated
> by wstring_convert::to_bytes().  It should be the number of UCS-4 characters
> multiplied by max_length() and then add the size of the BOM if required. 
> The resulting std::string can be resized after the conversion to eliminate
> the unused bytes.

I believe that's the usual use case for max_length, and agree it's better to
calculate N * max_length() + length(BOM), rather than have max_length() include
the BOM, however the way max_length() is specified in the standard does suggest
it should be including the BOM. We'll discuss it in the committee and process
it as a defect report against the standard if necessary.

> Note that the comment you mentioned in your reply probably only applies to
> codecvt_utf8_utf16 which converts between UTF-8 and UTF-16 directly without
> going thru the UCS-4 conversion.

Agreed.

[Bug libstdc++/66417] std::codecvt_utf16 generates incorrect output

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Leo Carreon from comment #5)
> Is this fix going to be applied to Fedora 22?

Yes, I expect so, and for your other reports too.

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[alalaw01 at gcc dot gnu.org]

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

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Is there a case where the result is different with vs without all the
extending/truncating?

It seems we should need the extending/truncating on vectors exactly iff we need
it on scalars?

[Bug pch/65550] [4.8/4.9 Regression] ICE (segfault) with pch

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On June 12, 2015 9:55:30 AM GMT+02:00, "jakub at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550
>
>Jakub Jelinek  changed:
>
>   What|Removed |Added
>
>   CC||jakub at gcc dot gnu.org
>
>--- Comment #9 from Jakub Jelinek  ---
>I suppose this is backportable to both 4.8 and 4.9.

Yes.  I must have missed it because the bug is not assigned to me...  Let's see
if I can get to it before the RC

gcc-bugs@gcc.gnu.org

[fkastrati at gmail dot com]

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

Bug ID: 66520
   Summary: bad code generated code for branches with single &
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastrati at gmail dot com
  Target Milestone: ---

consider the following code snippet (c++):

void ampamp(int x, int y) {
  if (x < 3 && y > 10 ) 
printf("%d%d", x, y);
}

void amp(int x, int y) {
  if ((x < 3) & (y > 10) ) 
printf("%d%d", x, y);
}


the assembly code generated by g++ (all versions I tested with  optimization
flag `-O3'), is not optimal (see the link on the bottom of this message).
Basically, for both methods, the generated assembly code is identical. For the
method "amp" (with single `&') there should be generated only one jump, as
branch misprediction penalty is very high otherwise!

As a side note: the code by intel's  compiler (ICC) is however generating
optimal code for such scenarios, at least for versions icc13, and icc15 that
I've tested.

See: http://goo.gl/oiTPX5

[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:52:42 2015
New Revision: 224418

URL: https://gcc.gnu.org/viewcvs?rev=224418&root=gcc&view=rev
Log:
PR middle-end/63608
* gcc.c-torture/compile/pr63608.c: New test.

Backported from mainline
2014-05-16  Eric Botcazou  

* fold-const (fold_unary_loc) : New case.
: Pass arg0 instead of op0 to fold_convert_const.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/compile/pr63608.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/fold-const.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:53:34 2015
New Revision: 224419

URL: https://gcc.gnu.org/viewcvs?rev=224419&root=gcc&view=rev
Log:
PR middle-end/63608
* gcc.c-torture/compile/pr63608.c: New test.

Backported from mainline
2014-05-16  Eric Botcazou  

* fold-const (fold_unary_loc) : New case.
: Pass arg0 instead of op0 to fold_convert_const.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr63608.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/fold-const.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/62642] [4.8/4.9 Regression] x86 rdtsc is moved through barrier

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:54:43 2015
New Revision: 224420

URL: https://gcc.gnu.org/viewcvs?rev=224420&root=gcc&view=rev
Log:
Backported from mainline
2014-12-15  Vladimir Makarov  

PR target/62642
* ira.c (rtx_moveable_p): Prevent UNSPEC_VOLATILE moves.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ira.c

[Bug target/62642] [4.8/4.9 Regression] x86 rdtsc is moved through barrier

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:55:11 2015
New Revision: 224421

URL: https://gcc.gnu.org/viewcvs?rev=224421&root=gcc&view=rev
Log:
Backported from mainline
2014-12-15  Vladimir Makarov  

PR target/62642
* ira.c (rtx_moveable_p): Prevent UNSPEC_VOLATILE moves.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ira.c

[Bug pch/65550] [4.8/4.9 Regression] ICE (segfault) with pch

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:56:08 2015
New Revision: 224422

URL: https://gcc.gnu.org/viewcvs?rev=224422&root=gcc&view=rev
Log:
Backported from mainline
2015-04-09  Richard Biener  

PR pch/65550
* files.c (pch_open_file): Allow main and pre-included files
when trying to open a PCH.

Modified:
branches/gcc-4_9-branch/libcpp/ChangeLog
branches/gcc-4_9-branch/libcpp/files.c

[Bug pch/65550] [4.8/4.9 Regression] ICE (segfault) with pch

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jun 12 11:56:39 2015
New Revision: 224423

URL: https://gcc.gnu.org/viewcvs?rev=224423&root=gcc&view=rev
Log:
Backported from mainline
2015-04-09  Richard Biener  

PR pch/65550
* files.c (pch_open_file): Allow main and pre-included files
when trying to open a PCH.

Modified:
branches/gcc-4_8-branch/libcpp/ChangeLog
branches/gcc-4_8-branch/libcpp/files.c

[Bug middle-end/63608] [4.8/4.9 Regression] error: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug target/62642] [4.8/4.9 Regression] x86 rdtsc is moved through barrier

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug pch/55399] pch tests fail on mips-mti-linux-gnu target

[jakub at gcc dot gnu.org]

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

Bug 65550 Summary: [4.8/4.9 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550

   What|Removed |Added

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

[Bug pch/65550] [4.8/4.9 Regression] ICE (segfault) with pch

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #9 from Marc Glisse  ---
(In reply to alalaw01 from comment #8)
> Is there a case where the result is different with vs without all the
> extending/truncating?
> 
> It seems we should need the extending/truncating on vectors exactly iff we
> need it on scalars?

The extending/truncating is what the standard requires. Then we can start
optimizing (since indeed in many cases it isn't necessary), and Jeff is working
on exactly that (shortening). This seems like a rather straightforward case,
but who knows...

[Bug debug/66301] internal compiler error when using -fopt-info

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00685.html

[Bug debug/66301] internal compiler error when using -fopt-info

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Martin Jambor from comment #3)
> I have proposed a fix on the mailing list:
> 

Oops, this is the correct URL :-)

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00867.html

[Bug tree-optimization/54803] Rotates are not vectorized

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 CC||alalaw01 at gcc dot gnu.org
 Ever confirmed|1   |0

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
on gcc6.0 development branch, for aarch64, at -O3: shiftb0 is vectorized
exactly as shift2.

[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc

[egall at gwmail dot gwu.edu]

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

--- Comment #1 from Eric Gallager  ---
Created attachment 35771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35771&action=edit
preprocessed source of file triggering bug

For what it's worth, re-running the command with -save-temps to generate this
preprocessed source resulted in the same crash, so I've been able to reproduce
it myself, at least...

[Bug bootstrap/66521] New: xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc

[egall at gwmail dot gwu.edu]

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

Bug ID: 66521
   Summary: xgcc: cc1plus segfaults when compiling
libstdc++-v3/src/c++11/ostream-inst.cc
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egall at gwmail dot gwu.edu
  Target Milestone: ---
  Host: x86_64-apple-darwin10.8.0
Target: x86_64-apple-darwin10.8.0
 Build: x86_64-apple-darwin10.8.0

Created attachment 35770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35770&action=edit
crash reporter log that resulted

Here's my version info:
$ /Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc
Target: x86_64-apple-darwin10.8.0
Thread model: posix
gcc version 6.0.0 20150604 (experimental) (GCC)

The "Configured with" line is too long, due to all the times it says
"reconfigured", so I'll just put the most recent one:

../configure --enable-libada --enable-libssp --enable-bootstrap --enable-lto
--enable-stage1-languages=all --enable-objc-gc --enable-vtable-verify
--enable-maintainer-mode --disable-werror --enable-host-shared
--enable-languages=c,c++,java,jit,lto,objc,obj-c++ --enable-stage1-checking=all
--enable-libstdcxx-time -C --enable-multilib --enable-multiarch
--enable-__cxa_atexit --enable-tls --with-system-libunwind --enable-secureplt
--enable-frame-pointer --enable-version-specific-runtime-libs --enable-plugin
--enable-cxx --enable-assert --enable-fat --enable-portable-binary
--enable-browser-plugin --enable-gconf-peer --enable-libgcj-debug
--enable-gc-debug --enable-interpreter --enable-aot-compile-rpm
--enable-java-home --with-x --enable-collections --enable-gstreamer-peer
--enable-xmlj --enable-qt-peer --enable-gmp --enable-debug
--enable-local-sockets --enable-concept-checks --without-isl
AUTOCONF=autoconf264 AUTOHEADER=autoheader264 AUTOM4TE=autom4te264
AUTORECONF=autoreconf264 AUTOSCAN=autoscan264 AUTOUPDATE=autoupdate264
IFNAMES=ifnames264

Command line and output:

/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -shared-libgcc
-B/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc -nostdinc++
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-apple-darwin10.8.0/bin/
-B/usr/local/x86_64-apple-darwin10.8.0/lib/ -isystem
/usr/local/x86_64-apple-darwin10.8.0/include -isystem
/usr/local/x86_64-apple-darwin10.8.0/sys-include   
-I/Users/ericgallager/gcc-git/libstdc++-v3/../libgcc
-I/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/Users/ericgallager/gcc-git/libstdc++-v3/libsupc++  -std=gnu++11 -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -fvtable-verify=std
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once 
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections 
-frandom-seed=ostream-inst.lo -g -O2  -c -o ostream-inst.lo
../../../../../libstdc++-v3/src/c++11/ostream-inst.cc
libtool: compile: 
/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -shared-libgcc
-B/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc -nostdinc++
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs
-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-apple-darwin10.8.0/bin/
-B/usr/local/x86_64-apple-darwin10.8.0/lib/ -isystem
/usr/local/x86_64-apple-darwin10.8.0/include -isystem
/usr/local/x86_64-apple-darwin10.8.0/sys-include
-I/Users/ericgallager/gcc-git/libstdc++-v3/../libgcc
-I/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/Users/ericgallager/gcc-git/libstdc++-v3/libsupc++ -std=gnu++11
-D_GLIBCXX_SHARED -fno-implicit-templates -fvtable-verify=std
-Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections

[Bug debug/63623] Lots of functions get -fvar-tracking silently turned off unnecessarily

[matz at gcc dot gnu.org]

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

--- Comment #4 from Michael Matz  ---
Author: matz
Date: Fri Jun 12 14:06:41 2015
New Revision: 224434

URL: https://gcc.gnu.org/viewcvs?rev=224434&root=gcc&view=rev
Log:
Backported from mainline
2014-10-23  Jakub Jelinek  

PR debug/63623
* var-tracking.c (stack_adjust_offset_pre_post_cb): New function.
(stack_adjust_offset_pre_post): Use it through for_each_inc_dec,
instead of only handling autoinc in dest if it is a MEM.
(vt_stack_adjustments): Fix up formatting.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/var-tracking.c

[Bug debug/63623] Lots of functions get -fvar-tracking silently turned off unnecessarily

[matz at gcc dot gnu.org]

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

--- Comment #5 from Michael Matz  ---
Author: matz
Date: Fri Jun 12 14:13:33 2015
New Revision: 224435

URL: https://gcc.gnu.org/viewcvs?rev=224435&root=gcc&view=rev
Log:
Backported from mainline
2014-10-23  Jakub Jelinek  

PR debug/63623
* var-tracking.c (stack_adjust_offset_pre_post_cb): New function.
(stack_adjust_offset_pre_post): Use it through for_each_inc_dec,
instead of only handling autoinc in dest if it is a MEM.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/var-tracking.c

[Bug tree-optimization/56688] Fortran save statement prevents loop vectorization.

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #6 from alalaw01 at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)

The C testcase vectorizes on gcc 6 development (at -O3 on aarch64 or
x86_64)

[Bug tree-optimization/66522] New: handle casts in nr of iterations in try_transform_to_exit_first_loop_alt

[vries at gcc dot gnu.org]

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

Bug ID: 66522
   Summary: handle casts in nr of iterations in
try_transform_to_exit_first_loop_alt
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There's a todo in try_transform_to_exit_first_loop_alt:
...
  /* There is a number of test-cases for which we don't get an alt_bound
 here: they're listed here, with the lhs of the last stmt as the nit:
 libgomp.graphite/force-parallel-1.c:
 _21 = (signed long) N_6(D);
 _19 = _21 + -1;
 _7 = (unsigned long) _19;
 libgomp.graphite/force-parallel-2.c:
 _33 = (signed long) N_9(D);
 _16 = _33 + -1;
 _37 = (unsigned long) _16;
 libgomp.graphite/force-parallel-5.c:
 :
 # graphite_IV.5_46 = PHI <0(5), graphite_IV.5_47(11)>
 :
 _33 = (unsigned long) graphite_IV.5_46;
 g++.dg/tree-ssa/pr34355.C:
 _2 = (unsigned int) i_9;
 _3 = 4 - _2;
 gcc.dg/pr53849.c:
 _5 = d.0_11 + -2;
 _18 = (unsigned int) _5;
 We will be able to handle some of these cases, if we can determine
when
 it's safe to look past casts.  */
...

I'm running into this todo for a trivial fortran test-case
gcc/testsuite/gfortran.dg/parloops-exit-first-loop-alt.f95:
...
! { dg-additional-options "-O2" }
! { dg-require-effective-target pthread }
! { dg-additional-options "-ftree-parallelize-loops=2" }
! { dg-additional-options "-fdump-tree-parloops" }

! Variable bound, vector addition.

subroutine foo(nr)
  integer, intent(in)   :: nr
  integer, parameter :: n = 1000
  integer, dimension (0:n-1) :: a, b, c
  common a, b, c
  integer:: ii

  do ii = 0, nr - 1
 c(ii) = a(ii) + b(ii) + 25
  end do
end subroutine foo

! Three times 'plus 25'
! - one in f._loopfn.0
! - one in the parallel
! - one in the low iteration count loop
! Crucially, none for a peeled off last iteration following the parallel.
! { dg-final { scan-tree-dump-times "(?n) \\+ 25;" 3 "parloops" } }
...

The scan-tree-dump-times currently fails, so
try_transform_to_exit_first_loop_alt is failing.

[Bug tree-optimization/66522] handle casts in nr of iterations in try_transform_to_exit_first_loop_alt

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 35772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35772&action=edit
tentative patch

[Bug target/66523] New: the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[howarth.at.gcc at gmail dot com]

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

Bug ID: 66523
   Summary: the new clang-based assembler in Xcode 7 on 10.11
fails on libobjc/NXConstStr.m
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

Created attachment 35773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35773&action=edit
proposed fix from Iain Sandoe

The new clang-based assembler in Xcode 7 fails to build libobjc in FSF gcc 5.1
with the following error...

/bin/sh ./libtool  --mode=compile
/sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.0.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.0.0/sys-include   
/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/NXConstStr.m -c \
   -I. -I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc   -g -O2 -W
-Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc/config -I../.././gcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../libgcc -I../libgcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../include  -fgnu-runtime \
   -o NXConstStr.lo
libtool: compile:  /sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.1.0-2/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin15.0.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.0.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin15.0.0/sys-include
/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/NXConstStr.m -c -I.
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc -g -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS
-fno-strict-aliasing -fexceptions
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../gcc/config -I../.././gcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../libgcc -I../libgcc
-I/sw/src/fink.build/gcc5-5.1.0-2/gcc-5.1.0/libobjc/../include -fgnu-runtime 
-fno-common -DPIC -o .libs/NXConstStr.o
/var/tmp//ccc9efWx.s:98:17: error: non-local symbol required in directive
.no_dead_strip L_OBJC_Module
   ^
make: *** [NXConstStr.lo] Error 1

The proposed patch from Iain Sandoe suppresses this assembler error and allows
libobjc to build under the clang-based assembler.

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Previously filed as radr://21323034, "the new clang-based assembler in Xcode 7
on 10.11 fails on the NXConstStr.s file from FSF gcc 5.1"

[Bug sanitizer/66524] New: Unable to detect InitializationOrderFiasco when compiled with "g++ -fsanitize=address"

[bhupendra_thosare at persistent dot co.in]

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

Bug ID: 66524
   Summary: Unable to detect InitializationOrderFiasco when
compiled with "g++ -fsanitize=address"
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bhupendra_thosare at persistent dot co.in
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

I am trying to run sample program provided in following link using g++ (4.8.2)
to report "initialization-order-fiasco" error.
https://code.google.com/p/address-sanitizer/wiki/InitializationOrderFiasco

However, if we are using g++ it do not report any error for following commands:
ASAN_OPTIONS=check_initialization_order=true ./a.out
export ASAN_OPTIONS=check_initialization_order=1; ./a.out
a.out // It will not work as AddressSanitizer can optionally detect dynamic
initialization order problems.

We are using following script to build and run the sample program:
==
# For gcc to print line numbers
export ASAN_OPTIONS=symbolize=1
export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer
#export ASAN_OPTIONS=check_initialization_order=1 # NOT WORKING :-/

flags="-fno-omit-frame-pointer -fno-common"

echo "+"
echo " Loose init-order checking"
echo "+"
rm -f a.out
g++ -fsanitize=address $flags -g a.cc b.cc

echo " ASAN_OPTIONS=check_initialization_order=true ./a.out "
ASAN_OPTIONS=check_initialization_order=true ./a.out
==

If we use "clang++" instead of "g++" in above script then it reports
"initialization-order-fiasco" error for same sample program.

Please let us know if I am missing any step OR
"ASAN_OPTIONS=check_initialization_order" is not supported for gcc 4.8.2.

[Bug c++/66501] [4.9/5/6 Regression] Default move assignment does not move array members

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Krügler  ---
The problem still exists in gcc HEAD 6.0.0 20150611 (experimental)

[Bug c++/66517] [5 Regression] [C++11] sorry, unimplemented: unexpected AST of kind type_decl

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

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

--- Comment #2 from Daniel Krügler  ---
Seems to be fixed in gcc HEAD 6.0.0 20150611 (experimental)

[Bug debug/66301] internal compiler error when using -fopt-info

[singhai at gcc dot gnu.org]

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

Sharad Singhai  changed:

   What|Removed |Added

 CC||singhai at gcc dot gnu.org

--- Comment #5 from Sharad Singhai  ---
Sorry, I didn't get time to look at this. Yes, this is the right fix in the
interim as old and new style of dumping cannot be mixed.

Another fix would require converting this and other passes to the new style.

[Bug c++/65719] Link error with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Fri Jun 12 18:16:22 2015
New Revision: 224442

URL: https://gcc.gnu.org/viewcvs?rev=224442&root=gcc&view=rev
Log:
PR c++/65719
* pt.c (tsubst_decl) [VAR_DECL]: Mark namespace-scope
variables as DECL_NOT_REALLY_EXTERN.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/65719] Link error with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Jun 12 19:11:35 2015
New Revision: 224443

URL: https://gcc.gnu.org/viewcvs?rev=224443&root=gcc&view=rev
Log:
PR c++/65719
* pt.c (tsubst_decl) [VAR_DECL]: Mark namespace-scope
variables as DECL_NOT_REALLY_EXTERN.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ29.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/65719] Link error with constexpr variable template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.2

--- Comment #8 from Jason Merrill  ---
Fixed for 5.2.

[Bug ada/66525] New: Implicit function declarations

[pini_os at yahoo dot fr]

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

Bug ID: 66525
   Summary: Implicit function declarations
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pini_os at yahoo dot fr
  Target Milestone: ---

Compiling the Ada frontend with -Wimplicit-function-declaration on x86_64
reports the following warnings:

gcc/ada/cal.c:108:3: warning: implicit declaration of function ‘time’
-> include should be on time.h rather than sys/time.h

gcc/ada/socket.c:150:3: warning: implicit declaration of function ‘pipe’
-> include of unistd.h is missing

[Bug ada/66526] New: Use of uninitialized variable

[pini_os at yahoo dot fr]

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

Bug ID: 66526
   Summary: Use of uninitialized variable
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pini_os at yahoo dot fr
  Target Milestone: ---

Compiling Ada frontend with -Wuninitialized reports the following warning:

gcc/ada/g-expect.adb:1338:7: warning: ‘INPUT’ is used uninitialized in this
function
gcc/ada/g-expect.adb:1339:7: warning: ‘OUTPUT’ is used uninitialized in this
function
gcc/ada/g-expect.adb:1340:7: warning: ‘ERROR’ is used uninitialized in this
function

In function ‘Set_Up_Child_Communications’, these local variables are only
initialized within the ‘if No_Fork_On_Target’ but each is used twice outside of
it.

The uses are following an execvp call, so no harm on *nix systems, but the
source is still oddly shaped. The uses of these variables should be controlled
by the same condition as their initialization.

[Bug driver/66203] aarch64-none-elf does not automatically find librdimon

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson  ---
This is more an arm newlib bug than a gcc aarch64 bug.

Most embedded ports support more than one rom monitor.  libgloss provides more
than one set of start files and libraries for these different rom monitors. 
Users are expected to supply a --specs option when linking to choose the right
support files for the rom monitor in use.  This is how the aarch64 port works.

However, arm works differently.  There is a single set of start files and
libraries provided by newlib that override libgloss.  These are compiled for
rdimon.  If you want to compile for a different rom monitor, then you either
need to add a newlib configure option --disable-newlib-supplied-syscalls or
else you need to hand edit newlib/libc/configure.host to enable a different
choice.

This was probably done to make this easier for end users.  If you make one rom
monitor the default, then they don't have to read docs to figure out how to
link.  Though this also means that by default the support for the other rom
monitors is broken unless you rebuild the toolchain.

This probably hasn't been done for aarch64 yet simply because there aren't
enough people doing bare target work for aarch64, and hence people haven't yet
noticed that the arm and aarch64 ports are working differently.

I do see a number of problems with the arm support here though.

There are two copies of the syscalls.c file, one in newlib/libc/sys/arm and one
in libgloss/arm.  It appears that they were the same file originally, but lack
of cross-maintenance means that they have accidentally diverged.  There may
also be some other files that have diverged.  I haven't checked them all.

The newlib/README file says --disable-newlib-supplied-syscalls is the default. 
But the configure code makes --enable-newlib-supplied-syscalls the default.

The libgloss arm specs files could perhaps be changed to put libgloss libraries
in front of newlib libraries, which may allow alternative rom monitors to work
without rebuilding the toolchain.  I haven't tried that.  Currently, they
include -lc first and then the monitor library, which won't work unless newlib
is configured to disable the syscall support.

There is also a related problem here that some of the specs files are
redefining link spec to add -l$(monitorlib).  That causes the archive file to
be included before any input files on the link line, which means it will get
ignored.  The correct specs files are using link_gcc_c_sequence.  It is OK to
put a -T*.ld linker script file in link spec, but libraries need to go into
link_gcc_c_sequence.

And of course, arm supports this but aarch64 does not, and it seems to be
general policy that things should work similarly for the two targets.

So I count 5 inter-related newlib arm/aarch64 problems that need to be fixed.

[Bug preprocessor/66527] New: incorrect line number in diagnostics for multiline initializers

[msebor at gcc dot gnu.org]

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

Bug ID: 66527
   Summary: incorrect line number in diagnostics for multiline
initializers
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In a diagnostic message pointing to an initializer that spans multiple lines,
instead of pointing to the offending construct gcc points to the line withe the
terminating semicolon or closing brace (when the initializer is an aggregate).

For example:

$ cat t.c && /build/gcc-66516/gcc/xgcc -B /build/gcc-66516/gcc -S -o/dev/null
t.c
/* 1 */ void f (register int i) {
/* 2 */ int* a =
/* 3 */ &i
/* 4 */ ;
/* 5 */ }
t.c: In function ‘f’:
t.c:4:9: error: address of register variable ‘i’ requested
 /* 4 */ ;
 ^

(I haven't seen this mentioned on the
https://gcc.gnu.org/wiki/Better_Diagnostics Wiki; sorry if this is another
known issue and I missed it.)

[Bug ipa/66271] -Os generates incorrect code on ARM possibly due to IPA

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

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

--- Comment #8 from Jim Wilson  ---
This is the same kernel string bug as in 65932.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #11 from Jim Wilson  ---
There is another testcase in 66271.

The LSR is emitted because the arm port has PROMOTE_MODE defined to make chars
and shorts unsigned when extended to int.  So the problem seems to be why it
wasn't re-sign-extended before the compare.  Maybe an optimization pass
incorrectly deleted that sign-extend.

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[damian at sourceryinstitute dot org]

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

--- Comment #4 from Damian Rouson  ---
Thanks for fixing this!  I just verified that the leak is gone with a gcc build
dated 20150607.

Damian

[Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram

[damian at sourceryinstitute dot org]

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

--- Comment #7 from Damian Rouson  ---
Thanks for the fix!  I'll update my source, rebuild, and test the fix.

Damian

[Bug fortran/66065] ICE on assignment to deferred-length character array

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Hi Dominique,

Do you know if anyone is working on fixing this bug?  Would it be worthwhile
for me to mail the gfortran developers list for an update?

Damian

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #12 from Jim Wilson  ---
Part of the problem here is that the arm port defines PROMOTE_MODE to force
short local variables to unsigned, but arm_promote_function_mode doesn't change
signedness.  So a signed short parameter and a signed short local have
different representations in a register.

Another part of the problem is that the eipa_sra pass is creating phi nodes
that mix parameters and local variables.  Copying a signed short local into a
signed short parameter requires a conversion, even though they have the same
type, because they get different in register promotion.

Another part of the problem is that the out-of-ssa pass when evaluating phi
nodes doesn't go through expand_expr, and hence doesn't handle mode promotion. 
The code is copying DECL_RTL directly into SA.partition_to_pseudo, and then
using SA.partition_to_pseudo when emitting the copy instructions.  Thus these
phi nodes won't emit any conversion instructions even though one is apparently
required.

I can get correct code if I pass DECL_RTL through expand_expr before storing it
into SA.partition_to_pseudo for VAR_DECLs.  However, if I then do the same
thing for PARM_DECLS, then I get a movhi insn instead of a conversion, because
both the source and dest are promoted subregs.  I think the problem here is
that emit_partition_copy doesn't handle promoted subregs.  I think we need
something like what store_expr_with_bounds does, when the dest is a promoted
subreg, to do the copy to the smaller mode, and then convert to the wider mode.
 But I have a few too many suppositions at this point and am not sure if this
makes sense.

It might be simpler to change the arm port so that promote_mode and
function_promote_mode match.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #13 from Jim Wilson  ---
Created attachment 35774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35774&action=edit
Experimental patch to force out-of-ssa to use promoted subregs for phi nodes.