[Bug rtl-optimization/87246] New: [6/7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379

[asolokha at gmx dot com]

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

Bug ID: 87246
   Summary: [6/7/8/9 Regression] ICE in decompose_normal_address,
at rtlanal.c:6379
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-9.0.0-alpha20180902 snapshot (r264045), gcc 8.2, 7.3, 6.3 all ICE when
compiling the following snippet w/ -O2 (-O3, -Ofast) -fnon-call-exceptions
-fno-split-wide-types:

__int128 zd;
int c1;

void
s2 (__int128 *qv)
{
  if (*qv != 0)
{
  zd = 0;
  c1 = c1 <= *qv;
}
}

void
lt (unsigned int vb)
{
  s2 (vb + 1);
}

% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20180902 -O2 -fnon-call-exceptions
-fno-split-wide-types -w -c anha8p3i.c
during RTL pass: reload
anha8p3i.c: In function 'lt':
anha8p3i.c:18:1: internal compiler error: in decompose_normal_address, at
rtlanal.c:6379
18 | }
   | ^
0x649cdf decompose_normal_address
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/rtlanal.c:6379
0x649cdf decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/rtlanal.c:6456
0xb48c09 process_address_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/lra-constraints.c:3279
0xb4a942 process_address
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/lra-constraints.c:3550
0xb4a942 curr_insn_transform
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/lra-constraints.c:3865
0xb4d6ea lra_constraints(bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/lra-constraints.c:4906
0xb3b2c4 lra(_IO_FILE*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/lra.c:2446
0xaf3461 do_reload
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/ira.c:5469
0xaf3461 execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180902/work/gcc-9-20180902/gcc/ira.c:5653

[Bug target/58442] bootstrapping vax crashes on NetBSD

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Martin Husemann from comment #10)
> Matt Thomas suggested to go with the easy solution for now: protect the
> calls with MEM_P, i.e.: change the ! mode_dependent_address_p() in the
> bitfield patterns to
> 
>  (MEM_P(..) && ! mode_dependent_address_p(...))
> 
> With this change, a NetBSD kernel can be compiled (but does not yet boot),
> and bootstrap goes way further along (will file another ticket for the next
> obstacle).

Did you ever file that other ticket?

[Bug rtl-optimization/55531] peephole2 pattern with multiple insns with match_parallel insn causes corrupted peephole2_insns matching function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
so this is... what, wrong-code? ice-on-valid-code? build? 

(I should go to bed instead of trying to figure this out...)

[Bug c++/84726] [8 regression] Unnecessary lambda capture of constant variables

[P at draigBrady dot com]

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

Pádraig Brady  changed:

   What|Removed |Added

 CC||P at draigBrady dot com

--- Comment #4 from Pádraig Brady  ---
Note bug 87185, mentions this snippet which is currently not handled by this
change:

  void f() { const int i=0; [&]() noexcept {i;}; }

Specifically the "noexcept" causes non traversal of the statements, and thus
"i" remains captured in this example.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #24 from Eric Gallager  ---
(In reply to Martin Liška from comment #23)
> I can easily split insn-emit.c. Once we know which was a split should be
> done, I can prepare patch for that.

Confirmed, please do this!

[Bug other/29442] insn-attrtab has grown too large

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #20 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to comment #18)
> > (In reply to comment #15)
> > Meanwhile Jakub implemented a different mean which doesn't call the 
> > get_attr_
> > functions dynamically more often (which my approach potentially does), but
> > which as result isn't nearly as effective in reducing size and compile and
> > generation time.
> 
> For reducing compile time (but not size/generation), we could just use the
> cache vars with some magic unset value (probably the cache vars would need
> to be int
> instead of enum for that).  Then if genattrtab finds out that there is no
> dominating call to the get_attr_* function, but still potentially for one
> insn the same get_attr_* might be called more than once in certain code
> path, then
> for that code path it could just use (cache_FOO != -1 ? (enum ...) cache_FOO
> : (cache_FOO = get_attr_FOO (...))).

If these are things that could still be done, would it make sense to reopen
this bug, or open a new one for them?

[Bug target/38093] undefined predicates in bfin.md

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #1)
> That patch looks like binary; are you sure it's really a patch?

It is uuencoded.  And yes a text file will look that funny as uuencoded file.

[Bug rtl-optimization/71596] gcc bootstrap fails due to segv in genrecog

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #9 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #6)
> Dropping the regression mark, as it isn't really a regression, just missing
> enhancement.

Changing importance then.

[Bug target/38093] undefined predicates in bfin.md

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
(In reply to Kueifong Li from comment #0)
> This is my system information,
> 
> FreeBSD cowboy.branda.to 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Fri Oct 17
> 22:32:29 CST 2008
> thin...@cowboy.branda.to:/usr/src/sys/i386/compile/cowboy  i386
> 
> My configuration command is
> 
> ../configure --prefix=/home/thinker/tmp/dest \
> --target=bfin-unknown-elf --host=i386-unknown-freebsd8.0 \
> --with-gmp=/usr/local --disable-libssp
> 
> But, genrecog is core dumped when making cross-compiler for bfin target.  It
> can be fixed by a small patch following.
> 
> begin 644 bfin-predicates.diff
> M9`M M+2T@82]G8V,O8V]N9FEG+V)F:6XO8F9I;BYC"5=E9"!397`@,C0@,3(Z,#$Z
> M,30@,C`P."`K,#@P,`HK*RL@8B]G8V,O8V]N9FEG+V)F:6XO8F9I;BYC"5=E
> M9"!.;W8@,3(@,C,Z,3@Z,3@@,C`P."`K,#@P,`I`0"`M,S`V-RPW("LS,#8W
> M+#<@0$`@ M90H@ M=&]? M(&]P+"!E;G5M(F5?;6]D92!M;V1E($%45%))0E5415]53E53140I
> M"BM?<'5S:%]M=6QT:7!L95]O<&5R871I;VX@*')T>"!O<"P@96YU;2!M86-H
> M:6YE7VUO9&4@;6]D92!!5%1224)55$5?54Y54T5$*0H@>PH@("!I;G0@;&%S
> M=&1R96<@/2`X+"!L87-T<')E9R`](#8["B`@(="!I+"!G M+3,Q,S M='@@;W`L(&5N=6T@;6$*('T*(`H@:6YT"BUP;W!?;75L=&5?;W!E M:6]N("AR='@@;W`L(&5N=6T@;6%C:]M;V1E(&4@05144DE"551%
> M7U5.55-%1"D**U]P;W!?;75L=&5?;W!E M=6T@;6%C:]M;V1E(&4@05144DE"551%7U5.55-%1"D*('L*("`@
> M:6YT( M=7`["D!`("TS,C`U+#<@*S,R,#4L-R!`0"!O=71P=71?<'5S:%]M=6QT:7!L
> M92`H"`J;W!E"B`@(="!O:SL*("`@"B`@("\J(%9A
> M;('1H92!I;G-N(&%G86EN+"!A;F0@8V]M<'5T92!F:7)S=%];9'!=
> M M;VX@*%!!5%1%4DX@* M;75L=&5?;W!E M.PH@("!G8V-?87-S97)T("AO:RD["B`@(`H@("!I9B`H9FER M;U]S879E(#T](#@I"D!`("TS,C(Y+#<@*S,R,CDL-R!`0"!O=71P=71?<&]P
> M7VUU;'1I<("AR='@@:6YS;BP@ M"B`@("\J(%9A;('1H92!I;G-N(&%G86EN+"!A;F0@8V]M<'5T92!F
> M:7)S=%];9'!= M7V]P97)A=B`H4$%45$523B`H:6YS;BDL(%9/241M;V1E*3L**R`@;VL@
> M/2!?<&]P7VUU;'1I<]P97)A=B`H4$%45$523B`H:6YS;BDL(%9/
> M241M;V1E*3L*("`@9V-C7V%S M M;F9I9R]B9FEN+W!R961I8V%T97,N;60*+2TM(&$O9V-C+V-O;F9I9R]B9FEN
> M+W!R961I8V%T97,N;60)5V5D(%-E<"`R-"`Q,CHP,3HQ-"`R,#`X("LP.#`P
> M"BLK*R!B+V=C8R]C;VYF:6 M,3(@,C,Z,3@Z,3@@,C`P."`K,#@P,`I`0"`M,3 M(%EO=2!S:&]U;&0@:&%V92!R96-E:79E9"!A(&-O<'D@;V8@=($=.52!'
> M96YE M('1H92!F:6QE($-/4%E)3D M(G!A M;&5?;W!E M=&4@(G!O<%]M=6QT:7!L95]O<&5R871I;VXB"BL@("AA;F0@*=&-H7V-O
> M9&4@(G!A M:7!L95]O<&5R871I;VXH;W`L(&4I(BDI*0H@"B`[.R!2971U M>F5R;R!I9F8@3U`@:7,@;VYE(&]F('1H92!I;G1E9V5R(&-O;G-T86YT M(&]R(#(N"B`H9&5F:6YE7W!R961I8V%T92`B<&]S7W-C86QE7V]P97)A;F0B
> !"@``
> `
> end

That patch looks like binary; are you sure it's really a patch?

[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #5)
> Does this still happen with newer versions of GCC?

No reply; guessing not

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-09-07
 Ever confirmed|0   |1

[Bug target/61024] nios2-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to sandra from comment #3)
> I believe this issue should be closed, as RTEMS support for Nios II was
> committed  back in July 2014.
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02124.html
> 
> That patch provided the missing definition for TARGET_LINUX_ABI, among other
> things.

OK cool.

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
(In reply to kargl from comment #2)
> (In reply to Jerry DeLisle from comment #1)
> > The check is easy enough to delete:
> > 
--- snip ---

> What happens with -std=f95 and -std=f2003?
> 
> -- 
> steve

Well obviously we dont have the hooks for f95 and f2003. AFAICT the code looks
acceptable per my read of f2008. So if we want to provide different levels of
diagnostics for the various version standards, I can add the hooks.  It
frustrates me since I feel like we are constantly chasing rabbits down the
rabit holes with these things. It would be nice if people just would conform to
the current standard, in this case it is more forgiving to to so.

[Bug target/61024] nios2-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I believe this issue should be closed, as RTEMS support for Nios II was
committed  back in July 2014.

https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02124.html

That patch provided the missing definition for TARGET_LINUX_ABI, among other
things.

[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
(In reply to Valeriy E. Ushakov from comment #6)
> (In reply to Oleg Endo from comment #5)
> > BTW, those two patterns do not exist anymore in trunk, as SH5 stuff has been
> > removed.
> 
> Yes, but that just masks the bug that L/LL selection is done in wrong
> context.

OK, so what would be a better way to word the title then, such that it doesn't
mention an obsolete target?

[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Paulo J. Matos from comment #2)
> Created attachment 25389 [details]
> Patch for GCC 4.6.1 implementing suggested enhancement

(In reply to Paulo J. Matos from comment #3)
> Created attachment 25420 [details]
> Allows reload to remove trivial insn
> 
> I noticed that reload was failing to remove insn of the form:
> (parallel [(set rX rX) (clobber RCC)])
> 
> Attached is a patch that does this. Removes move instructions whose clobber,
> clobbers registers defined in NOT_REALLY_HARD_REG.

Do these patches still apply against trunk? If so, please submit to gcc-patches
for review.

[Bug tree-optimization/87245] New: [missed optimization] switching on indices of struct members

[herring at lanl dot gov]

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

Bug ID: 87245
   Summary: [missed optimization] switching on indices of struct
members
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

Consider a simple struct whose members can be accessed by name or by index:

  struct vec {double x,y,z;};

  double get(const struct vec *v,unsigned long i) {
switch(i) {
  case 0: return v->x;
  case 1: return v->y;
  case 2: return v->z;
}
  }

Godbolt's trunk x86_64 build produces at -O3

  get:
cmpq $1, %rsi
ja .L2
je .L11
movsd (%rdi), %xmm0
ret
  .L2:
cmpq $2, %rsi
jne .L12
movsd 16(%rdi), %xmm0
ret
  .L11:
movsd 8(%rdi), %xmm0
ret
  .L12:
ret

when of course

  get:
movsd (%rdi,%rsi,8), %xmm0
ret

would suffice.  (Apologies if I picked the wrong -optimization component.)

Bonus points for collapsing

  double get(const struct vec *arr,unsigned long i) {
arr+=i/3;
switch(i%3) {
  case 0: return arr->x;
  case 1: return arr->y;
  case 2: return arr->z;
}
  }

to the same two instructions.

[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Gallager  ---
(In reply to Yves Caniou from comment #4)
> I have the same issue with gcc-4.8.2 compiling gcc-4.8.2, on a Intel(R)
> Xeon(R) CPU E5-2630 0 @ 2.30GHz.

What about with a newer, still-supported version?

[Bug driver/35532] Native GCC no longer searches $prefix/lib for startfiles when run from $objdir

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #16 from Eric Gallager  ---
(In reply to Earnie from comment #15)
> I know this is old but I have a similar issue with 2.8.1 in building a
> native MinGW build.  

You mean 4.8.1? Anyways that's old now too; are you still seeing the issue?

[Bug target/61024] nios2-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||sandra at codesourcery dot com

--- Comment #2 from Eric Gallager  ---
cc-ing other nios maintainer

[Bug target/55523] gencondmd C++ conversion breaks peephole2 predicates use of get_attr_*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
Does this still happen with newer gcc versions?

[Bug bootstrap/58828] Problem compiling gcc 4.8.2 using gcc 4.4.6

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Daniel Fruzynski from comment #3)
> OK, I found it. I used script symlink-tree (distributed with binutils) to
> create symlinks to binutils in gcc source dir. This script removed some gcc
> source files and replaced them with symlinks to corresponding files in
> binutils dir. I assumed that it will help me, but it created more problems.
> 
> I am building gcc without binutils symlinked, and build is on stage 2 now.
> Look that it will complete successfully.
> 
> I think that dedicated script to symlink all binutils into gcc dir would be
> useful. Could you create one?

"You" as in Richard or Ian?

[Bug bootstrap/37013] gcc-4.2.1 build breaks in fortran when using --with-mpfr=

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Martin Sebor from comment #5)
> GCC 4.2 is no longer maintained.  Has the problem cleared up for you in more
> recent (and currently maintained) versions of GCC?

No reply, so I'm going to close this.

[Bug bootstrap/56954] Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Does this still happen with newer GCC versions?

[Bug other/46489] tree optimizer and frontend files use target macros

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Joseph S. Myers from comment #7)
> FWIW, the following files include tm.h and appear not to have any direct
> uses of target macros, or uses of the most common headers (such as rtl.h or
> cp-tree.h) that depend on tm.h.  They require more careful checks of what
> headers they are using for any hidden tm.h dependencies, but may be good
> candidates for the removal of tm.h includes.
> 
> gcc/java/except.c
> gcc/java/jvgenmain.c
> gcc/java/jvspec.c
> gcc/java/mangle.c
> gcc/java/zextract.c

I don't know about the rest of them, but these at least are gone.

[Bug bootstrap/78893] gcc-6.3.0 build fails on genattrtab on CentOS 7

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to William Bader from comment #3)
> Thanks! Increasing the allocated memory fixed the problem, and the gcc build
> completed. Regards, William
> 
> $ /usr/bin/free -h
>   totalusedfree  shared  buff/cache  
> available
> Mem:   1.8G240M941M 28M658M   
> 1.3G
> Swap:  1.0G 81M943M

OK, closing this then.

[Bug rtl-optimization/39165] redundant simplify_cond in genattrtab.c

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
cc-ing gen* maintainer for his opinion

[Bug fortran/87244] Failure to compile an allocate statement of variable length

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|kargl at gcc dot gnu.org   |
 Resolution|--- |WONTFIX

--- Comment #2 from kargl at gcc dot gnu.org ---
As 4.9.2 is no longer under development, closing as WONTFIX.

[Bug fortran/87244] Failure to compile an allocate statement of variable length

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Your code compiles and executes with gfortran versions
6.4.1, 7.3.1, 8.1.1, and 9.0.0.


troutmask:sgk[205] gfcx -o z a.f90 && ./z
 0 Failure to open file: filenames
STOP timecomp:first open
troutmask:sgk[206] gfc8 -o z a.f90 && ./z
 0 Failure to open file: filenames
STOP timecomp:first open
troutmask:sgk[207] gfc7 -o z a.f90 && ./z
 0 Failure to open file: filenames
STOP timecomp:first open
troutmask:sgk[208] gfc6 -o z a.f90 && ./z
 0 Failure to open file: filenames
STOP timecomp:first open

Version 4.9.2 is no loner supported.  I suggest you 
(or your organization) update to supported version
of gfortran.

[Bug c++/87241] A hang problem for c++filt

[poppeter1982 at gmail dot com]

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

--- Comment #2 from Li Peng  ---
(In reply to Jonathan Wakely from comment #1)
> __cxa_demangle in cp-demangle.c correctly returns -2 (the mangled name is
> not valid) but cplus_demangle in cplus-dem.c tries to allocate crazy amounts
> of memory.

So you can confirm this is a bug, right?

[Bug fortran/87244] New: Failure to compile an allocate statement of variable length

[george.mesina at inl dot gov]

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

Bug ID: 87244
   Summary: Failure to compile an allocate statement of variable
length
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: george.mesina at inl dot gov
  Target Milestone: ---

Created attachment 44666
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44666=edit
File being compiled, timecomp.F90, is attached

VERSION of GFORTRAN
gfortran -v
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/apps/local/easybuild/software/GCC/4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran,lto --enable-lto
--enable-checking=release --disable-multilib --enable-shared=yes
--enable-static=yes --enable-threads=posix --enable-gold=default
--enable-plugins --enable-ld --with-plugin-ld=ld.gold
--prefix=/apps/local/easybuild/software/GCC/4.9.2
--with-local-prefix=/apps/local/easybuild/software/GCC/4.9.2 --enable-bootstrap
--with-cloog=/apps/local/easybuild/build/GCC/4.9.2/dummy-dummy/gcc-4.9.2/stage2_stuff
--with-isl=/apps/local/easybuild/build/GCC/4.9.2/dummy-dummy/gcc-4.9.2/stage2_stuff
Thread model: posix

PLATFORM:
uname -a
Linux falcon2 3.0.101-108.35-default #1 SMP Mon Feb 19 21:13:08 UTC 2018
(251ec24) x86_64 x86_64 x86_64 GNU/Linux

COMMAND
gfortran -Wall -Wconversion -pedantic -fbounds-check -fbacktrace
-fdefault-integer-8 -fdefault-real-8 -c -g -O2 -o timecomp.x timecomp.F90
timecomp.F90: In function ‘getfiledata’:
timecomp.F90:209:0: internal compiler error: Segmentation fault
allocate (fnames(10+nlines), source = blanks)
 ^
0x9a066f crash_signal
../../gcc/toplev.c:337
0x7f4100 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:1952
0x68021f gfc_array_init_size
../../gcc/fortran/trans-array.c:5085
0x68021f gfc_array_allocate(gfc_se*, gfc_expr*, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, gfc_expr*, gfc_typespec*)
../../gcc/fortran/trans-array.c:5237
0x6c8859 gfc_trans_allocate(gfc_code*)
../../gcc/fortran/trans-stmt.c:4952
0x6740c7 trans_code
../../gcc/fortran/trans.c:1794
0x6c0973 gfc_trans_if_1
../../gcc/fortran/trans-stmt.c:986
0x6c672a gfc_trans_if(gfc_code*)
../../gcc/fortran/trans-stmt.c:1017
0x6741a7 trans_code
../../gcc/fortran/trans.c:1736
0x69366b gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5653
0x693907 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:4771
0x693907 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:5589
0x6333d0 translate_all_program_units
../../gcc/fortran/parse.c:4953
0x6333d0 gfc_parse_file()
../../gcc/fortran/parse.c:5150
0x6703a5 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

File being compiled, timecomp.F90, is attached.

[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
All I'm asking is that that we describe the real bug (i.e. that we need to be
able to find the headers when they are not installed in some Well Known Place).
 It should also work for -mmacosz-version-min != current system revision (and
therefore, might need to deal with finding libraries too - or else, for
example, we won't be able to build m32 exes).

-

As it happens, I had been giving this problem some thought - a couple of years
ago.

What we don't want is to cripple Darwin's toolchain by making it call more and
more executables for each invocation.

IFF you want to configure to use the current installed Xcode - you could just
put 
--with-sysroot='xcrun --sdk ... etc` on the configure line.

That doesn't solve the issue of the Xcode package being moved or the user
issuing a --xcode-select ...

... so 
let's state the problem we want to solve and the cases we want to cover - and
then figure out how to do it.  The bug is not "we must use xcrun" the bug is
"we need to find the headers under the following circumstances".

I had in mind, for the record, some scheme using symlinks in the user's home
directory (since using schemes writing into the /xxx dirs require elevated
permissions).  There's still a penalty in looking up through a link c.f. direct
access to things - but it would me much less than running a second process and
parsing the output.



JFTR: To support non-Apple-native clang builds I have to patch the LLVM cmake
files to *avoid* the xcrun calls and use the SDk paths I want!.

[Bug target/86731] [8/9 Regression] Miscompiles vec_sl at -O3 with -fwrapv on ppc64el

[willschm at gcc dot gnu.org]

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

--- Comment #3 from Will Schmidt  ---
Author: willschm
Date: Thu Sep  6 19:47:06 2018
New Revision: 264150

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

2018-09-06  Will Schmidt  

PR target/86731
* config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Update logic
around folding of vec_sl to handle out of range shift values.

[testsuite]

2018-08-15  Will Schmidt  

PR target/86731
* gcc.target/powerpc/pr86731.c: New test.
* gcc.target/powerpc/pr86731-longlong.c: New test.
* gcc.target/powerpc/pr86731-fwrapv.c: New test.
* gcc.target/powerpc/pr86731-fwrapv-longlong.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold.c: New test.
* gcc.target/powerpc/pr86731-nogimplefold-longlong.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-fwrapv.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold-longlong.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731-nogimplefold.c
trunk/gcc/testsuite/gcc.target/powerpc/pr86731.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-06
 CC||janus at gcc dot gnu.org
Summary|Contiguous array pointer|[8/9 Regression] Contiguous
   |function result not |array pointer function
   |recognized as contiguous|result not recognized as
   ||contiguous
 Ever confirmed|0   |1

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the error with gfortran 8 and trunk, but I don't see it with
7.3.0 and earlier. Seems to be a regression. Slightly reduced test case:


module m
  implicit none

  type :: t1
   contains
 procedure :: get_ptr
  end type

  type :: t2
 class(t1), allocatable :: c
  end type

contains
  function get_ptr(this)
class(t1) :: this
real, dimension(:), contiguous, pointer :: get_ptr
  end function

  subroutine test()
real, dimension(:), contiguous, pointer:: ptr
type(t2) :: x
ptr => x%c%get_ptr()
  end subroutine

end module

[Bug fortran/87239] ICE in deferred-length string

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-06
 Ever confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org ---
I can confirm the ICE with all gfortran versions I tried (5 to trunk). Slightly
reduced test case (a separate module is not necessary):


program main
  implicit none
  character(3), parameter :: inp( 2 ) = [ 'aaa', 'bbb' ]
  character(:), allocatable :: out(:)

  out = gettwo( inp )
  print *, out

contains

  elemental function gettwo( s ) result( res )
character(*), intent(in) :: s
character(2) :: res
res = s(1:2)
  end function

end

[Bug c++/70124] alignas error in constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Another testcase:

#include 

int main() {
int aa = 0;
alignas(std::max(alignof(void*), alignof(int))) int bb;
bb = 1;
}

[Bug c/87242] optimize -O2 incorrect output

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Greg Minshall from comment #1)
> sorry, the attachment is too long (4MB).

You can compress it, usually preprocessed source compresses nicely with either
gzip or bzip2.

[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #1)
> I am strongly against making GCC's configure depend on xcrun.  It is quite
> possible that GCC could be used, for example, with PureDarwin - or on
> systems without any Xcode install (using headers built from the OpenSource
> packages).
> 
> So, yes we have to find a solution to finding the headers,
> but no, (at least I don't agree) that trying into yet another tool we don't
> control is that solution.

It could be conditional on system version. As long as there's a fallback path
for cases where there's no xcrun, it should be okay. See for example what the
emacs configure does:
http://git.savannah.gnu.org/cgit/emacs.git/tree/configure.ac#n73

[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
(In reply to Iain Sandoe from comment #1)
> I am strongly against making GCC's configure depend on xcrun.  It is quite
> possible that GCC could be used, for example, with PureDarwin - or on
> systems without any Xcode install (using headers built from the OpenSource
> packages).
> 
> So, yes we have to find a solution to finding the headers,
> but no, (at least I don't agree) that trying into yet another tool we don't
> control is that solution.

The problem is finding a mechanism which doesn't use Apple's xcrun yet still
allows you to find the SDK since the location of Xcode.app can change with
renaming and hence the location of the SDK.

[Bug target/87243] FSF needs to use xcrun on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe  ---
I am strongly against making GCC's configure depend on xcrun.  It is quite
possible that GCC could be used, for example, with PureDarwin - or on systems
without any Xcode install (using headers built from the OpenSource packages).

So, yes we have to find a solution to finding the headers,
but no, (at least I don't agree) that trying into yet another tool we don't
control is that solution.

[Bug target/87243] New: FSF needs to use xcrun on darwin18 to find system headers in SDK

[howarth.at.gcc at gmail dot com]

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

Bug ID: 87243
   Summary: FSF needs to use xcrun on darwin18 to find system
headers in SDK
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
  Target Milestone: ---

The Xcode 10 release on 10.14 deprecates the presence of the system headers in
/ such that the Command Line Tools package no longer installs a /usr/include
directory. While Apple is providing a fall back header package to install the
SDK in /, this will be dropped in a future macOS release. 

   The Apple clang compilers aren't explicitly patched to address this issue.
Rather the compiler stubs in /usr/bin execute the compilers in the Xcode
application and the Command Line Tools via the xcrun program which sets the
SDKROOT environmental appropriately. Since installing compiler wrappers to do
this for FSF gcc would be problematic for the other targets, the better
approach would be to have the header search path enhanced to default to
-iwithsysroot `xcrun --sdk macosx --show-sdk-path` for FSF gcc.

[Bug tree-optimization/87188] Function pointer canonicalization optimized away

[dave.anglin at bell dot net]

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

--- Comment #16 from dave.anglin at bell dot net ---
On 2018-09-05 7:38 PM, dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188
>
> --- Comment #15 from dave.anglin at bell dot net ---
> On 2018-09-05 7:21 PM, dave.anglin at bell dot net wrote:
>> Doing a "&" operation on a function pointer looks bad.
> No, I misread this line "_12 = SR.13_1 == operator!=;".  It looks like
> an expand problem.
We only get canonicalization of function pointers when we expand using 
do_compare_and_jump().
In the ifcombine pass, we transform the operation to "_12 = SR.13_1 == 
operator!=;".  I believe this
expands to one of the scc patterns without canonicalization.

[Bug c/87242] optimize -O2 incorrect output

[minshall at acm dot org]

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

--- Comment #1 from Greg Minshall  ---
sorry, the attachment is too long (4MB).

is there any tool for whittling away the unnecessary bits, given a .c file --
i'd create by -E, though maybe the .i file would work? -- and a target function
-- i.e., the closure of all the references in the target function?

[Bug c/87242] New: optimize -O2 incorrect output

[minshall at acm dot org]

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

Bug ID: 87242
   Summary: optimize -O2 incorrect output
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: minshall at acm dot org
  Target Milestone: ---

Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D' 'emacs' '-I' '.' '-I' '.' '-I'
'../lib' '-I' '../lib' '-pthread' '-isystem' '/usr/include/gtk-3.0' '-isystem'
'/usr/include/at-spi2-atk/2.0' '-isystem' '/usr/include/at-spi-2.0' '-isystem'
'/usr/include/dbus-1.0' '-isystem' '/usr/lib/x86_64-linux-gnu/dbus-1.0/include'
'-isystem' '/usr/include/gtk-3.0' '-isystem' '/usr/include/gio-unix-2.0/'
'-isystem' '/usr/include/mirclient' '-isystem' '/usr/include/mircore'
'-isystem' '/usr/include/mircookie' '-isystem' '/usr/include/cairo' '-isystem'
'/usr/include/pango-1.0' '-isystem' '/usr/include/harfbuzz' '-isystem'
'/usr/include/pango-1.0' '-isystem' '/usr/include/atk-1.0' '-isystem'
'/usr/include/cairo' '-isystem' '/usr/include/pixman-1' '-isystem'
'/usr/include/freetype2' '-isystem' '/usr/include/libpng12' '-isystem'
'/usr/include/gdk-pixbuf-2.0' '-isystem' '/usr/include/libpng12' '-isystem'
'/usr/include/glib-2.0' '-isystem' '/usr/lib/x86_64-linux-gnu/glib-2.0/include'
'-isystem' '/usr/include/freetype2' '-isystem' '/usr/include/libpng12'
'-isystem' '/usr/include/libxml2' '-pthread' '-isystem'
'/usr/include/webkitgtk-4.0' '-isystem' '/usr/include/gtk-3.0' '-isystem'
'/usr/include/at-spi2-atk/2.0' '-isystem' '/usr/include/at-spi-2.0' '-isystem'
'/usr/include/dbus-1.0' '-isystem' '/usr/lib/x86_64-linux-gnu/dbus-1.0/include'
'-isystem' '/usr/include/gtk-3.0' '-isystem' '/usr/include/gio-unix-2.0/'
'-isystem' '/usr/include/mirclient' '-isystem' '/usr/include/mircore'
'-isystem' '/usr/include/mircookie' '-isystem' '/usr/include/cairo' '-isystem'
'/usr/include/pango-1.0' '-isystem' '/usr/include/harfbuzz' '-isystem'
'/usr/include/pango-1.0' '-isystem' '/usr/include/atk-1.0' '-isystem'
'/usr/include/cairo' '-isystem' '/usr/include/pixman-1' '-isystem'
'/usr/include/freetype2' '-isystem' '/usr/include/libpng12' '-isystem'
'/usr/include/gdk-pixbuf-2.0' '-isystem' '/usr/include/libpng12' '-isystem'
'/usr/include/libsoup-2.4' '-isystem' '/usr/include/libxml2' '-isystem'
'/usr/include/webkitgtk-4.0' '-isystem' '/usr/include/glib-2.0' '-isystem'
'/usr/lib/x86_64-linux-gnu/glib-2.0/include' '-pthread' '-isystem'
'/usr/include/glib-2.0' '-isystem' '/usr/lib/x86_64-linux-gnu/glib-2.0/include'
'-isystem' '/usr/include/glib-2.0' '-isystem'
'/usr/lib/x86_64-linux-gnu/glib-2.0/include' '-isystem'
'/usr/include/freetype2' '-isystem' '/usr/include/freetype2' '-MMD' '-MF'
'deps/emacs-module.d' '-MP' '-isystem' '/usr/include/p11-kit-1' '-fno-common'
'-Wabi' '-Waddress' '-Waggressive-loop-optimizations' '-Wall' '-Wattributes'
'-Wbool-compare' '-Wbuiltin-macro-redefined' '-Wcast-align' '-Wchar-subscripts'
'-Wchkp' '-Wclobbered' '-Wcomment' '-Wcoverage-mismatch' '-Wcpp' '-Wdate-time'
'-Wdeprecated' '-Wdeprecated-declarations' '-Wdesignated-init'
'-Wdisabled-optimization' '-Wdiscarded-array-qualifiers'
'-Wdiscarded-qualifiers' '-Wdiv-by-zero' '-Wdouble-promotion' '-Wempty-body'
'-Wendif-labels' '-Wenum-compare' '-Wextra' '-Wformat-contains-nul'
'-Wformat-extra-args' '-Wformat-security' '-Wformat-signedness' '-Wformat-y2k'
'-Wformat-zero-length' '-Wfree-nonheap-object' '-Wignored-qualifiers'
'-Wimplicit' '-Wimplicit-function-declaration' '-Wimplicit-int'
'-Wincompatible-pointer-types' '-Winit-self' '-Wint-conversion'

[Bug middle-end/87162] [6.2.0] Internal compiler error: Error reporting routines re-entered.

[ma.jiang at zte dot com.cn]

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

ma.jiang at zte dot com.cn changed:

   What|Removed |Added

 CC||ma.jiang at zte dot com.cn

--- Comment #8 from ma.jiang at zte dot com.cn ---
(In reply to Wen Yang from comment #7)
> This patch will make it more robust:
> 
> # git diff
> diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
> index 1d4eb80..326e1c4 100644
> --- a/gcc/trans-mem.c
> +++ b/gcc/trans-mem.c
> @@ -2099,6 +2099,9 @@ gate_tm_init (void)
>if (!flag_tm)
>  return false;
>  
> +  if (!cfun->cfg)
> +return false;
> +
>calculate_dominance_info (CDI_DOMINATORS);
>bitmap_obstack_initialize (_obstack);

I think gate functions should not do complex compute. gate_tm_init should be
split into two parts.

[Bug c++/87241] A hang problem for c++filt

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-06
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
__cxa_demangle in cp-demangle.c correctly returns -2 (the mangled name is not
valid) but cplus_demangle in cplus-dem.c tries to allocate crazy amounts of
memory.

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[krebbel at gcc dot gnu.org]

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

--- Comment #14 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Sep  6 07:38:42 2018
New Revision: 264143

URL: https://gcc.gnu.org/viewcvs?rev=264143=gcc=rev
Log:
S/390: Prohibit SYMBOL_REF in UNSPECV_CAS

Inhibit constant propagation inlining SYMBOL_REF loads into
UNSPECV_CAS.  Even though reload can later undo it, the resulting
code will be less efficient.

gcc/ChangeLog:

2018-09-06  Ilya Leoshkevich  

PR target/80080
* config/s390/predicates.md: Add nonsym_memory_operand.
* config/s390/s390.c (s390_legitimize_cs_operand): If operand
contains a SYMBOL_REF, load it into an intermediate pseudo.
(s390_emit_compare_and_swap): Legitimize operand.
* config/s390/s390.md: Use the new nonsym_memory_operand
with UNSPECV_CAS patterns.

gcc/testsuite/ChangeLog:

2018-09-06  Ilya Leoshkevich  

PR target/80080
* gcc.target/s390/pr80080-3.c: New test.
* gcc.target/s390/s390.exp: Make sure the new test passes
on all optimization levels.



Added:
trunk/gcc/testsuite/gcc.target/s390/pr80080-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/predicates.md
trunk/gcc/config/s390/s390.c
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/s390/s390.exp

[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.

[krebbel at gcc dot gnu.org]

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

--- Comment #13 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Sep  6 07:35:35 2018
New Revision: 264142

URL: https://gcc.gnu.org/viewcvs?rev=264142=gcc=rev
Log:
S/390: Register pass_s390_early_mach statically

The dump file used to come at the end of the sorted dump file list,
because the pass was registered dynamically. This did not reflect the
order in which passes are executed. Static registration fixes this:

* foo4.c.277r.split2
* foo4.c.281r.early_mach
* foo4.c.282r.pro_and_epilogue

gcc/ChangeLog:

2018-09-06  Ilya Leoshkevich  

PR target/80080
* config/s390/s390-passes.def: New file.
* config/s390/s390-protos.h (class rtl_opt_pass): Add forward
declaration.
(make_pass_s390_early_mach): Add declaration.
* config/s390/s390.c (make_pass_s390_early_mach):
(s390_option_override): Remove dynamic registration.
* config/s390/t-s390: Add s390-passes.def.



Added:
trunk/gcc/config/s390/s390-passes.def
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390-protos.h
trunk/gcc/config/s390/s390.c
trunk/gcc/config/s390/t-s390

[Bug target/87231] stdatomic.h: No such file or directory on OpenBSD 6.3

[sh...@time-travellers.org]

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

--- Comment #3 from Shane Kerr  ---
(In reply to Andrew Pinski from comment #2)
> Similar issue to PR 69744.  OpenBSD config should just remove that.

How would I do that?

Should I just comment out the USER_H variable?