[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[ygribov at gcc dot gnu.org]

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

--- Comment #4 from Yury Gribov  ---
Created attachment 41824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41824=edit
Update pattern for Power

Another option is to adapt test for Power (attached but not tested).

[Bug demangler/56755] Global symbol demangling fails for _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
  Component|other   |demangler
Summary|Global symbol demangling|Global symbol demangling
   ||fails for
   ||_GLOBAL__sub_I__ZN4AMOS12Co
   ||ntigEdge_t5NCODEE

--- Comment #4 from Eric Gallager  ---
Changing component to demangler. This looks similar to bug 54254 but I'll leave
them separate since they're different symbols.

[Bug preprocessor/33898] Broken -I- vs -iquote behaviour

[archifishal at gmx dot co.uk]

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

Alex Macfarlane Smith  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Alex Macfarlane Smith  ---
I don't remember the exact details now to reproduce this as this was at a
previous company, so I'm inclined just to close this off as resolved :)

[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Eric Gallager  ---
(In reply to Florian Weimer from comment #5)
> Author: fw
> Date: Tue Sep 18 08:34:05 2012
> New Revision: 191413
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=191413
> Log:
> PR other/54411: integer overflow in objalloc_alloc
> 
> 2012-09-18  Florian Weimer  
> 
>   PR other/54411
>   * objalloc.h (objalloc_alloc): Do not use fast path on wraparound.
> 
> 2012-09-18  Florian Weimer  
> 
>   PR other/54411
>   * objalloc.c (_objalloc_alloc): Add overflow check covering
>   alignment and CHUNK_HEADER_SIZE addition.
> 
> Modified:
> trunk/include/ChangeLog
> trunk/include/objalloc.h
> trunk/libiberty/ChangeLog
> trunk/libiberty/objalloc.c

Looks like this fixed it.

[Bug c++/81547] New: Surrogate call function results in call to other conversion operator

[hstong at ca dot ibm.com]

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

Bug ID: 81547
   Summary: Surrogate call function results in call to other
conversion operator
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid, wrong-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

In the C++17 DIS subclause 16.3.1.1.2 [over.call.object] paragraph 3,
it is stated that the conversion function corresponding to the selected
surrogate call function is used to determine the function which is to be called
by the call syntax.

It appears that GCC instead chooses the function selected for the user-defined
conversion sequence formed for overload resolution.

### SOURCE ():
using ff = int (*)(int);
constexpr int ffimpl0(int x) { return x; }
constexpr int ffimpl1(int x) { return x + 1; }

struct A {
  template  constexpr operator T() const { return ffimpl0; }
  constexpr operator ff() const volatile { return ffimpl1; }
};

char x[A()(42.f)];
extern char x[43]; // Clang accepts; GCC rejects


### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -x c++ -


### ACTUAL OUTPUT:
:11:17: error: conflicting declaration 'char x [43]'
:10:6: note: previous declaration as 'char x [42]'


### EXPECTED OUTPUT:
(clean compile)


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170724 (experimental) (GCC)

[Bug demangler/54254] libiberty: demangling for global constructor is broken since r167781

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/viewcvs?
   ||root=gcc=rev=16778
   ||1
 CC||egallager at gcc dot gnu.org
  Component|other   |demangler
Summary|libiberty: demangling is|libiberty: demangling for
   |broken since r167781|global constructor is
   |(http://gcc.gnu.org/viewcvs |broken since r167781
   |?root=gcc=rev=1677 |
   |81) |

--- Comment #1 from Eric Gallager  ---
Changing component to demangler and moving URL from title to URL field

[Bug tree-optimization/81503] [8 Regression] Wrong code at -O2

[babokin at gmail dot com]

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

--- Comment #6 from Dmitry Babokin  ---
How can I switch off optimization phases to workaround the bug?

I have another instances of wrong code bugs, so I'd like to make sure that I
don't create duplicate reports for the same problem.

[Bug tree-optimization/81546] New: ICE at -O3 during GIMPLE pass dom

[babokin at gmail dot com]

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

Bug ID: 81546
   Summary: ICE at -O3 during GIMPLE pass dom
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: babokin at gmail dot com
  Target Milestone: ---

Created attachment 41823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41823=edit
reduced and original test cases

gcc trunk rev250367, x86_64

Test case is reduced from much larger code. During reduction blame phase has
changed from slsr to dom, but looks like it's still the same problem.

Another interesting observation, during test case reduction one of intermediate
results triggered too aggressive memory allocation (more that 128Gb), this was
reported separately in #81488


> time g++ -O0 -c fff.cpp

real0m0.048s
user0m0.035s
sys 0m0.012s

> time g++ -O2 -c fff.cpp

real0m0.085s
user0m0.075s
sys 0m0.010s

> time g++ -O3 -c fff.cpp
 IMM ERROR : (use_p : tree - 0x7f63cea18b68:0x7f63cea18b88)_5
for SSA_NAME: _5 in statement:
if (_5 != 0)
during GIMPLE pass: dom
fff.cpp: In function ‘void foo()’:
fff.cpp:30:6: internal compiler error: verify_ssa failed
 void foo() {
  ^~~
0x10f9043 verify_ssa(bool, bool)
../../gcc_svn_intel/gcc/tree-ssa.c:1186
0xe9088d execute_function_todo
../../gcc_svn_intel/gcc/passes.c:1996
0xe915ee execute_todo
../../gcc_svn_intel/gcc/passes.c:2043
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

real2m12.280s
user2m6.464s
sys 0m5.786s

[Bug other/53178] fixinclude needed for iso/ctype_iso.h on Solaris 8

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #3 from Eric Gallager  ---
(In reply to Daniel Richard G. from comment #2)
> (In reply to comment #1)
> > Is this problem also present in more recent Solaris releases?
> 
> It's gone as of Solaris 10 (the macros have the necessary casts), but I
> don't have a 9 system to check.
> 
> Can a fixinclude go in, just so that 4.7 can have reasonably complete
> -Werror support for Solaris 8? No previous version of GCC is going to have
> that.

Looks like this never happened. 4.7 branch is closed and Solaris 8 is no longer
supported so I'm going to close this.

[Bug other/47062] -mfpmath=sse,387 causes pow() to produce incorrect results

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Eric Gallager  ---
(In reply to Uroš Bizjak from comment #1)
> The testcase is useless, it only shows that the call to pow() returns wrong
> result. In case this is really a gcc bug, please provide runtime testcase
> from the implementation of pow and also exact compile flags that can be used
> to trigger the bug.

Reporter never provided the runtime testcase requested; closing this bug since
it's been stuck in the WAITING status for so long.

[Bug c/36941] gcc does not reject invalid cast

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Eric Gallager  ---
(In reply to Chris Lattner from comment #0)
> GCC accepts:
> extern struct S x;
> void foo() { (void)x; }
> 
> But correctly rejects:
> 
> extern struct S x;
> void foo() { x; }
> 

Confirmed. Note that clang diagnoses the first one like this:

$ /sw/opt/llvm-3.1/bin/clang-3.1 -c 36941.c
36941.c:2:20: error: incomplete type 'struct S' where a complete type is
required
void foo() { (void)x; }
   ^
36941.c:1:15: note: forward declaration of 'struct S'
extern struct S x;
  ^

[Bug c/37200] duplicate warning message with braced initializer list

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed that gcc still prints 2 warnings for the testcase. It's necessary to
set the standard manually to c89 or gnu89 now that GCC defaults to -std=gnu11.
Now that GCC has carets for its diagnostics, we can see that the 2 warnings
actually point to different places:

$ /usr/local/bin/gcc -c -std=gnu89 -pedantic 37200.c
37200.c: In function ‘foo’:
37200.c:10:11: warning: initializer element is not computable at load time
[-Wpedantic]
   {   (void**) >tst }
   ^
37200.c:10:3: warning: initializer element is not computable at load time
[-Wpedantic]
   {   (void**) >tst }
   ^

So are they still actually duplicates?

[Bug preprocessor/33898] Broken -I- vs -iquote behaviour

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
  Component|c   |preprocessor
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
Changing component to preprocessor; I can't confirm since I don't have the same
headers available. Could you attach the headers necessary to trigger this bug
please?

[Bug c/33719] "#pragma omp for firstprivate(shared_var)" in function labelled 'shared_var' as private

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Geir Johansen from comment #0)
> This case involves a function containing only a '#pragma omp for' directive
> and a 'for' loop to go with it.  The invoking routine is the one that
> determines whether the variable is shared or private.  There is no way to
> supply this information within the function without expanding what the
> function does. 
> 
> $ cat >bug2874.c
> /*  derived from ISU's tests RTED_OpenMP/C/SECTION_B/c_B_7_3_e_D_s.c
> c_B_7_3_f_D_s.c, c_B_7_3_g_D_s.c   */
> #include 
> #define N 17
> 
> void sub(double *shared_var,double result_var[],int thread_num){
> int i = 0;
> 
> #pragma omp for firstprivate(shared_var)
> for (i=0;i result_var[thread_num] = *shared_var;
> }
> }
> 
> $ gcc -c -fopenmp bug2874.c
> bug2874.c: In function 'sub':
> bug2874.c:9: error: firstprivate variable 'shared_var' is private in outer
> context

Confirmed that this error still occurs; albeit now with a caret:

$ /usr/local/bin/gcc -c -fopenmp 33719.c
33719.c: In function ‘sub’:
33719.c:9:9: error: firstprivate variable ‘shared_var’ is private in outer
context
 #pragma omp for firstprivate(shared_var)
 ^~~

[Bug c/28921] vector of a typedef applies the vector to the inner most type instead of erroring/warning out that vector does not apply

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #0)
> Testcase:
> typedef char *cptr;
> 
> char *a;
> 
> __attribute__ ((vector_size(16))) cptr t;
> 
> int f(void)
> {
> 
> __attribute__ ((vector_size(16))) int t1 =
>(__attribute__ ((vector_size(16))) int )t;
> }
> 
> We get an error about converting t to a vector int but t looks to me a
> vector of a char pointer.  This happens with both the C and C++ front-ends.

Confirmed.

[Bug inline-asm/26750] invalid inline asm sematics are caught too late

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-25
 CC||egallager at gcc dot gnu.org
  Component|c   |inline-asm
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Are there test cases that trigger these errors?

[Bug c/26613] Corner case causes garbage to be output by -aux-info switch.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Mark F. Haigh from comment #5)
> Created attachment 11005 [details]
> Fix for trunk (against 2006-03-03 CVS)

Could you submit a newer version of this patch to the gcc-patches mailing list
please?

[Bug c/19315] document undocumented extension that allows code where variable is not emitted in the asm

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 CC||egallager at gcc dot gnu.org
Summary|variable is not emitted in  |document undocumented
   |the asm |extension that allows code
   ||where variable is not
   ||emitted in the asm

--- Comment #5 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #4)
> This looks like one of those undocumented extensions.

I guess the solution then would be to document it; adding "documentation"
keyword

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Martin Liška from comment #1)
> I can take a look later for GCC 8.0.

Changing status to ASSIGNED then

[Bug target/81545] New: attributes longcall and shortcall silently accepted on the same function

[msebor at gcc dot gnu.org]

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

Bug ID: 81545
   Summary: attributes longcall and shortcall silently accepted on
the same function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The longcall and shortcall attributes are mutually exclusive and only one
should be accepted on any one declaration.  GCC accepts both attributes, both
on the same declaration and on distinct declarations of the same function.  The
first one is silly and relatively unlikely to occur in practice, but the second
one can come up when two declarations of a function in the same translation
unit are far removed from one another.  To help catch coding mistakes GCC
should detect both of these cases and either reject them with an error or issue
-Wattributes.

$ cat t.c && gcc -O2 -S -Wall -Wextra -Wpedantic t.c
void __attribute__ ((longcall)) f (void);
void __attribute__ ((shortcall)) f (void);

void __attribute__ ((longcall, shortcall)) g (void);
$

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
clang 5.0 handles stack alignment correctly:

[hjl@gnu-skl-1 pr79793]$ cat x.c
typedef unsigned int uword_t __attribute__ ((mode (__word__)));

__attribute__((interrupt))
void
fn (void *frame)
{
  char fxsave_region [512] __attribute__((aligned(16)));
  __builtin_ia32_fxsave (fxsave_region);
}
[hjl@gnu-skl-1 pr79793]$ cat y.c
typedef unsigned int uword_t __attribute__ ((mode (__word__)));

__attribute__((interrupt))
void
fn (void *frame, uword_t error)
{
  char fxsave_region [512] __attribute__((aligned(16)));
  __builtin_ia32_fxsave (fxsave_region);
}
[hjl@gnu-skl-1 pr79793]$ make 
/export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -O2
-mgeneral-regs-only -S -o y.s y.c
clang-5.0: warning: argument unused during compilation: '-mgeneral-regs-only'
[-Wunused-command-line-argument]
[hjl@gnu-skl-1 pr79793]$ cat x.s
.text
.file   "x.c"
.globl  fn  # -- Begin function fn
.p2align4, 0x90
.type   fn,@function
fn: # @fn
.cfi_startproc
# BB#0: # %entry
subq$392, %rsp  # imm = 0x188
.Lcfi0:
.cfi_def_cfa_offset 400
cld
fxsave  -128(%rsp)
addq$392, %rsp  # imm = 0x188
iretq
.Lfunc_end0:
.size   fn, .Lfunc_end0-fn
.cfi_endproc
# -- End function

.ident  "clang version 5.0.0 (http://llvm.org/git/clang.git
f53edbb006df3bc205bf38008d96de510b2a) (http://llvm.org/git/llvm.git
9889fe2290766430b99a2d4fadbc5ba92f8004b6)"
.section".note.GNU-stack","",@progbits
[hjl@gnu-skl-1 pr79793]$ cat y.s
.text
.file   "y.c"
.globl  fn  # -- Begin function fn
.p2align4, 0x90
.type   fn,@function
fn: # @fn
.cfi_startproc
# BB#0: # %entry
pushq   %rax
subq$400, %rsp  # imm = 0x190
.Lcfi0:
.cfi_def_cfa_offset 408
cld
fxsave  -120(%rsp)
addq$400, %rsp  # imm = 0x190
addq$16, %rsp
iretq
.Lfunc_end0:
.size   fn, .Lfunc_end0-fn
.cfi_endproc
# -- End function

.ident  "clang version 5.0.0 (http://llvm.org/git/clang.git
f53edbb006df3bc205bf38008d96de510b2a) (http://llvm.org/git/llvm.git
9889fe2290766430b99a2d4fadbc5ba92f8004b6)"
.section".note.GNU-stack","",@progbits
[hjl@gnu-skl-1 pr79793]$

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to H.J. Lu from comment #5)
> In 64-bit mode, stack is 16-byte aligned when entering handler.  But if
> there is error code
> 
> SS
> RSP
> FLAGS
> CS
> RIP
> Error Code
> 
> the stack alignment is off by 8 bytes.  That is %rsp + 8 isn't multiple
> of 16 at the start of handler.

A testcase:

[hjl@gnu-skl-1 pr79793]$ cat y.c
#include 

typedef unsigned int uword_t __attribute__ ((mode (__word__)));

struct interrupt_frame
{
  uword_t ip;
  uword_t cs;
  uword_t flags;
  uword_t sp;
  uword_t ss;
};

__attribute__((interrupt))
void
fn (struct interrupt_frame *frame, uword_t error)
{
  char fxsave_region [512] __attribute__((aligned(16)));
  _fxsave64 (fxsave_region);
}
[hjl@gnu-skl-1 pr79793]$ make y.s
/export/build/gnu/gcc-x32-7/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-7/build-x86_64-linux/gcc/ -O2 -mgeneral-regs-only
-S -o y.s y.c
[hjl@gnu-skl-1 pr79793]$ cat y.s
.file   "y.c"
.text
.p2align 4,,15
.globl  fn
.type   fn, @function
fn:
.LFB4:
.cfi_startproc
subq$400, %rsp
.cfi_def_cfa_offset 408
fxsave64-120(%rsp)
addq$408, %rsp
iretq
.cfi_endproc
.LFE4:
.size   fn, .-fn
.ident  "GCC: (GNU) 7.1.1 20170724"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr79793]$ 

-120(%rsp) isn't aligned at 16 bytes.

For

[hjl@gnu-skl-1 pr79793]$ cat x.c
#include 

typedef unsigned int uword_t __attribute__ ((mode (__word__)));

struct interrupt_frame
{
  uword_t ip;
  uword_t cs;
  uword_t flags;
  uword_t sp;
  uword_t ss;
};

__attribute__((interrupt))
void
fn (struct interrupt_frame *frame)
{
  char fxsave_region [512] __attribute__((aligned(16)));
  _fxsave64 (fxsave_region);
}
[hjl@gnu-skl-1 pr79793]$ make x.s
/export/build/gnu/gcc-x32-7/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32-7/build-x86_64-linux/gcc/ -O2 -mgeneral-regs-only
-S -o x.s x.c
[hjl@gnu-skl-1 pr79793]$ cat x.s
.file   "x.c"
.text
.p2align 4,,15
.globl  fn
.type   fn, @function
fn:
.LFB4:
.cfi_startproc
subq$400, %rsp
.cfi_def_cfa_offset 408
fxsave64-120(%rsp)
addq$400, %rsp
.cfi_def_cfa_offset 8
iretq
.cfi_endproc
.LFE4:
.size   fn, .-fn
.ident  "GCC: (GNU) 7.1.1 20170724"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr79793]$ 

-120(%rsp) is aligned at 16 bytes.

[Bug c/81544] attribute noreturn and warn_unused_result on the same function accepted

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
An example of how conflicting attributes could be handled is the mutually
exclusive pair of attributes always_inline and noinline:

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
void __attribute__ ((noinline)) f (void);
void __attribute__ ((always_inline)) f (void);

void __attribute__ ((always_inline)) g (void);
void __attribute__ ((noinline)) g (void);

b.c:2:38: warning: declaration of ‘f’ with attribute ‘always_inline’ follows
declaration with attribute ‘noinline’ [-Wattributes]
 void __attribute__ ((always_inline)) f (void);
  ^
b.c:1:33: note: previous declaration of ‘f’ was here
 void __attribute__ ((noinline)) f (void);
 ^
b.c:5:33: warning: declaration of ‘g’ with attribute ‘noinline’ follows
declaration with attribute ‘always_inline’ [-Wattributes]
 void __attribute__ ((noinline)) g (void);
 ^
b.c:4:38: note: previous declaration of ‘g’ was here
 void __attribute__ ((always_inline)) g (void);
  ^

[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[hubicka at gcc dot gnu.org]

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

--- Comment #9 from Jan Hubicka  ---
The original idea of tracing was that we can pro-actively duplicate tails and
rely on crossjumping to merge the paths back if they did not trigger context
sensitive optimizations.  Nowdays crossjumping much weaker than it used to be
because it does not handle well RTL genertated from SSA and we do not do any
gimple level tail merging after tracer which we probably should.

[Bug c/81544] New: attribute noreturn and warn_unused_result on the same function accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81544
   Summary: attribute noreturn and warn_unused_result on the same
function 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: ---

GCC silently accepts a function declaration that makes use of both attribute
noreturn and warn_unused_result.  The combination is meaningless as is evident
from the warnings issued for calls to such a function: regardless of whether
the function's return value is or isn't used GCC issues a warning.

Rather than accepting such meaningless combinations of attributes GCC should
validate them as they are accumulated from declarations and diagnose the
meaningless or invalid combinations early, before they are used.

$ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic b.c
int __attribute__ ((noreturn)) foo (void);
int __attribute__ ((warn_unused_result)) foo (void);

int bar (void)
{
  int n = foo ();
  return n;
}

void baz (void)
{
  foo ();
}


b.c: In function ‘bar’:
b.c:6:7: warning: ignoring return value of ‘foo’, declared with attribute
warn_unused_result [-Wunused-result]
   int n = foo ();
   ^
b.c: In function ‘baz’:
b.c:12:3: warning: ignoring return value of ‘foo’, declared with attribute
warn_unused_result [-Wunused-result]
   foo ();
   ^~

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[dansan at gcc dot gnu.org]

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

--- Comment #58 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Mon Jul 24 21:59:57 2017
New Revision: 250488

URL: https://gcc.gnu.org/viewcvs?rev=250488=gcc=rev
Log:
PR testsuite/80759 Fix -mcall-ms2sysv-xlogues on Darwin and Solaris

2017-07-24  Daniel Santos  

PR testsuite/80759
* config.host: include i386/t-msabi for darwin and solaris.
* config/i386/i386-asm.h
(ELFFN): Rename to FN_TYPE.
(FN_SIZE): New macro.
(FN_HIDDEN): Likewise.
(ASMNAME): Likewise.
(FUNC_START): Rename to FUNC_BEGIN, use ASMNAME, replace .global with
.globl.
(HIDDEN_FUNC): Use ASMNAME and .globl instead of .global.
(SSE_SAVE): Convert to cpp macro, hard-code offset (always 0x60).
* config/i386/resms64.S: Use SSE_SAVE as cpp macro instead of gas
.macro.
* config/i386/resms64f.S: Likewise.
* config/i386/resms64fx.S: Likewise.
* config/i386/resms64x.S: Likewise.
* config/i386/savms64.S: Likewise.
* config/i386/savms64f.S: Likewise.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config.host
trunk/libgcc/config/i386/i386-asm.h
trunk/libgcc/config/i386/resms64.S
trunk/libgcc/config/i386/resms64f.S
trunk/libgcc/config/i386/resms64fx.S
trunk/libgcc/config/i386/resms64x.S
trunk/libgcc/config/i386/savms64.S
trunk/libgcc/config/i386/savms64f.S

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[dansan at gcc dot gnu.org]

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

--- Comment #59 from dansan at gcc dot gnu.org ---
Author: dansan
Date: Mon Jul 24 22:00:35 2017
New Revision: 250489

URL: https://gcc.gnu.org/viewcvs?rev=250489=gcc=rev
Log:
PR testsuite/80759 Fix broken tests in ms-sysv.exp

2017-07-24  Daniel Santos  

PR testsuite/80759
* gcc.target/x86_64/abi/ms-sysv/do-test.S
(ELFFN_BEGIN): Rename to FN_TYPE.
(ELFFN_END): Rename to FN_SIZE.
(ASMNAME): New macro.
(FUNC): Rename to FUNC_BEGIN, use ASMNAME and use .globl instead of
.global.
(FUNC_END): Use ASMNAME.
(test_data_save): Remove.
(test_data_input): Likewise.
(test_data_output: Likewise.
(test_data_fn): Likewise.
(test_data_retaddr): Likewise.
(regs_to_mem): Make globals, use r10 instead of rax.
(mem_to_regs): Likewise.
(do_test_unaligned): Remove .cfi directives, remove pushf/popf, move
body to ms-sysv.c.
(do_test_aligned): Likewise.
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.c:
Add dg-* directives.
(PASTE_STR): New macro.
(ASMNAME): Likewise.
(LOAD_TEST_DATA_ADDR): Likewise.
(TEST_DATA_OFFSET): Likewise.
(do_test_body0): New C function.
(do_test_body): New inline assembly routine.
* gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp
(runtest_ms_sysv): Modify.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/do-test.S
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.c
trunk/gcc/testsuite/gcc.target/x86_64/abi/ms-sysv/ms-sysv.exp

[Bug c/81543] New: attribute may_alias on function and variable declarations silently accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 81543
   Summary: attribute may_alias on function and variable
declarations silently 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: ---

Attribute may_alias is documented among type attributes like so:

  Accesses through pointers to types with this attribute are not subject to
type-based alias analysis, but are instead assumed to be able to alias any
other type of objects.

The attribute is not listed not among those that can be applied to functions or
variables, yet GCC also accepts it on declarations of those.

It doesn't seem meaningful to specify the attribute on variables (especially of
non-pointer types), and using on a function declaration seems dubious.

Either the attribute should be rejected in those two contexts, or its meaning
should be documented.

$ cat b.c && /ssd/build/gcc-80806/gcc/xgcc -B /ssd/build/gcc-80806/gcc -O2 -S
-Wall -Wextra -Wpedantic b.c
int var __attribute__ ((may_alias));

void __attribute__ ((may_alias)) foo (void);
$

[Bug libstdc++/81542] Compilation failure with math.h and -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

[gmc at synopsys dot com]

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

Gordon Mc  changed:

   What|Removed |Added

 Target||Target: x86_64-redhat-linux

--- Comment #4 from Gordon Mc  ---
The use of _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC on the command line is historical
for some of our products ; I am still trying to obtain details of its origin to
see whether it can be removed. 

Are you suggesting that this setting should not be enabled by users, and is
intended only for GCC internal use ?

Thanks,
Gordon

[Bug c/19972] -Wreturn-local-addr misses return of local (nested) function pointer

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Last reconfirmed|2005-12-18 01:39:05 |2017-7-24
 CC||egallager at gcc dot gnu.org
Summary|Return Local (nested)   |-Wreturn-local-addr misses
   |function pointer|return of local (nested)
   ||function pointer

--- Comment #2 from Eric Gallager  ---
(In reply to Patrick Pelissier from comment #0)
> When returning local function pointer, it doesn't produce any warnings.
> For example:
> 
> int *h() {
>   int z;
>   return 
> }
> 
> int (*apply (int (*f) (const void *, const void *), void *a))(const void *)
> {
>   int zozo(const void * b) { return f(a,b); };
>   return 
> }
> 
> Compile with -O2 -Wall, it produces a warning for h:
> 
> ttt.c: In function 'h':
> ttt.c:17: warning: function returns address of local variable
> 

With a newer gcc, this warning is now:

$ /usr/local/bin/gcc -c -O2 -Wall 19972.c
19972.c: In function ‘h’:
19972.c:3:9: warning: function returns address of local variable
[-Wreturn-local-addr]
  return 
 ^~

Retitling this bug to better describe situation.

[Bug libstdc++/81542] Compilation failure with math.h and -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

[gmc at synopsys dot com]

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

--- Comment #3 from Gordon Mc  ---
GCC build being used, was configured with --enable-bootstrap
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,fortran --disable-libgcj --with-cpu=generic
--build=x86_64-redhat-linux
Thread model: posix

[Bug libstdc++/81542] Compilation failure with math.h and -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Also what target is this for?

[Bug libstdc++/81542] Compilation failure with math.h and -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Why are you defining _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC on the command line?

[Bug c++/81542] New: Compilation failure with math.h and -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

[gmc at synopsys dot com]

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

Bug ID: 81542
   Summary: Compilation failure with math.h and
-D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gmc at synopsys dot com
  Target Milestone: ---

There appears to be a problem with the math.h file created by GCC, starting
with GCC version 6.x

Create testfile "test.cxx" which contains ONLY the one line:
   #include 

and compile it as
   g++ -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC test.cxx -c

With GCC versions up to GCC 5.4 this works fine ; with GCC 6.1 -> 6.4 and 7.1
we get a compilation failure:

/remote/srm692/gmc/Gnu/GCC_6.2.0/include/c++/6.2.0/math.h:63:12: error:
'std::fpclassify' has not been declared
 using std::fpclassify;
^~

... etc. (as above, for each of: isfinite, isinf, isnan, isnormal, signbit,
isgreater, isgreaterequal, isless, islessequal, islessgreater, isunordered)


Looking at include file cmath from GCC 6.x, there are TWO conditions that must
be satisfied before we have definitions for fpclassify, isnan, etc... :

   542  #if _GLIBCXX_USE_C99_MATH
   543  #if !_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC

whereas in math.h there is only a single condition:

62  #if _GLIBCXX_USE_C99_MATH

Shouldn't the above math.h content match cmath in having the second
(!_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC) condition added ?

Thanks,
Gordon

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[ygribov at gcc dot gnu.org]

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

--- Comment #3 from Yury Gribov  ---
Created attachment 41822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41822=edit
Patch to disable test on PowerPC

(In reply to Yury Gribov from comment #2)
> pr56727-2.c is interesting, it does not repro on x86.

Ok, pr56727-2 fails because it gets optimized by tailcall pass (which is even
more agressive at optimizing recursive calls).  I worked around this (by
prohibiting tailcalls) but generated assembly is too different from x86.  So
perhaps simply disable this test on Power?  Patch attached.

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.5

--- Comment #9 from Uroš Bizjak  ---
Fixed everywhere.

[Bug other/49578] Profiling: call graph table overflows on Solaris.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to David Warme from comment #0)
> Created attachment 24631 [details]
> Patch to increase max num edges in profile call graph under Solaris.
> 
> The Solaris implementation of profiling (-pg option) links in a
> special gmon.o file that defines the mcount() routine, and related
> functions.  (On Solaris, mcount() does not reside in libc.so, so
> GCC must provide its own implementation.)
> 
> This implementation of mcount() creates linked lists of nodes
> using an "unsigned short" as the link field to the next node.
> This places a hard limit of 65533 edges in the call graph of any
> program that is profiled -- a limitation that is easily exceeded
> by modern programs.
> 
> The attached patch (made to the gcc-4.6.1 distribution) replaces
> the pertinent "unsigned short" fields with "unsigned int", and
> eliminates the upper bound when dynamically allocating the
> "tos" table.  This enables profiling of large programs under
> Solaris.
> 
> David Warme, Ph.D.
> Principal Computer Scientist
> Group W, Inc.
> Fairfax, VA  22031
> USA

Could you update your patch to a more recent version of gcc and then send it to
the gcc-patches mailing list please?

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[uros at gcc dot gnu.org]

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

--- Comment #8 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 24 20:29:02 2017
New Revision: 250486

URL: https://gcc.gnu.org/viewcvs?rev=250486=gcc=rev
Log:
PR target/80569
* config/i386/i386.c (ix86_option_override_internal): Disable
BMI, BMI2 and TBM instructions for -m16.

testsuite/ChangeLog:

PR target/80569
* gcc.target/i386/pr80569.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr80569.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug other/81541] New: Potential size optimisation: reusing common function endings

[jpakkane at gmail dot com]

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

Bug ID: 81541
   Summary: Potential size optimisation: reusing common function
endings
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpakkane at gmail dot com
  Target Milestone: ---

In embedded development code size optimizations are very important and there
are some optimizations that commercial compilers do but GCC does not seem to.
As an example compiling the following code:

int func5() {
  int i = 0;
  i+=func2();
  i+=func3();
  i+=func4();
  return i+func1();
}

int func6() {
  int i=1;
  i+=func3();
  i+=func3();
  i+=func4();
  return i+func1();
}

On ARM using -Os produces the following assembly:

func5():
push{r4, lr}
bl  func2()
mov r4, r0
bl  func3()
add r4, r4, r0
bl  func4()
add r4, r4, r0
bl  func1()
add r0, r4, r0
pop {r4, lr}
bx  lr
func6():
push{r4, lr}
bl  func3()
add r4, r0, #1
bl  func3()
add r4, r4, r0
bl  func4()
add r4, r4, r0
bl  func1()
add r0, r4, r0
pop {r4, lr}
bx  lr

Note how the ends of both of these functions have identical endings. This could
be converted to the following:

func5():
push{r4, lr}
bl  func2()
mov r4, r0
common_tail:
bl  func3()
add r4, r4, r0
bl  func4()
add r4, r4, r0
bl  func1()
add r0, r4, r0
pop {r4, lr}
bx  lr
func6():
push{r4, lr}
bl  func3()
add r4, r0, #1
b common_tail

which has smaller code size.

I did a simple experiment and based on that this might not be all that useful
on x86:
http://nibblestew.blogspot.com/2017/07/experiment-binary-size-reduction-by.html

On ARM and similar platforms this would probably be beneficial, especially
given that commercial compilers perform this optimization.

[Bug c++/78753] non-ambiguous overload resolution with function template partial ordering rules

[ed at catmur dot co.uk]

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

Ed Catmur  changed:

   What|Removed |Added

 CC||ed at catmur dot co.uk

--- Comment #1 from Ed Catmur  ---
I believe this was fixed by CWG 1395
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1395

> 11 - If, after considering the above, function template F is at least as 
> specialized as function template G and vice-versa, and if G has a trailing 
> parameter pack for which F does not have a corresponding parameter, and if F 
> does not have a trailing parameter pack, then F is more specialized than G.

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[ygribov at gcc dot gnu.org]

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

--- Comment #2 from Yury Gribov  ---
Thanks for detailed report.

For pr79439.c take a look at discussion in bug 56727 - the general agreement
there was that it should be valid to replace recursive PLT calls with direct
calls as long as function does not have aliases.  GCC has already been doing
such sort of optimization before.  So perhaps we need to update test (by adding
alias there)?

pr56727-2.c is interesting, it does not repro on x86.  I'll be back on Thursday
and will take a look (hopefully it's not urgent?).

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[ygribov at gcc dot gnu.org]

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

Yury Gribov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-24
 CC||ygribov at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tetra2005 at gmail dot 
com
 Ever confirmed|0   |1

[Bug tree-optimization/81540] New: tree-switch-conversion leads to code bloat

[gjl at gcc dot gnu.org]

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

Bug ID: 81540
   Summary: tree-switch-conversion leads to code bloat
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41821=edit
cswtch.c: C test case

The following code gets blown by tree-switch-conversion by a factor of 4:

typedef __UINT64_TYPE__ T;

T func64 (int i)
{
T x = (T) -1;
switch (i)
{
case 1: x = 2; break;
case 2: x = 2; break;
case 25: x = 0x12345678abcd; break;
default: break;
}
return x;
}


$ avr-gcc cswtch.c -Os -c -fno-ident
$ avr-size -A cswtch.o
cswtch.o  :
section   size   addr
.text   62  0
.rodata200  0
Total  262


$ avr-gcc cswtch.c -Os -c -fno-ident -fno-tree-switch-conversion
$ avr-size -A cswtch.o
cswtch.o  :
section   size   addr
.text 66  0
Total 66

Compiler sources are v8 trunk from around 2017-07-18

Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --disable-nls
--prefix=/local/gnu/install/gcc-8-avr-mingw32 --host=i686-w64-mingw32
--build=x86_64-linux-gnu --enable-languages=c,c++,lto --with-gnu-as
--with-gnu-ld --disable-shared --with-dwarf2 --enable-checking=release

[Bug other/46954] FDEs possibly left unsorted in unwind-dw2-fde.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Eric Gallager  ---
(In reply to Jan Voung from comment #2)
> I probably won't be able to come up with a repro at this point =/
> This involved some toolchain patches for Native Client (and a pretty old
> checkout of the NaCl sources too).
> Feel free to close this bug.

OK.

[Bug other/46954] FDEs possibly left unsorted in unwind-dw2-fde.c

[jvoung at google dot com]

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

--- Comment #2 from Jan Voung  ---
I probably won't be able to come up with a repro at this point =/
This involved some toolchain patches for Native Client (and a pretty old
checkout of the NaCl sources too).
Feel free to close this bug.

[Bug other/46954] FDEs possibly left unsorted in unwind-dw2-fde.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Jan Voung from comment #0)
> Not completely sure if this is a bug in GCC or my toolchain, but I have been
> able to trigger a situation where _Unwind_Find_FDE is unable to find an FDE.

How exactly were you able to trigger this situation? Do you have anything that
could be used as a testcase?

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #2 from John Paul Adrian Glaubitz  ---
Adding Kaz and Oleg to CC since it affects sh*-*-* as well [1].

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869373

[Bug target/80569] i686: "shrx" instruction generated in 16-bit mode

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Jul 24 18:59:21 2017
New Revision: 250479

URL: https://gcc.gnu.org/viewcvs?rev=250479=gcc=rev
Log:
PR target/80569
* config/i386/i386.c (ix86_option_override_internal): Disable
BMI, BMI2 and TBM instructions for -m16.

testsuite/ChangeLog:

PR target/80569
* gcc.target/i386/pr80569.c: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr80569.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/58750] Wrong code with realloc on assignment and array constructors with numeric type conversion

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|DUPLICATE   |---
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #15 from Thomas Koenig  ---
Not a duplicate - I have a patch which fixes this one,
leaving PR 52162 unfixed.

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||adam at aphirst dot karoo.co.uk

--- Comment #9 from Dominique d'Humieres  ---
*** Bug 58750 has been marked as a duplicate of this bug. ***

[Bug fortran/58750] Wrong code with realloc on assignment and array constructors with numeric type conversion

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #14 from Dominique d'Humieres  ---
The problem is fixed by the patch in pr52162 comment 8. Marking as a duplicate.

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

[Bug target/81535] [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
The failures also occur on powerpc64 BE.


This test that was added in this revision also fails:

spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr56727-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fPIC
-ffat-lto-objects -S -o pr56727-2.s
PASS: gcc.dg/pr56727-2.c (test for excess errors)
FAIL: gcc.dg/pr56727-2.c scan-assembler @(PLT|plt)

seurer@makalu-lp1:~/gcc/build/gcc-test$
/home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr56727-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fPIC
-ffat-lto-objects -S -o pr56727-2.s
seurer@makalu-lp1:~/gcc/build/gcc-test$ cat pr56727-2.s 
.file   "pr56727-2.c"
.section".text"
.align 2
.p2align 4,,15
.globl f
.section".opd","aw"
.align 3
f:
.quad   .L.f,.TOC.@tocbase,0
.previous
.type   f, @function
.L.f:
.p2align 4,,15
.L2:
b .L2
.long 0
.byte 0,0,0,0,0,0,0,0
.size   f,.-.L.f
.setg,f
.align 2
.p2align 4,,15
.globl h
.section".opd","aw"
.align 3
h:
.quad   .L.h,.TOC.@tocbase,0
.previous
.type   h, @function
.L.h:
li 3,0
b g
.long 0
.byte 0,0,0,0,0,0,0,0
.size   h,.-.L.h
.ident  "GCC: (GNU) 8.0.0 20170721 (experimental) [trunk revision
250442]"

[Bug fortran/79312] Empty array in assignment not correctly type-checked

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
The problem appears to be at the top of gfc_convert_type_warn:

  /* NULL and zero size arrays get their type here.  */
  if (expr->expr_type == EXPR_NULL
  || (expr->expr_type == EXPR_ARRAY && expr->value.constructor == NULL))
{
  /* Sometimes the RHS acquire the type.  */
  expr->ts = *ts;
  return true;
}

[Bug testsuite/81539] New: Bad target in new test case gcc.target/powerpc/mmx-packuswb-1.c from r250432

[seurer at gcc dot gnu.org]

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

Bug ID: 81539
   Summary: Bad target in new test case
gcc.target/powerpc/mmx-packuswb-1.c from r250432
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/mmx-packuswb-1.c
. . .
ERROR: gcc.target/powerpc/mmx-packuswb-1.c: syntax error in target selector
"powerpc*-*-*" for " dg-require-effective-target 4 p8vector_hw { powerpc*-*-* }
"

[Bug c++/60517] warning/error for taking address of member of a temporary object

[lopezibanez at gmail dot com]

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

--- Comment #22 from Manuel López-Ibáñez  ---
I honestly think the uninitialized warning and fixing TREE_NOWARNING is a
red-herring. My testcase should get a warning even if .x[0] is initialized.
The problem is taking the address of a temporary. That should be detected
way before SRA happens. No control flow needed, only scope info.

On 24 Jul 2017 6:07 pm, "fredrik.hederstie...@securitas-direct.com" <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517
>
> --- Comment #21 from Fredrik Hederstierna  securitas-direct.com> ---
> Started with fix for PR 43347 to not warn on artificial aggregates
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43347
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/67633] decltype on parenthesized class member access of a prvalue sometimes return wrong results

[felix.morgner at gmail dot com]

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

--- Comment #1 from Felix Morgner  ---
The same holds true for GCC 7.1 and the deduced type for decltype(auto):

#include 
#include 

struct s{int v{};};

decltype(auto) f()
  {
  return (s{}.v);
  }

int main()
  {
  std::cout << std::is_same{} << '\n';
  }


prints 0 instead of 1.

[Bug bootstrap/25470] [5/6/7/8 Regression] fixincludes/ subdirectory not cleaned by "make distclean"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||tom.browder at gmail dot com

--- Comment #26 from Eric Gallager  ---
*** Bug 45503 has been marked as a duplicate of this bug. ***

[Bug other/45503] "make distclean" Does Not Remove All Local Configuration Data

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Eric Gallager  ---
Duplicate of bug 25470 which was itself fixed.

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

[Bug other/44644] type/data name clash makes --enable-build-with-cxx cc1 hard to debug

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #3)
> Subject: Bug 44644
> 
> Author: amylaar
> Date: Wed Jun 23 14:25:33 2010
> New Revision: 161281
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=161281
> Log:
> PR other/44644
> * df-core.c (struct df): Rename to df_d.
> * df.h (struct df): Likewise.
> * dse.h (struct df): Remove forward declaration.
> * recog.h (struct insn_data): Rename to:
> (struct_insn_data_d).  Adjusted all users.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/builtins.c
> trunk/gcc/config/i386/i386.c
> trunk/gcc/config/mep/mep.c
> trunk/gcc/df-core.c
> trunk/gcc/df.h
> trunk/gcc/dse.h
> trunk/gcc/expmed.c
> trunk/gcc/genoutput.c
> trunk/gcc/recog.h

Assuming that since this was committed, it fixed it.

[Bug target/79041] aarch64 backend emits R_AARCH64_ADR_PREL_PG_HI21 relocation despite -mpc-relative-literal-loads option being used

[wilco at gcc dot gnu.org]

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

--- Comment #7 from Wilco  ---
Author: wilco
Date: Mon Jul 24 18:06:37 2017
New Revision: 250478

URL: https://gcc.gnu.org/viewcvs?rev=250478=gcc=rev
Log:
Fix PR79041

As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
may be used to avoid generating ADRP/ADD or ADRP/LDR.  However both
trunk and GCC7 may still emit ADRP for some constant pool literals.
Fix this by adding a aarch64_pcrelative_literal_loads check.

gcc/
PR target/79041
* config/aarch64/aarch64.c (aarch64_classify_symbol):
Avoid SYMBOL_SMALL_ABSOLUTE for literals with pc-relative literals
gcc/testsuite/
* gcc.target/aarch64/pr79041-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr79041-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/81538] Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 41820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41820=edit
.s file

Assembler output for Perl_custom_op_get_field.

[Bug rtl-optimization/81538] New: Optimization problem compiling op.c (Perl_custom_op_get_field) in perl 5.26

[danglin at gcc dot gnu.org]

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

Bug ID: 81538
   Summary: Optimization problem compiling op.c
(Perl_custom_op_get_field) in perl 5.26
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

Created attachment 41819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41819=edit
Preprocessed source

Perl 5.26 (currently in experimental) has never built on hppa yet. It's
failing with

./miniperl -Ilib make_ext.pl cpan/Archive-Tar/pm_to_blib  MAKE="/usr/bin/make"
LIBPERL_A=libperl.a
Unsuccessful Makefile.PL(cpan/Archive-Tar): code=11 at make_ext.pl line 518.

Miniperl branches to non existent code after calling Perl_custom_op_get_field:

Jul 20 20:18:48 mx3210 kernel: do_page_fault() command='miniperl' type=6
address=0xbf600703 in libcrypt-2.24.so[f77f9000+9000]
Jul 20 20:18:48 mx3210 kernel: trap #6: Instruction TLB miss fault, vm_start =
0x001e3000, vm_end = 0x005b4000

   0x0002eac8 :b,l 0x1a8d0
,rp
   0x0002eacc :copy r4,r26
   0x0002ead0 :movb,= ret0,r22,0x2e284

   0x0002ead4 :copy r3,r25
   0x0002ead8 :copy r15,r24
   0x0002eadc :copy r4,r26
   0x0002eae0 :b,l 0x3b218,r31
   0x0002eae4 :copy r31,rp

The branch at Perl_rpeep+2920 is an indirect call using the function pointer
returned from calling Perl_custom_op_get_field.  The value in $r22 for the
indirect call is 0xbf600701.  It is not a valid function pointer.

This is debian bug #869122:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869122

The value returned by Perl_custom_op_get_field is wrong for the case
when xop == _null.  It appears to get messed up by the merging of the
two switch statements in the C code.  The debian bug report has a patch
which revises the switch statements into one.  With the patch, the perl
build is successful on both hppa and sh.

Attached preprocessed source.  The compile command is:

/usr/lib/gcc/hppa-linux-gnu/6/cc1 -fpreprocessed opmini.i -quiet -dumpbase
opmini.c -auxbase opmini -g -g -O2 -O2 -Wdate-time -Wformat=1
-Werror=format-security -Wall -Werror=declaration-after-statement -Wextra
-Wc++-compat -Wwrite-strings -std=c90 -version
-fdebug-prefix-map=/home/dave/debian/perl/perl-5.26.0=. -fwrapv
-fno-strict-aliasing -o opmini.s

The perl 5.26 build is successful at -O0.

[Bug other/43445] Toplevel Makefile needs to export ABI variants of LD_LIBRARY_PATH

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Rainer Orth from comment #0)
> During a libjava build on i386-pc-solaris2.11, I noticed the following error:
> 
> ld.so.1: gcj-dbtool: fatal:
> /vol/gcc/obj/gcc-4.5.0-20100208/11-gcc-gld/./gcc/libgcc_s.so.1: wrong ELF
> class: ELFCLASS32
> /bin/ksh: 29209 Killed
> 
> This happens when trying to execute the 64-bit gcj-dbtool.  gcj-dbtool
> itself is a libtool wrapper script, which allows it to find the dependend
> libtool
> libraries, but for libgcc_s.so.1, it relies on HOST_EXPORTS in the toplevel
> Makefile to export LD_LIBRARY_PATH via RPATH_ENVVAR, it refers to
> TARGET_LIB_PATH and HOST_LIB_PATH, but none of them is multilib aware.
> 
> The toplevel Makefile probably needs to set all of LD_LIBRARY_PATH{, _32, _64}
> and their IRIX and Darwin equivalents.  See
> gcc/testsuite/lib/target-libpath.exp
> for the full list.

Is this still needed now that gcj-dbtool has been removed?

[Bug other/40046] GCC build fails due to host_address variable is empty

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Eric Gallager  ---
(In reply to Roman Marchenko from comment #0)
> There is the following line in configure script:
> 
> eval `${CC-cc} -E conftest.c | grep host_address=`
> 
> Since I have GREP_OPTIONS variable in my environment which looks like
> "GREP_OPTIONS=--color=always", some color codes are generated in grep's
> output. The issue is the "eval ..." does not work properly in this case and
> the host_address variable is empty.
> 
> I have repaired the build by replacing the line with the following:
> 
> eval `${CC-cc} -E conftest.c | grep --color=auto host_address=`

The GREP_OPTIONS environment variable is deprecated; don't use it:
https://www.gnu.org/software/grep/manual/html_node/Environment-Variables.html

[Bug other/18907] library makefiles should not set AM_MAKEFLAGS

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Last reconfirmed|2009-03-22 10:01:20 |2017-7-24
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #2)
> fastjar is gone. The rest still has AM_MAKEFLAGS.

boehm-gc, libjava, and libmudflap are also gone now. libffi, libstdc++-v3, and
zlib still have AM_MAKEFLAGS though.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #21 from Fredrik Hederstierna 
 ---
Started with fix for PR 43347 to not warn on artificial aggregates

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

[Bug c++/81536] [8 Regression] Recent crash in is_std_substitution

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Version|7.0 |8.0
   Target Milestone|--- |8.0
Summary|Recent crash in |[8 Regression] Recent crash
   |is_std_substitution |in is_std_substitution

[Bug tree-optimization/81537] [8 Regression] ice in vect_is_simple_reduction

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
Version|7.0 |8.0
   Target Milestone|--- |8.0
Summary|ice in  |[8 Regression] ice in
   |vect_is_simple_reduction|vect_is_simple_reduction

[Bug c/81537] New: ice in vect_is_simple_reduction

[dcb314 at hotmail dot com]

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

Bug ID: 81537
   Summary: ice in vect_is_simple_reduction
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

The following C code, when compiled by -O3 on recent revisions,
does this:

/home/dcb/gcc/results.250361/bin/gcc
/home/dcb/gcc/results.250426/bin/gcc
during GIMPLE pass: vect
bug372.c: In function ‘f’:
bug372.c:8:1: internal compiler error: Segmentation fault
 f(g) {
 ^
0xc6298f crash_signal
../../trunk/gcc/toplev.c:338
0xefca68 vect_is_simple_reduction
../../trunk/gcc/tree-vect-loop.c:3165
0xf00978 vect_force_simple_reduction(_loop_vec_info*, gimple*, bool*, bool)
../../trunk/gcc/tree-vect-loop.c:3298
0xf00978 vect_analyze_scalar_cycles_1
../../trunk/gcc/tree-vect-loop.c:857

The problem seems to exist between revision 250361 and 250426.

Code is

typedef h;
typedef k;
a;
b;
c;
d;
e;
f(g) {
  h *i = 
  k *j;
  if (d -= b)
for (; *j; *j += 1) {
  g = g || (a = e ? c = j : 0) + *i;
  i = 
}
}

[Bug c++/81536] New: Recent crash in is_std_substitution

[dcb314 at hotmail dot com]

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

Bug ID: 81536
   Summary: Recent crash in is_std_substitution
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

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

Somewhere between revision 250462 and revision 250476, there is a new
crash:

/home/dcb/gcc/results.250462/bin/gcc
/home/dcb/gcc/results.250476/bin/gcc
bug1.cc:9734:9: internal compiler error: Segmentation fault
   class exception
 ^
0xe8239f crash_signal
../../trunk/gcc/toplev.c:338
0x6fbffe is_std_substitution
../../trunk/gcc/cp/mangle.c:500
0x6fbffe find_substitution
../../trunk/gcc/cp/mangle.c:614
0x6f3ce4 write_type
../../trunk/gcc/cp/mangle.c:2074

Please compile the attached source code file with compiler flag -O2.

[Bug other/35848] Missing port entry in MAINTAINERS file

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
(In reply to Mike Stein from comment #0)
> Hi,
> the entry for the port "score" is missing in the MAINTAINERS file.

I'm checking MAINTAINERS and it has this line:

score port  Chen Liqin  

So I'm assuming this was fixed.

[Bug other/35511] release scripts added release note to zlib/ChangeLog, not zlib/ChangeLog.gcj

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Debian GCC Maintainers from comment #0)
> the release scripts added the release note for 4.3.0 to zlib/ChangeLog
> (upstream), not zlib/ChangeLog.gcj

IMO zlib/ChangeLog.gcj should be renamed since gcj has been removed from gcc.

[Bug target/81535] New: [8 regression] gcc.target/powerpc/pr79439.c fails starting with r250442

[seurer at gcc dot gnu.org]

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

Bug ID: 81535
   Summary: [8 regression] gcc.target/powerpc/pr79439.c fails
starting with r250442
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I noticed this on a powerpc64le power8 system:

spawn /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/pr79439.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fpic
-ffat-lto-objects -S -o pr79439.s
PASS: gcc.target/powerpc/pr79439.c (test for excess errors)
PASS: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl f\\M 1
PASS: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl g\\M 1
PASS: gcc.target/powerpc/pr79439.c scan-assembler-times \\mbl rec\\M 1
FAIL: gcc.target/powerpc/pr79439.c scan-assembler-times \\mnop\\M 3

seurer@genoa:~/gcc/build/gcc-test$ diff pr79439.s.r250441 pr79439.s.r250442
46,47c46
<   bl rec
<   nop
---
>   bl rec.localalias.0
54c53,54
<   .ident  "GCC: (GNU) 8.0.0 20170721 (experimental) [trunk revision
250441]"
---
>   .setrec.localalias.0,rec
>   .ident  "GCC: (GNU) 8.0.0 20170721 (experimental) [trunk revision 
> 250442]"

[Bug other/81334] -Wmisleading-indentation prints notes about being disabled even when already intentionally ignored

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
Summary|-Wmisleading-indentation|-Wmisleading-indentation
   ||prints notes about being
   ||disabled even when already
   ||intentionally ignored
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Mick P. from comment #0)
> "note: -Wmisleading-indentation is disabled from this point onwards, since
> column-tracking was disabled due to the size of the code/headers
> if(Min<0) Min = 0; if(Max 
> I'm seeing output like this even while -Wmisleading-indentation is #pragma
> ignored and so cannot be emitted itself.
> 
> Of course clients shouldn't have to disable this on the command-line in
> order to quite third party headers. (And so not be able to enjoy this
> gloriously diversity killing--and therefor creativity eradicating--feature
> for themselves.)

Could you attach preprocessed source that triggers this note?

[Bug bootstrap/50229] [5/6/7/8 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #29 from Eric Gallager  ---
(In reply to Ruben Van Boxem from comment #28)
> (In reply to Eric Gallager from comment #27)
> > (In reply to Iain Sandoe from comment #21)
> > > (In reply to Francois-Xavier Coudert from comment #20)
> > > > This PR appears to report two different issues:
> > > >   1. cross-compiler targeting Darwin
> > > >   2. cross-compiler hosted on Darwin
> > > in short (2) is very definitely "works for me"
> > So does this bug need to stay open then?
> 
> I reported the original issue using Fedora's Mac OS X cross compiler
> toolchains that were available at the time. They are still described here,
> but the repo has become unavailable:
> https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework
> 
> I cannot seem to locate an active repository providing these now.
> 
> So it is really your number one. If the problem lies outside of GCC sources,
> perhaps it's best to close this issue, but as it used to work in GCC 4.6, it
> seems something changed that made this setup nonfunctional.

Well looking back at comment #21 Iain did say some of his patches were for GCC
so at least some of the problem is in GCC sources, even if most of it is in the
rest of the toolchain... I'll change the status to NEW since it's not you we're
WAITING on.

[Bug target/81534] New: [7 Regression] ICE in in extract_insn, at recog.c:2311 (unrecognizable insn)

[doko at gcc dot gnu.org]

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

Bug ID: 81534
   Summary: [7 Regression] ICE in in extract_insn, at recog.c:2311
(unrecognizable insn)
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with gcc-7-branch 20170724 on s390x-linux-gnu. Looks like a variant of
PR78738 and PR78748.

$ cat global_statistics.i
struct {
  short b;
  long c
} a = {};
d() { __atomic_fetch_add(, 0, 5); }

$ gcc -march=zEC12 -c -g -O2 global_statistics.i
global_statistics.i:4:1: warning: no semicolon at end of struct or union
 } a = {};
 ^
global_statistics.i:5:1: warning: return type defaults to 'int'
[-Wimplicit-int]
 d() { __atomic_fetch_add(, 0, 5); }
 ^
global_statistics.i: In function 'd':
global_statistics.i:5:1: error: unrecognizable insn:
(insn 21 20 22 4 (parallel [
(set (reg:SI 71)
(mem/v:SI (symbol_ref:DI ("a") [flags 0x2] ) [-1  S4 A64]))
(set (mem/v:SI (symbol_ref:DI ("a") [flags 0x2] ) [-1  S4 A64])
(unspec_volatile:SI [
(mem/v:SI (symbol_ref:DI ("a") [flags 0x2] ) [-1  S4 A64])
(reg:SI 71)
(reg:SI 75)
] UNSPECV_CAS))
(set (reg:CCZ1 33 %cc)
(compare:CCZ1 (mem/v:SI (symbol_ref:DI ("a") [flags 0x2]
) [-1  S4 A64]) 
(reg:SI 71)))
]) "global_statistics.i":5 -1
 (nil))
global_statistics.i:5:1: internal compiler error: in extract_insn, at
recog.c:2311
0x159681d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x159685d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x1565907 extract_insn(rtx_insn*)
../../src/gcc/recog.c:2311
0x1382d29 instantiate_virtual_regs_in_insn
../../src/gcc/function.c:1637
0x1382d29 instantiate_virtual_regs
../../src/gcc/function.c:1957
0x1382d29 execute
../../src/gcc/function.c:2006
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug bootstrap/50229] [5/6/7/8 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[vanboxem.ruben at gmail dot com]

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

--- Comment #28 from Ruben Van Boxem  ---
(In reply to Eric Gallager from comment #27)
> (In reply to Iain Sandoe from comment #21)
> > (In reply to Francois-Xavier Coudert from comment #20)
> > > This PR appears to report two different issues:
> > >   1. cross-compiler targeting Darwin
> > >   2. cross-compiler hosted on Darwin
> > in short (2) is very definitely "works for me"
> So does this bug need to stay open then?

I reported the original issue using Fedora's Mac OS X cross compiler toolchains
that were available at the time. They are still described here, but the repo
has become unavailable:
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework

I cannot seem to locate an active repository providing these now.

So it is really your number one. If the problem lies outside of GCC sources,
perhaps it's best to close this issue, but as it used to work in GCC 4.6, it
seems something changed that made this setup nonfunctional.

[Bug fortran/58750] Wrong code with realloc on assignment and array constructors with numeric type conversion

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> Still fails on current trunk.

Well, if has not been marked as fixed, it likely to fail on trunk. More
seriously, from comment 7, IIRC it is a duplicate of pr52162.

[Bug fortran/58750] Wrong code with realloc on assignment and array constructors with numeric type conversion

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Last reconfirmed|2013-10-16 00:00:00 |2017-7-24
 CC||tkoenig at gcc dot gnu.org

--- Comment #12 from Thomas Koenig  ---
Still fails on current trunk.

[Bug other/32184] Library makefiles are not created properly. Re-configuring and creating warnings.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-07-24
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to Rob from comment #0)
> Two little things when building the libraries.
> 
> When building all languages on the target i686-pc-linux-gnu the make does
> all it's stages and then builds the libraries.
> 
> It build them in this order: libgcc, libada, libstdc++-v3, libiberty, 
> libmudflap, libssp, libgfortran, boehm-gc, libobjc, libffi and then
> finally zlib. The next library build is libjava. 
> 
> 1): Then it goes back after configuring classpath and _rebuilds_ zlib 
> again. After re-doing zlib it continues with the rest of libjava.
> 
> It is too bad it can't build it satisfactory for libjava the first time.
> 
> 
> 2): Another issue is I see this warning:
> 
> # grep -B 2 -A 2 --color=always configure:\ WARNING:
> /opt/gcc-4_3-build/make_9_log.txt  
> no
> checking whether Solaris gcc optimization fix is necessary... no
> configure: WARNING: "Must define GC_DEBUG and use debug alloc. in clients."
> configure: WARNING: "Client must not use -fomit-frame-pointer."
> updating cache ./config.cache
> configure: creating ./config.status
> 
> 
> Why take an action to trigger the warning, apparently we should define
> GC_DEBUG
> and not use -fomit-frame-pointer so lets refrain from creating the Makefile
> that way.
> 
> 
> # gcc/xgcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: /root/downloads/gcc-4_3-trunk/configure --verbose
> --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp
> --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib
> --with-gxx-include-dir=/usr/include/c++/4.3 --enable-libstdcxx-debug
> --enable-static --enable-shared --enable-initfini-array
> --enable-__cxa_atexit --enable-threads=posix
> --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap
> --enable-libgomp --disable-werror --enable-nls --with-included-gettext
> --enable-decimal-float --with-long-double-128 --enable-debug
> --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include
> --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo
> --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers
> --enable-portable-native-sync --enable-examples --enable-libgcj-multifile
> --with-stabs --enable-hash-synchronization --enable-gc-debug
> --enable-interpreter --with-system-zlib --enable-libada --with-tls
> --with-cpu=athlon-xp --with-arch=athlon-xp
> --enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree
> Thread model: posix
> gcc version 4.3.0 20070601 (experimental)

As far as 1 goes, libjava has been removed so that part is no longer relevant.
For 2, which configure script prints that warning?

[Bug fortran/63469] Automatic reallocation of allocatable scalar length even when substring implicitly specified

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
This works now, closing.

[Bug target/81521] [8 Regression] After [r250413] GCC 8.0 doesn't compile for Windows

[mateuszb at poczta dot onet.pl]

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

--- Comment #3 from mateuszb at poczta dot onet.pl ---
Thanks for the patch.
There is left one more TYPE_METHODS in file trunk/gcc/config/i386/winnt-cxx.c
see
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/winnt-cxx.c?view=markup=250476#l154

Now the bug is:
/home/ma/m/source/gcc-8/gcc/config/i386/winnt-cxx.c: In function ‘void
i386_pe_adjust_class_at_definition(tree)’:
/home/ma/m/source/gcc-8/gcc/config/i386/winnt-cxx.c:154:36: error:
‘TYPE_METHODS’ was not declared in this scope
   for (member = TYPE_METHODS (t); member;  member = DECL_CHAIN (member))
^
/home/ma/m/source/gcc-8/gcc/config/i386/t-cygming:32: recipe for target
'winnt-cxx.o' failed
make[1]: *** [winnt-cxx.o] Error 1

[Bug other/29504] target header files are refrenced (or installed) in wrong location.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Jim Hanley from comment #1)
> I beleive that this issue is actaully a duplicate or at least related to
> 22479.

bug 22479 was about the --with-headers configure flag and that doesn't seem to
be used here

[Bug c++/81533] New: g++ pops up a constructor for objects that could be initialized at load-time

[gjl at gcc dot gnu.org]

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

Bug ID: 81533
   Summary: g++ pops up a constructor for objects that could be
initialized at load-time
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41817=edit
foo.cpp: C++ test case

When compiling the following module with g++ from v8 trunk

$ g++ foo.cpp -S -O2 -save-temps

then it pops a constructor to initialize s:

struct S { int id; const char *labl; };

const S* get_S_B()
{
  static const S s =
{ 456,
  (__extension__({
  static char ccc[] = "TextB";
  [0];
})) };
  return 
}


The generated assembly reads (x86_64):

_Z7get_S_Bv:
.LFB0:
.cfi_startproc
movzbl  _ZGVZ7get_S_BvE1s(%rip), %eax
testb   %al, %al
je  .L13
movl$_ZZ7get_S_BvE1s, %eax
ret
.p2align 4,,10
.p2align 3
.L13:
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$_ZGVZ7get_S_BvE1s, %edi
call__cxa_guard_acquire
testl   %eax, %eax
jne .L14
movl$_ZZ7get_S_BvE1s, %eax
addq$8, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret


The code could be just as smart as with the following test case

struct S { int id; const char *labl; };

const S* get_S_A()
{
  static const S s = { 123, "TextA" };
  return 
}

which generates:

_Z7get_S_Av:
movl$_ZZ7get_S_AvE1s, %eax
ret

.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "TextA"

.section.rodata
_ZZ7get_S_AvE1s:
.long   123
.zero   4
.quad   .LC0
.ident  "GCC: (GNU) 8.0.0 20170724 (experimental)"


The first version with the "TextB" assignment to ccc is useful when ccc needs a
variable attribute.

[Bug c++/61414] enum class bitfield size-checking failure

[tromey at gcc dot gnu.org]

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

--- Comment #10 from Tom Tromey  ---
I ran into this again, went to file a bug, and then found that
I'd already filed the bug...

[Bug target/81521] [8 Regression] After [r250413] GCC 8.0 doesn't compile for Windows

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jul 24 13:02:06 2017
New Revision: 250476

URL: https://gcc.gnu.org/viewcvs?rev=250476=gcc=rev
Log:
PR bootstrap/81521
* tree.def: Remove TYPE_METHODS documentation, adjust TYPE_FIELDS
documentation.
* doc/generic.texi: Likewise.
* config/i386/winnt-cxx.c (i386_pe_adjust_class_at_definition): Look
for FUNCTION_DECLs in TYPE_FIELDS rather than TYPE_METHODS.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/winnt-cxx.c
trunk/gcc/doc/generic.texi
trunk/gcc/tree.def

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Yes, I can confirm that GCC 7 can detect all 6 situations with:

gcc pr81524.c  -fsanitize=address -g &&
ASAN_OPTIONS="detect_stack_use_after_return=1"  ./a.out

Can we close the PR? As resolved?

[Bug fortran/81531] Multiple Invalid reads seen by valgrind on an invalid test-case

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
When compiling gfortran.dg/fimplicit_none_2.f90 with an instrumented compiler I
get

/opt/gcc/work/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90:5:34:

character(*), parameter :: z(2) = [character(n) :: 'x', 'y'] ! { dg-error
"Scalar INTEGER expression expected" }
  1
Error: Cannot initialize parameter array at (1) with variable length elements
=
==43942==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400f68
at pc 0x000100308c73 bp 0x7fff5fbfea10 sp 0x7fff5fbfea08
READ of size 8 at 0x60400f68 thread T0
#0 0x100308c72 in gfc_resolve_expr(gfc_expr*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100308c72)
#1 0x10031ccfc in resolve_charlen(gfc_charlen*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10031ccfc)
#2 0x100341138 in resolve_types(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100341138)
#3 0x1002efa1a in gfc_resolve(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002efa1a)
#4 0x100279e98 in resolve_all_program_units(gfc_namespace*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100279e98)
#5 0x1002958d8 in gfc_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1002958d8)
#6 0x1003ec86e in gfc_be_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1003ec86e)
#7 0x10457dccc in compile_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10457dccc)
#8 0x1045868f4 in do_compile()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1045868f4)
#9 0x106498d0f in toplev::main(int, char**)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x106498d0f)
#10 0x10649e0ae in main
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10649e0ae)
#11 0x7fffa0edd234 in start (/usr/lib/system/libdyld.dylib+0x5234)

0x60400f68 is located 24 bytes inside of 48-byte region
[0x60400f50,0x60400f80)
freed by thread T0 here:
#0 0x152ae26c0 in wrap_free.part.0
(/opt/gcc/gcc7a/lib/libasan.4.dylib+0x646c0)
#1 0x1003a5e11 in gfc_delete_symtree(gfc_symtree**, char const*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1003a5e11)
#2 0x1003bb0d8 in gfc_restore_last_undo_checkpoint()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1003bb0d8)
#3 0x1003bb2a7 in gfc_undo_symbols()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1003bb2a7)
#4 0x10027a285 in reject_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10027a285)
#5 0x10027a385 in match_word(char const*, match (*)(), locus*)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10027a385)
#6 0x100285627 in decode_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100285627)
#7 0x100287b74 in next_free()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100287b74)
#8 0x10028843e in next_statement()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10028843e)
#9 0x10028dbc0 in parse_spec(gfc_statement)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10028dbc0)
#10 0x100293a7f in parse_progunit(gfc_statement)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x100293a7f)
#11 0x10029589a in gfc_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10029589a)
#12 0x1003ec86e in gfc_be_parse_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1003ec86e)
#13 0x10457dccc in compile_file()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10457dccc)
#14 0x1045868f4 in do_compile()
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1045868f4)
#15 0x106498d0f in toplev::main(int, char**)
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x106498d0f)
#16 0x10649e0ae in main
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x10649e0ae)
#17 0x7fffa0edd234 in start (/usr/lib/system/libdyld.dylib+0x5234)

previously allocated by thread T0 here:
#0 0x152ae1d40 in wrap_calloc (/opt/gcc/gcc7a/lib/libasan.4.dylib+0x63d40)
#1 0x1062bca71 in xcalloc
(/opt/gcc/gcc8g/libexec/gcc/x86_64-apple-darwin16.6.0/8.0.0/f951+0x1062bca71)
#2 0x1003a5b0a in 

[Bug c++/81513] __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work

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

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

--- Comment #4 from Andreas Schwab  ---
> #if __cpp_attributes >= 200809 && defined(__has_cpp_attribute) \
>   && __has_cpp_attribute(maybe_unused)

This will result in a syntax error if the compiler does not support
__has_cpp_attribute.  You need to separate the check from the use of the macro.

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

[wilco at gcc dot gnu.org]

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

--- Comment #8 from Wilco  ---
(In reply to Richard Biener from comment #7)

Unfortunately these commits have had no effect on AArch64...

[Bug c++/81506] Invalid declaration with decltype accepted

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug c++/81513] __has_cpp_attribute returns non-zero in C++03 mode, but attributes don't work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jonathan Wakely  ---
(In reply to Pavel Roskin from comment #2)
> __has_cpp_attribute is not supposed to check if the functionality is
> available somehow using some other approaches and keywords. It is supposed
> to check if the functionality is available as an attribute.

__has_cpp_attribute(X) tells you if X is a valid attribute. To know if you can
also use the C++11 attribute syntax you can use __cpp_attributes >= 200809.

So I would write your test as:

#if __cpp_attributes >= 200809 && defined(__has_cpp_attribute) \
  && __has_cpp_attribute(maybe_unused)
# define __maybe_unused [[maybe_unused]]
#endif

#ifndef __maybe_unused
# define __maybe_unused
#endif

That will make it work in C++03 mode.

If your bug report is that __has_cpp_attribute doesn't tell you if C++11
attribute syntax is supported, then the bug report is invalid. You should be
using __cplusplus >= 201103L for that (or the non-standard but WG21-approved
__cpp_attributes >= 200809), not assuming that the existence of
__cpp_has_attribute implies C++11 attributes work.

The reason is that you can use __has_cpp_attribute(gnu::unused) in C++03 mode
to test if __attribute__((unused)) will work.

Maybe we should make __has_cpp_attribute false in C++03 mode for any attribute
without the gnu:: prefix, if such attributes really aren't usable without C++11
syntax.

> Even is there is some alternative notation for C++03, I expect the attribute
> name to be the same. If __has_cpp_attribute(maybe_unused) is set to a
> non-zero value, I expect to use "maybe_unused", not "unused".

I'm not disagreeing, I was only observing that the other attribute name does
work as __attribute__((maybe_unused)). But I think that's because the correct
test for that would be __has_cpp_attribute(gnu::maybe_unused) (which is false,
as expected).


We should probably document the behaviour of __has_cpp_attribute and how it
interacts with GNU-style attributes as well as C++11-style attributes.

[Bug target/81532] [8 Regression] insn does not satisfy its constraints: extract_constrain_insn, at recog.c:2213

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41816=edit
gcc8-pr81532.patch

Untested fix.

[Bug driver/81519] Enhancement: Add --help=target-distcc or similar to dump clean, optimal CFLAGS without using -march=native

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I can take a look later for GCC 8.0.

[Bug tree-optimization/81511] [8 Regression] ICE at -O3 on valid code on x86_64-linux-gnu in operator[], at vec.h:749

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Liška  ---
Dup.

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

[Bug tree-optimization/81510] [8 Regression] ice in operator[], at vec.h:749

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||helloqirun at gmail dot com

--- Comment #3 from Martin Liška  ---
*** Bug 81511 has been marked as a duplicate of this bug. ***

[Bug c++/60517] warning/error for taking address of member of a temporary object

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #20 from Fredrik Hederstierna 
 ---
Simplest fix might be something like?
- else
+ else if (access->grp_no_warning)
so we do not always suppress warnings, but name will look funny for temp.

[Bug c++/81527] Missing inherited constructor by "using-declarations"

[tuwwcn at gmail dot com]

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

--- Comment #2 from Wei-Wei Tu  ---
> The above code is REJECTED by GCC 6.2.0 too.
==> Sorry for the mistake, The above code is ACCEPTED by GCC 6.2.0 too.

(In reply to Wei-Wei Tu from comment #1)
> Some additional information:
> 
> The above code is REJECTED by GCC 6.2.0 too.
> 
> But the below code is PASSED by GCC 6.1.0, 6.3.0, 6.4.0, 7.1.0. The only
> difference is explicitly casting p's type to its own type.
> 
> /
> #include 
> 
> struct A : public std::pair< int, int> {
> using std::pair::pair;
> };
> 
> int main() {
> std::pair p{1, 2}; 
> A a(std::pair(p));
> }
> ///

[Bug c++/81527] Missing inherited constructor by "using-declarations"

[tuwwcn at gmail dot com]

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

--- Comment #1 from Wei-Wei Tu  ---
Some additional information:

The above code is REJECTED by GCC 6.2.0 too.

But the below code is PASSED by GCC 6.1.0, 6.3.0, 6.4.0, 7.1.0. The only
difference is explicitly casting p's type to its own type.

/
#include 

struct A : public std::pair< int, int> {
using std::pair::pair;
};

int main() {
std::pair p{1, 2}; 
A a(std::pair(p));
}
///

[Bug target/81532] [8 Regression] insn does not satisfy its constraints: extract_constrain_insn, at recog.c:2213

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-24
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
-O2 -mavx512bw -mavx512vl is enough to reproduce.
Cleaned up testcase:

typedef unsigned __int128 V __attribute__ ((vector_size (64)));
V
foo (V c)
{
  c >>= 0 != c;
  return c;
}

The problem is I believe that Yd/Ye constraints use wrong ISA macro.
For !TARGET_64BIT ALL_SSE_REGS is equivalent to SSE_REGS, and for TARGET_64BIT
Yd/Ye is only used in movti_internal.  For the corresponding splitters to work,
I believe we need vpextrq and vpinsrq instructions, both of which are AVX512DQ
rather than AVX512BW - AVX512BW is only for vp{ext,ins}r{b,w}.