[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---

(In reply to Anatol from comment #2)
> Theoretically it is possible to do things like this manually. Track
> functions x86 extensions usage and save registers accordingly. But I would
> love to see a more automated and less error-prone way to do it. Similar to
> what CLANG compiler already does. CLANG tracks registers use and reduces a
> lot of burden for me.
> 
> That is the reason why we switched to CLANG in our project for now but I
> would love to see GCC first-class support as well.
> 
> What is the reason that GCC does not track SSE register usage? Is it a GGC
> architecture restriction or something else?

To use SSE registers in interrupt handler, you need to save the complete
vector state, %xmm0-%xmm15 isn't sufficient.  You need to preserve the
whole set of vector registers plus MXCSR register.  One way to do it is
to use xsave/xrstor.

[Bug c++/81873] spurious -Wreturn-type calling a locally declared noreturn function

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This is not so much an -Wreturn-type issue but a symptom of the C++ front-end
not merging decls for globals.  You filed a few other cases which are accepts
invalid which are the same here.

[Bug target/81709] __attribute__((interrupt)) should handle SSE registers

[anatol.pomozov at gmail dot com]

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

--- Comment #2 from Anatol  ---
Theoretically it is possible to do things like this manually. Track functions
x86 extensions usage and save registers accordingly. But I would love to see a
more automated and less error-prone way to do it. Similar to what CLANG
compiler already does. CLANG tracks registers use and reduces a lot of burden
for me.

That is the reason why we switched to CLANG in our project for now but I would
love to see GCC first-class support as well.

What is the reason that GCC does not track SSE register usage? Is it a GGC
architecture restriction or something else?

[Bug c++/81855] [mingw-w64] dllexport-ed explicit template instantiation has no symbol in DLL in certain condition

[lanxingcan at gmail dot com]

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

--- Comment #2 from Xingcan Lan  ---
Checked diassembly code and found that __declspec(dllexport) never applied to
explicitly instantiated `Template`. 

If I change the code from
`extern template struct __declspec(dllexport) Template;` to
`extern template __declspec(dllexport) struct Template;`, the compiler
will warns me that dllexport attribute will be ignored.

My conclusion:
  1) I didn't properly applied dllexport attribute, which was syntactical
incorrect but silently accepted by the compiler.

  2) I suspect the behavior of linker is, if no symbol were marked as
dll-exported, then all symbol will be exported.

Anyway, it's expected that explicit instantiated template could be exported
normally as other symbol. 

Even if it's not supported, compiler should at least warns about the syntax
error or ignore those explicit template instantiation which were marked with 
__declspec(dllimport) and/or __declspec(dllexport) and emit code for each
compile unit that implicitly instantiated the template to avoid link error.

[Bug target/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Thu Aug 17 02:03:03 2017
New Revision: 251140

URL: https://gcc.gnu.org/viewcvs?rev=251140=gcc=rev
Log:
[RS6000] PR 80938, Don't emit frame info for regs that don't need saving

It is possible when using out-of-line register saves or store multiple
to save some registers unnecessarily, for example one reg in the block
saved might be unused.  We don't need to emit frame info for those
registers as that just bloats the info, and also can result in an ICE
when shrink-wrap gives multiple paths through the function saving
different sets of registers.  Join points need to have identical frame
register save state regardless of the path taken.

This patch reverts the previous fix for PR80939 "Use SAVE_MULTIPLE
only if we restore what it saves (PR80938)" and instead fixes the PR
by correcting the frame info.  The change to rs6000_savres_strategy
is an optimization, but note that it hides the underlying problem in
the PR testcase.

PR target/80938
* config/rs6000/rs6000.c (rs6000_savres_strategy): Revert 2017-08-09.
Don't use store multiple if only one reg needs saving.
(interesting_frame_related_regno): New function.
(rs6000_frame_related): Don't emit frame info for regs that
don't need saving.
(rs6000_emit_epilogue): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #24 from Randy MacLeod  ---
This ICE still happens with gcc-7.2. 
Here's the stacktrace:

(gdb) bt
#0  store_expr_with_bounds (exp=exp@entry=0x76275900,
target=target@entry=0x7625d660, call_param_p=call_param_p@entry=0,
nontemporal=nontemporal@entry=false, reverse=reverse@entry=false, 
btarget=btarget@entry=0x76524318) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/expr.c:5575
#1  0x00760cb0 in expand_assignment (to=0x76524318,
from=from@entry=0x76275900, nontemporal=nontemporal@entry=false) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/expr.c:5321
#2  0x0067309b in expand_call_stmt (stmt=0x76521750) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cfgexpand.c:2656
#3  expand_gimple_stmt_1 (stmt=0x76521750) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cfgexpand.c:3571
#4  expand_gimple_stmt (stmt=stmt@entry=0x76521750) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cfgexpand.c:3737
#5  0x00674a91 in expand_gimple_basic_block (bb=0x7659f680,
disable_tail_calls=disable_tail_calls@entry=false) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cfgexpand.c:5744
#6  0x0067957f in (anonymous namespace)::pass_expand::execute
(this=, fun=0x7639a0b0) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cfgexpand.c:6357
#7  0x0092c99b in execute_one_pass (pass=pass@entry=0x1a8a650) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/passes.c:2465
#8  0x0092d1b8 in execute_pass_list_1 (pass=0x1a8a650) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/passes.c:2554
#9  0x0092d215 in execute_pass_list (fn=,
pass=) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/passes.c:2565
#10 0x006a3dad in cgraph_node::expand (this=0x7649be60) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cgraphunit.c:2042
#11 0x006a52dd in expand_all_functions () at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cgraphunit.c:2178
#12 symbol_table::compile (this=this@entry=0x76585000) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cgraphunit.c:2535
#13 0x006a6d38 in symbol_table::compile (this=0x76585000) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cgraphunit.c:2599
#14 symbol_table::finalize_compilation_unit (this=0x76585000) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/cgraphunit.c:2625
#15 0x009e8060 in compile_file () at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/toplev.c:492
#16 0x0057817c in do_compile () at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/toplev.c:2003
#17 toplev::main (this=this@entry=0x7fffada0, argc=argc@entry=27,
argv=argv@entry=0x7fffaea8) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/toplev.c:2137
#18 0x0057a517 in main (argc=27, argv=0x7fffaea8) at
../../../../../../../work-shared/gcc-7.2.0-r0/gcc-7.2.0/gcc/main.c:39


Aside from the address variations and the newer toolchain version, the stack
trackes look the same to my untrained dragon slaying eyes. :)

[Bug c++/81873] spurious -Wreturn-type calling a locally declared noreturn function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=79996

--- Comment #1 from Martin Sebor  ---
See also bug 79996 for another C++-specific -Wreturn-type false positive.

Clang handles this correctly.

[Bug c++/81873] New: spurious -Wreturn-type calling a locally declared noreturn function

[msebor at gcc dot gnu.org]

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

Bug ID: 81873
   Summary: spurious -Wreturn-type calling a locally declared
noreturn function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When a noreturn function first locally declared in another function and then
redeclared in another function without attribute noreturn is called the C front
end correctly avoids warning if the call isn't followed by a return statement
in a function expected to return a value.

The test case below shows that the C++ front end doesn't handle this case
correctly and issues a spurious warning.

$ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C
void f (void)
{
  int __attribute__ ((noreturn)) g ();
}

int h (void)
{
  int g ();

  g ();
}
t.C: In function ‘int h()’:
t.C:11:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Just for the record, the problem disappears with r250523, in which a change to
reassociation of multiplication in match.pd causes the SLSR opportunities to
disappear.  So the SLSR problem has just gone latent, as suspected.

[Bug target/81863] [7 regression] -mword-relocations is unreliable

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

  Known to work|6.3.1   |

--- Comment #1 from Arnd Bergmann  ---
I originally couldn't reproduce this on gcc-6, but now I found another file
that shows very similar behavior with gcc-6.3.1 but not gcc-5 or gcc-7. In that
case we increment a global variable "cell->id = cmodio_id++;", reading the
variable uses a relative relocation, but writing it back uses
R_ARM_MOVW_ABS_NC.

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
It doesn't happen with the preprocessed source.

[Bug target/81872] Enable __float128 by default on PowerPC Linux systems

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-16
 Ever confirmed|0   |1

[Bug target/81872] New: Enable __float128 by default on PowerPC Linux systems

[meissner at gcc dot gnu.org]

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

Bug ID: 81872
   Summary: Enable __float128 by default on PowerPC Linux systems
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In GCC 8.0, we should ensure that __float128 is enabled by default for PowerPC
linux systems without having to use the -mfloat128 option.

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to H.J. Lu from comment #2)
> On 64-bit hosts, I got
> 
> (gdb) p cfun->cfg->x_last_basic_block
> $1 = 432
> (gdb) call debug_tree (cfun->decl)

Please ignore this. I didn't use --enable-checking=yes,rtl on 64-bit hosts.

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
On 32-bit hosts, we get a huge number of basic blocks:

Breakpoint 7, (anonymous namespace)::pass_cprop_hardreg::execute (
this=0x30f8fd0, fun=0xd346b3a8)
at /export/gnu/import/git/sources/gcc/gcc/regcprop.c:1272
1272  all_vd = XNEWVEC (struct value_data, last_basic_block_for_fn (fun));
$9 = 43050
(gdb) p cfun->cfg->x_last_basic_block
$10 = 43050
(gdb) call debug_tree (cfun->decl)
 >
QI
size 
unit-size 
align:8 symtab:0 alias-set -1 canonical-type 0xd335a1e0
arg-types 
chain >>>
asm_written nothrow public static decl_5 QI insn-extract.c:18:1 align:8
context  initial 
result 
ignored VOID insn-extract.c:18:29
align:8 context >
full-name "void insn_extract(rtx_insn*)"
pending-inline-info 0xc83d3120
arguments 
sizes-gimplified public unsigned type_6 SI
size 
unit-size 
align:32 symtab:0 alias-set 36 canonical-type 0xd36c6c00
pointer_to_this  reference_to_this
>
used unsigned read SI insn-extract.c:18:25 size  unit-size 
align:32 context 

(reg/v/f:DI 5 di [orig:51981 insn ] [51981]) arg-type 
incoming-rtl (reg:DI 5 di [ insn ])>
struct-function 0xd346b3a8 chain >
(gdb)

On 64-bit hosts, I got

(gdb) p cfun->cfg->x_last_basic_block
$1 = 432
(gdb) call debug_tree (cfun->decl)
 >
QI
size 
unit-size 
align:8 symtab:0 alias-set -1 canonical-type 0x7f9662442498
arg-types 
chain >>>
asm_written nothrow public static decl_5 QI insn-extract.c:18:1 align:8
context  initial 
result 
ignored VOID insn-extract.c:18:29
align:8 context >
full-name "void insn_extract(rtx_insn*)"
pending-inline-info 0x7f966254fc60
arguments 
asm_written public unsigned type_6 DI
size 
unit-size 
align:64 symtab:1651843712 alias-set -1 canonical-type
0x7f96650fc3f0
pointer_to_this  reference_to_this
>
used unsigned read DI insn-extract.c:18:25 size  unit-size 
align:64 context 

(reg/v/f:DI 5 di [orig:9470 insn ] [9470]) arg-type 
incoming-rtl (reg:DI 5 di [ insn ])>
struct-function 0x7f9662541d10 chain >
(gdb)

[Bug sanitizer/81870] -fsanitize=undefined doesn't pay attention to __builtin_assume_aligned()

[kobalicek.petr at gmail dot com]

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

--- Comment #2 from Petr  ---
I see, so if I understand it correctly then:

1. `__builtin_assume_aligned()` should be used to promote the type to a higher
than natural alignment, for example 16 bytes for easier auto-vectorization.

2. `__attribute__((aligned(N)))` should be used to relax alignment of native
types to lower than natural alignment.

It's interesting that with `__builtin_assume_aligned()` I achieved basically
the same effect as with `__attribute__((aligned(N))`, just the sanitizer is not
happy.

Interestingly, I thought that __builtin_assume_aligned() is basically
equivalent to `__assume_aligned()` provided by Intel and MS compilers.

Anyway thanks for your answer, I need to fix my code a bit.

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
With a cross it doesn't reproduce for current trunk (r251128) either, but does
reproduce with r250217 as originally reported.  So I can look at that.  Going
to check what made the problem go away also...

[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|lto |target

--- Comment #7 from Uroš Bizjak  ---
(In reply to Maxim Ostapenko from comment #6)
> Moving options saving down fixes the issue, although I'm not sure this is a
> correct fix.

This does look like a correct fix to me. Also, regression tests with the patch
on x86_64-linux-gnu {,-m32} were OK.

Back to target component...

[Bug sanitizer/81870] -fsanitize=undefined doesn't pay attention to __builtin_assume_aligned()

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
No the code is still undefined as the type which you are using has an alignment
requirement.

Use a different type like say:
typedef int unaligned_int32_t __attribute__((aligned(1)));

[Bug c/78666] conflicting attribute alloc_size accepted

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81871

--- Comment #8 from Martin Sebor  ---
Whoops. This bug is about alloc_size and my comment about alloc_align.  I think
that needs a bug of its own.  I opened pr81871 for it.

[Bug c/81871] New: bogus attribute alloc_align accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81871
   Summary: bogus attribute alloc_align accepted
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 78666, GCC accepts nonsensical attribute alloc_align specifiers
on functions where they have no meaning, such as on on functions that return
void or those that reference arguments of non-integer types.  They should
either be diagnosed with -Wattributes or rejected with an error.

$ cat a.c && gcc -O2 -S -Wall -Wextra -Wpedantic -Werror a.c
void __attribute__ ((alloc_align (1))) f (void*);

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
On 64-bit host, I got

Number of expanded macros: 25177
Average number of tokens per macro expansion: 34

Line Table allocations during the compilation process
Number of ordinary maps used:  550 
Ordinary map used size: 17k
Number of ordinary maps allocated:1024 
Ordinary maps allocated size:   32k
Number of macro maps used:  24k
Macro maps used size:  974k
Macro maps locations size:6778k
Macro maps size:  7753k
Duplicated maps locations size:   1094k
Total allocated maps size:7834k
Total used maps size: 7770k
Ad-hoc table size:3072k
Ad-hoc table entries used:   104753
optimized_ranges: 550961
unoptimized_ranges: 80362

Memory still allocated at the end of the compilation process
Size  AllocatedUsedOverhead
884k 52k   2520 
16  768k642k 16k
32 1592k   1076k 27k
64  928k840k 14k
2563532k   3316k 48k
5121720k   1661k 23k
1024   4440k   4411k 60k
2048876k862k 11k
4096 48k 48k672 
8192152k152k   1064 
1638416k 16k 56 
3276896k 96k168 
6553664k 64k 56 
131072  128k128k 56 
262144  768k768k168 
524288  512k512k 56 
10485761024k   1024k 56 
41943044096k   4096k 56 
24 1272k683k 22k
40 2568k   1459k 40k
48  552k403k   8832 
56  112k 69k   1792 
72 2376k   1746k 32k
80 1320k   1197k 18k
88   44k 27k616 
96  264k155k   3696 
112 936k917k 12k
120 164k 95k   2296 
1521336k   1235k 18k
1284412k   4094k 60k
1441152k942k 15k
1684508k   4351k 61k
176 152k 97k   2128 
104  72k 65k   1008 
3682620k   2563k 35k
272  32k  10064 448 
Total43M 38M546k

String pool
entries 39907
identifiers 24309 (60.91%)
slots   65536
deleted 15598
bytes   479k (17592186044415M overhead)
table size  512k
coll/search 0.5331
ins/search  0.1515
avg. entry  12.29 bytes (+/- 12.63)
longest entry   89
(No per-node statistics)
Type hash: size 8191, 4274 elements, 0.881900 collisions
DECL_DEBUG_EXPR  hash: size 1021, 0 elements, 0.00 collisions
DECL_VALUE_EXPR  hash: size 1021, 0 elements, 0.00 collisions
no search statistics
decl_specializations: size 1021, 487 elements, 1.284593 collisions
type_specializations: size 2039, 996 elements, 1.451110 collisions
No gimple statistics
No RTX statistics

Heap vectorsLeak   Peak 
Times   Leak items Peak items




Total  0
00




Alias oracle query stats:
  refs_may_alias_p: 0 disambiguations, 0 queries
  ref_maybe_used_by_call_p: 3 disambiguations, 0 queries
  call_may_clobber_ref_p: 0 disambiguations, 0 queries
  TBAA oracle: 563340 disambiguations 5861823 queries
   828998 are in alias set 0
   1801509 queries asked about the same object
   0 queries asked about the same alias set
   0 access volatile
   2667976 are dependent in the DAG
   0 are aritificially in conflict with void *

PTA query stats:
  pt_solution_includes: 0 disambiguations, 2219933 queries
  pt_solutions_intersect: 0 disambiguations, 0 queries

[Bug sanitizer/81870] New: -fsanitize=undefined doesn't pay attention to __builtin_assume_aligned()

[kobalicek.petr at gmail dot com]

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

Bug ID: 81870
   Summary: -fsanitize=undefined doesn't pay attention to
__builtin_assume_aligned()
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kobalicek.petr at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I'm having problem with GCC -fsanitize=undefined and __builtin_assume_aligned()
builtin.

The following code `sanitizer-test.cpp`:

  #include 

  static __attribute((__noinline__)) uint32_t readu32(const void* p) {
p = __builtin_assume_aligned(p, 1);
return static_cast(p)[0];
  }

  static __attribute((__noinline__)) void writeu32(void* p, uint32_t x) {
p = __builtin_assume_aligned(p, 1);
static_cast(p)[0] = x;
  }

  int main(int argc, char* argv[]) {
char buf[] = { 0, 1, 2, 3, 4, 5, 6 };
writeu32(buf + 1, 0x44332211);
uint32_t ret = readu32(buf + 1);
return static_cast(ret);
  }

Compiled as:

  gcc-7 -fsanitize=undefined sanitizer-test.cpp -o sanitizer-test

Outputs the following when executed:

$ ./sanitizer-test
sanitizer-test.cpp:10:32: runtime error: store to misaligned address
0x7ffd643f6ab6 for type 'uint32_t', which requires 4 byte alignment
0x7ffd643f6ab6: note: pointer points here
 3f 64 fd 00 01 02  03 04 05 06 00 00 00 00  60 b8 a8 09 b3 55 00 00  b1 f2 ab
be 80 7f 00 00  01 00
 ^ 
sanitizer-test.cpp:5:43: runtime error: load of misaligned address
0x7ffd643f6ab6 for type 'const uint32_t', which requires 4 byte alignment
0x7ffd643f6ab6: note: pointer points here
 3f 64 fd 00 11 22  33 44 05 06 00 00 00 00  60 b8 a8 09 b3 55 00 00  b1 f2 ab
be 80 7f 00 00  01 00

I think that in this case the sanitizer should not report the runtime error as
the pointer was marked to be aligned to 1 byte.

[Bug c/78666] conflicting attribute alloc_size accepted

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
The following nonsensical declaration is also not diagnosed:

  void __attribute__ ((alloc_align (1))) f (void*);

The attribute handler should check that the referenced argument has integer
type and that the function returns a pointer.

[Bug bootstrap/81869] New: [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[hjl.tools at gmail dot com]

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

Bug ID: 81869
   Summary: [8 Regression] --enable-checking=yes,rtl failed to
bootstrap on 32-bit hosts
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On 32-bit hosts, when configured with

--enable-checking=yes,rtl

I got

Breakpoint 5, xmalloc_failed (size=56137200)
at /export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:123
123   if (first_break != NULL)
(gdb) bt
#0  xmalloc_failed (size=56137200)
at /export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:123
#1  0x024ce8f0 in xmalloc (size=56137200)
at /export/gnu/import/git/sources/gcc/libiberty/xmalloc.c:149
#2  0x011c91f9 in (anonymous namespace)::pass_cprop_hardreg::execute (
this=0x30f8fd0, fun=0xd34b63a8)
at /export/gnu/import/git/sources/gcc/gcc/regcprop.c:1272
#3  0x01147550 in execute_one_pass (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2495
#4  0x011478c6 in execute_pass_list_1 (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2584
#5  0x011478f8 in execute_pass_list_1 (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2585
#6  0x011478f8 in execute_pass_list_1 (
pass=)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2585
#7  0x0114795a in execute_pass_list (fn=0xd34b63a8, pass=
)
at /export/gnu/import/git/sources/gcc/gcc/passes.c:2595
#8  0x00c52937 in cgraph_node::expand (
---Type  to continue, or q  to quit---
this=)
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2054
#9  0x00c53009 in expand_all_functions ()
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2190
#10 0x00c53c27 in symbol_table::compile (this=0xf64080d8)
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2542
#11 0x00c53e92 in symbol_table::finalize_compilation_unit (this=0xf64080d8)
at /export/gnu/import/git/sources/gcc/gcc/cgraphunit.c:2631
#12 0x01337fc6 in compile_file ()
at /export/gnu/import/git/sources/gcc/gcc/toplev.c:496
#13 0x0133a77d in do_compile ()
at /export/gnu/import/git/sources/gcc/gcc/toplev.c:2037
#14 0x0133aa9a in toplev::main (this=0xc3ee, argc=72, argv=0xc4d4)
at /export/gnu/import/git/sources/gcc/gcc/toplev.c:2171
#15 0x02415af2 in main (argc=72, argv=0xc4d4)
at /export/gnu/import/git/sources/gcc/gcc/main.c:39
(gdb) call dump_memory_report (1)
Number of expanded macros: 82835
Average number of tokens per macro expansion:291

Line Table allocations during the compilation process
Number of ordinary maps used:  550 
Ordinary map used size: 12k
Number of ordinary maps allocated:1365 
Ordinary maps allocated size:   31k
Number of macro maps used:  80k
Macro maps used size: 1936k
Macro maps locations size: 184M
Macro maps size:   186M
Duplicated maps locations size:   5533k
Total allocated maps size: 186M
Total used maps size:  186M
Ad-hoc table size:  64M
Ad-hoc table entries used:   2145806
optimized_ranges: 580577
unoptimized_ranges: 1958174

Memory still allocated at the end of the compilation process
Size  AllocatedUsedOverhead
8   340k307k   8160 
16   51M 15M826k
32   12M   3631k151k
128  36k 17k324 
256  48k 21k384 
512 124k 86k992 
1024   2548k   2509k 19k
2048   2936k   2918k 22k
4096 10M 10M 84k
8192 11M 11M 46k
1638440M 40M 81k
3276854M 54M 54k
6553661M 61M 30k
131072   50M 50M 12k
262144   32M 32M   4096 
524288   16M 16M   1024 
1048576  10M 10M320 
20971522048k   2048k 32 
67108864 64M 64M 32 
24   38M 12M500k
40   31M 18M343k
48   15M   4353k150k
56 5076k   1055k 49k
72 1048k840k   9432 
112  20k   7280 180 
1201496k   1486k 13k
80 3196k   2535k 28k
88   

[Bug fortran/81651] Enhancement request: have f951 print out fully qualified module file name

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Thomas Koenig  ---
I can see how this would be useful.

[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug lto/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[m.ostapenko at samsung dot com]

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

--- Comment #6 from Maxim Ostapenko  ---
Created attachment 41990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990=edit
Untested fix

The problem is that LTO doesn't propagate changed
ix86_stack_protector_guard_reg value:

 6654   /* Save the initial options in case the user does function specific
 6655  options.  */
 6656   if (main_args_p)
 6657 target_option_default_node = target_option_current_node
 6658   = build_target_option_node (opts); <== save flags
 6659 
...
 6695   ix86_stack_protector_guard_reg = DEFAULT_TLS_SEG_REG;  <== missed
change

Thus ix86_stack_protector_guard_reg becomes left ADDR_SPACE_GENERIC in ltrans
stage that confuses optimizer later (wrong constant propagation in this case).

Moving options saving down fixes the issue, although I'm not sure this is a
correct fix.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Wed, 16 Aug 2017, NightStrike wrote:

> On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor  wrote:
> > On 08/14/2017 04:22 PM, Eric Gallager wrote:
> >>
> >> I'm emailing this manually to the list because Bugzilla is down and I
> >> can't file a bug on Bugzilla about Bugzilla being down. The error
> >> message looks like this:
> >
> > Bugzilla and the rest of gcc.gnu.org have been down much of
> > the afternoon/evening due to a hard drive upgrade (the old disk
> > apparently failed).  You're not the only one who found out about
> 
> There's no RAID?

The problem was apparently a kernel bug (in the 2.6.32 RHEL6 kernel, may 
or may not be in current kernels) that arose when adding a new SSD mirror 
to the RAID with the old hard drives marked writemostly.  (Separately, one 
of the hard drives in the existing HDD RAID is showing signs of failing 
and needs to be replaced.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Wed, 16 Aug 2017, Eric Gallager wrote:

> I see Richi redid all his 7.2 release changes; does that imply that
> the server restore is now complete?

No, there's still a search process ongoing to identify corrupted or 
missing files by comparison with the last backup.

My expectation is that all the other Bugzilla changes from 13 and 14 
August UTC need redoing manually (recreating bugs with new numbers in the 
case of new bugs filed during that period, if those bugs are still 
relevant, repeating comments, etc. - and possibly recreating accounts for 
people who created accounts and filed bugs during that period).  But I 
haven't seen any official announcement from overseers to all affected 
projects (for both GCC and Sourceware Bugzillas) yet.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Aug 16 17:21:22 2017
New Revision: 251125

URL: https://gcc.gnu.org/viewcvs?rev=251125=gcc=rev
Log:
2017-08-16  Thomas Koenig  

PR fortran/81116
* frontend-passes.c (realloc_string_callback): If expression is a
concatenation, also check for dependency.
(constant_string_length): Check for presence of symtree.

2017-08-16  Thomas Koenig  

PR fortran/81116
* gfortran.dg/realloc_on_assignment_29.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_29.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[misty at brew dot sh]

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

Misty De Meo  changed:

   What|Removed |Added

 CC||misty at brew dot sh

--- Comment #3 from Misty De Meo  ---
I'm seeing a similar failure, also on macOS 10.13. I can only reproduce when
macOS is installed on an APFS filesystem, not HFS+. The issue occurs
intermittently, and the specific header that libstdc++ fails to find varies
from run to run.

/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/./gcc/xgcc
-shared-libgcc -B/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/./gcc
-nostdinc++
-L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src
-L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs
-L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs
-B/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/bin/
-B/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/lib/ -isystem
/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/include -isystem
/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/sys-include-x
c++-header -nostdinc++ -g -O2 
-I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0
-I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include
-I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/libsupc++  -O2
-g
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h
-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch
In file included from
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/sstream:38:0,
 from
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/complex:45,
 from
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ccomplex:39,
 from
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h:52:
/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/istream:38:10:
fatal error: ios: No such file or directory
 #include 
  ^

I can confirm that $target/libstdc++-v3/include/ios exists.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[NightStrike]

On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor  wrote:
> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>
>> I'm emailing this manually to the list because Bugzilla is down and I
>> can't file a bug on Bugzilla about Bugzilla being down. The error
>> message looks like this:
>
> Bugzilla and the rest of gcc.gnu.org have been down much of
> the afternoon/evening due to a hard drive upgrade (the old disk
> apparently failed).  You're not the only one who found out about

There's no RAID?

[Bug c++/81868] Internal completer error: Segmentation Fault

[al_thomason at iname dot com]

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

--- Comment #1 from Al Thomason  ---
I was unable to attach the source files, too large.  Please download directly
from:
 https://github.com/AlternatorRegulator/alt-Source/archive/1.1.0.zip
-or-
 https://github.com/AlternatorRegulator/alt-Source/archive/1.1.0.tar.gz

[Bug c++/81868] New: Internal completer error: Segmentation Fault

[al_thomason at iname dot com]

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

Bug ID: 81868
   Summary: Internal completer error:  Segmentation Fault
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: al_thomason at iname dot com
  Target Milestone: ---

While compiling my project using the Arduino IDE, I received the following:


sketch/AltReg_Serial.cpp: In function 'send_outbound':
sketch/AltReg_Serial.cpp:704:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper:
/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-gcc
returned 1 exit status
/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
exit status 1
Error compiling for board Arduino/Genuino Uno.
==

Environment is Arduino 1.8.1 for Linux.
Board type selected is Arduino/Genuino Uno

Per the release notes, gcc version is: 4.9.2

The following is a more verbose output during compiling:
==

Arduino: 1.8.1 (Linux), Board: "Arduino/Genuino Uno"

/usr/lib/arduino-1.8.1/arduino-builder -dump-prefs -logger=machine -hardware
/usr/lib/arduino-1.8.1/hardware -hardware /home/al/.arduino15/packages
-hardware /home/al/Arduino/hardware -tools /usr/lib/arduino-1.8.1/tools-builder
-tools /usr/lib/arduino-1.8.1/hardware/tools/avr -tools
/home/al/.arduino15/packages -built-in-libraries
/usr/lib/arduino-1.8.1/libraries -libraries /home/al/Arduino/libraries
-fqbn=arduino:avr:uno -ide-version=10801 -build-path /tmp/arduino_build_538784
-warnings=none -prefs=build.warn_data_percentage=75
-prefs=runtime.tools.avr-gcc.path=/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2
-prefs=runtime.tools.arduinoOTA.path=/home/al/.arduino15/packages/arduino/tools/arduinoOTA/1.1.1
-prefs=runtime.tools.avrdude.path=/home/al/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9
-verbose /home/al/Arduino/SmartRegulatorv1.1.0/SmartRegulatorv1.1.0.ino
/usr/lib/arduino-1.8.1/arduino-builder -compile -logger=machine -hardware
/usr/lib/arduino-1.8.1/hardware -hardware /home/al/.arduino15/packages
-hardware /home/al/Arduino/hardware -tools /usr/lib/arduino-1.8.1/tools-builder
-tools /usr/lib/arduino-1.8.1/hardware/tools/avr -tools
/home/al/.arduino15/packages -built-in-libraries
/usr/lib/arduino-1.8.1/libraries -libraries /home/al/Arduino/libraries
-fqbn=arduino:avr:uno -ide-version=10801 -build-path /tmp/arduino_build_538784
-warnings=none -prefs=build.warn_data_percentage=75
-prefs=runtime.tools.avr-gcc.path=/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2
-prefs=runtime.tools.arduinoOTA.path=/home/al/.arduino15/packages/arduino/tools/arduinoOTA/1.1.1
-prefs=runtime.tools.avrdude.path=/home/al/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9
-verbose /home/al/Arduino/SmartRegulatorv1.1.0/SmartRegulatorv1.1.0.ino
Using board 'uno' from platform in folder:
/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18
Using core 'arduino' from platform in folder:
/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18
Detecting libraries used...
"/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections
-fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC
-mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10801 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR  
"-I/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18/cores/arduino"
"-I/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18/variants/standard"
"/tmp/arduino_build_538784/sketch/SmartRegulatorv1.1.0.ino.cpp" -o "/dev/null"
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/AltReg_CAN.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/AltReg_Serial.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Alternator.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/CPE.c
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Flash.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Sensors.cpp
Using cached library dependencies for file:
/home/al/Arduino/libraries/I2Cx/I2Cx.cpp
Generating function prototypes...
"/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections

[Bug tree-optimization/81303] [8 Regression] 410.bwaves regression caused by r249919

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to Wilco from comment #8)
> (In reply to Richard Biener from comment #7)
> 
> Unfortunately these commits have had no effect on AArch64...

Because we (as well as powerpc?) don't peel for alignment now, thus the change
in peeling cost has no impact on AArch64.  I still believe interchange (on the
basis of distribution) is the correct direction to fix this regression (and
bring further improvement).  Of course, vectorization should be avoided even
after interchange on x86.

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01004.html

[Bug c++/81867] New: Internal completer error: Segmentation Fault

[al_thomason at iname dot com]

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

Bug ID: 81867
   Summary: Internal completer error:  Segmentation Fault
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: al_thomason at iname dot com
  Target Milestone: ---

While compiling my project using the Arduino IDE, I received the following:


sketch/AltReg_Serial.cpp: In function 'send_outbound':
sketch/AltReg_Serial.cpp:704:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper:
/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-gcc
returned 1 exit status
/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/../lib/gcc/avr/4.9.2/../../../../avr/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
exit status 1
Error compiling for board Arduino/Genuino Uno.
==

Environment is Arduino 1.8.1 for Linux.
Board type selected is Arduino/Genuino Uno

Per the release notes, gcc version is: 4.9.2

The following is a more verbose output during compiling:
==

Arduino: 1.8.1 (Linux), Board: "Arduino/Genuino Uno"

/usr/lib/arduino-1.8.1/arduino-builder -dump-prefs -logger=machine -hardware
/usr/lib/arduino-1.8.1/hardware -hardware /home/al/.arduino15/packages
-hardware /home/al/Arduino/hardware -tools /usr/lib/arduino-1.8.1/tools-builder
-tools /usr/lib/arduino-1.8.1/hardware/tools/avr -tools
/home/al/.arduino15/packages -built-in-libraries
/usr/lib/arduino-1.8.1/libraries -libraries /home/al/Arduino/libraries
-fqbn=arduino:avr:uno -ide-version=10801 -build-path /tmp/arduino_build_538784
-warnings=none -prefs=build.warn_data_percentage=75
-prefs=runtime.tools.avr-gcc.path=/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2
-prefs=runtime.tools.arduinoOTA.path=/home/al/.arduino15/packages/arduino/tools/arduinoOTA/1.1.1
-prefs=runtime.tools.avrdude.path=/home/al/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9
-verbose /home/al/Arduino/SmartRegulatorv1.1.0/SmartRegulatorv1.1.0.ino
/usr/lib/arduino-1.8.1/arduino-builder -compile -logger=machine -hardware
/usr/lib/arduino-1.8.1/hardware -hardware /home/al/.arduino15/packages
-hardware /home/al/Arduino/hardware -tools /usr/lib/arduino-1.8.1/tools-builder
-tools /usr/lib/arduino-1.8.1/hardware/tools/avr -tools
/home/al/.arduino15/packages -built-in-libraries
/usr/lib/arduino-1.8.1/libraries -libraries /home/al/Arduino/libraries
-fqbn=arduino:avr:uno -ide-version=10801 -build-path /tmp/arduino_build_538784
-warnings=none -prefs=build.warn_data_percentage=75
-prefs=runtime.tools.avr-gcc.path=/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2
-prefs=runtime.tools.arduinoOTA.path=/home/al/.arduino15/packages/arduino/tools/arduinoOTA/1.1.1
-prefs=runtime.tools.avrdude.path=/home/al/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino9
-verbose /home/al/Arduino/SmartRegulatorv1.1.0/SmartRegulatorv1.1.0.ino
Using board 'uno' from platform in folder:
/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18
Using core 'arduino' from platform in folder:
/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18
Detecting libraries used...
"/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections
-fdata-sections -fno-threadsafe-statics  -flto -w -x c++ -E -CC
-mmcu=atmega328p -DF_CPU=1600L -DARDUINO=10801 -DARDUINO_AVR_UNO
-DARDUINO_ARCH_AVR  
"-I/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18/cores/arduino"
"-I/home/al/.arduino15/packages/arduino/hardware/avr/1.6.18/variants/standard"
"/tmp/arduino_build_538784/sketch/SmartRegulatorv1.1.0.ino.cpp" -o "/dev/null"
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/AltReg_CAN.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/AltReg_Serial.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Alternator.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/CPE.c
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Flash.cpp
Using cached library dependencies for file:
/tmp/arduino_build_538784/sketch/Sensors.cpp
Using cached library dependencies for file:
/home/al/Arduino/libraries/I2Cx/I2Cx.cpp
Generating function prototypes...
"/home/al/.arduino15/packages/arduino/tools/avr-gcc/4.9.2-atmel3.5.4-arduino2/bin/avr-g++"
-c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections

[Bug middle-end/81814] [5/6/7/8 Regression] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Target Milestone|--- |5.5
Summary|Incorrect behaviour at -O0  |[5/6/7/8 Regression]
   |(conditional operator)  |Incorrect behaviour at -O0
   ||(conditional operator)

[Bug c++/81866] New: ICE with a default template parameter which is a template class nested in a template class

[lee.deokjae at gmail dot com]

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

Bug ID: 81866
   Summary: ICE with a default template parameter which is a
template class nested in a template class
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lee.deokjae at gmail dot com
  Target Milestone: ---

The following code causes an ICE with GCC 7.1.1. Clang 4.0 and VC++ 2017
compile the code successfully.

If I remove the forward declaration of struct C, it removes the error. Or
replacing the default template parameter with any template class defined
outside A also removes the error.



template
struct A {

   template struct C;

   template struct B;

   template>
struct C {};

};

int main(int, char**) {
A::C<> ac;
return 0;
}



Test.cpp: In instantiation of ‘struct A’:
Test.cpp:14:15:   required from here
Test.cpp:6:31: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2976
template struct B;

[Bug target/46091] missed optimization: x86 bt/btc/bts instructions

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Aug 16 15:25:34 2017
New Revision: 251124

URL: https://gcc.gnu.org/viewcvs?rev=251124=gcc=rev
Log:
PR target/46091
* config/i386/i386.md (*anddi_1_btr): Change predicates of
operand 0 and operand 1 to nomimmediate_operand. Add "m" constraint.
Add ix86_binary_operator_ok to insn constraint.
(*iordi_1_bts): Ditto.
(*xordi_1_btc): Ditto.
(*btsq): Change predicate of operand 0 to nonimmediate_operand.
Update corresponding peephole2 pattern.
(*btrq): Ditto.
(*btcq): Ditto.

testsuite/ChangeLog:

PR target/46091
* gcc.target/i386/pr46091-1.c: Update scan-assembler-times.
(testm): New test function.
* gcc.target/i386/pr46091-2.c: Ditto.
* gcc.target/i386/pr46091-3.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr46091-1.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-2.c
trunk/gcc/testsuite/gcc.target/i386/pr46091-3.c

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 Ever confirmed|0   |1

--- Comment #4 from Oleg Endo  ---
(In reply to Joseph S. Myers from comment #3)
> The patch committed limits the unrolling, but not necessarily as much as
> desirable (given the bug is about an 8-byte case and the limit is 32 bytes).

The unrolled byte checking tail doesn't seem to make sense at all.  It will run
for 4 bytes at most, because the 4-byte loop (at L5 with cmp/str in the above
example) will have already determined that there is a byte mismatch in one of
the 4 bytes.

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Eric Gallager]

On 8/15/17, Jonathan Wakely  wrote:
> On 15 August 2017 at 04:10, Martin Sebor wrote:
>> On 08/14/2017 04:22 PM, Eric Gallager wrote:
>>>
>>> I'm emailing this manually to the list because Bugzilla is down and I
>>> can't file a bug on Bugzilla about Bugzilla being down. The error
>>> message looks like this:
>
>
> Even if it were possible, there wouldn't be any point in filing a bug
> that bugzilla's down, and so not much point emailing gcc-bugs either
> (since that's for bugzilla mail).  Using gcc@ seems like the right
> list to me.
>
> N.B. since the server is being restored from a backup all of
> yesterday's changes to bugzilla have been lost, including all Richi's
> 7.2 release changes, and Eric's housekeeping.
>
> I don't suggest redoing all that work until all services are fully
> restored, in case it's lost again.
>

I see Richi redid all his 7.2 release changes; does that imply that
the server restore is now complete?

[Bug middle-end/81832] [8 Regression] ICE in expand_LOOP_DIST_ALIAS, at internal-fn.c:2273

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Aug 16 15:02:03 2017
New Revision: 251123

URL: https://gcc.gnu.org/viewcvs?rev=251123=gcc=rev
Log:
PR tree-optimization/81832
* tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Don't
copy loop header which has IFN_LOOP_DIST_ALIAS call.

gcc/testsuite
* gcc.dg/tree-ssa/pr81832.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr81832.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-ch.c

[Bug tree-optimization/81488] [8 Regression] gcc goes off the limits allocating memory in gimple-ssa-strength-reduction.c

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Doesn't reproduce for powerpc64le on current trunk.  I'll try a cross.

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bill Schmidt  ---
Now fixed everywhere.

[Bug bootstrap/81864] New: building gcc 8 with --enable-gather-detailed-mem-stats fails on x86-64, arm and aarch64 under gnu linux

[andrewm.roberts at sky dot com]

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

Bug ID: 81864
   Summary: building gcc 8 with --enable-gather-detailed-mem-stats
fails on x86-64, arm and aarch64 under gnu linux
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrewm.roberts at sky dot com
  Target Milestone: ---

Building gcc gcc-8-20170806 with --enable-gather-detailed-mem-stats fails:
On x64, arm and aarch64.

gcc-7.2.0 (release version) builds ok (at least on x64) with same options.
gcc-8.0.0 20170813 also fails on all.

on x64:

/home/aroberts/gcc/gcc-build/./gcc/xgcc -B/home/aroberts/gcc/gcc-build/./gcc/
-xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc-8.0.0/gcc/testsuite/selftests
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1952: s-selftest-c] Error 4
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod
gfortran.pod gcov-tool.pod
make[2]: Leaving directory '/home/aroberts/gcc/gcc-build/gcc'
make[1]: *** [Makefile:4305: all-gcc] Error 2
make[1]: Leaving directory '/home/aroberts/gcc/gcc-build'
make: *** [Makefile:918: all] Error 2

/home/aroberts/gcc/gcc-build/./gcc/xgcc -v -save-temps
-B/home/aroberts/gcc/gcc-build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc-8.0.0/gcc/testsuite/selftests
Reading specs from /home/aroberts/gcc/gcc-build/./gcc/specs
COLLECT_GCC=/home/aroberts/gcc/gcc-build/./gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0
--program-suffix= --disable-werror --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --enable-gnu-indirect-function --with-isl
--enable-languages=c,c++,fortran,lto --disable-libgcj --enable-lto
--enable-multilib --with-tune=generic --with-arch_32=i686
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--with-ld=/usr/local/bin/ld --with-gnu-ld --with-as=/usr/local/bin/as
--with-gnu-as --disable-bootstrap --enable-gather-detailed-mem-stats
Thread model: posix
gcc version 8.0.0 20170806 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B'
'/home/aroberts/gcc/gcc-build/./gcc/' '-nostdinc' '-S' '-o' '/dev/null'
'-fself-test=../../gcc-8.0.0/gcc/testsuite/selftests' '-mtune=generic'
'-march=x86-64'
 /home/aroberts/gcc/gcc-build/./gcc/cc1 -E -quiet -nostdinc -v -iprefix
/home/aroberts/gcc/gcc-build/gcc/../lib/gcc/x86_64-unknown-linux-gnu/8.0.0/
-isystem /home/aroberts/gcc/gcc-build/./gcc/include -isystem
/home/aroberts/gcc/gcc-build/./gcc/include-fixed /dev/null -mtune=generic
-march=x86-64 -fself-test=../../gcc-8.0.0/gcc/testsuite/selftests
-fpch-preprocess -o null.i
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Host OS:
Fedora 26 - x64

host gcc: 
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC) 

host ld:
ld -v
GNU ld (GNU Binutils) 2.29

uname -a
Linux ryzen 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64
x86_64 x86_64 GNU/Linux

cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 23
model   : 1
model name  : AMD Ryzen 7 1700 Eight-Core Processor
stepping: 1
microcode   : 0x8001126
cpu MHz : 1550.000
cache size  : 512 KB
physical id : 0
siblings: 16
core id : 0
cpu cores   : 8
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes

[Bug target/61373] neon registers restored incorrectly with -mapcs-frame -O -fno-omit-frame-pointer

[rolf.woehrm...@t-online.de]

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

rolf.woehrm...@t-online.de changed:

   What|Removed |Added

 CC||rolf.woehrm...@t-online.de

--- Comment #4 from rolf.woehrm...@t-online.de ---
Hi

this problem of generating wrong restore code for neon registers is still
happening in 7.2.0 when using the -mapcs-frame option.

Since this is just wrong code generation which should never happen, I highly
recommend to either emit a warning when using neon with -mapcs-frame option
(like together with -mfpu=neon-xyz) or simply fix the code generation bug.

I ran into this problem and spent aka wasted the last 3 days to find this out.
A simple warning at least should have avoided this. In most of the cases we
could remove -mapcs-frame if we only knew.

Gret Thanks
Rolf

[Bug tree-optimization/81814] Incorrect behaviour at -O0 (conditional operator)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
I wonder if I could just

--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -3401,14 +3401,14 @@ operand_equal_for_comparison_p (tree arg0, tree arg1,
tree other)

   primarg1 = get_narrower (arg1, );
   primother = get_narrower (other, );
+  tree type = TREE_TYPE (arg0);

   correct_width = TYPE_PRECISION (TREE_TYPE (arg1));
   if (unsignedp1 == unsignedpo
+  && TYPE_PRECISION (TREE_TYPE (primarg1)) == TYPE_PRECISION (type)
   && TYPE_PRECISION (TREE_TYPE (primarg1)) < correct_width
   && TYPE_PRECISION (TREE_TYPE (primother)) < correct_width)
 {
-  tree type = TREE_TYPE (arg0);
-
   /* Make sure shorter operand is extended the right way
 to match the longer operand.  */
   primarg1 = fold_convert (signed_or_unsigned_type_for

so far it seems to work.

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[rearnsha at gcc dot gnu.org]

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

--- Comment #9 from Richard Earnshaw  ---
(In reply to Andrew Roberts from comment #8)
> I've tried building gcc-8-20170806 and gcc-8-20170813 with
> --enable-gather-detailed-mem-stats
> 
> This fails on x86-64, arm and aarch64 with the same error.
> 
> Shall I file a separate bug report for gcc-8?
> 

Yes please.  One bug report per issue.

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Aug 16 14:13:27 2017
New Revision: 251122

URL: https://gcc.gnu.org/viewcvs?rev=251122=gcc=rev
Log:
[gcc]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Insert on edges rather than explicitly creating landing pads.
(analyze_candidates_and_replace): Commit edge inserts.


[gcc/testsuite]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* g++.dg/torture/pr81354.C: New file.


Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/torture/pr81354.C
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Aug 16 14:11:26 2017
New Revision: 251121

URL: https://gcc.gnu.org/viewcvs?rev=251121=gcc=rev
Log:
[gcc]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Insert on edges rather than explicitly creating landing pads.
(analyze_candidates_and_replace): Commit edge inserts.


[gcc/testsuite]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* g++.dg/torture/pr81354.C: New file.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr81354.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #8 from Andrew Roberts  ---
I've tried building gcc-8-20170806 and gcc-8-20170813 with
--enable-gather-detailed-mem-stats

This fails on x86-64, arm and aarch64 with the same error.

The recently released 7.2.0 build ok on x86-64 at least, still testing the
rest.

Shall I file a separate bug report for gcc-8?

The error is:
/home/aroberts/gcc/gcc-build/./gcc/xgcc -B/home/aroberts/gcc/gcc-build/./gcc/
-xc -nostdinc /dev/null -S -o /dev/null
-fself-test=../../gcc-8.0.0/gcc/testsuite/selftests
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [Makefile:1952: s-selftest-c] Error 4
rm fsf-funding.pod gcov.pod gpl.pod cpp.pod gfdl.pod gcc.pod gcov-dump.pod
gfortran.pod gcov-tool.pod
make[2]: Leaving directory '/home/aroberts/gcc/gcc-build/gcc'
make[1]: *** [Makefile:4305: all-gcc] Error 2
make[1]: Leaving directory '/home/aroberts/gcc/gcc-build'
make: *** [Makefile:918: all] Error 2

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Yes, r251029 still needs tweaking.  It needs to use strnlen(s, n) to safely
determine the length of s, not strlen(s), to avoid reading past the end of s if
it's not nul-terminated.

[Bug tree-optimization/81354] [5/6 Regression] Segmentation fault in SSA Strength Reduction using -O3

[wschmidt at gcc dot gnu.org]

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

--- Comment #12 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Aug 16 14:09:15 2017
New Revision: 251120

URL: https://gcc.gnu.org/viewcvs?rev=251120=gcc=rev
Log:
[gcc]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* gimple-ssa-strength-reduction.c (create_add_on_incoming_edge):
Insert on edges rather than explicitly creating landing pads.
(analyze_candidates_and_replace): Commit edge inserts.


[gcc/testsuite]

2017-08-16  Bill Schmidt  

Backport from mainline
2017-08-08  Bill Schmidt  

PR tree-optimization/81354
* g++.dg/torture/pr81354.C: New file.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr81354.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug lto/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Uroš Bizjak  ---
CC Richi.

[Bug lto/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug lto/81861] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
  Component|tree-optimization   |lto
 Ever confirmed|0   |1

--- Comment #4 from Uroš Bizjak  ---
Yep, something is wrong with LTO:

/hdd/uros/gcc-build/gcc/xgcc -B
/hdd/uros/gcc-build/x86_64-pc-linux-gnu/libsanitizer/ -B
/hdd/uros/gcc-build/x86_64-pc-linux-gnu/libsanitizer/asan/ -B
/hdd/uros/gcc-build/x86_64-pc-linux-gnu/libsanitizer/asan/.libs -B
/hdd/uros/gcc-build/gcc -fstack-protector-strong -fsanitize=address -O2 -flto
-save-temps pr64820.c

produces ccbxiIwG.ltrans0.s with:

movl$-235802127, 2147450880(%rdx)
movl$-202116109, 2147451396(%rdx)
>>  movq0, %rax
movq%rax, 4184(%rsp)
xorl%eax, %eax

Confirmed as LTO problem.

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Testing a patch changing level 5 at -O1 from

> /usr/bin/time /space/rguenther/install/gcc-7.2/bin/gfortran -S t.f90 -O 
1139.91user 1.99system 19:02.37elapsed 99%CPU (0avgtext+0avgdata
8035048maxresident)k
40816inputs+144outputs (49major+2004165minor)pagefaults 0swaps

to

> /usr/bin/time /abuild/rguenther/obj2/gcc/f951 t.f90 -O -quiet
126.42user 1.18system 2:26.94elapsed 86%CPU (0avgtext+0avgdata
2433296maxresident)k
0inputs+176outputs (0major+638570minor)pagefaults 0swaps

[Bug tree-optimization/81861] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[m.ostapenko at samsung dot com]

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

--- Comment #3 from Maxim Ostapenko  ---

(In reply to Uroš Bizjak from comment #1)
> You didn't specify compile flags, but using:
> 
> -O2 -fstack-protector-strong -fsanitize=address, I get:

Sorry, here they are:

$ /home/max/build/master/gcc/xgcc -B/home/max/build/master/gcc/
/home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c
-B/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/
-B/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/asan/
-L/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs
-fsanitize=address -g
-I/home/max/workspace/downloads/gcc/gcc/testsuite/../../libsanitizer/include
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects -fstack-protector-strong -lm -o
./pr64820.exe

$ /home/max/build/master/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/max/build/master/gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib
--enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master --disable-bootstrap --enable-languages=c,c++
CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' : (reconfigured)
/home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking
--target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master
--disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0'
build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu
target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure
--enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0'
CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu
host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu
--enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured)
/home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking
--target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master
--disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0'
build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu
target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure
--enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0'
CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu
host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu
--enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured)
/home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking
--target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master
--disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0'
build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu
target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create
--no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure
--enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu
--prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0'
CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu
host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu
--enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
gcc version 8.0.0 20170808 (experimental) (GCC) 

> 
>   51:   c7 82 00 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8000(%rdx)
>   58:   f1 f1 f1 
>   5b:   c7 82 04 82 ff 7f f3movl   $0xf3f3f3f3,0x7fff8204(%rdx)
>   62:   f3 f3 f3 
>   65:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
>   6c:   00 00 
>   6e:   48 89 84 24 58 10 00mov%rax,0x1058(%rsp)
>   75:   00 
>   76:   31 c0   xor%eax,%eax
> 
> The insn in question is:
> 
> #(insn:TI 35 19 40 3 (parallel [
> #(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp)
> #(const_int 4184 [0x1058])) [2 D.2177+0 S8 A64])
> #(unspec:DI [
> #(mem/f:DI (const_int 40 [0x28]) [4
> MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
> #] UNSPEC_SP_SET))
> #(set (reg:DI 0 ax [97])
> #(const_int 0 [0]))
> #  

[Bug tree-optimization/81861] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #1)

> Maybe LTO doesn't handle address spaces correctly?
Er, asan, not LTO.

[Bug target/81863] New: [7 regression] -mword-relocations is unreliable

[arnd at linaro dot org]

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

Bug ID: 81863
   Summary: [7 regression] -mword-relocations is unreliable
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 41989
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41989=edit
preprocessed linux/mm/shmem.c file, compressed

I ran into a few files in the linux kernel that while building with
-mword-relocations still produce 16-bit relocations, leading to a link error
with -fpie, e.g.

arm-linux-gnueabi-ld: mm/page_alloc.o: relocation R_ARM_THM_MOVW_ABS_NC against
`vm_zone_stat' can not be used when making a shared object; recompile with
-fPIC

With the attached source file:

$ arm-linux-gnueabi-gcc-7.1.1 -Wall mm/shmem.i -O2 -march=armv7-a -c
-Wno-unused -Wno-pointer-sign -fno-strict-aliasing -mword-relocations
$ objdump -dr mm/shmem.o | grep R_ARM_MOVW
326c: R_ARM_MOVW_ABS_NC vm_committed_as
34b8: R_ARM_MOVW_ABS_NC vm_committed_as
357c: R_ARM_MOVW_ABS_NC vm_committed_as

[Bug c++/81862] New: [C++11][constexpr] Constructor Parenthesized Initialization of Member Array Crash

[dsanders11 at ucsbalum dot com]

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

Bug ID: 81862
   Summary: [C++11][constexpr] Constructor Parenthesized
Initialization of Member Array Crash
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dsanders11 at ucsbalum dot com
  Target Milestone: ---

Created attachment 41988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41988=edit
Reproduce case

Crash when using a parenthesized initialization of a member array with a
constexpr constructor.

Whittled the reproduce case down as much as I could, all parts of the reproduce
case source seem relevant to causing the crash. Switching to the standard
initialization of the member array without parentheses fixes the crash.

Crash error:

main.cpp:46:46: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2635
 constexpr Foo foobar(32, false);

[Bug tree-optimization/81861] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
You didn't specify compile flags, but using:

-O2 -fstack-protector-strong -fsanitize=address, I get:

  51:   c7 82 00 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8000(%rdx)
  58:   f1 f1 f1 
  5b:   c7 82 04 82 ff 7f f3movl   $0xf3f3f3f3,0x7fff8204(%rdx)
  62:   f3 f3 f3 
  65:   64 48 8b 04 25 28 00mov%fs:0x28,%rax
  6c:   00 00 
  6e:   48 89 84 24 58 10 00mov%rax,0x1058(%rsp)
  75:   00 
  76:   31 c0   xor%eax,%eax

The insn in question is:

#(insn:TI 35 19 40 3 (parallel [
#(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp)
#(const_int 4184 [0x1058])) [2 D.2177+0 S8 A64])
#(unspec:DI [
#(mem/f:DI (const_int 40 [0x28]) [4
MEM[( long unsigned int *)40B]+0 S8 A64 AS1])
#] UNSPEC_SP_SET))
#(set (reg:DI 0 ax [97])
#(const_int 0 [0]))
#(clobber (reg:CC 17 flags))
#]) "pr64820.c":13 1002 {stack_protect_set_di}
# (expr_list:REG_UNUSED (reg:CC 17 flags)
#(expr_list:REG_UNUSED (reg:DI 0 ax [97])
#(nil
movq%fs:40, %rax# 35stack_protect_set_di[length = 16]
movq%rax, 4184(%rsp)
xorl%eax, %eax

Maybe LTO doesn't handle address spaces correctly?

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 CC||marxin at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r251029.

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #10 from christian.tremel at itsv dot at ---
tried out the 6.4 source, same errors.

[Bug target/77953] [MIPS] ice: insn does not satisfy its constraints - __bswapsi2

[james410 at cowgill dot org.uk]

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

--- Comment #2 from James Cowgill  ---
This appears to be fixed with GCC 7. It is still broken on the GCC 6 branch
though (using 6.4).

[Bug tree-optimization/81861] New: ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong

[m.ostapenko at samsung dot com]

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

Bug ID: 81861
   Summary: ASan pr64820.c testcase segfaults with LTO and
-fstack-protector-strong
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.ostapenko at samsung dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

After r250965 the ASan's pr64820.c tescase fails with:

ASAN:DEADLYSIGNAL
=
==15720==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x004009e5 bp 0x7fff5fca17c0 sp 0x7fff5fca17c0 T0)
==15720==The signal is caused by a READ memory access.
==15720==Hint: address points to the zero page.
#0 0x4009e4 in Func1
/home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:13
#1 0x40080a in main
/home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:23
#2 0x2b7622799f44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21f44)
#3 0x40085a 
(/home/max/build/master/gcc/testsuite/gcc/pr64820.exe+0x40085a)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:13
in Func1
==15720==ABORTING

The code in resuting binary looks like this:

00400910 :
  400910:   41 54   push   %r12
  400912:   55  push   %rbp
  400913:   53  push   %rbx
  400914:   48 81 ec 60 10 00 00sub$0x1060,%rsp
  40091b:   8b 05 5f 06 20 00   mov0x20065f(%rip),%eax#
600f80 <__TMC_END__>
  400921:   48 89 e3mov%rsp,%rbx
  400924:   48 89 ddmov%rbx,%rbp
  400927:   85 c0   test   %eax,%eax
  400929:   0f 85 8a 00 00 00   jne4009b9 
  40092f:   48 89 damov%rbx,%rdx
  400932:   48 8d 7b 20 lea0x20(%rbx),%rdi
  400936:   48 c7 03 b3 8a b5 41movq   $0x41b58ab3,(%rbx)
  40093d:   48 c1 ea 03 shr$0x3,%rdx
  400941:   48 c7 43 08 08 0b 40movq   $0x400b08,0x8(%rbx)
  400948:   00 
  400949:   48 c7 43 10 10 09 40movq   $0x400910,0x10(%rbx)
  400950:   00 
  400951:   c7 82 00 80 ff 7f f1movl   $0xf1f1f1f1,0x7fff8000(%rdx)
  400958:   f1 f1 f1 
  40095b:   c7 82 04 82 ff 7f f3movl   $0xf3f3f3f3,0x7fff8204(%rdx)
  400962:   f3 f3 f3 

Segfault here==> 400965:   48 8b 04 25 00 00 00mov0x0,%rax

  40096c:   00 
  40096d:   48 89 84 24 58 10 00mov%rax,0x1058(%rsp)
  400974:   00 
  400975:   31 c0   xor%eax,%eax
  400977:   e8 84 ff ff ff  callq  400900 

[Bug other/81096] [8 regression] test case ttest in libbacktrace fails starting with its introduction in r249111

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 CC||wilco at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Wilco  ---
Confirmed. It works fine for me with ttest_CFLAGS = -pthread -funwind-tables so
the issue is that it doesn't also add $(AM_CFLAGS) like btest_CFLAGS does.

[Bug c++/81860] New: Call to undefined inline function involving inheriting constructors

[wielkiegie at gmail dot com]

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

Bug ID: 81860
   Summary: Call to undefined inline function involving inheriting
constructors
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wielkiegie at gmail dot com
  Target Milestone: ---

Created attachment 41987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41987=edit
Minimized test case that reproduces the issue

It seems that gcc forgets to emit or inline an empty inline constructor when
the following are used:
1. An empty template class A with empty constructor A() {} that is the one that
is missed
2. A class B with a template constructor (doesn't matter what is templated)
that accepts an object of class A with a default argument A() and stores it
inside of itself
3. A class C that derives from class B and uses inheriting constructors

Attached is a test-case for this.

$ g++ test-case3.cpp
/tmp/ccoFntWy.o: In function `main':
test-case3.cpp:(.text+0x11): undefined reference to `A::A()'
collect2: error: ld returned 1 exit status

The problem does occur on gcc 7 and the newest snapshot (tested on godbolt). It
does not occur on gcc 6 and gcc 5. As such, it's a regression that first occurs
in gcc 7.

[Bug c/81859] [8 Regression] valgrind error from warn_about_normalization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|valgrind error from |[8 Regression] valgrind
   |warn_about_normalization|error from
   ||warn_about_normalization

[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.3 |6.3

--- Comment #10 from Ramana Radhakrishnan  ---
This was really fixed for 6.3 ...

[Bug c/81845] const union's field doesn't interpret as const in switch/case

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Aleksandr Slobodeniuk from comment #0)
> What's funny is that I didn't find any compiler, that could compile it.

That usually means it's not a bug then.

[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug 16 11:26:41 2017
New Revision: 251119

URL: https://gcc.gnu.org/viewcvs?rev=251119=gcc=rev
Log:
PR middle/81695
* fold-const.c (fold_indirect_ref_1): Restore original behavior
regarding size_zero_node.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c

[Bug c/64609] No -Wbool-compare warning on "(a = 0 && 0) <= 4"

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
It's because we get rid of that && 0 prior calling maybe_warn_bool_compare. 
But we warn for

int
fn1 (int a, int b)
{
  return ((a && b) <= 4);
}

warning: comparison of constant ‘4’ with boolean expression is always true

[Bug c/81845] const union's field doesn't interpret as const in switch/case

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Aleksandr Slobodeniuk from comment #3)
> Fields of const-qualified structs and unions, that were initialized with
> const literals ARE *constant expressions*, isn't it?

No. See 6.6 p6

[Bug c/81845] const union's field doesn't interpret as const in switch/case

[alenuke at yandex dot ru]

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

--- Comment #4 from Aleksandr Slobodeniuk  ---
> Fields of const-qualified structs and unions, that were initialized with
> const literals ARE *constant expressions*, isn't it?

Maybe that's the answer:

C11 standard.
6.6 Constant expressions.

> 6 Aninteger constant expression117) shall have integer type and shall only 
> have operands that are integer constants, enumeration constants, character
> constants, sizeof expressions whose results are integer constants,
> _Alignof expressions, and floating constants that are the immediate
> operands of casts. Cast operators in an integer constant expression
> shall only convert arithmetic types to integer types, except as part of
> an operand to the sizeof or _Alignof operator.

[Bug c/81845] const union's field doesn't interpret as const in switch/case

[alenuke at yandex dot ru]

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

--- Comment #3 from Aleksandr Slobodeniuk  ---
(In reply to Richard Biener from comment #1)
> it has to be a constant literal.

Sorry, I didn't really specify the standard (and mess c with c++).

C11 standard.
6.8.4.2 The switch statement.

> 3 The expression of each case label shall be an integer constant expression
> and no two of the case constant expressions in the same switch statement 
> shall have the same value after conversion.


So, by C11 standard case label shall be a constant expression.

Fields of const-qualified structs and unions, that were initialized with const
literals ARE *constant expressions*, isn't it?

-

Yes, the standard also says that uninitialized part of union is undefined, but
that's not that case if we have fields with the same size.

-

Sorry for wasting your time.

[Bug c/81845] const union's field doesn't interpret as const in switch/case

[alenuke at yandex dot ru]

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

--- Comment #2 from Aleksandr Slobodeniuk  ---
Sorry, I didn't really specify the standard (and mess c with c++).

C11 standard.
6.8.4.2 The switch statement.

> 3 The expression of each case label shall be an integer constant expression
> and no two of the case constant expressions in the same switch statement 
> shall have the same value after conversion.

So, by C11 standard case label shall be a constant expression.

Fields of const-qualified structs and unions, that were initialized with const
literals ARE *constant expressions*, isn't it?

-

Yes, the standard also says that uninitialized part of union is undefined, but
that's not that case if we have fields with the same size.

-

Sorry for wasting your time.

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #9 from christian.tremel at itsv dot at ---
this is one more reason why i prefer the native ibm compilers.

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #7 from Andrew Roberts  ---
I'll try the memory testing on both arm and aarch64.

I've also tried -fopt-info-all-optall, I was hoping this would provide some
info on what was happening, but it only seems to give any output under -O3.

[Bug lto/81487] [mingw32] ld.exe: error: asprintf failed

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.3 |7.2

--- Comment #6 from Georg-Johann Lay  ---
Fixed in 6.5 and 7.2+.

[Bug middle-end/81818] aarch64 uses 2-3x memory and 2x time of arm at -Os, -O2, -O3

[andrewm.roberts at sky dot com]

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

--- Comment #6 from Andrew Roberts  ---
Looks like this info got purged by the bugzilla failure, here it is again:

Ok, I've done some more digging. 

Looking at the optimization options enabled by -O2 vs -O1, I built the test
program at -O1 and enabled each optimization in turn, on both ARM and AARCH64.

It looks like -fgcse is using the most memory of all the optimizations.
On ARM "-O1 -fgcse" is using MORE memory than "-O2". 

This suggests to me that on ARM the gcse optimization is not being run for -O2
due to some cost benefit analysis or something. Where as it is on AARCH64. Is
there anyway to get some info out of gcc to prove this?

On AARCH64 -fgcse results in a huge compile time increase due to the additional
memory usage causing massive swapping. ARM compile time increased by 14%, but
AARCH compile time increased by 400%. When there is enough RAM to avoid
swapping  -fgcse looks ok (2Gb on odroid-c2).

Tested using: gcc version 8.0.0 20170806 (experimental) (GCC) on
Raspberry PI 3 1Gb RAM (both armv7l and aarch64).

For ARM:

Optimization Level: -O1 -falign-functions
Time=1:20.76 Mem=320040 PageFaults=0
Optimization Level: -O1 -falign-jumps
Time=1:21.10 Mem=319940 PageFaults=0
Optimization Level: -O1 -falign-labels
Time=1:21.00 Mem=320028 PageFaults=0
Optimization Level: -O1 -falign-loops
Time=1:20.62 Mem=320028 PageFaults=0
Optimization Level: -O1 -fcaller-saves
Time=1:20.45 Mem=319884 PageFaults=0
Optimization Level: -O1 -fcode-hoisting
Time=1:22.01 Mem=320832 PageFaults=0
Optimization Level: -O1 -fcrossjumping
Time=1:21.28 Mem=320164 PageFaults=0
Optimization Level: -O1 -fcse-follow-jumps
Time=1:20.47 Mem=32 PageFaults=0
Optimization Level: -O1 -fdevirtualize
Time=1:42.07 Mem=320032 PageFaults=0
Optimization Level: -O1 -fdevirtualize-speculatively
Time=1:20.44 Mem=320008 PageFaults=0
Optimization Level: -O1 -fexpensive-optimizations
Time=1:22.92 Mem=321752 PageFaults=0
Optimization Level: -O1 -fgcse
Time=1:34.12 Mem=556640 PageFaults=0 <
Optimization Level: -O1 -fhoist-adjacent-loads
Time=1:20.45 Mem=319940 PageFaults=0
Optimization Level: -O1 -findirect-inlining
Time=1:21.31 Mem=320020 PageFaults=0
Optimization Level: -O1 -finline-small-functions
Time=1:32.36 Mem=319992 PageFaults=0
Optimization Level: -O1 -fipa-bit-cp
Time=1:21.13 Mem=320008 PageFaults=0
Optimization Level: -O1 -fipa-cp
Time=1:19.94 Mem=322140 PageFaults=0
Optimization Level: -O1 -fipa-icf
Time=1:21.50 Mem=319940 PageFaults=0
Optimization Level: -O1 -fipa-icf-functions
Time=1:20.93 Mem=320060 PageFaults=0
Optimization Level: -O1 -fipa-icf-variables
Time=1:20.48 Mem=320044 PageFaults=0
Optimization Level: -O1 -fipa-ra
Time=1:20.58 Mem=320284 PageFaults=0
Optimization Level: -O1 -fipa-sra
Time=1:12.69 Mem=310648 PageFaults=0
Optimization Level: -O1 -fipa-vrp
Time=1:20.45 Mem=319836 PageFaults=0
Optimization Level: -O1 -fisolate-erroneous-paths-dereference
Time=1:20.61 Mem=320024 PageFaults=0
Optimization Level: -O1 -flra-remat
Time=1:20.56 Mem=319944 PageFaults=0
Optimization Level: -O1 -foptimize-sibling-calls
Time=1:20.69 Mem=320012 PageFaults=0
Optimization Level: -O1 -foptimize-strlen
Time=1:21.10 Mem=320024 PageFaults=0
Optimization Level: -O1 -fpartial-inlining
Time=1:21.19 Mem=319888 PageFaults=0
Optimization Level: -O1 -fpeephole2
Time=1:20.75 Mem=319888 PageFaults=0
Optimization Level: -O1 -freorder-functions
Time=1:20.63 Mem=319884 PageFaults=0
Optimization Level: -O1 -frerun-cse-after-loop
Time=1:21.96 Mem=320984 PageFaults=0
Optimization Level: -O1 -fschedule-insns2
Time=1:24.68 Mem=343916 PageFaults=0
Optimization Level: -O1 -fschedule-insns
Time=1:52.77 Mem=324696 PageFaults=0
Optimization Level: -O1 -fstore-merging
Time=1:20.47 Mem=320208 PageFaults=0
Optimization Level: -O1 -fstrict-aliasing
Time=1:20.86 Mem=319880 PageFaults=0
Optimization Level: -O1 -fthread-jumps
Time=1:20.31 Mem=319900 PageFaults=0
Optimization Level: -O1 -ftree-pre
Time=1:21.38 Mem=320696 PageFaults=0
Optimization Level: -O1 -ftree-switch-conversion
Time=1:20.51 Mem=320004 PageFaults=0
Optimization Level: -O1 -ftree-tail-merge
Time=1:21.13 Mem=320040 PageFaults=0
Optimization Level: -O1 -ftree-vrp
Time=1:21.01 Mem=323032 PageFaults=0

For AARCH64:

Optimization Level: -O1 -falign-functions
Time=2:22.49 Mem=393844 PageFaults=150
Optimization Level: -O1 -falign-jumps
Time=2:20.70 Mem=393952 PageFaults=0
Optimization Level: -O1 -falign-labels
Time=2:21.09 Mem=393880 PageFaults=0
Optimization Level: -O1 -falign-loops
Time=2:20.68 Mem=393956 PageFaults=0
Optimization Level: -O1 -fcaller-saves
Time=2:20.98 Mem=393968 PageFaults=0
Optimization Level: -O1 -fcode-hoisting
Time=2:22.60 Mem=395656 PageFaults=0
Optimization Level: -O1 -fcrossjumping
Time=2:21.69 Mem=393956 PageFaults=0
Optimization Level: -O1 -fcse-follow-jumps
Time=2:21.12 Mem=393968 PageFaults=0
Optimization Level: -O1 -fdevirtualize
Time=2:58.68 Mem=393412 PageFaults=0
Optimization Level: 

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

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

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

--- Comment #8 from Andreas Schwab  ---
Your g++ is broken.

configure: error: in `/usr/local/src/gnutoolchain/gcc-7.2.0/gcc-build-7.2/gcc':
configure: error: cannot compute sizeof (long long)
See `config.log' for more details.

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #7 from christian.tremel at itsv dot at ---
Created attachment 41986
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41986=edit
build_gcc.log

to rule out potential xlc quirks, i took a run with an older version of gcc.
also fails at same stage.

build script used:

#!/usr/bin/bash

gmake clean
gmake distclean

export CONFIG_SHELL="/opt/freeware/bin/bash"
export CONFIGURE_ENV_ARGS="/opt/freeware/bin/bash"

# work around strange libtool error, see details at:
# https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14145662
export RM="/usr/bin/rm -f"
export AR="/usr/bin/ar"

# use maximum amount of memory (heap) available to 32-bit programs
# seems not to be taken into account though
export LDR_CNTRL="MAXDATA=0x8000"

export CC="gcc"
export CXX="g++"
export BOOT_CFLAGS="-O2 -I/opt/freeware/include"
export CFLAGS="-O2 -I/opt/freeware/include"
export CXXFLAGS="-O2 -I/opt/freeware/include"
export LIBCFLAGS="-O2 -I/opt/freeware/include"
export LIBCXXFLAGS="-O2 -I/opt/freeware/include"
export LDFLAGS="-L/opt/freeware/lib -Wl,-bbigtoc
-Wl,-blibpath:/opt/freeware/lib/gcc/powerpc-ibm-aix7.1.0.0/4.9.4:/opt/freeware/lib:/usr/lib:/lib
-Wl,-bmaxdata:0x8000"

../configure \
--with-as=/usr/bin/as \
--with-ld=/usr/bin/ld \
--prefix=/usr/local/gcc7 \
--disable-werror \
--enable-languages="c,c++,fortran,objc" \
--enable-version-specific-runtime-libs \
--disable-nls \
--enable-decimal-float=dpd \
--with-cloog=no \
--with-ppl=no \
--enable-__cxa_atexit \
--disable-libstdcxx-pch \
--with-included-gettext \
--enable-bootstrap

ulimit -d unlimited
ulimit -s unlimited
gmake -j 4 bootstrap

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #6 from christian.tremel at itsv dot at ---
well, it is.

root@aixbuildhost: /root # cat hello.cpp
#include 

int main()
{
  std::cout << "It's me,Maria !\n";
}

root@aixbuildhost: /root # vi hello.cpp
root@aixbuildhost: /root # xlC_r -o /root/hello /root/hello.cpp
root@aixbuildhost: /root # ./hello
It's me,Mario !

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

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

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

--- Comment #5 from Andreas Schwab  ---
Looks like xlC_r is not a C++ compiler.

[Bug c/81859] New: valgrind error from warn_about_normalization

[dcb314 at hotmail dot com]

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

Bug ID: 81859
   Summary: valgrind error from warn_about_normalization
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the C testsuite file c-c++-common/cpp/normalize-3.c,
a valgrind build of trunk gcc revision 251105 does this:

c-c++-common/cpp/normalize-3.c:5:1: error: unknown type name ‘ª’
 \u00AA
 ^~
==24049== Conditional jump or move depends on uninitialised value(s)
==24049==at 0x4C31B98: strlen (vg_replace_strmem.c:458)
==24049==by 0x112A520: pp_format(pretty_printer*, text_info*)
(pretty-print.
c:676)
==24049==by 0x112322E: diagnostic_report_diagnostic(diagnostic_context*,
dia
gnostic_info*) (diagnostic.c:974)
==24049==by 0x61977A: c_cpp_error(cpp_reader*, int, int, rich_location*,
cha
r const*, __va_list_tag (*) [1]) (c-common.c:6128)
==24049==by 0x1139A20: cpp_diagnostic_with_line(cpp_reader*, int, int,
unsig
ned int, unsigned int, char const*, __va_list_tag (*) [1]) (errors.c:174)
==24049==by 0x1139DE8: cpp_warning_with_line(cpp_reader*, int, unsigned
int,
 unsigned int, char const*, ...) (errors.c:210)
==24049==by 0x1142B97: warn_about_normalization(cpp_reader*, cpp_token
const
*, normalize_state const*) [clone .isra.11] [clone .part.12] (lex.c:1310)
==24049==by 0x114521C: warn_about_normalization (lex.c:2916)

Revision 250947 doesn't have this problem, so it looks new to me.

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||joerg.rich...@pdv-fs.de

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

[Bug c++/81858] Wrong strict-aliasing warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
This is already fixed in GCC 7.2, which was released this week.

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

[Bug c++/81858] New: Wrong strict-aliasing warning

[joerg.rich...@pdv-fs.de]

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

Bug ID: 81858
   Summary: Wrong strict-aliasing warning
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

cat > t.cc < struct Quux
{
void foo() const
{
  Baz baz;
  if( !baz.val )
  {
  }
}
};
EOF
g++ -O2 -c t.cc -Wall

t.cc: In member function 'void Quux::foo() const':
t.cc:16:16: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
   if( !baz.val )
^~~

[Bug libstdc++/81857] New: istreambuf_iterator not work as input iterator

[abominable-snowman at yandex dot ru]

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

Bug ID: 81857
   Summary: istreambuf_iterator not work as input iterator
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abominable-snowman at yandex dot ru
  Target Milestone: ---

istreambuf_iterator not increment g-pointer of istream, so character will be
extracted twice (or more, under some occasion), so it not work as single-pass
input iterator:

  std::stringstream s;
  char b[] = "c2ee3d09-43b3-466d-b490-db35999a22cf";
  char r[] = "";
  //  012345678901234567890123456789012345

  s << b;
  EXAM_CHECK( !s.fail() ); // pass
  std::copy_n( std::istreambuf_iterator(s), 36, r );
  EXAM_CHECK( !s.fail() ); // pass
  EXAM_CHECK( memcmp(b, r, 36) == 0 ); // pass
  EXAM_CHECK( s.tellg() == 35 ); // pass ?!
  char c = 'q';
  std::copy_n( std::istreambuf_iterator(s), 1,  );
  EXAM_CHECK( !s.fail() ); // pass ?!
  EXAM_CHECK( c == 'f' ); // pass ?!
  EXAM_CHECK( s.tellg() == 35 ); // pass ?!

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #4 from christian.tremel at itsv dot at ---
Created attachment 41985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41985=edit
build.log

[Bug libstdc++/68210] nothrow operator fails to call default new

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|7.3 |---

[Bug c++/81852] Feature request: __cpp_threadsafe_static_init

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-16
 Ever confirmed|0   |1

[Bug libstdc++/81017] Class with vector of unique_ptr and std::function does not compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|7.3 |6.5

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

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

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

--- Comment #3 from Andreas Schwab  ---
The full build log, not just an excerpt.

[Bug bootstrap/81856] AIX: Makefile:20538: recipe for target 'stage1-bubble' failed

[christian.tremel at itsv dot at]

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

--- Comment #2 from christian.tremel at itsv dot at ---
hmmm..not sure which logfile you are after. theres is nothing in config.log
that points to that bubble error.

root@aixbuildhost: /usr/local/src/gnutoolchain/gcc-7.2.0/gcc-build-7.2 # grep
-r stage1-bubble *
Makefile:.PHONY: stage1-bubble
Makefile:stage1-bubble::
Makefile:stage2-bubble:: stage1-bubble
Makefile:stageprofile-bubble:: stage1-bubble
Makefile:stageautoprofile-bubble:: stage1-bubble
Makefile:   $(MAKE) $(RECURSE_FLAGS_TO_PASS) stage1-bubble

[Bug fortran/81827] Large compile time with derived-type rrays

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
4.9.4 seems "fine" (well, it doesn't allocate recursively but just
zero-initializes everything...)

[Bug c++/81852] Feature request: __cpp_threadsafe_static_init

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement