[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing

[g...@axel-naumann.de]

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

--- Comment #10 from Axel Naumann  ---
(In reply to jos...@codesourcery.com from comment #9)
> On Thu, 7 Apr 2016, manu at gcc dot gnu.org wrote:
> It's simply the case that if the 'p' or 'P' is followed by a digit, rather 
> than by '+' or '-', then it forms part of the pp-number whatever standard 
> version is in use

See, and that's the part I cannot find in the standard. I don't see 'P' or 'p'
being part of a pp-number, according to [lex.ppnumber] in C++14. I don't see
0x123P2 being a valid pp-number in C++14.

(In reply to Manuel López-Ibáñez from comment #8)
> (In reply to Axel Naumann from comment #2)
> > NB: Even if I would buy into the argument that diagnostics are limited by
> > the tokens, I don't yet see why 'P' ends up being concated to the pp-number
> > token in C++ < 1z.
> 
> You have to run g++ (actually, cc1plus) under a debugger to see why. See
> lex_number. Doing it in a different way would probably break a lot of other
> things.

I meant to say "I don't yet see why 'P' is *meant* to end up being concated to
the pp-number token in C++ < 1z."

[Bug tree-optimization/68953] [6 Regression] [graphite] Wrong code w/ -O[12] -floop-nest-optimize

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #7 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00373.html

[Bug c++/70590] New: [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

Bug ID: 70590
   Summary: [6 Regression] r234810 causes error: location
references block not in block tree
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

Since r234810 Firefox doesn't build anymore on ppc64le:

trippels@gcc2-power8 xslt % /home/trippels/gcc_test/usr/local/bin/c++ -c -w -O2
-std=gnu++0x txMozillaXMLOutput.ii
/home/trippels/gecko-dev/dom/xslt/xslt/txMozillaXMLOutput.cpp: In member
function ‘MozExternalRefCountType nsNodeInfoManager::Release()’:
/home/trippels/gecko-dev/dom/xslt/xslt/txMozillaXMLOutput.cpp:1081:1: error:
location references block not in block tree
 }
 ^
&_cycleCollectorGlobal.D.86308
D.356459 = nsCycleCollectingAutoRefCnt::decr (D.356455, this,
&_cycleCollectorGlobal.D.86308, 0B);
/home/trippels/gecko-dev/dom/xslt/xslt/txMozillaXMLOutput.cpp:1081:1: internal
compiler error: verify_gimple failed
0x10b189e3 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5125
0x109ba45f execute_function_todo
../../gcc/gcc/passes.c:1958
0x109bb223 do_per_function
../../gcc/gcc/passes.c:1652
0x109bb42f execute_todo
../../gcc/gcc/passes.c:2010

Reducing...

[Bug translation/70591] New: add ability to use a fallback LANGUAGE variable instead of primary language

[dront78 at gmail dot com]

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

Bug ID: 70591
   Summary: add ability to use a fallback LANGUAGE variable
instead of primary language
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dront78 at gmail dot com
  Target Milestone: ---

based on
https://www.google.ru/search?q=gcc+use+LANGUAGE&ie=utf-8&oe=utf-8&gws_rd=cr&ei=_l4HV8aSKIaqswHfzqzoCA#q=gcc+localization
the localized output it seems very annoying to a lot of people including me )

[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
pp-number:
  digit
  . digit
  pp-number digit
  pp-number identifier-nondigit
  pp-number e sign
  pp-number E sign
  pp-number .
identifier-nondigit:
  nondigit
  universal-character-name
  other implementation-defined characters
nondigit: one of
  a b c d e f g h i j k l m
  n o p q r s t u v w x y z
  A B C D E F G H I J K L M
  N O P Q R S T U V W X Y Z _
digit: one of
  0 1 2 3 4 5 6 7 8 9
sign: one of
  + -
Thus
0x123P2
is valid pp-number, because it starts with a digit, is followed by nondigit,
then 3 times digit, then nondigit and then another digit, all matching the
above grammar.  But 0x123P-2 is not a pp-number, because in the grammar
sign is only allowed after e or E letters.
0.123P2E-3E+3e-2E+2 is also a pp-number.  After lexing this one is of course
rejected, because it is not a valid floating point constant.

[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Should be fixed now.  Yeah, if you as doesn't support AVX512-F, UNSUPPORTED is
the only thing we can do.

[Bug fortran/70592] New: Addressing error in dynamically-allocated character array

[KnowlesPJ at Cardiff dot ac.uk]

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

Bug ID: 70592
   Summary: Addressing error in dynamically-allocated character
array
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: KnowlesPJ at Cardiff dot ac.uk
  Target Milestone: ---

Created attachment 38217
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38217&action=edit
failing test case

The attached code incorrectly prints '66' as its last line instead of
'123456' apparently because the program thinks that the addresses of all
elements of the array are the same.

The compiler also produces the somewhat cryptic warning


  CHARACTER(len=:), DIMENSION(:), POINTER :: cp
 ^
Warning: '.cp' is used uninitialized in this function [-Wuninitialized]

[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing

[g...@axel-naumann.de]

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

--- Comment #12 from Axel Naumann  ---
Thanks for explaining, Jakub - I missed the identifier-nondigit.

Then it's really a matter of making the diagnostic more informative.

[Bug middle-end/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Apr  8 08:31:40 2016
New Revision: 234823

URL: https://gcc.gnu.org/viewcvs?rev=234823&root=gcc&view=rev
Log:
[PR testsuite/70579, PR testsuite/70580] Fix test cases failing because of the
compiler's "avoid offloading" decision

libgomp/
PR testsuite/70579
PR testsuite/70580
* testsuite/libgomp.oacc-c-c++-common/host_data-1.c: Initialize
the runtime for acc_device_nvidia.
* testsuite/libgomp.oacc-c-c++-common/if-1.c: Cope with
"avoid offloading" situation.
* libgomp.texi (Enabling OpenACC): Elaborate on interactions of
"avoid offloading".

Modified:
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
branches/gomp-4_0-branch/libgomp/libgomp.texi
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-1.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c

[Bug middle-end/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Author: tschwinge
Date: Fri Apr  8 08:31:40 2016
New Revision: 234823

URL: https://gcc.gnu.org/viewcvs?rev=234823&root=gcc&view=rev
Log:
[PR testsuite/70579, PR testsuite/70580] Fix test cases failing because of the
compiler's "avoid offloading" decision

libgomp/
PR testsuite/70579
PR testsuite/70580
* testsuite/libgomp.oacc-c-c++-common/host_data-1.c: Initialize
the runtime for acc_device_nvidia.
* testsuite/libgomp.oacc-c-c++-common/if-1.c: Cope with
"avoid offloading" situation.
* libgomp.texi (Enabling OpenACC): Elaborate on interactions of
"avoid offloading".

Modified:
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
branches/gomp-4_0-branch/libgomp/libgomp.texi
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/host_data-1.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/if-1.c

[Bug middle-end/70593] New: [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

Bug ID: 70593
   Summary: [6 Regression] Miscompilation of xen starting with
r226901
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

__attribute__((noinline, noclone)) unsigned long
foo (unsigned long x, unsigned long y, unsigned z)
{
  unsigned long a, b, c, d = z;
  asm volatile ("xorl\t%k1, %k1\n\txorl\t%k2, %k2\n\txorl\t%k3,
%k3\n\tmovl\t$7, %k0"
: "=&c" (d), "=&D" (a), "=&S" (b), "=&r" (c) : "0" (d), "1"
(x), "2" (y), "3" (d) : "memory");
  return d;
}

int
main ()
{
  if (foo (1, 2, 3) != 7)
__builtin_abort ();
  return 0;
}

is miscompiled on x86_64-linux at -O2 starting with r226901, -O2
-fno-tree-coalesce-vars works.  The return value d is in %rcx at the end of the
inline asm, but with -O2 the copy of %rcx to %rax is lost.

[Bug middle-end/70593] [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-08
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug testsuite/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|middle-end  |testsuite
 Resolution|--- |FIXED

--- Comment #2 from Thomas Schwinge  ---
.

[Bug testsuite/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|middle-end  |testsuite
 Resolution|--- |FIXED

--- Comment #2 from Thomas Schwinge  ---
.

[Bug middle-end/70593] [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Simplified testcase:
__attribute__((noinline, noclone)) unsigned long
foo (unsigned x)
{
  unsigned long a, c = x;
  asm volatile ("xorl\t%k1, %k1\n\tmovl\t$7, %k0"
: "=c" (c), "=a" (a) : "0" (c), "1" (c) : "memory");
  return c;
}

int
main ()
{
  if (foo (3) != 7)
__builtin_abort ();
  return 0;
}

The *.optimized dump looks good:
  c_2 = (long unsigned int) x_1(D);
  __asm__ __volatile__("xorl%k1, %k1
movl$7, %k0" : "=c" c_5, "=a" a_6 : "0" c_2, "1" c_2 : "memory");
  return c_5;
but in *.expand we have incorrect:
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v:SI 88 [ x ])
(reg:SI 5 di [ x ])) pr70593.c:3 -1
 (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 9 2 (set (reg/v:DI 87 [  ])
(zero_extend:DI (reg/v:SI 88 [ x ]))) pr70593.c:4 -1
 (nil))
(insn 9 6 7 2 (parallel [
(set (reg:DI 89 [ c ])
(asm_operands/v:DI ("xorl   %k1, %k1
movl$7, %k0") ("=c") 0 [
(reg/v:DI 87 [  ])
(reg/v:DI 87 [  ])
]
 [
(asm_input:DI ("0") pr70593.c:5)
(asm_input:DI ("1") pr70593.c:5)
]
 [] pr70593.c:5))
(set (reg:DI 90 [ a ])
(asm_operands/v:DI ("xorl   %k1, %k1
movl$7, %k0") ("=a") 1 [
(reg/v:DI 87 [  ])
(reg/v:DI 87 [  ])
]
 [
(asm_input:DI ("0") pr70593.c:5)
(asm_input:DI ("1") pr70593.c:5)
]
 [] pr70593.c:5))
(clobber (mem:BLK (scratch) [0  A8]))
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
]) pr70593.c:5 -1
 (nil))
(insn 7 9 8 2 (set (reg/v:DI 87 [  ])
(reg:DI 89 [ c ])) pr70593.c:5 -1
 (nil))
(insn 8 7 13 2 (set (reg/v:DI 87 [  ])
(reg:DI 90 [ a ])) pr70593.c:5 -1
 (nil))
(insn 13 8 14 2 (set (reg/i:DI 0 ax)
(reg/v:DI 87 [  ])) pr70593.c:7 -1
 (nil))
(insn 14 13 0 2 (use (reg/i:DI 0 ax)) pr70593.c:7 -1
 (nil))

insn 8 really shouldn't be there.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #44 from Roger Orr  ---
Created attachment 38218
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38218&action=edit
Intermediate file

I am as yet unable to upload the code for an example.

However, I've attached a file containing the generated line directives using

grep "#" rsMessaging.cxx.ii > lineDirectives

from one of the troublesome pre-processsed output files (rsMessaging.cxx.ii).

As far as I can tell the directives are correct.

The .ii file generates the following diagnostic when compiled:

$ /var/tmp/gcc-trunk-234481/install/bin/g++ -std=c++14 -O3 -Werror -c
rsMessaging.cxx.ii
In file included from
/opt/reactor-buildkit/B2BH-BK2GIT44-1/poco/include/Poco/Net/IPAddress.h:379:0,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx:18,
 from
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx:15:
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:117:165:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/messaging/rsHintServerBase.hxx"
linemarker ignored due to incorrect nesting [-Werror]

   
   
 ^
/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/hxx/rsEnumMnemonic.hxx:212:154:
error: file
"/home/rorr/linuxdev109ws_9119/rorr_linuxdev109ws_9119/Reactor5/project/prj-lcc-device-longer-name/reactor/src/base/messaging/src/rsMessaging.cxx"
linemarker ignored due to incorrect nesting [-Werror]
cc1plus: all warnings being treated as errors

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-08
 CC||vries at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from vries at gcc dot gnu.org ---
Confirmed with r231093 (2015-12-01 daily bump revision)

[Bug c++/70594] New: [6 Regression] -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

Bug ID: 70594
   Summary: [6 Regression] -fcompare-debug failure
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

No example as I failed to reduce one; I also tried to use a reduced set of
flags; this set worked on the original file - but not on the delta-reduced
file. All of those point to a memory-related issue. Interestingly, with
-save-temps it didn't occur while w/o -save-temps, the result differed as
follows (two lines shifted down by five lines):

--- /tmp/ccRrTlry.gkd   2016-04-08 09:12:27.463899521 +0200
+++ /tmp/ccV2i7s5.gk.gkd2016-04-08 09:12:35.739842097 +0200
@@ -74901,2 +74900,0 @@
-29:   void yyreduce = <<< error >>>;
-1861:   void yyerrlab = <<< error >>>;
@@ -74906,0 +74905,2 @@
+29:   void yyreduce = <<< error >>>;
+1861:   void yyerrlab = <<< error >>>;


Bisecting GCC points to Patrick Palka's commit r234753:

Fix PR c++/70452 (regression in C++ parsing performance)

gcc/cp/ChangeLog:

PR c++/70452
* constexpr.c (struct fundef_copy): New struct.
(struct fundef_copies_table_t): New struct.
(fundef_copies_table): New static variable.
(maybe_initialize_fundef_copies_table): New static function.
(get_fundef_copy): New static function.
(save_fundef_copy): New static function.
(cxx_eval_call_expression): Use get_fundef_copy, and
save_fundef_copy.
(constexpr_call_table): Add "deletable" GTY marker.

gcc/testsuite/ChangeLog:

PR c++/70452
* g++.dg/ext/constexpr-vla4.C: New test.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #45 from Roger Orr  ---
While investigating the problem I am experiencing I have found it is stable
across g++ builds - I have tried a build using revision 234741 which has the
identical diagnostic output from the compilation.

However, small changes to the source code -- such as changing the length of the
directory paths involved -- can change whether or not the diagnostic is
produced.

In the example I posted, if I change path "/home/rorr/linuxdev109ws_9119/..."
to "/home/rorr/..." in the line directives of the ii file the compilation
succeeds without problem.

Hence it is not clear to me whether this diagnostic is the root problem or
merely a symptom of a different problem - possibly a memory overwrite or use of
an uninitialised variable whose value depends on the history of the memory
location.

[Bug middle-end/70593] [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org,
   ||bernds at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Conflict graph:

After sorting:
Sorted Coalesce list:
(1, 0) c_2 <-> c_5
(1, 0) c_2 <-> a_6
(1, 0) c_5 <-> _7(D)

Partition map

Partition 0 (x_1(D) - 1 )
Partition 1 (c_2 - 2 )
Partition 2 (c_5 - 5 )
Partition 3 (a_6 - 6 )
Partition 4 (_7(D) - 7 )

Coalesce list: (2)c_2 & (5)c_5 [map: 1, 2] : Success -> 1
Coalesce list: (2)c_2 & (6)a_6 [map: 1, 3] : Success -> 1
Coalesce list: (5)c_2 & (7)_7(D) [map: 1, 4] : Success -> 1
After Coalescing:

Partition map

Partition 0 (x_1(D) - 1 )
Partition 1 (c_2 - 2 5 6 7 )

There should be some conflict that a_6 and c_5 can't be in the same partitions,
they are different vars, and used in different asm outputs.  But guess what
confuses the coalesce handling is that that have matching constraint and the
same value in those.

Perhaps just build_ssa_conflict_graph isn't ready to handle statements with
multiple SSA_OP_DEFs (where we need to arrange for conflicts in between the
partitions in different outputs)?

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Without the testcase it is hard to guess.
But one guess is that if in case of GC the cache is wiped and recreating it may
create something -fcompare-debug cares about (e.g. creation of new decls - we
care not about exact values of DECL_UID, but about their order), then the
deletable cache is a serious problem, because with -g and with -g0 there is
likely different amount of memory used, which means ggc_collect at different
times and thus we could be using the cache successfully with -g and not without
-g or vice versa.

[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Fri Apr  8 09:39:44 2016
New Revision: 234825

URL: https://gcc.gnu.org/viewcvs?rev=234825&root=gcc&view=rev
Log:
[ARM] PR target/70566 Check that condition register is dead in tst-imm ->
lsls-imm Thumb2 peepholes

PR target/70566
* config/arm/thumb2.md (tst + branch-> lsls + branch
peephole below *orsi_not_shiftsi_si): Require that condition
register is dead after the peephole.
(second peephole after the above): Likewise.

* gcc.c-torture/execute/pr70566.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70566.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/thumb2.md
trunk/gcc/testsuite/ChangeLog

[Bug target/70566] [4.9/5] Bad ARM code generated for evaluating unsigned int bitfield value

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.0
Summary|[4.9/5/6 Regression] Bad|[4.9/5] Bad ARM code
   |ARM code generated for  |generated for evaluating
   |evaluating unsigned int |unsigned int bitfield value
   |bitfield value  |
  Known to fail|6.0 |

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Fixed on trunk.
The patch backports cleanly to 4.9 and 5 branches and bootstrap and test looks
good.
I'll ask for a backport after a bit of time on trunk

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Perhaps a way to reduce this (though not as a -fcompare-debug failure) would be
to see if on the original testcase you get different code generation or
different -fdump-final-insns= dump between normal GC parameters and additional
--param ggc-min-expand=0 --param ggc-min-heapsize=0
Though it would be best to verify first if before the problematic commit you
get the same code generation (and same -fdump-final-insns=).

[Bug middle-end/70593] [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
And there is another thing special on this testcase - a_6 has zero uses, so
isn't live.
If both the values would be live after the asm, there would be an conflict
added, even during the SSA_OP_DEF processing of one of the defs vs. the other
one.
So, I see generally two solutions: ensure conflict between multiple SSA_OP_DEFs
of GIMPLE_ASM even if they aren't live, or during expansion for output operands
of GIMPLE_ASM which have zero uses don't try to move them to any pseudo etc.

[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer

[chefmax at gcc dot gnu.org]

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

--- Comment #5 from chefmax at gcc dot gnu.org ---
Author: chefmax
Date: Fri Apr  8 10:46:13 2016
New Revision: 234827

URL: https://gcc.gnu.org/viewcvs?rev=234827&root=gcc&view=rev
Log:
2016-04-08  Maxim Ostapenko  

PR sanitizer/70541
* asan.c (instrument_derefs): If we get unknown location, extract it
with EXPR_LOCATION.
(maybe_instrument_call): Instrument gimple_call's arguments if needed.

* c-c++-common/asan/pr70541.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr70541.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/70595] New: Cilk Plus testsuite needs massive cleanup

[ro at gcc dot gnu.org]

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

Bug ID: 70595
   Summary: Cilk Plus testsuite needs massive cleanup
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Prompted by the tentative patch to support SPARC in libcilkrts (PR
target/68945),
I looked into the current Cilk Plus testsuite and found tons of issues, way
beyond
what it takes to support a new target:

* Every single execution test explicitly lists the targets to run on, often
even
  twice (in the dg-do target selector and then again when adding -lcilkrts via
  dg-options).  This is completely unmaintainable and should be replaced by a
  target selector.  I'm using the current check_libcilkrts_available, renamed
to
  cilkplus_runtime, for thta purpose.  There's no need to add -lcilkrts at all;
  -fcilkplus already does this when linking.

* Two tests (c-c++-common/cilk-plus/CK/pr63307.c and
c-c++-common/cilk-plus/SE/ef_error3.c)
  are pure compile tests and don't need a target selector at all.

* This only leaves us with c-c++-common/cilk-plus/SE/ef_error2.c, where the
expected
  warning is x86-specific, thus the target selector needs to stay.

With those changes and the cleaned-up sparc port, I could successfully run the
cilk-plus testsuite on Solaris/SPARC, too.

But there's more cleanup possible/necessary:

* Two tests (c-c++-common/cilk-plus/AN/decl-ptr-colon.c and
c-c++-common/cilk-plus/AN/vla.c) 
  live in a common directory, but are restricted to target c.  Unless someone
  can educate me otherwise, they simply should be moved to gcc.dg/cilk-plus,
  losing the target selector.

* Every since testcase is compiled/linked with -fcilkplus, most (all?) of them
  specifying this explicitly via ad-options.  This is plain silly and should be
  moved into the framework.

* Many tests are run at several optimization levels.  This cries for using
   the torture framework instead of doing it explicitly.

There may be more, but that's what I've found so far.  I'm attaching my current
patch for reference, but this is clearly gcc-7 material.

  Rainer

[Bug testsuite/70595] Cilk Plus testsuite needs massive cleanup

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-08
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
Mine.

[Bug testsuite/70595] Cilk Plus testsuite needs massive cleanup

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth  ---
Created attachment 38219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38219&action=edit
Initial patch

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-08
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc2-power8 xslt % cat txMozillaXMLOutput.ii
struct nsCycleCollectionParticipant;
struct A {
  void incr(void *, nsCycleCollectionParticipant *);
  void decr(void *, nsCycleCollectionParticipant *);
};
template  struct B {
  T *assign_with_AddRef_aRawPtr;
  T *assign_assuming_AddRef_oldPtr;
  void operator=(T *) {
assign_with_AddRef_aRawPtr->AddRef();
assign_assuming_AddRef_oldPtr->Release();
  }
};
struct nsCycleCollectionParticipant {};
struct C {
  struct cycleCollection : nsCycleCollectionParticipant {
static constexpr nsCycleCollectionParticipant *GetParticipant() {
  return &_cycleCollectorGlobal;
}
  } static _cycleCollectorGlobal;
  void AddRef() { mRefCnt.incr(0, cycleCollection::GetParticipant()); }
  void Release() { mRefCnt.decr(0, cycleCollection::GetParticipant()); }
  A mRefCnt;
};
struct D {
  D(bool);
  B mNodeInfoManager;
};
D::D(bool) { mNodeInfoManager = 0; }

trippels@gcc2-power8 xslt % c++ -c -O2 txMozillaXMLOutput.ii
txMozillaXMLOutput.ii: In member function ‘void C::AddRef()’:
txMozillaXMLOutput.ii:29:36: error: location references block not in block tree
 D::D(bool) { mNodeInfoManager = 0; }
^
&_cycleCollectorGlobal
A::incr (D.2923, 0B, &_cycleCollectorGlobal);
txMozillaXMLOutput.ii:29:36: internal compiler error: verify_gimple failed
0x10b189e3 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5125
0x109ba45f execute_function_todo
../../gcc/gcc/passes.c:1958
0x109bb223 do_per_function
../../gcc/gcc/passes.c:1652
0x109bb42f execute_todo
../../gcc/gcc/passes.c:2010

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
location references block not in block tree generally means insufficient
unsharing, where some function that got through gimple-low.c where
TREE_SET_BLOCK has been used on some of the trees is sharing trees with a
different function.

[Bug middle-end/70593] [6 Regression] Miscompilation of xen starting with r226901

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 38220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38220&action=edit
gcc6-pr70593.patch

Untested fix.

[Bug target/68945] enable libcilkrts on SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ro at gcc dot gnu.org
 Depends on||70595
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #5 from Rainer Orth  ---
Since Stefan hasn't followed up and I'm currently looking at other libcilkrts
issues
anyway, I'm taking over from here.

I think I've addressed all review comments.  The necessary testsuite changes
have been split out into PR testsuite/70595.

I'm attaching my current patch, which allows all cilk-plus testcases to PASS
on 32-bit Solaris 12/SPARC.  The picture is different for 64-bit, though, where
a couple of the execution tests FAIL in a way I cannot yet make sense of: they
all
die with SIGBUS like this:

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x7f614d14 in elf_rtbndr () from /usr/lib/sparcv9/ld.so.1
(gdb) where
#0  0x7f614d14 in elf_rtbndr () from /usr/lib/sparcv9/ld.so.1
#1  0x7efd8e6c in _ti_bind_clear () from /lib/64/libc.so.1
#2  0x7f6335e8 in elf_bndr () from /usr/lib/sparcv9/ld.so.1

I suspect this is due to libcilkrts messing around with the internals of
a __builtin_setjmp/__builtin_longjmp jmpbuf in
libcilkplus/runtime/cilk_fiber-unix.cpp (cilk_fiber_sysdep::run), but haven't
yet pinpointed what's actually
wrong.  Calls for more investigation.

  Rainer


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70595
[Bug 70595] Cilk Plus testsuite needs massive cleanup

[Bug target/68945] enable libcilkrts on SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #37050|0   |1
is obsolete||

--- Comment #6 from Rainer Orth  ---
Created attachment 38221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38221&action=edit
Cleaned-up patch

[Bug rtl-optimization/70596] New: [6 Regression] -fcompare-debug failure with one extra NOTE_INSN_DELETED

[zsojka at seznam dot cz]

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

Bug ID: 70596
   Summary: [6 Regression] -fcompare-debug failure with one extra
NOTE_INSN_DELETED
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

Created attachment 38222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38222&action=edit
reduced testcase

Compiler output:
$ gcc testcase.c -O2 -fno-dce -fschedule-insns -fno-tree-coalesce-vars
-fno-tree-dce -fno-tree-fre -fno-tree-pre -fcompare-debug -mavx512f 
x86_64-pc-linux-gnu-gcc: error: testcase.c: -fcompare-debug failure (length)

$ diff -u testcase*gkd
@@ -648,7 +648,6 @@
 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 NOTE_INSN_DELETED)
 (note # 0 0 NOTE_INSN_DELETED)
-(note # 0 0 NOTE_INSN_DELETED)
 (insn/f:TI # 0 0 2 (set (reg:DI 39 r10)
 (plus:DI (reg/f:DI 7 sp)
 (const_int 8 [0x8]))) testcase.c:5# {*leadi}


The .reload dump is the first one where is one more NOTE_INSN_DELETED.

$ grep -c NOTE_INSN_DELETED *.c.*
...
testcase.c.255r.ira:155
testcase.c.256r.reload:646
testcase.c.257r.postreload:646
...
testcase.c.gk.255r.ira:155
testcase.c.gk.256r.reload:647
testcase.c.gk.257r.postreload:647
...

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #46 from Bernd Schmidt  ---
I tried compiling this file, with C or C++, with or without -fpreprocessed, all
sorts of options including -std=c++14 -O3, and did not get a compilation
failure.

Can anyone else reproduce this?

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #2)
> location references block not in block tree generally means insufficient
> unsharing, where some function that got through gimple-low.c where
> TREE_SET_BLOCK has been used on some of the trees is sharing trees with a
> different function.

That makes sense.  So in cxx_eval_call_expression we should unconditionally
unshare the result of the call because the two caches (fundef_copies_table and
constexpr_call_table) may cause us to share the same trees in different
functions.  Alternatively we can just call unshare_expr once in the top-level
cxx_eval_outermost_constant_expression, I think.  Markus, does this patch fix
the build for you?

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 7f4bb04..b2e27c1 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4140,6 +4140,7 @@ cxx_eval_outermost_constant_expr (tree t, bool
allow_non_constant,

   r = cxx_eval_constant_expression (&ctx, r,
false, &non_constant_p, &overflow_p);
+  r = unshare_expr (r);

   verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Failure no longer reproducible after r232812, "new scop schedule for isl-0.15"

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Patrick Palka from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > location references block not in block tree generally means insufficient
> > unsharing, where some function that got through gimple-low.c where
> > TREE_SET_BLOCK has been used on some of the trees is sharing trees with a
> > different function.
> 
> That makes sense.  So in cxx_eval_call_expression we should unconditionally
> unshare the result of the call because the two caches (fundef_copies_table
> and constexpr_call_table) may cause us to share the same trees in different
> functions.  Alternatively we can just call unshare_expr once in the
> top-level cxx_eval_outermost_constant_expression, I think.  Markus, does
> this patch fix the build for you?

No. It now ICEs: in maybe_constant_value_1, at cp/constexpr.c:4328

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
(In reply to Markus Trippelsdorf from comment #4)
> (In reply to Patrick Palka from comment #3)
> > (In reply to Jakub Jelinek from comment #2)
> > > location references block not in block tree generally means insufficient
> > > unsharing, where some function that got through gimple-low.c where
> > > TREE_SET_BLOCK has been used on some of the trees is sharing trees with a
> > > different function.
> > 
> > That makes sense.  So in cxx_eval_call_expression we should unconditionally
> > unshare the result of the call because the two caches (fundef_copies_table
> > and constexpr_call_table) may cause us to share the same trees in different
> > functions.  Alternatively we can just call unshare_expr once in the
> > top-level cxx_eval_outermost_constant_expression, I think.  Markus, does
> > this patch fix the build for you?
> 
> No. It now ICEs: in maybe_constant_value_1, at cp/constexpr.c:4328

What about just this instead?

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 7f4bb04..7f485d2 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1558,7 +1558,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
 }

   pop_cx_call_context ();
-  return unshare_constructor (result);
+  return unshare_expr (result);
 }

 /* FIXME speed this up, it's taking 16% of compile time on sieve testcase.  */

[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id

[asolokha at gmx dot com]

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

--- Comment #6 from Arseny Solokha  ---
(In reply to vries from comment #5)
> Failure no longer reproducible after r232812, "new scop schedule for
> isl-0.15"

There are four snippets in this PR. All except the first one (snippet 1 from
#c0) are still reproducible w/ gcc-6.0.0-alpha20160403.

[Bug c++/70498] Libiberty Demangler segfaults (3)

[bernds at gcc dot gnu.org]

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

--- Comment #1 from Bernd Schmidt  ---
Author: bernds
Date: Fri Apr  8 12:06:59 2016
New Revision: 234828

URL: https://gcc.gnu.org/viewcvs?rev=234828&root=gcc&view=rev
Log:
Handle an overflow case (PR70498, patch by Marcel Böhme).

PR c++/70498
* cplus-dem.c (gnu_special): Handle case where consume_count returns
-1.


Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cplus-dem.c

[Bug go/70597] New: [6 Regression] cmd/go: deduplicate gccgo afiles by package path, not *Package

[doko at gcc dot gnu.org]

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

Bug ID: 70597
   Summary: [6 Regression] cmd/go: deduplicate gccgo afiles by
package path, not *Package
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

see https://go-review.googlesource.com/#/c/21692/

fixes building the golang-goprotobuf package with gccgo, which worked with GCC
5.

original report at
https://bugs.launchpad.net/ubuntu/+source/gccgo-6/+bug/1566552

[Bug c++/69687] Buffer Overflow in libiberty

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
Author: bernds
Date: Fri Apr  8 12:10:21 2016
New Revision: 234829

URL: https://gcc.gnu.org/viewcvs?rev=234829&root=gcc&view=rev
Log:
Fix memory allocation size overflows (PR69687, patch by Marcel Böhme)

PR c++/69687
* cplus-dem.c: Include  if available.
(INT_MAX): Define if necessary.
(remember_type, remember_Ktype, register_Btype, string_need):
Abort if we detect cases where we the size of the allocation would
overflow.


Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cplus-dem.c

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Patrick Palka from comment #5)
> (In reply to Markus Trippelsdorf from comment #4)
> > (In reply to Patrick Palka from comment #3)
> > > (In reply to Jakub Jelinek from comment #2)
> > > > location references block not in block tree generally means insufficient
> > > > unsharing, where some function that got through gimple-low.c where
> > > > TREE_SET_BLOCK has been used on some of the trees is sharing trees with 
> > > > a
> > > > different function.
> > > 
> > > That makes sense.  So in cxx_eval_call_expression we should 
> > > unconditionally
> > > unshare the result of the call because the two caches (fundef_copies_table
> > > and constexpr_call_table) may cause us to share the same trees in 
> > > different
> > > functions.  Alternatively we can just call unshare_expr once in the
> > > top-level cxx_eval_outermost_constant_expression, I think.  Markus, does
> > > this patch fix the build for you?
> > 
> > No. It now ICEs: in maybe_constant_value_1, at cp/constexpr.c:4328
> 
> What about just this instead?

This one fixes the issue. Firefox now builds fine. Thanks.

[Bug c++/69687] Buffer Overflow in libiberty

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #13 from Bernd Schmidt  ---
Fixed.

[Bug c++/70492] Libiberty Demangler segfaults (2)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Bernd Schmidt  ---
Fixed. Commit message went to a different PR unfortunately.

[Bug c++/70498] Libiberty Demangler segfaults (3)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Bernd Schmidt  ---
That was the commit for 70492, sorry.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #47 from Roger Orr  ---
Sorry, I wasn't clear enough. I'm unfortunately not at present able to post the
whole source file.

The file I posted *only* contains the line directives, so people can confirm
whether there were any problems with them. (That file compiles fine for me too)

There seems to be some interaction with some other part of the compilation, I'm
trying to get a example I can post but this is proving troublesome.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #1)
> Without the testcase it is hard to guess.
> But one guess is that if in case of GC the cache is wiped and recreating it
> may create something -fcompare-debug cares about (e.g. creation of new decls
> - we care not about exact values of DECL_UID, but about their order), then
> the deletable cache is a serious problem, because with -g and with -g0 there
> is likely different amount of memory used, which means ggc_collect at
> different times and thus we could be using the cache successfully with -g
> and not without -g or vice versa.

I'm having trouble imagining a scenario where the order of two decls changes
due to the tables getting deleted.  Clearing of the tables would cause copy_fn
to get called a few more times in the subsequent constexpr call evaluations,
causing later DECL_UIDs to be bigger but still in the same order I think.

And I don't think the remapped decls of a copied constexpr function body could
ever be visible to the callee so their particular DECL_UIDs shouldn't matter...

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #48 from Bernd Schmidt  ---
Try running cc1plus with valgrind to see whether that detects anything
untoward.

[Bug tree-optimization/70577] [6 regression] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|tree-ssa/prefetch-5.c   |[6 regression]
   |scan-tree-dump-times|tree-ssa/prefetch-5.c
   |aprefetch failures  |scan-tree-dump-times
   ||aprefetch failures

--- Comment #4 from Rainer Orth  ---
This is a regression from the gcc-5 branch.

[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #15 from Marek Polacek  ---
It's now up to me to handle the C FE side.

[Bug tree-optimization/70577] [6 regression] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Hi.

It shows that after Honza's change, 'estimated_stmt_executions_int' return -1
for all 3 situations.
Thus 'Issued prefetch' is not printed to the dump file.

However, before Honza's patch was applied, estimated_stmt_executions_int
returns strange results for following 2 loops:

struct tail0
{
  int xxx;
  int yyy[2];
};

int loop0 (int n, struct tail0 *x)
{
  int i, s = 0;

  for (i = 0; i < n; i++)
s += x->yyy[i];

  return s;
}

returns 3, however:

struct tail1
{
  int xxx;
  int yyy[1];
};

int loop1 (int n, struct tail1 *x)
{
  int i, s = 0;

  for (i = 0; i < n; i++)
s += x->yyy[i];

  return s;
}

returns -1. Well, I would expect here to we given value 2. According to tree
dump file, both loops have exactly the same CFG.

Martin

[Bug fortran/70598] New: Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

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

Bug ID: 70598
   Summary: Fortran OpenACC host_data construct ICE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: major
  Priority: P3
 Component: fortran
  Assignee: cltang at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As once reported in

and thereabouts, there is no execution (libgomp) testing of the Fortran OpenACC
host_data construct, and the one test case present on gomp-4_0-branch,
libgomp.oacc-fortran/host_data-1.f90, runs into an ICE (for trunk as well as
gomp-4_0-branch).  Please have a look at that, and also increase test coverage
(for example, by translating C/C++ execution (libgomp) test cases, if
applicable).

As the implementation of OpenACC host_data/use_device has been completely
re-done during patch review (to match OpenMP's use_device_ptr clause), I
suppose it's possible that there is some middle end infrastructure missing to
deal with constructs generated by the Fortran front end.  Maybe Jakub can
advise on that, in case he's already started implementing the Fortran support
for OpenMP (which is currently missing).  Or maybe the ICE is due to something
completely different.  ;-)

[Bug fortran/70598] Fortran OpenACC host_data construct ICE

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-08
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug c++/70599] New: Crash when adding debug symbols to a program making heavy use of nested templates.

[graemehattan7 at hotmail dot com]

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

Bug ID: 70599
   Summary: Crash when adding debug symbols to a program making
heavy use of nested templates.
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: graemehattan7 at hotmail dot com
  Target Milestone: ---

This issue was found while trying to compile the source code for the aprinter
3D printer firmware - https://github.com/ambrop72/aprinter

Normal compilation works fine, the issue is when I try to add the -g option for
a debug build. When I do this, the compilation resources increase until 100%
cpu and memory are used. Eventually I get the following message:

arm-none-eabi-gcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The aprinter software makes heavy use of nested templates, I imagine that this
is what trigger the issue. I have attached the pre-processor output from the
file that fails. Unfortunately this is quite large due to the number of headers
defining template classes.

The issue can be reproduced with the following command -

arm-none-eabi-gcc -g -x c++ -c -mcpu=cortex-m3 -mthumb -Wall -Wextra
-Wfatal-errors -Wno-unused -Wno-sign-compare -std=c++11 -fno-access-control
aprinter-nixbuild.ii

Note that there will be a lot of compiler warnings produced (~750 MB!) if the
-Wno-unused flag is removed. This is in part because of the very long type
names produced by template nesting.

Additional info:

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/nix/store/hq0izgjckpfiw9mmbh4lz2skfx70bzlw-gcc-arm-embedded-fromsrc-5.3.0/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/nix/store/hq0izgjckpfiw9mmbh4lz2skfx70bzlw-gcc-arm-embedded-fromsrc-5.3.0/libexec/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-5.3.0/configure --target=arm-none-eabi
--prefix=/nix/store/hq0izgjckpfiw9mmbh4lz2skfx70bzlw-gcc-arm-embedded-fromsrc-5.3.0
--with-sysroot=/nix/store/hq0izgjckpfiw9mmbh4lz2skfx70bzlw-gcc-arm-embedded-fromsrc-5.3.0/arm-none-eabi
--enable-interwork --disable-nls
--with-build-time-tools=/nix/store/hq0izgjckpfiw9mmbh4lz2skfx70bzlw-gcc-arm-embedded-fromsrc-5.3.0/arm-none-eabi/bin
--enable-poison-system-directories --enable-lto --enable-gold
--disable-decimal-float --disable-libffi --disable-libgomp
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-threads --disable-shared --disable-tls --with-newlib
--disable-libunwind-exceptions --enable-checking=release
--enable-languages=c,c++
Thread model: single
gcc version 5.3.0 (GCC)

The compiler was built via the nix-build derivation included in aprinter -
https://github.com/ambrop72/aprinter/blob/master/nix/gcc-arm-embedded-fromsrc.nix

This includes some (small) custom patches which are included in the aprinter
code. As far as I can see they are unrelated to the issue.

I have also tried to use the arm-none-eabi compiler in the Ubunutu 15.10
repositories (4.9.3) and have the same issue -

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/4.9.3/lto-wrapper
Target: arm-none-eabi
Configured with: ../src/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/lib/include' --mandir='/usr/lib/share/man'
--infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir='/usr/lib/lib/x86_64-linux-gnu'
--libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man
--enable-languages=c,c++,lto --enable-multilib --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --build=x86_64-linux-gnu --target=arm-none-eabi
--with-system-zlib --with-gnu-as --with-gnu-ld
--with-pkgversion=15:4.9.3+svn227297-1 --without-included-gettext
--prefix=/usr/lib --infodir=/usr/share/doc/gcc-arm-none-eabi/info
--htmldir=/usr/share/doc/gcc-arm-none-eabi/html
--pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3
--host=x86_64-linux-gnu --with-headers=no --without-newlib
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r CFLAGS='-g -O2
-fstack-protector-strong' CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS='-g -O2
-fstack-protector-strong' FCFLAGS='-g -O2 -fstack-protector-strong' FFLAGS='-g
-O2 -fstack-protector-strong' GCJFLAGS='-g -O2 -fstack-protector-strong'
LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2
-fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fstack-protector-strong'
INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0 AR_FOR_TA

[Bug c++/70599] Crash when adding debug symbols to a program making heavy use of nested templates.

[graemehattan7 at hotmail dot com]

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

--- Comment #1 from Graeme  ---
Created attachment 38223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38223&action=edit
Pre-processed source file, gzipped to get around size limit.

[Bug c++/70588] [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Jakub, feel free to remove the regression marker if you don't think it's
appropriate.

[Bug tree-optimization/70600] New: Missed tree optimization with multiple additions in different types.

[bernds at gcc dot gnu.org]

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

Bug ID: 70600
   Summary: Missed tree optimization with multiple additions in
different types.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernds at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

The following is a testcase reduced from a Linux kernel file. Compile with -O2
on x86_64-linux.

There are two additions, the first in type unsigned long, the second one after
casting the first result to unsigned int. Together, they end up as a no-op, but
this is not caught during tree optimization. The combiner finally manages to
eliminate them, with the help of a note added by fwprop.

(I was looking at whether we could eliminate the creation of REG_EQUAL notes
from fwprop, and found only three cases out of a set of 4492 source files where
they changed code generation; this was one of them.)

int p (long mem_map, long page, unsigned int *p, unsigned int *frag)
{

  unsigned int _83 = *p;
  long _142 = page - mem_map;
  long _143 = _142 / 56;
  unsigned long _144 = _143;
  unsigned long _145 = _144 << 12;
  unsigned long _146 = _145 + 0xc000;
  unsigned int _147 = _146;
  unsigned int _190 = _83 + 0x4000;
  unsigned int _149 = _147 + _190;
  return _149;
}

[Bug fortran/70592] Addressing error in dynamically-allocated character array

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
  Known to work||5.3.1, 6.0

--- Comment #1 from kargl at gcc dot gnu.org ---
On i686-*-freebsd, I get 

laptop-kargl:kargl[220] ./z
6 1 6
1 679608344 2 679608345
3 679608346 4 679608347
5 679608348 6 679608349
 123456

On x86_64-*-freebsd, I get

troutmask:sgk[203] gfc6 -o z a.f90
troutmask:sgk[204] ./z
6 1 6
1 8615239704 2 8615239705
3 8615239706 4 8615239707
5 8615239708 6 8615239709
 123456
troutmask:sgk[205] gfc5 -o z a.f90
troutmask:sgk[206] ./z
6 1 6
1 8615239704 2 8615239705
3 8615239706 4 8615239707
5 8615239708 6 8615239709
 123456

So, the appears to be fixed on both trunk and the 5-branch.

[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 38224
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38224&action=edit
gcc6-pr70586.patch

Untested fix.  In my understanding, even const functions can contain floating
point math (that could raise floating point exceptions) or integer
division/modulo without constant divisor, at least our pure/const discovery
doesn't care about those, and I bet the vast majority of floating point const
functions could in some cases raise exceptions etc.
Thus IMHO for ifcombine no side effects discovery even const calls are
problematic, we shouldn't move calls to them before conditions that originally
guarded them, as in this example where the (after fnsplit) condition in the
caller checks that the second argument is not 0 and only calls the const
function if the second argument is non-zero, but ifcombine arranges for the
condition to be tested only after the call instead of before it.

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka  ---
Reduced :


// PR c++/70590
// { dg-options "-O2" }

int a;

constexpr int *
foo ()
{
  return &a;
}

void blah (int *);

int
bar ()
{
  blah (foo ());
}

int
baz ()
{
  blah (foo ());
}

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  ---
Created attachment 38225
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38225&action=edit
test.ii  test case (g++ -O1 -fcompare-debug)

(In reply to Jakub Jelinek from comment #1)
> Without the testcase it is hard to guess.

I now tried to compile LLVM with -fcompare-debug - and I guessed correctly, one
of the files also fails there (lib/Support/CommandLine.cpp).

I am not sure whether it is the same issue, but it is a debug miscompare.
Contrary to my original file, it also fails when a .ii is generated with "-E";
additionally, it also fails already with -O1 and it reduced more readily (for
my original example, it seemed to depend much more on the memory layout such
that comment lines were kept).

The somewhat reduced example is attached; it fails here (and hopefully
elsewhere) using "g++ -O1 -fcompare-debug" with: "g++: error: test.ii:
-fcompare-debug failure".

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

--- Comment #8 from Patrick Palka  ---
(In reply to Markus Trippelsdorf from comment #6)
> (In reply to Patrick Palka from comment #5)
> > (In reply to Markus Trippelsdorf from comment #4)
> > > (In reply to Patrick Palka from comment #3)
> > > > (In reply to Jakub Jelinek from comment #2)
> > > > > location references block not in block tree generally means 
> > > > > insufficient
> > > > > unsharing, where some function that got through gimple-low.c where
> > > > > TREE_SET_BLOCK has been used on some of the trees is sharing trees 
> > > > > with a
> > > > > different function.
> > > > 
> > > > That makes sense.  So in cxx_eval_call_expression we should 
> > > > unconditionally
> > > > unshare the result of the call because the two caches 
> > > > (fundef_copies_table
> > > > and constexpr_call_table) may cause us to share the same trees in 
> > > > different
> > > > functions.  Alternatively we can just call unshare_expr once in the
> > > > top-level cxx_eval_outermost_constant_expression, I think.  Markus, does
> > > > this patch fix the build for you?
> > > 
> > > No. It now ICEs: in maybe_constant_value_1, at cp/constexpr.c:4328
> > 
> > What about just this instead?
> 
> This one fixes the issue. Firefox now builds fine. Thanks.

Markus, when you have time, can you please test this patch?

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 649d336..6acd5fc 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4144,6 +4144,9 @@ cxx_eval_outermost_constant_expr (tree t, bool
allow_non_constant,

   r = cxx_eval_constant_expression (&ctx, r,
false, &non_constant_p, &overflow_p);
+  if (r != t
+  && TREE_CODE (r) != CONSTRUCTOR)
+r = unshare_expr (r);

   verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);


It is one that I'm more comfortable with.(In reply to Markus Trippelsdorf from
comment #6)
> (In reply to Patrick Palka from comment #5)
> > (In reply to Markus Trippelsdorf from comment #4)
> > > (In reply to Patrick Palka from comment #3)
> > > > (In reply to Jakub Jelinek from comment #2)
> > > > > location references block not in block tree generally means 
> > > > > insufficient
> > > > > unsharing, where some function that got through gimple-low.c where
> > > > > TREE_SET_BLOCK has been used on some of the trees is sharing trees 
> > > > > with a
> > > > > different function.
> > > > 
> > > > That makes sense.  So in cxx_eval_call_expression we should 
> > > > unconditionally
> > > > unshare the result of the call because the two caches 
> > > > (fundef_copies_table
> > > > and constexpr_call_table) may cause us to share the same trees in 
> > > > different
> > > > functions.  Alternatively we can just call unshare_expr once in the
> > > > top-level cxx_eval_outermost_constant_expression, I think.  Markus, does
> > > > this patch fix the build for you?
> > > 
> > > No. It now ICEs: in maybe_constant_value_1, at cp/constexpr.c:4328
> > 
> > What about just this instead?
> 
> This one fixes the issue. Firefox now builds fine. Thanks.

When you have time, could you please test this patch?

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 7f4bb04..b66cbad 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -4143,6 +4143,12 @@ cxx_eval_outermost_constant_expr (tree t, bool
allow_non_constant,

   verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);

+  /* Unshare the result unless it's a CONSTRUCTOR in which case it's already
+ unshared.  */
+  if (r != t
+  && TREE_CODE (r) != CONSTRUCTOR)
+r = unshare_expr (r);
+
   /* Mutable logic is a bit tricky: we want to allow initialization of
  constexpr variables with mutable members, but we can't copy those
  members to another constexpr variable.  */

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Which hunk do you want me to test?

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[ppalka at gcc dot gnu.org]

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

--- Comment #10 from Patrick Palka  ---
(In reply to Markus Trippelsdorf from comment #9)
> Which hunk do you want me to test?

The last one, sorry about the garbled message.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[ppalka at gcc dot gnu.org]

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

--- Comment #5 from Patrick Palka  ---
(In reply to Tobias Burnus from comment #4)
> Created attachment 38225 [details]
> test.ii  test case (g++ -O1 -fcompare-debug)
> 
> (In reply to Jakub Jelinek from comment #1)
> > Without the testcase it is hard to guess.
> 
> I now tried to compile LLVM with -fcompare-debug - and I guessed correctly,
> one of the files also fails there (lib/Support/CommandLine.cpp).
> 
> I am not sure whether it is the same issue, but it is a debug miscompare.
> Contrary to my original file, it also fails when a .ii is generated with
> "-E"; additionally, it also fails already with -O1 and it reduced more
> readily (for my original example, it seemed to depend much more on the
> memory layout such that comment lines were kept).
> 
> The somewhat reduced example is attached; it fails here (and hopefully
> elsewhere) using "g++ -O1 -fcompare-debug" with: "g++: error: test.ii:
> -fcompare-debug failure".

Same here.  Some observations:

Reverting the portion of the patch that added the "deletable" GTY tag to
constexpr_call_table fixes the failure.

Making get_fundef_copy() to always allocate a new function (thus making it as
if the fundef_copies_table didn't exist) doesn't fix the failure.

So it seems that adding the "deletable" GTY tag to constexpr_call_table is
responsible for this regression, and not the new fundef_copies_table.  Still
have no idea why or how though.

[Bug c++/70588] [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||16994

--- Comment #4 from Martin Sebor  ---
I should add that the test case in comment #0 isn't the best.  It just squeaks
by in 4.9.3 because of the optimization.  Without optimization, it crashes too.
 This is because the code that implements the bounds overflow detection has a
bug that prevents it from reliably detecting the SIZE_MAX / 2 + 1 case.  It
works correctly for larger values (SIZE_MAX / 2 + 2 to SIZE_MAX) but only for
one-dimensional VLAs, and fails for things like char a[2][N] for very large N.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
[Bug 16994] [meta-bug] VLA and C++

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
(In reply to Patrick Palka from comment #10)
> (In reply to Markus Trippelsdorf from comment #9)
> > Which hunk do you want me to test?
> 
> The last one, sorry about the garbled message.

Firefox compiles fine with this one, too.

[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||afanfa at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Tobias, Alessandro,

could you shed some light what should happen here?  This is a regression after
all.

Thanks.
  Rainer

[Bug debug/70599] Crash when adding debug symbols to a program making heavy use of nested templates.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-08
 CC||ktkachov at gcc dot gnu.org
  Component|c++ |debug
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed that adding -g does indeed use up much more memory and gets killed by
my machine too, whereas without -g it succeeds, producing an assembly file with
313851 lines.

Generating debug info is known to increase memory usage, but I don't know if
such an increase is expected for a file of type.

[Bug c++/70590] [6 Regression] r234810 causes error: location references block not in block tree

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Patrick Palka from comment #8)
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -4143,6 +4143,12 @@ cxx_eval_outermost_constant_expr (tree t, bool
> allow_non_constant,
>  
>verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);
>  
> +  /* Unshare the result unless it's a CONSTRUCTOR in which case it's already
> + unshared.  */
> +  if (r != t
> +  && TREE_CODE (r) != CONSTRUCTOR)
> +r = unshare_expr (r);
> +
>/* Mutable logic is a bit tricky: we want to allow initialization of
>   constexpr variables with mutable members, but we can't copy those
>   members to another constexpr variable.  */

Wouldn't it be better to move it even further down, so that we don't unshare
even when actually not returning r or something based on it?
E.g. (completely untested)?

--- gcc/cp/constexpr.c.jj   2016-04-07 23:27:44.0 +0200
+++ gcc/cp/constexpr.c  2016-04-08 17:36:49.774326934 +0200
@@ -4168,6 +4168,11 @@ cxx_eval_outermost_constant_expr (tree t
 return error_mark_node;
   else if (non_constant_p && TREE_CONSTANT (r))
 {
+  /* Unshare the result unless it's a CONSTRUCTOR in which case it's
+ already unshared.  */
+  if (r != t && TREE_CODE (r) != CONSTRUCTOR)
+   r = unshare_expr (r);
+
   /* This isn't actually constant, so unset TREE_CONSTANT.  */
   if (EXPR_P (r))
r = copy_node (r);
@@ -4179,6 +4184,10 @@ cxx_eval_outermost_constant_expr (tree t
 }
   else if (non_constant_p || r == t)
 return t;
+  /* Unshare the result unless it's a CONSTRUCTOR in which case it's
+ already unshared.  */
+  else if (r != t && TREE_CODE (r) != CONSTRUCTOR)
+r = unshare_expr (r);

   if (TREE_CODE (r) == CONSTRUCTOR && CLASS_TYPE_P (TREE_TYPE (r)))
 {

[Bug target/68945] enable libcilkrts on SPARC

[stefan.teleman at oracle dot com]

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

--- Comment #7 from Stefan Teleman  ---
> Since Stefan hasn't followed up and I'm currently looking at other
> libcilkrts issues anyway, I'm taking over from here.

Had every intention to follow-up with a cleaned-up patch, but did not find
the time to re-do the patch.

I will look into the SIGBUS crashes on SPARC64 and see what i come up
with.

[Bug tree-optimization/70600] Missed tree optimization with multiple additions in different types.

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-08
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
We could match a pattern (a±c1)±(b±c2) with intermediate conversions, or try to
generalize reassoc, but in this particular case, it mostly looks like yet
another example for the missing narrowing pass. _146 has a single use, which is
a narrowing conversion to a "good" type (not something like a 16 bit 'short' on
a platform where all arithmetic insns are for 32 bits), so I can't see any
reason not to perform the addition (with a constant) in the narrower mode, and
transitively the shift as well.

[Bug fortran/70601] New: [OOP] ICE on procedure pointer component call

[zmi007 at gmail dot com]

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

Bug ID: 70601
   Summary: [OOP] ICE on procedure pointer component call
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zmi007 at gmail dot com
  Target Milestone: ---

I am playing around with procedure pointer components and get ICE 

module_gfortran_bug.f90:62:0:

call concrete % run()

internal compiler error: in fold_convert_loc, at fold-const.c:2256

on the following code with gfortran-6 [trunk revision 234449]. Note that I am
not sure if the code is valid, but ifort 16 is able to compile it.


! code
module abstract_type_module
   implicit none
   private
   public :: abstract_type


   type, abstract :: abstract_type
  procedure (abstract_type_procedure1), pointer :: run => NULL()
   end type abstract_type

   abstract interface
  subroutine abstract_type_procedure1(this)
 import  :: abstract_type
 class(abstract_type), intent(inout) :: this
  end subroutine abstract_type_procedure1
   end interface

end module abstract_type_module


module concrete_type_module
   use abstract_type_module
   implicit none
   private
   public :: concrete_type

   type, extends(abstract_type) :: concrete_type
   contains
  procedure , pass :: init => init_concrete_type
   end type concrete_type

contains

   subroutine  run_concrete_type(this)
  implicit none
  class(abstract_type), intent(inout) :: this

select type (this)
type is (concrete_type)
write(*,*) "run_concrete_type"
class default
write(*,*) "?"
end select
   end subroutine run_concrete_type

   subroutine  init_concrete_type(this)
  implicit none
  class(concrete_type), intent(inout) :: this
  this % run => run_concrete_type
  write(*,*) "init_concrete_type"

   end subroutine init_concrete_type

end module concrete_type_module


programtest
   use concrete_type_module
   implicit none
type(concrete_type) :: concrete

   call concrete % init()
   call concrete % run()

end program test

[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 regression] SIGBUS on  |SIGBUS on a VLA larger than
   |a VLA larger than SIZE_MAX  |SIZE_MAX / 2
   |/ 2 |

--- Comment #5 from Jakub Jelinek  ---
Also, I kind of don't understand why is it so important to diagnose SIZE_MAX /
2 VLAs, when already significantly smaller VLAs will not really work on most
systems (say with most Linux defaults usually something over 10MB or so
already).
As the VLAs in C++ are just an extension, IMHO it is better to keep it closer
to the C VLAs (not throw etc.).

[Bug fortran/70601] [OOP] ICE on procedure pointer component call

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-04-08
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME (x86_64-apple-darwin15) from 4.8 up to trunk (6.0).

[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I agree that the SIZE_MAX/2 limit isn't very useful.   A lower limit would be
more useful (I proposed one on the order of tens of kilobytes to megabytes in
my patch for bug 69517).  Jason and I have been discussing making the limit
customizable somehow (see
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00368.html for some ideas --
suggestions for better solutions are welcome).

Other than that, while I also agree with the goal of keeping C++ VLAs close to
C, since overflowing the stack is the most serious shortcoming of the latter,
detecting and preventing that condition (as well as detecting excess
initializers in the G++ extension) by throwing an exception is an important
improvement that makes the feature safer to use.  It is in line with how
overflowing array bounds in the array new expression is handled.

(As an aside, since C doesn't have exceptions, trapping or aborting in case of
bound overflow might be worth considering as a stopgap solution.)

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #49 from Roger Orr  ---
Alas, valgrind finds nothing untoward.

make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" clean-stage1
make MAKEINFO=true STAGE1_CXXFLAGS="-g -O0" all-stage1

valgrind /var/tmp/gcc-trunk-234481/build/gcc/cc1plus -fpreprocessed direct.ii
-quiet -dumpbase direct.ii -mtune=generic -march=x86-64 -auxbase direct -O3
-Werror -std=c++14 -fmax-errors=1 -o /tmp/ccGReQOF.s

I've also tried a build with -fsanitize=address,undefined but this too reports
no problems.

Running under gdb and breaking at libcpp/directives.c:1057 I can see the
following:

(gdb) p MAIN_FILE_P(map)
$17 = true

# This is the reason why it is trying to print the message

  if (reason == LC_LEAVE)
{
  const line_map_ordinary *from;
  if (MAIN_FILE_P (map)
  || (/*...*/))
  {
cpp_warning ( // ...


(gdb) p map
$18 = (const line_map_ordinary *) 0x7fffec6ddfe0

(gdb) p *map
$19 = { = {start_location = 2779096485, reason = 165}, to_file =
0xa5a5a5a5a5a5a5a5 ,
to_line = 2779096485,
  included_from = -1515870811, sysp = 165 '▒', m_column_and_range_bits = 165,
m_range_bits = 165}

# These values look concerning ... what do they mean and where do they come
from?!

'map' comes from line 979:

const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (line_table);

(gdb) p line_table
$20 = (line_maps *) 0x7fffecf8b000
(gdb) p *line_table
$21 = {info_ordinary = {maps = 0x7fffec9f4000, allocated = 16384, used = 4097,
cache = 4096}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0},
depth = 3,
  trace_includes = false, highest_location = 485446816, highest_line =
485446816, max_column_hint = 256, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4140, allocated =
8192, data = 0x7fffeb80c000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 486644, num_unoptimized_ranges = 4140}

This code is unknown to me, so I am not sure where to look next ...

[Bug fortran/70601] [OOP] ICE on procedure pointer component call

[zmi007 at gmail dot com]

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

--- Comment #2 from zmi  ---
and this one?

programtest
   use concrete_type_module
   implicit none
type(concrete_type), allocatable :: concrete
allocate(concrete)

   call concrete % init()
   call concrete % run()

end program test

[Bug c++/39159] unhelpful attribute warning on matching declaration after definition

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I'm not an expert in this area but the approach seems reasonable to me.  I
didn't test it in 5.x but with 6.0, it doesn't make a difference because
simple_cst_equal() cannot compare TREE_LISTs.  Using attribute_value_equal()
instead does work.

>From a user's point of view, though, it would be helpful if the diagnostic
included the names of the "new" attributes that are being ignored, and pointed
to the location of the previous "old" declaration that the current one
conflicts with.  The former should be a matter of concatenating the names of
the new attributes into a string and making that part of the warning.  The
latter can be done by calling:

  inform (DECL_SOURCE_LOCATION (TYPE_FIELDS (*anode)), "previous declaration
here");

To get the patch reviewed and ultimately approved, you should rebase it to the
current trunk, add tests and ChangeLog entries, and post it to gcc-patches.

[Bug fortran/70601] [OOP] ICE on procedure pointer component call

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> and this one?
> ...

It gives

call concrete % run()

internal compiler error: in fold_convert_loc, at fold-const.c:2256

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #50 from Bernd Schmidt  ---
The 0xa5 bytes probably come from ggc-page, which tries to poison freed memory.
This does suggest that there's a use-after-free issue here.

At the step after "p map", try "watch -l map->to_file" followed by "run", which
should get you to the point where the memory is overwritten.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #51 from Roger Orr  ---
Thanks, I hope to try that on Monday.
The function gets called multiple times, so I need to identify the last time.

The memory must have changed *during* the call to do_linemarker as the new_file
variable is set from map on line 981:

  const char *new_file = ORDINARY_MAP_FILE_NAME (map);

but the same call executed now fails:

(gdb) p ORDINARY_MAP_FILE_NAME (map)
$3 = 0xa5a5a5a5a5a5a5a5 

[Bug bootstrap/70519] genmatch fails to compile under gcc-5.2.0 - missing '-lstdc++' .

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #11 from Jim Wilson  ---
The -lstdc++ is added by lang_specific_driver in g++spec.c.  g++spec.o is
linked into xg++.  In the function lang_specific_driver, library is set to 1 if
the input file is not a header file, and then near the bottom a generate_option
call adds the -lstdc++ to the command line options.  You should debug
lang_specific_driver to see why it isn't working.

[Bug fortran/70601] [OOP] ICE on procedure pointer component call

[zmi007 at gmail dot com]

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

--- Comment #4 from zmi  ---
ok, my fault)
ice on allocatable type only

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[rogero at howzatt dot demon.co.uk]

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

--- Comment #52 from Roger Orr  ---
Ah - added print of *pfile->line_table  at line 978 and compared with the value
when we error.

978   struct line_maps *line_table = pfile->line_table;
$3702 = {info_ordinary = {maps = 0x7fffec65d000, allocated = 4096, used = 4096,
cache = 4095}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache = 0},
depth = 8,
  trace_includes = false, highest_location = 511461984, highest_line =
511461856, max_column_hint = 128, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4884, allocated =
8192, data = 0x7fffeb7ab000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 500030, num_unoptimized_ranges = 4884}

(gdb) p *pfile->line_table
$3703 = {info_ordinary = {maps = 0x7fffec993000, allocated = 16384, used =
4097, cache = 4096}, info_macro = {maps = 0x0, allocated = 0, used = 0, cache =
0}, depth = 8,
  trace_includes = false, highest_location = 511470272, highest_line =
511470272, max_column_hint = 256, reallocator = 0x25409c0
,
  round_alloc_size = 0x11bf0fa ,
location_adhoc_data_map = {htab = 0x60b0ad80, curr_loc = 4885, allocated =
8192, data = 0x7fffeb7ab000},
  builtin_location = 1, seen_line_directive = true, default_range_bits = 5,
num_optimized_ranges = 500031, num_unoptimized_ranges = 4885}


The 'mapos' address has changed and the allocated size has changed from 4096 to
16384. The 'map' variable points 0x1ffe0 bytes beyond the *old* value of maps.

[Bug c++/70594] [6 Regression] -fcompare-debug failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to Tobias Burnus from comment #4)
> Created attachment 38225 [details]
> test.ii  test case (g++ -O1 -fcompare-debug)
> 
> (In reply to Jakub Jelinek from comment #1)
> > Without the testcase it is hard to guess.
> 
> I now tried to compile LLVM with -fcompare-debug - and I guessed correctly,
> one of the files also fails there (lib/Support/CommandLine.cpp).
> 
> I am not sure whether it is the same issue, but it is a debug miscompare.
> Contrary to my original file, it also fails when a .ii is generated with
> "-E"; additionally, it also fails already with -O1 and it reduced more
> readily (for my original example, it seemed to depend much more on the
> memory layout such that comment lines were kept).
> 
> The somewhat reduced example is attached; it fails here (and hopefully
> elsewhere) using "g++ -O1 -fcompare-debug" with: "g++: error: test.ii:
> -fcompare-debug failure".

That looks like a different issue though, perhaps make_fancy_decl_name should
not add DECL_UID to the names, but just D. instead, either when
-fdump-final-insns= option is used only, or always?
E.g. if the FIELD_DECLs or VAR_DECLs etc. have no name and different DECL_UIDs,
they will then show up in -fdump-final-insns= dumps, which have means to 
print  instead of actual uids, but in the SSA fancy names doesn't know
there are any uids embedded in there.
That said, if the constexpr processing in case the cache has been emptied can
create new decls, then I generally don't see how the desirable same order of
uids for the same things could be ever guaranteed.
Consider constexpr handling of some function (which puts it into cache), that
creates DECL_UIDs 37, 38, 39.  Then some further parsing is performed, and
DECL_UIDs 40, 41, 42 are created.  Then we do constexpr handling for the same
function, if we find it in the cache, we don't generate new uids, otherwise, if
GC happens after DECL_UID 42 generation, we need to redo the constexpr handling
and create DECL_UIDs 43, 44, 45.
Now the important question is if these decls (VAR_DECLs, CONST_DECLs,
FIELD_DECLs, PARM_DECLs, RESULT_DECLs, FUNCTION_DECLs) can ever make it into
the IL or not.  If they would be just temporaries during the constexpr
processing, perhaps we are fine if we fix up the tree-sra.c case, but the #c0
hints perhaps something different.
The Declarations used... list that #c0 differs on is sorted by DECL_UID.

[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

[bernds at gcc dot gnu.org]

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

--- Comment #53 from Bernd Schmidt  ---
Hmm. Something got reallocated perhaps? It's not entirely obvious to me where
that would happen. Does the following help at all?

Index: directives.c
===
--- directives.c(revision 234831)
+++ directives.c(working copy)
@@ -977,6 +977,8 @@ do_linemarker (cpp_reader *pfile)
 {
   struct line_maps *line_table = pfile->line_table;
   const line_map_ordinary *map = LINEMAPS_LAST_ORDINARY_MAP (line_table);
+  bool main_file_p = MAIN_FILE_P (map);
+  const line_map_ordinary *from = INCLUDED_FROM (pfile->line_table, map);
   const cpp_token *token;
   const char *new_file = ORDINARY_MAP_FILE_NAME (map);
   linenum_type new_lineno;
@@ -1048,10 +1050,9 @@ do_linemarker (cpp_reader *pfile)

   if (reason == LC_LEAVE)
 {
-  const line_map_ordinary *from;  
-  if (MAIN_FILE_P (map)
+  if (main_file_p
  || (new_file
- && (from = INCLUDED_FROM (pfile->line_table, map)) != NULL
+ && from != NULL
  && filename_cmp (ORDINARY_MAP_FILE_NAME (from), new_file) != 0))
{
  cpp_warning (pfile, CPP_W_NONE,

[Bug tree-optimization/65447] AArch64: iv-opt causes bad addressing

[ctice at gcc dot gnu.org]

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

--- Comment #5 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Apr  8 17:09:09 2016
New Revision: 234832

URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev
Log:
Unify changes with Android's GCC 4.9 compiler.

Add the following changes from the Android
GCC 4.9 compiler (mostly adding fixes for aarch64):

Fix mingw build breakage
1) Add missing _GCOV_fopen if !__KERNEL__
2) Use _fullpath

Backport Cortex-A57's machine description support from trunk

Adjust generic move costs for aarch64. Backport from trunk

Enable C++ exceptions and RTTI by default.

Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default

Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs.

Drop mips64r2 from Android compiler's multilib

Merge "Drop mips64r2 from Android compiler's multilib"

Adjust several costs for AArch64:
  Refactor aarch64_address_costs; add cost tables for Cortex-A7;
  better estimate cost of building a constant; wrap aarch64_rtx_costs
  to dump verbose output; factor out common MULT cases; det default
  costs and handle vector modes; cost memory accesses using address
  costs; better cost logical operations; improve costs for div/mod and
  sign/zero extend operations; cost comparisons, flag setting
  operators and IF_THEN_ELSE; cost more Floating point RTX; cost
  TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are
  unable to cost an insn; fix typos in cost data structure.


Add several improvements for AArch64 (Backported from GCC 5):
  (spill code - swap order in shr patterns; spill code - swap order in
  shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in
  FP compare-with-0.0 case; properly cost FABD pattern; properly
  handle mvn-register and add EON+shift pattern and cost
  appropriately).

Disable inlining of memcpy for x86 with 'rep movs'.
Default to TLS guard for x86 stack-protector.
Change gcc BASE-VER from 4.9.x-google to 4.9.x

Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954
(svn rev 230894, PR tree-optimization/65447,
PR tree-optimization/52563, tree-optimization/62173,
PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735.

Port revision 219584 from linaro/gcc-4_9-branch

Fix for arm64 bad code for copysignl.


Added:
branches/google/gcc-4_9-mobile/gcc/sancov.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c
Modified:
branches/google/gcc-4_9-mobile/ChangeLog
branches/google/gcc-4_9-mobile/config/futex.m4
branches/google/gcc-4_9-mobile/configure
branches/google/gcc-4_9-mobile/configure.ac
branches/google/gcc-4_9-mobile/gcc/BASE-VER
branches/google/gcc-4_9-mobile/gcc/ChangeLog
branches/google/gcc-4_9-mobile/gcc/Makefile.in
branches/google/gcc-4_9-mobile/gcc/builtins.def
branches/google/gcc-4_9-mobile/gcc/cfghooks.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.h
branches/google/gcc-4_9-mobile/gcc/common.opt
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt
branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c
branches/google/gcc-4_9-mobile/gcc/config/linux-android.h
branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64
branches/google/gcc-4_9-mobile/gcc/configure
branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi
branches/google/gcc-4_9-mobile/gcc/except.c
branches/google/gcc-4_9-mobile/gcc/expmed.c
branches/google/gcc-4_9-mobile/gcc/gcov-io.h
branches/google/gcc-4_9-mobile/gcc/loop-init.c
branches/google/gcc-4_9-mobile/gcc/lra-constraints.c
branches/google/gcc-4_9-mobile/gcc/omp-low.c
branches/google/gcc-4_9-mobile/gcc/params.def
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/sanitizer.def
branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.h
branches/google/gcc-4_9-mobile/gcc/tree-chrec.c
branches/goog

[Bug bootstrap/66638] [6 Regression] profiledbootstrap failure on x86-64 with LTO

[ctice at gcc dot gnu.org]

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

--- Comment #7 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Apr  8 17:09:09 2016
New Revision: 234832

URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev
Log:
Unify changes with Android's GCC 4.9 compiler.

Add the following changes from the Android
GCC 4.9 compiler (mostly adding fixes for aarch64):

Fix mingw build breakage
1) Add missing _GCOV_fopen if !__KERNEL__
2) Use _fullpath

Backport Cortex-A57's machine description support from trunk

Adjust generic move costs for aarch64. Backport from trunk

Enable C++ exceptions and RTTI by default.

Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default

Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs.

Drop mips64r2 from Android compiler's multilib

Merge "Drop mips64r2 from Android compiler's multilib"

Adjust several costs for AArch64:
  Refactor aarch64_address_costs; add cost tables for Cortex-A7;
  better estimate cost of building a constant; wrap aarch64_rtx_costs
  to dump verbose output; factor out common MULT cases; det default
  costs and handle vector modes; cost memory accesses using address
  costs; better cost logical operations; improve costs for div/mod and
  sign/zero extend operations; cost comparisons, flag setting
  operators and IF_THEN_ELSE; cost more Floating point RTX; cost
  TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are
  unable to cost an insn; fix typos in cost data structure.


Add several improvements for AArch64 (Backported from GCC 5):
  (spill code - swap order in shr patterns; spill code - swap order in
  shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in
  FP compare-with-0.0 case; properly cost FABD pattern; properly
  handle mvn-register and add EON+shift pattern and cost
  appropriately).

Disable inlining of memcpy for x86 with 'rep movs'.
Default to TLS guard for x86 stack-protector.
Change gcc BASE-VER from 4.9.x-google to 4.9.x

Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954
(svn rev 230894, PR tree-optimization/65447,
PR tree-optimization/52563, tree-optimization/62173,
PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735.

Port revision 219584 from linaro/gcc-4_9-branch

Fix for arm64 bad code for copysignl.


Added:
branches/google/gcc-4_9-mobile/gcc/sancov.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c
Modified:
branches/google/gcc-4_9-mobile/ChangeLog
branches/google/gcc-4_9-mobile/config/futex.m4
branches/google/gcc-4_9-mobile/configure
branches/google/gcc-4_9-mobile/configure.ac
branches/google/gcc-4_9-mobile/gcc/BASE-VER
branches/google/gcc-4_9-mobile/gcc/ChangeLog
branches/google/gcc-4_9-mobile/gcc/Makefile.in
branches/google/gcc-4_9-mobile/gcc/builtins.def
branches/google/gcc-4_9-mobile/gcc/cfghooks.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.h
branches/google/gcc-4_9-mobile/gcc/common.opt
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt
branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c
branches/google/gcc-4_9-mobile/gcc/config/linux-android.h
branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64
branches/google/gcc-4_9-mobile/gcc/configure
branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi
branches/google/gcc-4_9-mobile/gcc/except.c
branches/google/gcc-4_9-mobile/gcc/expmed.c
branches/google/gcc-4_9-mobile/gcc/gcov-io.h
branches/google/gcc-4_9-mobile/gcc/loop-init.c
branches/google/gcc-4_9-mobile/gcc/lra-constraints.c
branches/google/gcc-4_9-mobile/gcc/omp-low.c
branches/google/gcc-4_9-mobile/gcc/params.def
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/sanitizer.def
branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.h
branches/google/gcc-4_9-mobile/gcc/tree-chrec.c
branches/goog

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[ctice at gcc dot gnu.org]

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

--- Comment #10 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Apr  8 17:09:09 2016
New Revision: 234832

URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev
Log:
Unify changes with Android's GCC 4.9 compiler.

Add the following changes from the Android
GCC 4.9 compiler (mostly adding fixes for aarch64):

Fix mingw build breakage
1) Add missing _GCOV_fopen if !__KERNEL__
2) Use _fullpath

Backport Cortex-A57's machine description support from trunk

Adjust generic move costs for aarch64. Backport from trunk

Enable C++ exceptions and RTTI by default.

Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default

Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs.

Drop mips64r2 from Android compiler's multilib

Merge "Drop mips64r2 from Android compiler's multilib"

Adjust several costs for AArch64:
  Refactor aarch64_address_costs; add cost tables for Cortex-A7;
  better estimate cost of building a constant; wrap aarch64_rtx_costs
  to dump verbose output; factor out common MULT cases; det default
  costs and handle vector modes; cost memory accesses using address
  costs; better cost logical operations; improve costs for div/mod and
  sign/zero extend operations; cost comparisons, flag setting
  operators and IF_THEN_ELSE; cost more Floating point RTX; cost
  TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are
  unable to cost an insn; fix typos in cost data structure.


Add several improvements for AArch64 (Backported from GCC 5):
  (spill code - swap order in shr patterns; spill code - swap order in
  shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in
  FP compare-with-0.0 case; properly cost FABD pattern; properly
  handle mvn-register and add EON+shift pattern and cost
  appropriately).

Disable inlining of memcpy for x86 with 'rep movs'.
Default to TLS guard for x86 stack-protector.
Change gcc BASE-VER from 4.9.x-google to 4.9.x

Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954
(svn rev 230894, PR tree-optimization/65447,
PR tree-optimization/52563, tree-optimization/62173,
PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735.

Port revision 219584 from linaro/gcc-4_9-branch

Fix for arm64 bad code for copysignl.


Added:
branches/google/gcc-4_9-mobile/gcc/sancov.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c
Modified:
branches/google/gcc-4_9-mobile/ChangeLog
branches/google/gcc-4_9-mobile/config/futex.m4
branches/google/gcc-4_9-mobile/configure
branches/google/gcc-4_9-mobile/configure.ac
branches/google/gcc-4_9-mobile/gcc/BASE-VER
branches/google/gcc-4_9-mobile/gcc/ChangeLog
branches/google/gcc-4_9-mobile/gcc/Makefile.in
branches/google/gcc-4_9-mobile/gcc/builtins.def
branches/google/gcc-4_9-mobile/gcc/cfghooks.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.h
branches/google/gcc-4_9-mobile/gcc/common.opt
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt
branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c
branches/google/gcc-4_9-mobile/gcc/config/linux-android.h
branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64
branches/google/gcc-4_9-mobile/gcc/configure
branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi
branches/google/gcc-4_9-mobile/gcc/except.c
branches/google/gcc-4_9-mobile/gcc/expmed.c
branches/google/gcc-4_9-mobile/gcc/gcov-io.h
branches/google/gcc-4_9-mobile/gcc/loop-init.c
branches/google/gcc-4_9-mobile/gcc/lra-constraints.c
branches/google/gcc-4_9-mobile/gcc/omp-low.c
branches/google/gcc-4_9-mobile/gcc/params.def
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/sanitizer.def
branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.h
branches/google/gcc-4_9-mobile/gcc/tree-chrec.c
branches/goo

[Bug tree-optimization/64878] [5 Regression] Miscompilation of nntpgrab

[ctice at gcc dot gnu.org]

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

--- Comment #10 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Apr  8 17:09:09 2016
New Revision: 234832

URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev
Log:
Unify changes with Android's GCC 4.9 compiler.

Add the following changes from the Android
GCC 4.9 compiler (mostly adding fixes for aarch64):

Fix mingw build breakage
1) Add missing _GCOV_fopen if !__KERNEL__
2) Use _fullpath

Backport Cortex-A57's machine description support from trunk

Adjust generic move costs for aarch64. Backport from trunk

Enable C++ exceptions and RTTI by default.

Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default

Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs.

Drop mips64r2 from Android compiler's multilib

Merge "Drop mips64r2 from Android compiler's multilib"

Adjust several costs for AArch64:
  Refactor aarch64_address_costs; add cost tables for Cortex-A7;
  better estimate cost of building a constant; wrap aarch64_rtx_costs
  to dump verbose output; factor out common MULT cases; det default
  costs and handle vector modes; cost memory accesses using address
  costs; better cost logical operations; improve costs for div/mod and
  sign/zero extend operations; cost comparisons, flag setting
  operators and IF_THEN_ELSE; cost more Floating point RTX; cost
  TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are
  unable to cost an insn; fix typos in cost data structure.


Add several improvements for AArch64 (Backported from GCC 5):
  (spill code - swap order in shr patterns; spill code - swap order in
  shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in
  FP compare-with-0.0 case; properly cost FABD pattern; properly
  handle mvn-register and add EON+shift pattern and cost
  appropriately).

Disable inlining of memcpy for x86 with 'rep movs'.
Default to TLS guard for x86 stack-protector.
Change gcc BASE-VER from 4.9.x-google to 4.9.x

Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954
(svn rev 230894, PR tree-optimization/65447,
PR tree-optimization/52563, tree-optimization/62173,
PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735.

Port revision 219584 from linaro/gcc-4_9-branch

Fix for arm64 bad code for copysignl.


Added:
branches/google/gcc-4_9-mobile/gcc/sancov.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c
Modified:
branches/google/gcc-4_9-mobile/ChangeLog
branches/google/gcc-4_9-mobile/config/futex.m4
branches/google/gcc-4_9-mobile/configure
branches/google/gcc-4_9-mobile/configure.ac
branches/google/gcc-4_9-mobile/gcc/BASE-VER
branches/google/gcc-4_9-mobile/gcc/ChangeLog
branches/google/gcc-4_9-mobile/gcc/Makefile.in
branches/google/gcc-4_9-mobile/gcc/builtins.def
branches/google/gcc-4_9-mobile/gcc/cfghooks.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.h
branches/google/gcc-4_9-mobile/gcc/common.opt
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt
branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c
branches/google/gcc-4_9-mobile/gcc/config/linux-android.h
branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64
branches/google/gcc-4_9-mobile/gcc/configure
branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi
branches/google/gcc-4_9-mobile/gcc/except.c
branches/google/gcc-4_9-mobile/gcc/expmed.c
branches/google/gcc-4_9-mobile/gcc/gcov-io.h
branches/google/gcc-4_9-mobile/gcc/loop-init.c
branches/google/gcc-4_9-mobile/gcc/lra-constraints.c
branches/google/gcc-4_9-mobile/gcc/omp-low.c
branches/google/gcc-4_9-mobile/gcc/params.def
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/sanitizer.def
branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.h
branches/google/gcc-4_9-mobile/gcc/tree-chrec.c
branches/goo

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

[ctice at gcc dot gnu.org]

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

--- Comment #18 from ctice at gcc dot gnu.org ---
Author: ctice
Date: Fri Apr  8 17:09:09 2016
New Revision: 234832

URL: https://gcc.gnu.org/viewcvs?rev=234832&root=gcc&view=rev
Log:
Unify changes with Android's GCC 4.9 compiler.

Add the following changes from the Android
GCC 4.9 compiler (mostly adding fixes for aarch64):

Fix mingw build breakage
1) Add missing _GCOV_fopen if !__KERNEL__
2) Use _fullpath

Backport Cortex-A57's machine description support from trunk

Adjust generic move costs for aarch64. Backport from trunk

Enable C++ exceptions and RTTI by default.

Modify LINK_SPEC to pass --fix-cortex-a53-843419 as default

Rename libstdc++.so to libgnustl_shared.so when enabling bionic libs.

Drop mips64r2 from Android compiler's multilib

Merge "Drop mips64r2 from Android compiler's multilib"

Adjust several costs for AArch64:
  Refactor aarch64_address_costs; add cost tables for Cortex-A7;
  better estimate cost of building a constant; wrap aarch64_rtx_costs
  to dump verbose output; factor out common MULT cases; det default
  costs and handle vector modes; cost memory accesses using address
  costs; better cost logical operations; improve costs for div/mod and
  sign/zero extend operations; cost comparisons, flag setting
  operators and IF_THEN_ELSE; cost more Floating point RTX; cost
  TRUNCATE, SET, SYMBOL_REF, HIGH and LO_SUM; dump a message if we are
  unable to cost an insn; fix typos in cost data structure.


Add several improvements for AArch64 (Backported from GCC 5):
  (spill code - swap order in shr patterns; spill code - swap order in
  shl pattern; fix aarch64_rtx_costs of PLUS/MINUS; cost operand 0 in
  FP compare-with-0.0 case; properly cost FABD pattern; properly
  handle mvn-register and add EON+shift pattern and cost
  appropriately).

Disable inlining of memcpy for x86 with 'rep movs'.
Default to TLS guard for x86 stack-protector.
Change gcc BASE-VER from 4.9.x-google to 4.9.x

Cherry pick the following fixes from trunk: PR bootstrap/66638, 67954
(svn rev 230894, PR tree-optimization/65447,
PR tree-optimization/52563, tree-optimization/62173,
PR tree-optimization/48052, PR 64878, PR65048, PR65177, PR65735.

Port revision 219584 from linaro/gcc-4_9-branch

Fix for arm64 bad code for copysignl.


Added:
branches/google/gcc-4_9-mobile/gcc/sancov.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/asan.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic0.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic1.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/sancov/basic2.c
Modified:
branches/google/gcc-4_9-mobile/ChangeLog
branches/google/gcc-4_9-mobile/config/futex.m4
branches/google/gcc-4_9-mobile/configure
branches/google/gcc-4_9-mobile/configure.ac
branches/google/gcc-4_9-mobile/gcc/BASE-VER
branches/google/gcc-4_9-mobile/gcc/ChangeLog
branches/google/gcc-4_9-mobile/gcc/Makefile.in
branches/google/gcc-4_9-mobile/gcc/builtins.def
branches/google/gcc-4_9-mobile/gcc/cfghooks.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.c
branches/google/gcc-4_9-mobile/gcc/cfgloop.h
branches/google/gcc-4_9-mobile/gcc/common.opt
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-cores.def
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-elf-raw.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-linux.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-protos.h
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64-tune.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.c
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.md
branches/google/gcc-4_9-mobile/gcc/config/aarch64/aarch64.opt
branches/google/gcc-4_9-mobile/gcc/config/i386/i386.c
branches/google/gcc-4_9-mobile/gcc/config/linux-android.h
branches/google/gcc-4_9-mobile/gcc/config/mips/t-linux-android64
branches/google/gcc-4_9-mobile/gcc/configure
branches/google/gcc-4_9-mobile/gcc/doc/invoke.texi
branches/google/gcc-4_9-mobile/gcc/except.c
branches/google/gcc-4_9-mobile/gcc/expmed.c
branches/google/gcc-4_9-mobile/gcc/gcov-io.h
branches/google/gcc-4_9-mobile/gcc/loop-init.c
branches/google/gcc-4_9-mobile/gcc/lra-constraints.c
branches/google/gcc-4_9-mobile/gcc/omp-low.c
branches/google/gcc-4_9-mobile/gcc/params.def
branches/google/gcc-4_9-mobile/gcc/passes.def
branches/google/gcc-4_9-mobile/gcc/sanitizer.def
branches/google/gcc-4_9-mobile/gcc/testsuite/ChangeLog
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-3.c
branches/google/gcc-4_9-mobile/gcc/testsuite/gcc.dg/tree-ssa/scev-4.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.c
branches/google/gcc-4_9-mobile/gcc/tree-cfg.h
branches/google/gcc-4_9-mobile/gcc/tree-chrec.c
branches/goo

[Bug rtl-optimization/70602] New: wrong code at -O1 and above on x86_64-linux-gnu in 32-bit mode (and at -Os only in 64-bit mode)

[su at cs dot ucdavis.edu]

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

Bug ID: 70602
   Summary: wrong code at -O1 and above on x86_64-linux-gnu in
32-bit mode (and at -Os only in 64-bit mode)
   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-gnu at -O1
and above in the 32-bit mode and at -Os only in the 64-bit mode.

This is a regression from 5.3.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160408 (experimental) [trunk revision 234826] (GCC) 
$ 
$ gcc-trunk -m32 -O0 small.c; ./a.out
$ gcc-5.3 -m32 -O1 small.c; ./a.out
$  
$ gcc-trunk -m32 -O1 small.c  
$ ./a.out
Segmentation fault (core dumped)
$ 


-


#pragma pack(1)
struct S0
{
  int f0:1;
  int f1:20;
};

int a, b, c;

int
main ()
{
  for (; a < 1; a++)
{
  struct S0 e[] = { {0, 9}, {0, 9}, {0, 9}, {0, 0}, {0, 9}, {0, 9}, {0, 9}, 
{0, 0}, {0, 9}, {0, 9}, {0, 9}, {0, 0}, {0, 9}, {0, 9}, 
{0, 9}, {0, 0}, {0, 9}, {0, 9}, {0, 9}, {0, 0}, {0, 9}
};
  b = b || e[0].f0;
  c = e[0].f1;
}
  return 0;
}

[Bug target/70574] [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr  8 17:21:17 2016
New Revision: 234833

URL: https://gcc.gnu.org/viewcvs?rev=234833&root=gcc&view=rev
Log:
PR rtl-optimization/70574
* fwprop.c (forward_propagate_and_simplify): Don't add
REG_EQUAL note if DF_REF_REG (use) is a paradoxical subreg.
(try_fwprop_subst): Don't add REG_EQUAL note if there are any
paradoxical subregs within *loc.

* gcc.target/i386/avx2-pr70574.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx2-pr70574.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fwprop.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

[amker at gcc dot gnu.org]

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

--- Comment #19 from amker at gcc dot gnu.org ---
I think this is fixed now.