[Bug c++/65656] __builtin_constant_p should always be constexpr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug target/32838] gcc generates incorrect trampoline code in thumb mode

[leo at marco dot de]

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

--- Comment #8 from Matthias Pfaller  ---
On 07/27/2017 02:34 AM, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32838
> 
> Eric Gallager  changed:
> 
>What|Removed |Added
> 
>  Status|WAITING |RESOLVED
>  CC||egallager at gcc dot gnu.org
>  Resolution|--- |INVALID
> 
> --- Comment #7 from Eric Gallager  ---
> (In reply to Matthias Pfaller from comment #6)
>> Subject: Re:  gcc generates incorrect trampoline code in
>>  thumb mode
>>
>> sam at gcc dot gnu dot org wrote:
>>> --- Comment #5 from sam at gcc dot gnu dot org  2009-03-19 10:15 ---
>>> Matthias,
>>>
>>> I think Laurent was asking for an executable test case, which fails before 
>>> your
>>> test and succeeds after, so that it can enter the regression suite.
>>>
>>>
>>>   
>> We are using the compiler strictly for our embedded systems (software
>> running on the bare hardware). Sorry, I cannot provide you an
>> exececutable testcase.
>>
>> Regards, Matthias
> 
> Well since that was presumably what this bug was marked as WAITING for, I 
> guess
> I can close it then

And it's fixed in newer gcc versions. sorry for not following up.

regards, Matthias

[Bug go/64900] gotools don't link on Solaris 11/x86

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug middle-end/64182] wide-int rounding division is broken

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |5.0

--- Comment #16 from Andrew Pinski  ---
Fixed for GCC 5.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug c++/61105] [constexpr] accepts-invalid with new-expression in constant expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug target/60949] Thumb2 LRA ICE for case pr34856.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
No feedback in over one year so closing.

[Bug target/61079] #pragma fini doesn't apply without definition

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|5.5 |---

[Bug testsuite/60806] libstdc++ abi check should ignore missing TLS symbols

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug c++/60615] bad location in error from initializer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug c++/60608] Template argument problem

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.5 |---

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|5.4 |---

[Bug libstdc++/79162] [7/8 Regression] [C++17] ambiguity in string assignment due to string_view overload

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|7.0 |7.2
Summary|[7 Regression] [C++17]  |[7/8 Regression] [C++17]
   |ambiguity in string |ambiguity in string
   |assignment due to   |assignment due to
   |string_view overload|string_view overload

[Bug tree-optimization/81558] Loop not vectorized

[kugan at gcc dot gnu.org]

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

--- Comment #2 from kugan at gcc dot gnu.org ---

> Does LLVM do a runtime alias check here?  For foo1 GCC adds a runtime alias
> check
> (BB vectorization cannot version for aliasing).

Yes. LLVM does not seem to be unrolling the inner loop. As you said, when
disabling cunrolli it works. cunroll pass will unroll after loop vectorisation.
Can anything  done with the heuristics for this case? Thanks.

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[wilson at gcc dot gnu.org]

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

--- Comment #7 from Jim Wilson  ---
I must have failed to realize that this was a bug I had created when I got the
earlier message.

Looking now, I see that I can still reproduce with mainline, though the problem
is not as obvious with this testcase.  Compiling with -O -S -fdump-rtl-all, I
see for the bitfield insert of i into foo.i

(insn 8 5 9 2 (set (reg:DI 348)
(zero_extend:DI (reg/v:SI 345 [ i ]))) "tmp.c":10 -1
 (nil))
(insn 9 8 10 2 (set (reg:DI 350)
(const_int 2147483647 [0x7fff])) "tmp.c":10 -1
 (nil))
(insn 10 9 11 2 (set (reg:DI 349)
(and:DI (reg:DI 348)
(reg:DI 350))) "tmp.c":10 -1
 (nil))
(insn 11 10 12 2 (set (reg:DI 352)
(const_int -2147483648 [0x8000])) "tmp.c":10 -1
 (nil))
(insn 12 11 13 2 (set (reg:DI 351)
(and:DI (reg:DI 343 [ D.1463 ])
(reg:DI 352))) "tmp.c":10 -1
 (nil))
(insn 13 12 14 2 (set (reg:DI 353)
(ior:DI (reg:DI 351)
(reg:DI 349))) "tmp.c":10 -1
 (nil))
(insn 14 13 15 2 (set (reg:DI 343 [ D.1463 ])
(reg:DI 353)) "tmp.c":10 -1
 (nil))

And note that in the fifth insn (reg:DI 343) is used uninitialized.  This is
not safe on IA-64, as an uninit register may accidentally have the NaT bit set,
which would then cause a trap.

For this testcase, later optimization passes clean up the mess, and we get
correct code at the end.  However, it is not safe to have a read of an uninit
pseudo on IA-64, as there is no guarantee that a later optimization pass will
accidentally fix it.

Mostly the compiler works because we rarely speculate, and hence we rarely have
registers with the NaT bit set, and hence it is very rare that anyone will ever
trigger this problem.

Andrew Pinski suggests that it is an NRV problem, but I see the same issue with
NRV disabled.

An possible fix might be to force all locals to zero, to ensure that we never
read from an uninit register.

I no longer have access to IA-64 hardware at home or at work.  There is no
IA-64 hardware in the compile farm either.  I also no longer care whether this
issue gets addressed.

[Bug tree-optimization/55748] compile eror when -fprefetch-loop-arrays is added , while everything goes well without the option.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Gallager  ---
(In reply to Richard Biener from comment #7)
> Note that GCC 4.4.0 is no longer maintained, please update to at least GCC
> 4.6.3.

Reporter never got back about updating; closing due to lack of response

[Bug lto/54856] Corrupted LTO type merging

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to Richard Biener from comment #3)
> Which revision was that with?  Doesn't seem to reproduce for me.

Closing due to lack of answer and unreproducability

[Bug rtl-optimization/47379] fwprop1 generates bad codes for x86-64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #7 from H.J. Lu  ---
X32 has switched to 32-bit Pmode by default in GCC 4.8.  This is no longer
an issue.

[Bug tree-optimization/81571] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes (internal compiler error: in as_a, at is-a.h:192)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||x86_64-pc-linux-gnu
  Component|c   |tree-optimization
Version|unknown |8.0
   Target Milestone|--- |8.0
Summary|ICE at -O3 on   |[8 Regression] ICE at -O3
   |x86_64-linux-gnu in both|in both 32-bit and 64-bit
   |32-bit and 64-bit modes |modes (internal compiler
   |(internal compiler error:   |error: in as_a, at
   |in as_a, at is-a.h:192) |is-a.h:192)

[Bug lto/48005] program using libgloss fails to link when built with -flto

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> What's the state on the 4.7 branch with recent binutils?

4.7.0 branch is closed, closing this bug too since it's so old and marked as
WAITING

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[postmas...@aiscientific-com.bounceio.net]

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

--- Comment #10 from postmas...@aiscientific-com.bounceio.net ---
Created attachment 41841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41841=edit
attachment-54311-1.eml

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[postmas...@aiscientific-com.bounceio.net]

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

--- Comment #9 from postmas...@aiscientific-com.bounceio.net ---
   [IMAGE]

   There was a problem delivering your email to:


   alf.la...@aiscientific.com


   -

   WHAT HAPPENED?

   The domain name of the email address is not valid.

   -

   WHAT CAN YOU DO?

   Check the "aiscientific.com" part of the email address for
   misspellings or missing letters. (If you find an error, you might need
   to correct it in your contacts list or address book too.)

   If necessary, contact your recipient another way (e.g., phone or text
   message) to confirm their email address.

   Find out more information about this bounce message.[1]

   [IMAGE][2]

   [IMAGE]

   [IMAGE]

   [IMAGE][3]

   [IMAGE][4]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE]

   [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]
   Advertisement | Prefer no ads?[5]

   -

   WHO ARE WE?

   BetterBounces.net works on behalf of various Internet properties to
   give you better information about why your email wasn't delivered. You
   can learn more about us here[6]. You can learn about our privacy
   policies here[7].

   -

   YOU MIGHT LIKE

   [8]

   [9]

   [10]

   Learn more about RevenueStripe...[11]

   RATE THIS EMAIL

   Helpful[12] Not Helpful[13]


   908 Main Street #310, Louisville, Colorado © 2014 betterbounces.net,
   All rights reserved. Get more help[14]

   [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

   1.
https://a.b-io.me/c/Y1lM9w9S1KeX7SWXPn4dzgOzHoT8aQ.gcVzksUNNFlHQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMkXyJ0GluE0jrC6dBxPgEOcD_rjbPA_fmN.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZnZZhABxRZ1.GPlrCAb2xVvz4J3lwrkA1478gTOQr_5hpkEy9FPtj35HT_nFlQ4ws54S9DrtbASNUK147Skv5.8O0_uWEiuOStg9O0vHufy5RTEs9P71azQxHbhGW5VAufkY9o9ANO3jvXiRG1gUNJHQ4GO3oznBlwSAVfTJjze1Cgw0xy5O6LfM11eQELWLpH0Vs8NmgE3MY0TiDO3KU_V7w0eHjri9.twOAjjam3qwexF5mKhqpExhISz9s4aEPdIh5Xy3pfStfC6XkIH.wpYbyhnUqjyBPfwqkU_VGBCBX1H4BcP7L0d
   2.
https://a.b-io.me/c/Y1lM9w9S1KeX7SWXPn4dzgOzHoT8aQ.gcVzksUNNFlHQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMkXyJ0GluE0jrC6dBxPgEOcD_rjbPA_fmN.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZluV4ajfQfxyhHO3MqYA5onmAAdkmLDAJNrGDUjHp72VpHxNoJHvfrslfFHjX5L4yutdOI4_PyQYPP6OLShEg9SAMEPvovvq2AHbrUhtVfdCDmTJvPrmrFgb8KwyXezwQfNMeNpFuTm847tXFHmf8F3o.aI.OrIrngzXV5AQtYukfRWzw2aATcxjROIM7cpT5XvDR4eOuL3_3A4CONqberB_SROVT5mPaHPfFPKs.DXGqEVYZ24p6WFD6f0oeFZE7PzoYLQWYgQD1b34HimA2jsFSr3GUqtU6mHxKC7854IErTOGBpQIUGH
   3.
https://a.b-io.me/c/Y1lM9w9S1KeX7SWXPn4dzgOzHoT8aQ.gcVzksUNNFlHQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMkXyJ0GluE0jrC6dBxPgEOcD_rjbPA_fmN.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZluV4ajfQfxyhHO3MqYA5onmAAdkmLDAJN7oajnH4u1IrqilRf9BAOy5xiIa2tKlBPnMkCcGkJkPcgA56_OSWgOlAhIp6tgwjhaO7AZSO9FvKA42f73sw2HyUEgvd.HurjguehahPZSLJIzDZUJ5kOrV1MGR.Dk11IJPtQ_X.ATaXcguetEUJBeda9ItrafeZNHTMPUQ_HnehmCpbP6BG7.aTv4703HMScNfKYuD6Zg_y9SGxGYSc.ee5GbGdn1gd3yfdUS7ZS1JfLHhxjD_PRHZGfEhPTgJPo9A34en2SkbQ--
   4.
https://a.b-io.me/c/Y1lM9w9S1KeX7SWXPn4dzgOzHoT8aQ.gcVzksUNNFlHQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMkXyJ0GluE0jrC6dBxPgEOcD_rjbPA_fmN.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZluV4ajfQfxyhHO3MqYA5onmAAdkmLDAJMQ.3qnFSj4N38fE31SEoqTf1nxpoSbW4Q8bQ9f77M1jXWZHn7etOdf9mjZ4WefeJ5EKJRRMW4vkNgp0n6DHkcQKKhj6fi.gwWaGRlX5BMMXlZbfmmEVipxnZFC5xprWHo3LnC4yHEAcc9IhrWnm6PTj3vgnMFFcniA6aC5DF1aKP4kj2t_n8arBqxJwu_oRSxf9QE_i1Gu04SEs.bOGhD3SIeV8t6X0rXwul5CB.8KWG8oZ1Ko8gT38KpFPlRgQgV9R_AXD_y9HQ--
   5.
https://a.b-io.me/c/Y1lM9w9S1KeX7SWXPn4dzgOzHoT8aQ.gcVzksUNNFlHQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMkXyJ0GluE0jrC6dBxPgEOcD_rjbPA_fmN.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZmDr7KmBjRYOVAywhgwaaaObOr9x3nBDeDGZ9ASZHAAF2fOcO4meyeBXDi96jqNftz3M_RNaE.JSKKTY4FWMP6jIB_cUtp3SnuLmpPGRhhOZnoMPYRVEkpqPu2Y2eFw2V0Eqkng_SA65573cu0j0pqWhiFPSqibclUKggRtVmy4AESGeT8JcpfbCATwJUM9aW5c7awzSf0xSv9A5_WLm4BPVU1qcO3_IlanT5V1ZbIOw5eLXsoDV52Rp9GAw1WCrbn7tiqNwraQ.sfoK9l5iX9PhIaTQ3E_HwHJbXwRbzhExQb998OLVfqmdIDx4.9SxYhgY35PGobvPqL0ZUil9k3saC8ALHvCejrLkwlnNoLAG4mhy7Y3j6ymXwctOnfjul9m49VB51fnc8F2u5KpnrWedISAEwwb06BTgu7SpOBDydFzHY0dHS1Co4u3.EqxkaIr9tLCZquJmyJHOHTf_MSzHVd04_CUEda2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.14qn7bKQw4SkhiK.TwPcr5YMSvLq3pKqXLPAkyzje2U7sYVQ6wz6YInHU6U2s_XYNmZMJ5GrId0A-
   6.

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #8 from Martin Sebor  ---
I think the problem here is not so much that it's difficult to implement but
rather that there isn't enough interest or motivation in providing a solution
(which is evident from the absence of updates/patches/duplicate requests since
2008).  IMO, the appropriate way to solve the problem is for projects/users to
define a macro in the user namespace (no leading underscores).  With that,
resolving as Won't Fix.

[Bug rtl-optimization/47037] 465.tonto Segmentation Fault in memset with -fcaller-saves (default at -O2 or higher)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #10 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #9)
> Does this work now?

Guess so since the reporter never replied

[Bug sanitizer/55479] gfortran.dg/coarray/registering_1.f90 -fcoarray=lib -O2 -lcaf_single execution test fails with -fsanitize=address

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to Francois-Xavier Coudert from comment #3)
> I can't reproduce that on x86_64-apple-darwin14 (Yosemite), neither with
> trunk, nor 4.9.2, nor 4.8.0. Can anyone test darwin12 or darwin13 to see if
> it's OS-dependent? Or was it fixed throughout?

Guess no one could test

[Bug driver/63869] gcc-4.9.2 make failed

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Does this work now?
> 
> Also can you supply the exact command sequence you used to configure/invoke
> make?

Reporter never replied; closing for being stuck in WAITING for so long

[Bug debug/44664] CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Mark Wielaard from comment #2)
> I think the DW_AT_entry_pc issue was resolved by:
> 
> commit cb18bd3ce42532858cc65a1f20f3d79d5c253dde
> Author: mark 
> Date:   Fri Apr 1 18:24:52 2011 +
> 
> Don't add DW_AT_low_pc if the CU has no associated code.
> 
> * dwarf2out.c (dwarf2out_finish): Don't add low_pc and/or
> high_pc attribute if the CU has no associated code. Only output
> DW_AT_entry_pc for CU if not generating strict dwarf and
> dwarf_version < 4.
> 
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171846
> 138bc75d-0d04-0410-96
> 
> Since comment #1 said "So, from (a) IMHO only the point about DW_AT_entry_pc
> not allowed on CU is valid." Can this issue now be closed?

I guess so

[Bug go/63269] libgo/math test failures in TestLog2

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
URL||https://github.com/golang/g
   ||o/issues/9066
 CC||egallager at gcc dot gnu.org
 Resolution|--- |MOVED

--- Comment #7 from Eric Gallager  ---
(In reply to Dominik Vogt from comment #6)
> (In reply to Ian Lance Taylor from comment #3)
> > First, let me say that this code is in the Go master library and must be
> > fixed there.  It might be more effective to discuss it on the Go issue
> > tracker at http://golang.org/issue.
> 
> --> https://code.google.com/p/go/issues/detail?id=9066

Markings as MOVED upstream then

[Bug rtl-optimization/47379] fwprop1 generates bad codes for x86-64

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to H.J. Lu from comment #5)
> (In reply to comment #4)
> > Can you try after:
> > 2011-12-19  Richard Sandiford  
> > 
> > PR rtl-optimization/42839
> > * fwprop.c (forward_propagate_subreg): Skip the SIGN/ZERO_EXTEND
> > optimization if the source register is already extended.
> 
> GCC 4.7.0 20120131 still does it.

4.7.0 branch is closed now, could you try a branch that's still open now?

[Bug target/38384] shared link/execute fails for cross gcc from linux to target hppa64-hp-hpux11.00

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #51 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #50)
> There was a lot of patch activity for this PR. Is it fixed?

I guess so

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Richard Biener from comment #5)
> Is this still an issue?

Guessing it isn't since the reporter never replied

[Bug other/19815] Documentation change - GCC Internals MODES_TIEABLE_P

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Richard Biener from comment #2)
> Is this still an issue?

Reporter never replied; guess not

[Bug tree-optimization/50824] memset or memcpy on structure prevents SRA

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Biener from comment #1)
> No, I think because it counts as address-taken, not because it escapes.
> 
> Do you have a testcase?  Most memcpys should be folded to a plain assignment
> already, but we don't fold memset to zero to = {} I guess.

No testcase provided; closing since it's been in WAITING so long with no
response

[Bug target/49057] scheduling difference of subs cause 80% performance difference

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Earnshaw from comment #1)
> You haven't said what CPU this is for, what options you used when compiling,
> and you haven't provided a complete testcase.
> 
> Are you *absolutely* sure this is the only difference? because I find that
> hard to believe.  More likely is that the loop has a different alignment, or
> there is some other, secondary, issue that you've exposed.

Reporter never replied; closing

[Bug c/81571] New: ICE at -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes (internal compiler error: in as_a, at is-a.h:192)

[chengniansun at gmail dot com]

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

Bug ID: 81571
   Summary: ICE at -O3 on x86_64-linux-gnu in both 32-bit and
64-bit modes (internal compiler error: in as_a, at
is-a.h:192)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170726 (experimental) [trunk revision 250555] (GCC) 
$ gcc-trunk -O3 small.c
small.c: In function ‘fn1’:
small.c:2:7: warning: type of ‘p1’ defaults to ‘int’ [-Wimplicit-int]
 short fn1(p1) { return p1; }
   ^~~
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:6:5: internal compiler error: in as_a, at is-a.h:192
 int main() {
 ^~~~
0x5c7e8b as_a<gphi*, gimple>
../../gcc-source-trunk/gcc/is-a.h:192
0x5c7e96 as_a<gphi*, gimple>
../../gcc-source-trunk/gcc/is-a.h:192
0x5c7e96 gimple_phi_arg
../../gcc-source-trunk/gcc/gimple.h:4362
0x5c7e96 gimple_phi_arg_def
../../gcc-source-trunk/gcc/gimple.h:4406
0x5ca73e get_initial_defs_for_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:4254
0x5cabc4 vect_create_epilog_for_reduction
../../gcc-source-trunk/gcc/tree-vect-loop.c:4476
0xecf1c0 vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*, _slp_instance*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:6526
0xec072c vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
../../gcc-source-trunk/gcc/tree-vect-stmts.c:8719
0xee2922 vect_schedule_slp_instance
../../gcc-source-trunk/gcc/tree-vect-slp.c:3724
0xee3233 vect_schedule_slp(vec_info*)
../../gcc-source-trunk/gcc/tree-vect-slp.c:3796
0xec87bb vect_transform_loop(_loop_vec_info*)
../../gcc-source-trunk/gcc/tree-vect-loop.c:7614
0xeeada3 vectorize_loops()
../../gcc-source-trunk/gcc/tree-vectorizer.c:745
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ cat small.c
int a, b, c, d;
short fn1(p1) { return p1; }

int fn2(int p1) {}

int main() {
  for (; c; c++)
a |= fn1(1, a) | fn2(b |= d);
  return 0;
}
$

[Bug other/47681] gcc-4.3.2 compilation failed for armv4

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Richard Earnshaw from comment #1)
> Why are you trying to use 4.3.2?  There are a number of more recent compiler
> releases, including many bug fixes to the 4.3 series in 4.3.3, 4.3.4 and
> 4.3.5.
> 
> However, it would make more sense to switch to the 4.5 series, which is
> still being actively maintained.

Reporter never answered; closing

[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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|NEW
 Depends on||81570

--- Comment #18 from H.J. Lu  ---
(In reply to H.J. Lu from comment #17)
> 
> We didn't lose the info. The problem is that create_pseudo_cfg assumes
> INCOMING_FRAME_SP_OFFSET is a constant.

I opened PR 81570.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81570
[Bug 81570] create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a
constant

[Bug debug/81570] New: create_pseudo_cfg assumes that INCOMING_FRAME_SP_OFFSET is a constant

[hjl.tools at gmail dot com]

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

Bug ID: 81570
   Summary: create_pseudo_cfg assumes that
INCOMING_FRAME_SP_OFFSET is a constant
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

There are

@defmac INCOMING_FRAME_SP_OFFSET
A C expression whose value is an integer giving the offset, in bytes,
from the value of the stack pointer register to the top of the stack
frame at the beginning of any function, before the prologue.  The top of
the frame is defined to be the value of the stack pointer in the
previous frame, just before the call instruction.

You only need to define this macro if you want to support call frame
debugging information like that provided by DWARF 2.
@end defmac

It doesn't say that INCOMING_FRAME_SP_OFFSET must be a constant.  There
are

config/stormy16/stormy16.h:#define INCOMING_FRAME_SP_OFFSET
(xstormy16_interrupt_function_p () ? -6 : -4)

But create_cie_data has

create_cie_data (void)
{
  dw_cfa_location loc;
  dw_trace_info cie_trace;

  dw_stack_pointer_regnum = DWARF_FRAME_REGNUM (STACK_POINTER_REGNUM);

  memset (_trace, 0, sizeof (cie_trace));
  cur_trace = _trace;

  add_cfi_vec = _cfi_vec;
  cie_cfi_row = cur_row = new_cfi_row ();

  /* On entry, the Canonical Frame Address is at SP.  */
  memset (, 0, sizeof (loc));
  loc.reg = dw_stack_pointer_regnum;
  loc.offset = INCOMING_FRAME_SP_OFFSET;
  def_cfa_1 ();

and create_pseudo_cfg has

  bool saw_barrier, switch_sections;
  dw_trace_info ti;
  rtx_insn *insn;
  unsigned i;

  /* The first trace begins at the start of the function,
 and begins with the CIE row state.  */
  trace_info.create (16);
  memset (, 0, sizeof (ti));
  ti.head = get_insns ();
  ti.beg_row = cie_cfi_row;
  ti.cfa_store = cie_cfi_row->cfa; <<<  This assumes
INCOMING_FRAME_SP_OFFSET
is constant for different functions.
  ti.cfa_temp.reg = INVALID_REGNUM;
  trace_info.quick_push (ti);

When INCOMING_FRAME_SP_OFFSET changes, the debug info is broken.

[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 #17 from H.J. Lu  ---
(In reply to H.J. Lu from comment #16)
> The problem is in create_cie_data:
> 
>  /* On entry, the Canonical Frame Address is at SP.  */
>   memset (, 0, sizeof (loc));
>   loc.reg = dw_stack_pointer_regnum;
>   loc.offset = INCOMING_FRAME_SP_OFFSET;
>   def_cfa_1 ();
> 
> We lost the function type info with LTO.

We didn't lose the info. The problem is that create_pseudo_cfg assumes
INCOMING_FRAME_SP_OFFSET is a constant.

[Bug tree-optimization/44704] gobject-introspection Error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> A few things.
> We need the preprocessed source as requested by
> http://gcc.gnu.org/bugs.html.  
> Next I notice you are using a GCC provided by freebsd, you should report
> this bug to them really.
> Not to mention 4.2.x is no longer supported, you might want to try a newer
> version first to see if it has already been fixed.

Reporter never got back about trying a newer version; closing

[Bug ada/66437] False Positive warning "Variable is not modified in loop body"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Botcazou from comment #1)
> 4.7.x is not supported anymore, please try more recent versions.  IIRC this
> was fixed at some point.

Closing because it seems the reporter never tried a more recent version

[Bug c/34455] Request warning for casts to _Bool

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #3)
> To be honest, I am not sure whether this is really useful or not for other
> people. And I am not sure whether it is actually possible.
> 
> What I am sure is that there is nobody except you interested in implementing
> it, so if you want to get it done, you will have to work on it (or pay
> someone to do it).
> 
> Meanwhile, I am putting this in WAITING, so it doesn't show up as pending
> confirmation.

Changing to SUSPENDED so people don't close it from being in WAITING for so
long

[Bug c++/33715] Suggest -Wmemleak warning for C++

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #2)
> I don't even know if we would ever want this. And since nobody seems to
> care, I am putting it in WAITING until someone that cares enough steps up.

That sounds more like it should be put in SUSPENDED; WAITING is for when the
reporter needs to provide more information

[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Gallager  ---
(In reply to Kaveh Ghazi from comment #12)
> What remains to be done here?

I guess since no one responded, nothing.

[Bug preprocessor/45599] Remove all code applying to obsolete "#pragma once"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Changing from WAITING to SUSPENDED, that seems more accurate

[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 #16 from H.J. Lu  ---
The problem is in create_cie_data:

 /* On entry, the Canonical Frame Address is at SP.  */
  memset (, 0, sizeof (loc));
  loc.reg = dw_stack_pointer_regnum;
  loc.offset = INCOMING_FRAME_SP_OFFSET;
  def_cfa_1 ();

We lost the function type info with LTO.

[Bug target/35296] init_expr_once suboptimal for Thumb

[egallager at gcc dot gnu.org]

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

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 Jacobowitz from comment #2)
> Sorry, I don't know.

So I guess this can be closed then

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[postmas...@aiscientific-com.bounceio.net]

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

--- Comment #7 from postmas...@aiscientific-com.bounceio.net ---
   [IMAGE]

   There was a problem delivering your email to:


   alf.la...@aiscientific.com


   -

   WHAT HAPPENED?

   The domain name of the email address is not valid.

   -

   WHAT CAN YOU DO?

   Check the "aiscientific.com" part of the email address for
   misspellings or missing letters. (If you find an error, you might need
   to correct it in your contacts list or address book too.)

   If necessary, contact your recipient another way (e.g., phone or text
   message) to confirm their email address.

   Find out more information about this bounce message.[1]

   Learn more about RevenueStripe... [2]

   [3]


   Advertisement | Prefer no ads?[4]

   -

   WHO ARE WE?

   BetterBounces.net works on behalf of various Internet properties to
   give you better information about why your email wasn't delivered. You
   can learn more about us here[5]. You can learn about our privacy
   policies here[6].

   -

   YOU MIGHT LIKE

   [7]

   [8]

   [9]

   Learn more about RevenueStripe...[10]

   -

   RATE THIS EMAIL

   Helpful[11] Not Helpful[12]


   908 Main Street #310, Louisville, Colorado © 2015 betterbounces.net,
   All rights reserved. Get more help[13]

   [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE]

   1.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZnZZhABxRZ1.GPlrCAb2xVvz4J3lwrkA1478gTOQr_5hpkEy9FPtj35HT_nFlQ4ws54S9DrtbASNUK147Skv5.8O0_uWEiuOStg9O0vHufy5RTEs9P71azQxHbhGW5VAufkY9o9ANO3jvXiRG1gUNJHQ4GO3oznBlwSAVfTJjze1Cgw0xy5O6LfM11eQELWLpH0Vs8NmgE3MY0TiDO3KU_V7w0eHjri9.twOAjjam3qwexF5mKhqpExZ6EtABJoSDDk9EPMl52BaZVmKG7WIz5npVsB9rQGdHV96lZPR2BVIO6b0al3Y5l6
   2.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZnMIVOVnnOJ4lOXPoqe3HjCT9ujPR.S.S87O5WgweqPENk8avIY_bkNHzSjXTzBjIE6ZeUMcFnWxjc_0VTozWrAMvkY23PuyAAUxLPT_9Ws0CzGSkligKaJ4M0VvESxqgfEEYvdrsXesMceBPXMZwpElJb31_zx8K8ejbbeQ3AaOEPhX9R5a_6guQLm1cKeJ6S1cfkiVDfPQMbECjzZ29.9IXGNq.y0hb_hFWGduKelhRG3p5DktWQGZtYfj3pPAi0Ovw5XBQ7mtyIq0YxQuiVgxHW69pHbvU_0zhgaUCFBhw--
   3.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZkqPN_gm5PBHRNLqr7Q8W37FO96c74pQ0SlSYFZWjSOujJOO7fjBjeTzdDL0qqqeuZtDGMCGMsuCHGj6DtEHMd5obLUEC6i2HPby1SmWMxiN.J1xgOyz_KFE.IA89Tqpzilz9GH27X5pzMvhRVDJD1zU8TPQmkWmLJ80SeeJDzx9w_MKwqTTTxLPi8mmk6gmc8ww9rhx299hRWxcFyiRzHeCT7UPl.wE2l3ILnrRFCQXnWvSLa2n3mTR0zD1EPh53oZgqWz_gRu.yoyl1uTr4ISuUr4B8qzqk5WbuGl1uk.jOX8XyReHDZsCA.teU.k6HWNmofwLhXg9aPfD441AGls
   4.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZmDr7KmBjRYOVAywhgwaaaObOr9x3nBDeDGZ9ASZHAAF7lRL4TYkPGT8CEB__Nr9VUa8iVf77HXmKk7HIKnRqPQ9oK5Uz87vzmLmpPGRhhOZnoMPYRVEkpqPu2Y2eFw2V0Eqkng_SA65573cu0j0pqWhiFPSqibclUKggRtVmy4AESGeT8JcpfbCATwJUM9aW6IB8_2_qPo0P5itFRZu6qAJj6KJQfYtYkSeAKIAFgh79z4XSPSnRppp9GAw1WCrbn7tiqNwraQ.sfoK9l5iX9PhIaTQ3E_HwHJbXwRbzhExQb998OLVfqmdIDx4.9SxYhgY35PGobvPqL0ZUil9k3saC8ALHvCejrLkwlnNoLAG4mhy7Y3j6ymXwctOnfjul.nAzQnEBvdF2S8UJfRZuMvliiBhnqByyZee_KcuTpvo8wVfgwsEPOu7Hy2spl4Y5RjIJkgOTMDue9ZDYcakyE4HVd04_CUEda2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.14qn7bKQw4Snr5rpEiUJ9X7g3C7tCPA0FfL8Y7wt.eqkU95PuaXEn.0r1kkaQRbgj.40KR5wNun0-
   5.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZnPIFYhqRJZzH5Rg1hLC21dmG9RxqpLHmS2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.14qn7bKQw4Snr5rpEiUJ9X7g3C7tCPA0FfL8Y7wt.eqkU95PuaXEn.0r1kkaQRbgj.40KR5wNun0-
   6.
https://a.b-io.me/c/Y1lM9w9S1Kc.QUfnJa7xcEOcTZ49xueuPRXcF1mTTC7QaWlkIsfqBNRgrwhzFkMcrwIXvcetvsbk_VHUbG1uUjxtD1.vszWNbh48gr0Cetc_MU8C9_RDMgGoelCU5EUoDQC751PGspIQzctdojckPt.AB.gVJW_oMX8r6IcThHBNJW92YsgE1jth7GpaA9CD.t4yph5G4ZnZZhABxRZ1.GPlrCAb2xVvz4J3lwrkA176TDp46HPht0mGQsKeSgRyeGg6LxGAjf8JPtQ_X.ATaXcguetEUJBeda9ItrafeZNHTMPUQ_HnehmCpbP6BG7.KjKXW5OvghK5SvgHyrOqTlZu4aXW6T_M5fxfJF4cNmwID_15T_TodY2ah.AuFeD1o98PjjUAaWw-
   7.

[Bug preprocessor/30867] Can we have a new __DATE__ which is sortable, eg YYYY-MM-DD

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED
 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
Changing from WAITING to SUSPENDED; WAITING is for when the reporter needs to
provide additional information, and I don't think that's relevant here

[Bug target/32838] gcc generates incorrect trampoline code in thumb mode

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Gallager  ---
(In reply to Matthias Pfaller from comment #6)
> Subject: Re:  gcc generates incorrect trampoline code in
>  thumb mode
> 
> sam at gcc dot gnu dot org wrote:
> > --- Comment #5 from sam at gcc dot gnu dot org  2009-03-19 10:15 ---
> > Matthias,
> >
> > I think Laurent was asking for an executable test case, which fails before 
> > your
> > test and succeeds after, so that it can enter the regression suite.
> >
> >
> >   
> We are using the compiler strictly for our embedded systems (software
> running on the bare hardware). Sorry, I cannot provide you an
> exececutable testcase.
> 
> Regards, Matthias

Well since that was presumably what this bug was marked as WAITING for, I guess
I can close it then

[Bug web/81560] Error in C documentation regarding min/max substitute macros MIN/MAX

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Jonathan Wakely  ---
GCC 3.4 is unsupported and unmaintained, so nobody's going to bother to fix its
documentation now. Those extensions were removed from G++ many yeas ago anyway.

[Bug go/81548] "make distclean" does not clean all of gotools/

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Well, distclean does  rm -rf $(TARGET_SUBDIR);  which takes care of a
lot (in the root generated Makefile).  Everything else is in gcc/, not
sure where that is deleted; gotools/ has the only .sum/.log outside of
those two dirs, it seems.

[Bug libstdc++/81567] New test case 27_io/basic_fstream/53984.cc fails on powerpc64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|powerpc64*-*-*  |
  Component|other   |libstdc++
   Host|powerpc64*-*-*  |
   Target Milestone|--- |8.0
  Build|powerpc64*-*-*  |

[Bug other/81567] New test case 27_io/basic_fstream/53984.cc fails on powerpc64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Fixed by r250594

[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Wed Jul 26 22:06:13 2017
New Revision: 250594

URL: https://gcc.gnu.org/viewcvs?rev=250594=gcc=rev
Log:
PR libstdc++/53984 fix failing test

PR libstdc++/53984
* testsuite/27_io/basic_fstream/53984.cc: Fix test.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/27_io/basic_fstream/53984.cc

[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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #41834|0   |1
is obsolete||

--- Comment #15 from H.J. Lu  ---
Created attachment 41839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41839=edit
A patch

-g -O2 -flto generates:

Dump of assembler code for function fn:
   0x00400550 <+0>: push   %rdi
   0x00400551 <+1>: sub$0x8,%rsp
   0x00400555 <+5>: cmpq   $0x12345670,0x10(%rsp)
   0x0040055e <+14>:jne0x400430 
=> 0x00400564 <+20>:cmpq   $0x12345671,0x18(%rsp)

with debug info:

0084 0018 0058 FDE cie=0030
pc=00400550..004005b7
  DW_CFA_advance_loc: 1 to 00400551
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r5 (rdi) at cfa-16
  DW_CFA_advance_loc: 4 to 00400555
  DW_CFA_def_cfa_offset: 24
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

-g -O2 generates:

   0x00400550 <+0>: push   %rdi
   0x00400551 <+1>: sub$0x8,%rsp
   0x00400555 <+5>: cmpq   $0x12345670,0x10(%rsp)
   0x0040055e <+14>:jne0x400430 
   0x00400564 <+20>:cmpq   $0x12345671,0x18(%rsp)

with debug info:

0070 0018 0044 FDE cie=0030
pc=00400550..004005b7
  DW_CFA_advance_loc: 1 to 00400551
  DW_CFA_def_cfa_offset: 24 
  DW_CFA_offset: r5 (rdi) at cfa-24
  DW_CFA_advance_loc: 4 to 00400555
  DW_CFA_def_cfa_offset: 32 
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

Somehow -flto -O2 generates the incorrect debug info.

[Bug go/81548] "make distclean" does not clean all of gotools/

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Fixed, probably.

[Bug go/81548] "make distclean" does not clean all of gotools/

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Wed Jul 26 22:01:36 2017
New Revision: 250593

URL: https://gcc.gnu.org/viewcvs?rev=250593=gcc=rev
Log:
PR go/81548
* Makefile.am (MOSTLYCLEANFILES): Add *.sent.
* Makefile.in: Rebuild.

Modified:
trunk/gotools/ChangeLog
trunk/gotools/Makefile.am
trunk/gotools/Makefile.in

[Bug c++/71570] [6/7/8 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Jul 26 21:46:22 2017
New Revision: 250591

URL: https://gcc.gnu.org/viewcvs?rev=250591=gcc=rev
Log:
/cp
2017-07-26  Paolo Carlini  

PR c++/71570
* lambda.c (add_capture): Early return if we cannot capture by
reference.

/testsuite
2017-07-26  Paolo Carlini  

PR c++/71570
* g++.dg/cpp0x/lambda/lambda-ice17.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice17.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/71570] [6/7 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

Summary|[6/7/8 regression] ICE on   |[6/7 regression] ICE on
   |invalid variable capture in |invalid variable capture in
   |cxx_incomplete_type_diagnos |cxx_incomplete_type_diagnos
   |tic, at cp/typeck2.c:551|tic, at cp/typeck2.c:551

--- Comment #10 from Paolo Carlini  ---
Fixed in trunk so far.

[Bug go/81548] "make distclean" does not clean all of gotools/

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
That's a very good question.  I don't know; I tried to fix it but gave up.
All I know is gotools/ is the only did not removed by distclean, because
the two .sent files are left.

[Bug debug/81569] New: gcc.guality tests fail with -flto option

[sje at gcc dot gnu.org]

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

Bug ID: 81569
   Summary: gcc.guality tests fail with -flto option
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-*-*
Target: aarch64-*-*
 Build: aarch64-*-*

Created attachment 41838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41838=edit
Test case (same as gcc.dg/guality/pr45882.c)

A number of gcc.guality tests like gcc.dg/guality/pr45882.c fail on aarch64
when compiled with -flto.  The tests work when compiled with -O0 -g or with -O2
-g, but fail with -O2 -flto -g.

I have attached the source of gcc.dg/guality/pr45882.c to this test, if you
compile it and debug it and give gdb the following commands:

break 16
run
print e
quit

gdb will print 142 when debugging a program that was compiled without -flto
and 0 when debugging a program compiled with -flto.

[Bug go/81548] "make distclean" does not clean all of gotools/

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
You are saying that the files gotools.log.sent and gotools.sum.sent should be
removed by "make distclean" (or some clean target) in gotools/Makefile.am?

I couldn't find any other clean targets in the GCC tree that remove files by
those names.  What is special about gotools?

[Bug c/81568] attribute always_inline honored even after attribute noinline

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, wrong-code
   Severity|normal  |minor

--- Comment #1 from Martin Sebor  ---
The cause of the problem is in the validation for these two attributes being
done in two places: one in handle_always_inline_attribute and
handle_noinline_attribute in c-attribs.c, and another in
diagnose_mismatched_attributes.  The former rejects the attribute if it's found
to conflict with the other on the same declaration, but it doesn't detect
conflicts across declarations.  The latter does detect those conflicts but it
doesn't reject them.  As a result, the same problem gets handled differently in
the two situations.

[Bug c/81568] New: attribute always_inline honored even after attribute noinline

[msebor at gcc dot gnu.org]

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

Bug ID: 81568
   Summary: attribute always_inline honored even after attribute
noinline
   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 detects and warns about the obviously nonsensical combination of attribute
always_inline and noinline on the same function.  That's good so far as it goes
but there are a couple of minor problems with how GCC treats this situation:

When the conflicting attributes appear on distinct declarations of the same
function (the more likely case of the problem) it doesn't indicate which of the
two GCC accepts.  When the conflicting attributes appear the same declaration
of a function the warning makes it clear that it's the second of the two
attributes that's ignored.  Based on this one would expect the same to be true
in the first case (distinct declarations) but, as it turns out (and as the test
case below shows), that doesn't appear to be the case. 

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic -o/dev/stdout x.c
int __attribute__ ((noinline)) f (int);
int __attribute__ ((always_inline)) f (int);

int f (int i) { return i > 1 ? i * f (i - 1) * f (i - 2) : i > 0 ? i * f (i -
1) : 1; }

int f1 (void)
{
  return f (123);
}

int __attribute__ ((always_inline, noinline)) g (int);
.file   "x.c"
x.c:2:37: warning: declaration of ‘f’ with attribute ‘always_inline’ follows
declaration with attribute ‘noinline’ [-Wattributes]
 int __attribute__ ((always_inline)) f (int);
 ^
x.c:1:32: note: previous declaration of ‘f’ was here
 int __attribute__ ((noinline)) f (int);
^
x.c:11:1: warning: ‘noinline’ attribute ignored due to conflict with attribute
‘always_inline’ [-Wattributes]
 int __attribute__ ((always_inline, noinline)) g (int);
 ^~~
x.c: In function ‘f1’:
x.c:4:5: error: inlining failed in call to always_inline ‘f’: function not
inlinable
 int f (int i) { return i > 1 ? i * f (i - 1) * f (i - 2) : i > 0 ? i * f (i -
1) : 1; }
 ^
x.c:8:10: note: called from here
   return f (123);
  ^~~

[Bug other/81567] New: New test case 27_io/basic_fstream/53984.cc fails on powerpc64

[seurer at gcc dot gnu.org]

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

Bug ID: 81567
   Summary: New test case 27_io/basic_fstream/53984.cc fails on
powerpc64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This fails on powerpc64 both BE and LE.  It throws the assertion on line 29. 
Tested on a power8 system.

make -k check RUNTESTFLAGS=conformance.exp=27_io/basic_fstream/53984.cc
. . .
Running
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp
...
FAIL: 27_io/basic_fstream/53984.cc execution test

=== libstdc++ Summary ===

# of expected passes1
# of unexpected failures1



spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/install/gcc-test/powerpc64-unknown-linux-gnu/lib/ -isystem
/home/seurer/gcc/install/gcc-test/powerpc64-unknown-linux-gnu/include -isystem
/home/seurer/gcc/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/27_io/basic_fstream/53984.cc
-include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtestc++.a -Wl,--gc-sections
-L/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./53984.exe
PASS: 27_io/basic_fstream/53984.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/gcc/32::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test/gcc/32:/home/seurer/gcc/install/gcc-6.3.0/lib64
spawn [open ...]
/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/27_io/basic_fstream/53984.cc:29:
void test01(): Assertion 'in.bad()' failed.
FAIL: 27_io/basic_fstream/53984.cc execution test

[Bug target/80180] Incorrect codegen from rdseed intrinsic use

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #5 from Florian Weimer  ---
Patch was posted here: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01349.html

[Bug c/81566] New: attribute aligned with no argument accepted on functions

[msebor at gcc dot gnu.org]

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

Bug ID: 81566
   Summary: attribute aligned with no argument accepted on
functions
   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: ---

The function form of attribute aligned is documented to take an argument but
not without:

  aligned (alignment)
  This attribute specifies a minimum alignment for the function, measured
in bytes.

In addition, the manual states that

  You cannot use this attribute to decrease the alignment of a function, only
to increase it. 

However, GCC accepts the attribute even without an argument, and it also
accepts declarations that appear to decrease the alignment of a function only
to proceed to silently ignore them.  See the test case below.

The manual should be updated and the effect of the attribute without an
argument (or GCC changed to reject it), and the attribute handler should be
enhanced to issue -Wattributes for attribute arguments that violate the
requirements outlined in the manual.

$ cat x.c && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -O2 -S -Wall
-Wextra -Wpedantic -o/dev/stdout x.c
int __attribute__ ((aligned)) f (void);

int __attribute__ ((aligned (4))) f (void);
int __attribute__ ((aligned (2))) f (void);
int __attribute__ ((aligned (1))) f (void);
int __attribute__ ((aligned (0))) f (void);

int f (void) { return 0; }

int __attribute__ ((aligned (2))) g (void);
int __attribute__ ((aligned (1))) g (void);
int __attribute__ ((aligned (0))) g (void);

int g (void) { return 0; }

.file   "x.c"
.text
.align 16
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.size   f, .-f
.align 2
.globl  g
.type   g, @function
g:
.LFB1:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE1:
.size   g, .-g
.ident  "GCC: (GNU) 8.0.0 20170717 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug target/81563] [8 Regression] Callee-saved registers are restored incorrectly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/81563] [8 Regression] Callee-saved registers are restored incorrectly

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Jul 26 19:13:23 2017
New Revision: 250587

URL: https://gcc.gnu.org/viewcvs?rev=250587=gcc=rev
Log:
x86: Properly check saved register CFA offset

X86 prologue saves register at CFA offset.  Since its location on stack
is computed as CFA - its CFA_OFFSET, CFA_OFFSET points the end of the
saved register area on stack.  This patch updates sp_valid_at and
fp_valid_at to properly check saved register CFA offset.

gcc/

PR target/81563
* config/i386/i386.c (sp_valid_at): Properly check CFA offset.
(fp_valid_at): Likewise.

gcc/testsuite/

PR target/81563
* gcc.target/i386/pr81563.c: New test

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81563.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81563] [8 Regression] Callee-saved registers are restored incorrectly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com
   Target Milestone|--- |8.0
Summary|Callee-saved registers are  |[8 Regression] Callee-saved
   |restored incorrectly|registers are restored
   ||incorrectly

--- Comment #1 from H.J. Lu  ---
This was introduced by r248029.

[Bug target/81563] [8 Regression] Callee-saved registers are restored incorrectly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

[Bug c/45784] gcc OpenMP - error: invalid controlling predicate

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
Confirmed, still produces the error with gcc8

[Bug c/54162] Please accept static global anonymous unions or structs as an extension

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #6 from Eric Gallager  ---
(In reply to Josh Triplett from comment #5)
> Visual C (2017 at least), clang, and as far as I can tell, current GCC.
> 
> I don't know at what point this started working, but it seems to work now.

Oh OK, closing as FIXED then.

[Bug c/81565] New: confusion between function and type attributes

[msebor at gcc dot gnu.org]

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

Bug ID: 81565
   Summary: confusion between function and type attributes
   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: ---

Attributes noreturn and warn_unused_result are both documented to apply to
functions and are not documented to apply to types.  However, as the following
test case shows, while attribute noreturn is, in fact, a part of a function
declaration only and not its type, attribute warn_unused_result is also part of
the function's type and transfers to function pointers along with it.  This
subtlety leads to confusion, surprising results, and bug reports about missing
or bogus warnings.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
int __attribute__ ((noreturn)) f0 (void);

int g0 (void)
{
  __typeof__ (f0) *pf = f0;

  pf ();

}  // -Wreturn-type implies "noreturn" isn't part of f0's type.

int __attribute__ ((warn_unused_result)) f1 (void);

int f2 (void);

void g1 (void)
{
  __typeof__ (f1) *pf = f1;

  pf ();   // -Wunused-result implies "warn_unused_result" is part of f1's type

  pf = f2;

  pf ();   // bogus -Wunused-result
}

x.c: In function ‘g0’:
x.c:9:1: warning: control reaches end of non-void function [-Wreturn-type]
 }  // -Wreturn-type implies "noreturn" isn't part of f0's type.
 ^
x.c: In function ‘g1’:
x.c:19:3: warning: ignoring return value of function declared with attribute
warn_unused_result [-Wunused-result]
   pf ();   // -Wunused-result implies "warn_unused_result" is part of f1's
type
   ^
x.c:23:3: warning: ignoring return value of function declared with attribute
warn_unused_result [-Wunused-result]
   pf ();   // bogus -Wunused-result
   ^

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
-Werror=return-type might not work but -Werror -Wreturn-type does:

$ /usr/local/bin/gcc -c -Werror=return-type 55976.c
55976.c: In function ‘t’:
55976.c:3:20: warning: ‘return’ with a value, in function returning void
 void t () { return 1; } // does not error
^
55976.c:3:6: note: declared here
 void t () { return 1; } // does not error
  ^
55976.c: In function ‘b’:
55976.c:4:12: warning: ‘return’ with no value, in function returning non-void
 int b () { return; }// does
^~
55976.c:4:5: note: declared here
 int b () { return; }// does
 ^
$ /usr/local/bin/gcc -c -Werror -Wreturn-type 55976.c
55976.c: In function ‘t’:
55976.c:3:20: error: ‘return’ with a value, in function returning void
[-Werror]
 void t () { return 1; } // does not error
^
55976.c:3:6: note: declared here
 void t () { return 1; } // does not error
  ^
55976.c: In function ‘b’:
55976.c:4:12: error: ‘return’ with no value, in function returning non-void
[-Werror]
 int b () { return; }// does
^~
55976.c:4:5: note: declared here
 int b () { return; }// does
 ^
cc1: all warnings being treated as errors
$

Confirming on the basis that -Werror=return-type should work just as well as
-Werror -Wreturn-type.

[Bug c/54162] Please accept static global anonymous unions or structs as an extension

[josh at joshtriplett dot org]

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

--- Comment #5 from Josh Triplett  ---
Visual C (2017 at least), clang, and as far as I can tell, current GCC.

I don't know at what point this started working, but it seems to work now.

[Bug c/55096] Wconversion-nul does not work in C

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
Confirmed, gcc is silent even with -Wc++-compat added! 

$ /usr/local/bin/gcc -c -Wall -Wextra -Wconversion -Wc++-compat 55096.c
$

What's worse is that with g++, the -Wconversion-null warning is now an error:

$ /usr/local/bin/g++ -c -Wall -Wextra -Wconversion 55096.c
55096.c: In function ‘bool* ProcessRequest(bool*)’:
55096.c:5:17: error: cannot convert ‘bool’ to ‘bool*’ in assignment
   charge_acct = false;
 ^
$

So this means that this is also an issue of -Wc++-compat failing to catch
something that would be an error in C++.

[Bug c/54787] Inconsistent -Wtype-limits warning for different-sized bitfields

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail||4.4.3, 4.6.3, 4.7.2

--- Comment #3 from Eric Gallager  ---
I can't reproduce this bug; none of these produce any warnings for me:

$ /usr/local/bin/gcc -c -Wtype-limits 28336.c
$ /usr/local/bin/gcc -c -Wall -Wextra -Wtype-limits 28336.c
$ /usr/local/bin/gcc -c -m32 -Wall -Wextra -Wtype-limits 28336.c
$ /usr/local/bin/gcc -c -m64 -Wall -Wextra -Wtype-limits 28336.c
$ 

Assuming it was fixed at some point.

[Bug c++/67054] Constructor inheritance with non-default constructible members

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Jul 26 17:39:26 2017
New Revision: 250583

URL: https://gcc.gnu.org/viewcvs?rev=250583=gcc=rev
Log:
PR c++/67054 - Inherited ctor with non-default-constructible members
* method.c (walk_field_subobs) Consider member initializers (NSDMIs)
when deducing an inheriting constructor.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c

[Bug c/54433] bogus -Wmissing-format-attribute warnings when "first to check" is wrong

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
  Known to work||8.0
 Resolution|--- |FIXED
  Known to fail||4.3.6, 4.7.0

--- Comment #1 from Eric Gallager  ---
I can't reproduce this bug; neither of these produce any warnings for me:

$ /usr/local/bin/gcc -c -Wmissing-format-attribute 54433.c
$ /usr/local/bin/gcc -c -Wall -Wformat=2 -Wextra -Wunused
-Wmissing-format-attribute 54433.c
$

Assuming it was fixed.

[Bug c/54162] Please accept static global anonymous unions or structs as an extension

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
(In reply to Josh Triplett from comment #3)
> How odd.  Quite a number of sources seem to suggest that C11 allows this. 
> But in any case, several other compilers *do* allow this syntax; thus,
> reopening this and turning it into a request for an extension.

Which other compilers?

[Bug tree-optimization/80724] [8 Regression] gcc.target/aarch64/pr62178.c failed because of r247885

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-26
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|gcc.target/aarch64/pr62178. |[8 Regression]
   |c failed because of r247885 |gcc.target/aarch64/pr62178.
   ||c failed because of r247885
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
The vectorized loop looks like:
.L7:
ldr w2, [x1, 4]!
ldr q1, [x0], 124
fmovs3, w2
mla v0.4s, v1.4s, v3.s[0]
cmp x0, x3
bne .L7


Which is worse than before in GCC 7:
.L7:
ld1r{v1.4s}, [x1], 4
ldr q2, [x0], 124
mla v0.4s, v2.4s, v1.4s
cmp x0, x2
bne .L7

[Bug c/43673] Incorrect warning: use of 'D' length modifier with 'a' type character

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
Confirmed, although for me it also prints an additional error about my target
lacking support for decimal floating point:

$ /usr/local/bin/gcc -Wall -c 43673.c
43673.c: In function ‘main’:
43673.c:7:2: error: decimal floating point not supported for this target
  _Decimal64 e = 0.1dd;
  ^~
43673.c:9:13: warning: use of ‘D’ length modifier with ‘a’ type character has
either no effect or undefined behavior [-Wformat=]
  printf ("%Da\n", e);
 ^

[Bug middle-end/81564] ICE in group_case_labels_stmt()

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-26
 CC||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Peter Bergner  ---
Mine.  Testing a patch.

[Bug middle-end/81564] New: ICE in group_case_labels_stmt()

[bergner at gcc dot gnu.org]

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

Bug ID: 81564
   Summary: ICE in group_case_labels_stmt()
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Yet another fallout from the switch changes.

bergner@pike:~/gcc/BUGS/$ cat bug.i
struct a {
int b;
int c;
};

void
foo (void)
{
  struct a *e;
  switch (e->c)
  {
case 7:
case 3:
  if (__builtin_expect(!0, 0))
__builtin_unreachable();
  }
}
bergner@pike:~/gcc/BUGS/$
/home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-debug/gcc -O2 -S bug.i
during GIMPLE pass: cfg
bug.i: In function ‘foo’:
bug.i:7:1: internal compiler error: Segmentation fault
 foo (void)
 ^~~
0x10e70e77 crash_signal
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/toplev.c:338
0x10ee1508 group_case_labels_stmt(gswitch*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfg.c:1740
0x10edf98b end_recording_case_labels()
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfg.c:1255
0x10f0b9af cleanup_tree_cfg_1
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfgcleanup.c:748
0x10f0bdab cleanup_tree_cfg_noloop
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfgcleanup.c:843
0x10f0bfcf cleanup_tree_cfg()
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfgcleanup.c:899
0x10edcbcf execute_build_cfg
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfg.c:405
0x10edcca7 execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/tree-cfg.c:434
Please submit a full bug report,
with preprocessed source if appropriate.

Program received signal SIGSEGV, Segmentation fault.
0x10ee1508 in group_case_labels_stmt (stmt=0x3fffb59e7940)
at /home/bergner/gcc/gcc-fsf-mainline-pr72804-base/gcc/tree-cfg.c:1740
1740  if (EDGE_COUNT (base_bb->succs) == 0
(gdb) p base_bb
$2 = (basic_block) 0x0
(gdb) p base_case
$1 = (tree) 0x3fffb5a8
(gdb) ptree base_case
 >
side-effects
arg 0 
constant 7>
arg 2 
ignored VOID file (null) line 0 col 0
align 1 context >
bug.i:12:5 start: bug.i:12:5 finish: bug.i:12:8>
(gdb) p CASE_LABEL(base_case)
$3 = (tree) 0x3fffb5a50380
(gdb) ptree $3
 >
ignored VOID file (null) line 0 col 0
align 1 context >
(gdb) pcfg
;; basic block 2, loop depth 0
;;  pred:   ENTRY
;;  succ:   5
;; basic block 5, loop depth 0
;;  pred:   2
;;  succ:   EXIT
(gdb) pbb 2
;; basic block 2, loop depth 0
;;  pred:   ENTRY
_1 = e->c;
switch (_1)  [INV] [count: INV], case 3: , case 7: >
;;  succ:   5

(gdb) pbb 5
;; basic block 5, loop depth 0
;;  pred:   2
 [0.00%] [count: INV]:
return;
;;  succ:   EXIT

So it seems the block that the case labels point to has been deleted, which is
confirmed in the bug.i.011t.cfg dump file:

Removing basic block 3
;; basic block 3, loop depth 0
;;  pred:  
 [0.00%] [count: INV]:
;;  succ:   4


Removing basic block 4
;; basic block 4, loop depth 0
;;  pred:   2
 [0.00%] [count: INV]:
__builtin_unreachable ();
;;  succ:  


EMERGENCY DUMP:

foo ()
{
  struct a * eD.2678;

;;   basic block 2, loop depth 0, freq 0, maybe hot
;;prev block 0, next block 5, flags: (NEW, REACHABLE)
;;pred:   ENTRY (FALLTHRU)
  _1 = eD.2678->cD.2674;
  switch (_1)  [INV] [count: INV], case 3: , case 7: >
;;succ:   5

;;   basic block 5, loop depth 0, freq 0, maybe hot
;;prev block 2, next block 1, flags: (NEW, REACHABLE)
;;pred:   2
 [0.00%] [count: INV]:
  return;
;;succ:   EXIT

}

In this base, we should probably discard these case statements similarly to how
we discard cases that have the same label as the default case.

[Bug c/51971] unclear/unverified restrictions on attribute((const|pure))

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||documentation
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
Related: bug 18487. They seem different enough to leave as separate bugs
though.

[Bug target/81563] New: Callee-saved registers are restored incorrectly

[hjl.tools at gmail dot com]

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

Bug ID: 81563
   Summary: Callee-saved registers are restored incorrectly
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86

[hjl@gnu-6 xxx]$ cat x.i
extern void bar (long long int, int);

long long int
fn1 (long long int x)
{
  bar (x, 1);
  return x;
}
[hjl@gnu-6 xxx]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -Wall
-maccumulate-outgoing-args  -m32 -mincoming-stack-boundary=2
-mpreferred-stack-boundary=3 -mregparm=3 -mtune-ctrl=epilogue_using_move -S -o
x.s x.i
[hjl@gnu-6 xxx]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl  fn1
.type   fn1, @function
fn1:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl$1, %ecx
movl%esp, %ebp
.cfi_def_cfa_register 5
pushl   %edi
pushl   %esi
.cfi_offset 7, -12
.cfi_offset 6, -16
movl%edx, %edi
movl%eax, %esi
andl$-8, %esp
callbar
movl%esi, %eax
movl%edi, %edx
movl(%esp), %esi  <<<<<<<<< We can't restore %esi with %esp.
movl-4(%ebp), %edi
leave
.cfi_restore 5
.cfi_restore 7
.cfi_restore 6
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size   fn1, .-fn1
    .ident  "GCC: (GNU) 8.0.0 20170726 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 xxx]$

[Bug debug/81562] New: GDB cannot display long double register variable values

[sje at gcc dot gnu.org]

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

Bug ID: 81562
   Summary: GDB cannot display long double register variable
values
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---
  Host: aarch64-*-*
Target: aarch64-*-*
 Build: aarch64-*-*

Created attachment 41837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41837=edit
gdb.base/store.c test case

The GDB test case gdb.base/store.c fails with GCC 5.4.0 and above, it passes
with GCC 4.8.0.  If the register keyword is removed from the test case, it
works.

To reproduce the problem, compile store.c with -g, and do these gdb commands:

b wack_doublest
r
n
print l
print r

With GCC 4.8.0 both l and r can be printed (-1 and -2), with GCC 5.4.0 or
Top-of-tree (8.0), gdb will print l but say that r has been 

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||meta-bug
 Depends on||67353, 7651
Summary|Some warnings are not   |[meta-bug] Some warnings
   |linked to diagnostics   |are not linked to
   |options |diagnostics options

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #3)
> There are two cases:
> 
> * Warnings that are controlled by an option (e.g., Wall) but do not show up
> in -fdiagnostics-show-option. These are obvious bugs and normally trivial to
> fix: there is already an -Wsomething option controlling them but the warning
> call is done with warning (0, "warning") instead of warning (OPT_Wsomething,
> "warning"). If you provide me a list of those that you can find, I will fix
> them.
> 
> * Warnings that are not controlled by any option and are enabled by default.
> These cases are not clear-cut because we do not want millions of options, so
> we would prefer to group related warnings under the same option. Also,
> proposing a good -Wname for the option is always controversial. I don't
> think there are many of these, but a list of the worst offenders would also
> help.

Making this a meta-bug; will add relevant bugs as dependencies to this one as I
find them. That can count as a list.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug 7651] Define -Wextra strictly in terms of other warning flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67353
[Bug 67353] [avr] Option-ize Warning "appears to be a misspelled signal /
interrupt handler"

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[derodat at adacore dot com]

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

--- Comment #7 from Pierre-Marie de Rodat  ---
(In reply to John Marino from comment #6)
> It looks like the release of 7.2 is upcoming.  It would be really great if
> this ICE/Regression is addressed for that release.  Is there any way to
> raise the visibility on this issue to avoid missing a fix for 7.2?

I would be all for it. For the record, I sent a PING for my patch on
gcc-patches@ on Monday:
.

[Bug ada/79542] [7/8 regression] ICE in add_gnat_descriptive_type_attribute

[gnugcc at marino dot st]

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

--- Comment #6 from John Marino  ---
It looks like the release of 7.2 is upcoming.  It would be really great if this
ICE/Regression is addressed for that release.  Is there any way to raise the
visibility on this issue to avoid missing a fix for 7.2?

[Bug fortran/79854] diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-07-26
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
AFAICT this internal error has never triggered. If someone can come with a test
for it, this would be nice.

[Bug libfortran/78449] compile time ieee_support_halting is not correct on arm and aarch64 ( FAIL: gfortran.dg/ieee/ieee_8.f90 -Os execution test )

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Ramana Radhakrishnan from comment #2)
> Fixed then ?

Guess so; closing as such.

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

--- Comment #10 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul 26 14:58:42 2017
New Revision: 250577

URL: https://gcc.gnu.org/viewcvs?rev=250577=gcc=rev
Log:
gcc/
Backport from 2016-06-15 trunk r237486.
Backport from 2017-07-12 trunk r250156.
PR target/79883
PR target/67353
* config/avr/avr.c (avr_set_current_function): Warn misspelled ISR
only if -Wmisspelled-isr is on.  In diagnostic messages: Quote
keywords and (parts of) identifiers.
[WITH_AVRLIBC]: Warn functions named "ISR", "SIGNAL" or "INTERUPT".
* doc/invoke.texi (AVR Options) <-Wmisspelled-isr>: Decument.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.c
branches/gcc-6-branch/gcc/config/avr/avr.opt
branches/gcc-6-branch/gcc/doc/invoke.texi

[Bug target/67353] [avr] Option-ize Warning "appears to be a misspelled signal / interrupt handler"

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul 26 14:58:42 2017
New Revision: 250577

URL: https://gcc.gnu.org/viewcvs?rev=250577=gcc=rev
Log:
gcc/
Backport from 2016-06-15 trunk r237486.
Backport from 2017-07-12 trunk r250156.
PR target/79883
PR target/67353
* config/avr/avr.c (avr_set_current_function): Warn misspelled ISR
only if -Wmisspelled-isr is on.  In diagnostic messages: Quote
keywords and (parts of) identifiers.
[WITH_AVRLIBC]: Warn functions named "ISR", "SIGNAL" or "INTERUPT".
* doc/invoke.texi (AVR Options) <-Wmisspelled-isr>: Decument.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.c
branches/gcc-6-branch/gcc/config/avr/avr.opt
branches/gcc-6-branch/gcc/doc/invoke.texi

[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Seeing as this bug is about how libffi is used by gcj, and gcj has been removed
from gcc, does it still need to stay open? Or does it affect other users of
libffi in gcc, too? (e.g. go)

[Bug fortran/79861] i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
Could someone familiar with fortran/openmp.c have a look to this PR?

[Bug gcov-profile/81080] target libgcov not built with large file support

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #4 from Eric Gallager  ---
I think this is fixed by comment #2 and comment #3