Re: Undefined behavior or gcc is doing additional good job?
On Fri, Jan 3, 2014 at 5:17 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 03, 2014 at 04:44:48PM +0800, Bin.Cheng wrote:
extern uint32_t __bss_start[];
extern uint32_t __data_start[];
void Reset_Handler(void)
{
/* Clear .bss section (initialize with zeros) */
for (uint32_t* bss_ptr = __bss_start; bss_ptr != __data_start;
++bss_ptr) {
*bss_ptr = 0;
}
}
I believe this is undefined behavior, so GCC can assume
bss_ptr != __data_start is true always. You need something like
Sorry for posting the premature question. Since both __bss_start and
__data_start are declared as array, it seems there is no undefined
behavior, the check is between two pointers with same type actually,
I think this has been discussed in some PR, unfortunately I can't find it.
If it was or =, then it would be obvious undefined behavior, those
comparisons can't be performed between different objects, the above is
questionable, because you still assume that you get through pointer
arithmetics from one object to another one, without dereference pointer
arithmetics can be at one past last entry in the array, but whether that is
equal to the object object is still quite problematic.
Sorry for late replying.
It seems equality operators allow two pointers to compare equal if one
pointer is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space. Then the != condition can't be always true in the example.
right? So the question remains, why GCC would clear the two lower
bits of __data_start - __bss_start then? Am I some stupid mistake?
That said, if either of __bss_start of __data_start aren't 32-bit aligned,
then it is a clear undefined behavior, the masking of low 2 bits (doesn't
happen on x86_64) comes from IVopts computing the end as
((__data_start - __bss_start) + 1) * 4 and the __data_start - __bss_start
is exact division by 4, apparently we don't fold that back to just
(char *) __data_start - (char *) __bss_start + 4.
Em, YES, it comes from ivopt rewriting, but, if it's not undefined
behavior, won't it be annoying (or simply wrong) for compiler to do
something not written by the code?
Thanks,
bin
--
Best Regards.
Re: Undefined behavior or gcc is doing additional good job?
On Tue, Jan 07, 2014 at 04:01:23PM +0800, Bin.Cheng wrote: Em, YES, it comes from ivopt rewriting, but, if it's not undefined behavior, won't it be annoying (or simply wrong) for compiler to do something not written by the code? If __bss_start of __data_start aren't 32-bit aligned, then it is undefined behavior, so it is not wrong. Jakub
Re: Undefined behavior or gcc is doing additional good job?
On Tue, Jan 7, 2014 at 4:10 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Jan 07, 2014 at 04:01:23PM +0800, Bin.Cheng wrote: Em, YES, it comes from ivopt rewriting, but, if it's not undefined behavior, won't it be annoying (or simply wrong) for compiler to do something not written by the code? If __bss_start of __data_start aren't 32-bit aligned, then it is undefined behavior, so it is not wrong. I see. Thanks for elaborating. Thanks, bin -- Best Regards.
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On 01/04/2014 07:21 PM, Joseph S. Myers wrote: FYI: a draft set of C bindings for additional floating-point functions from IEEE 754-2008 are now available (draft TS 18661-4): Is there an accurate summary of IEEE 754-2008 available online? I'm asking because IEEE 754 is widely quoted, but nobody really seems to know what's in it. (It seems that some operations are allowed to be off by an ulp or more, for instance, which I find rather surprising.) -- Florian Weimer / Red Hat Product Security Team
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On Tue, 7 Jan 2014, Florian Weimer wrote: On 01/04/2014 07:21 PM, Joseph S. Myers wrote: FYI: a draft set of C bindings for additional floating-point functions from IEEE 754-2008 are now available (draft TS 18661-4): Is there an accurate summary of IEEE 754-2008 available online? No. It's available for purchase from IEEE, or through IEEE Xplore if you have a site subscription to that. (ISO/IEC/IEEE 60559:2011 is just IEEE 754-2008 with different cover pages / front matter.) I'm asking because IEEE 754 is widely quoted, but nobody really seems to know what's in it. (It seems that some operations are allowed to be off by an ulp or more, for instance, which I find rather surprising.) The IEEE 754 operations are corrected rounded. However, the C bindings choose to provide most of the recommended operations from IEEE 754-2008 subclause 9.2 only in versions with unspecified accuracy, and not in correctly rounded versions, with names being reserved for the correctly rounded versions but no requirement that those functions be provided. (As far as I know, the state of the art on exhaustive searches for worst cases for correct rounding - as needed to implement correctly rounded transcendental functions with bounded resource use - does not make such searches feasible for IEEE binary128, which is a clear reason not to require such functions to be provided.) -- Joseph S. Myers jos...@codesourcery.com
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On Tue, 7 Jan 2014, Joseph S. Myers wrote: The IEEE 754 operations are corrected rounded. However, the C bindings (Except that the IEEE 754 reduction operations - subclause 9.4 - return an implementation-defined approximation. But 9.2 is Recommended correctly rounded functions, e.g. exp and sin, for which the strictly corresponding C functions are crexp and crsin.) -- Joseph S. Myers jos...@codesourcery.com
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On 01/07/2014 02:48 PM, Joseph S. Myers wrote: On Tue, 7 Jan 2014, Joseph S. Myers wrote: The IEEE 754 operations are corrected rounded. However, the C bindings (Except that the IEEE 754 reduction operations - subclause 9.4 - return an implementation-defined approximation. But 9.2 is Recommended correctly rounded functions, e.g. exp and sin, for which the strictly corresponding C functions are crexp and crsin.) Has anyone found a way to do it? Even crlibm only provides routines that are probably correctly rounded. Although I'll grant you that the probability of incorrect rounding is very low. Andrew.
RE: Infinite number of iterations in loop [v850, mep]
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
Matos
Sent: 13 November 2013 16:14
To: Andrew Haley
Cc: gcc@gcc.gnu.org
Subject: RE: Infinite number of iterations in loop [v850, mep]
-Original Message-
From: Andrew Haley [mailto:a...@redhat.com]
Sent: 13 November 2013 15:56
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Infinite number of iterations in loop [v850, mep]
On 11/13/2013 03:48 PM, Paulo Matos wrote:
Because GCC does not know that *c++ = 0; will not overwrite b . I
suppose you could argue that it's not really infinite, because a will
eventually equal 0x, but I think that's what is going on.
Andrew.
I will try to investigate further.
After re-encountering this issue something is amiss. I think this is incorrect.
In the example:
extern int *c;
void fn1 (unsigned int b)
{
unsigned int a;
for (a = 0; a b; a++)
*c++ = 0;
}
It doesn't make sense to assume *c++ will overwrite b. b is an argument to the
function.
The same situation occurs with a coremark function:
void matrix_add_const(ee_u32 N, MATDAT *A, MATDAT val) {
ee_u32 i,j;
for (i=0; iN; i++) {
for (j=0; jN; j++) {
A[i*N+j] += val;
}
}
}
It also says the inner loop might be infinite but it can't N is given as
argument. j starts as 0, N is unsigned like N. This will loop N times. GCC
cannot possibly assume array A will overwrite the value of N in the loop. This
seems like something is wrong in alias analysis.
--
PMatos
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On 2014-01-07 14:36:58 +, Joseph S. Myers wrote: (As far as I know, the state of the art on exhaustive searches for worst cases for correct rounding - as needed to implement correctly rounded transcendental functions with bounded resource use - does not make such searches feasible for IEEE binary128, which is a clear reason not to require such functions to be provided.) Well, an implementation can still provide very accurate versions (say, with a guaranteed 512 bits accuracy), and the functions will be correctly rounded with a very high probability. In practice, the proof of correct rounding can be obtained only with an exhaustive search (well there is some hope to obtain a proof if the maximum precision of the implementation is around several thousands bits). The exhaustive search also allows one to optimize code even more. On 2014-01-07 14:55:31 +, Andrew Haley wrote: On 01/07/2014 02:48 PM, Joseph S. Myers wrote: On Tue, 7 Jan 2014, Joseph S. Myers wrote: The IEEE 754 operations are corrected rounded. However, the C bindings (Except that the IEEE 754 reduction operations - subclause 9.4 - return an implementation-defined approximation. But 9.2 is Recommended correctly rounded functions, e.g. exp and sin, for which the strictly corresponding C functions are crexp and crsin.) Has anyone found a way to do it? Even crlibm only provides routines that are probably correctly rounded. Although I'll grant you that the probability of incorrect rounding is very low. For some of them, this is proved. Here's a summary of the current status: http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On Tue, 7 Jan 2014, Vincent Lefevre wrote: For some of them, this is proved. Here's a summary of the current status: http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf Thanks for the details. What's the current state of the art on the asymptotic cost of the exhaustive searches? -- Joseph S. Myers jos...@codesourcery.com
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On 2014-01-07 14:48:01 +, Joseph S. Myers wrote: (Except that the IEEE 754 reduction operations - subclause 9.4 - return an implementation-defined approximation. But 9.2 is Recommended correctly rounded functions, e.g. exp and sin, for which the strictly corresponding C functions are crexp and crsin.) Some of the reduction operations may be standardized with the correct rounding requirement in the future IEEE 1788 standard on interval arithmetic (even though I think that such operations do not belong to IEEE 1788), if it passes. In any case, they should also have their own correctly rounded version. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On 2014-01-07 16:18:48 +, Joseph S. Myers wrote: On Tue, 7 Jan 2014, Vincent Lefevre wrote: For some of them, this is proved. Here's a summary of the current status: http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf Thanks for the details. What's the current state of the art on the asymptotic cost of the exhaustive searches? The theoretical bound is O(N^(2/3+epsilon)), where N is the number of inputs. In practice, for binary128 (N ~ 2^128), this is already unfeasible. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Draft C bindings for IEEE 754-2008 part 4 now available
On Tue, 7 Jan 2014, Vincent Lefevre wrote: On 2014-01-07 14:48:01 +, Joseph S. Myers wrote: (Except that the IEEE 754 reduction operations - subclause 9.4 - return an implementation-defined approximation. But 9.2 is Recommended correctly rounded functions, e.g. exp and sin, for which the strictly corresponding C functions are crexp and crsin.) Some of the reduction operations may be standardized with the correct rounding requirement in the future IEEE 1788 standard on interval arithmetic (even though I think that such operations do not belong to IEEE 1788), if it passes. In any case, they should also have their own correctly rounded version. Sure, such a correctly rounded function is useful just like correctly rounded versions of other functions. The proposed C bindings reserve cr* names *only* for the specific functions listed in 9.2 where IEEE 754 recommends correctly rounded functions, not for other existing ISO C functions (e.g. erf, tgamma) or functions added by the C bindings by analogy with other IEEE 754 functions (e.g. tanpi), but I think correctly rounded versions of other functions (with the same naming convention) could reasonably be added to glibc if anyone wishes to implement them. (I'd like to see GCC and glibc get full support for C99/C11 Annexes F and G and the TS parts 1 and 4 at least, but given the amount of work involved have no current plans to work on this.) -- Joseph S. Myers jos...@codesourcery.com
[ANN] Registration for C++Now 2014 is Open
Hi, Registration is now open for the eighth annual C++Now conference (formerly BoostCon) which will be held in Aspen, Colorado, USA, May 12th to 17th, 2014. C++Now is a general C++ conference for C++ experts and enthusiasts. It is not specific to any library/framework or compiler vendor and has three tracks with presentations ranging from hands-on, practical tutorials to advanced C++ design and development techniques. In particular, one of the tracks is dedicated exclusively to tutorials. Last year the conference sold out pretty quickly and we expect it to happen again this year. As a result, we encourage anyone interested in attending to register early. Additionally, early bird hotel reservations end January 10th. For more information on registering, visit: http://cppnow.org/2014/01/2014-registration-is-open/ For early bird hotel reservations, visit: http://cppnow.org/location/lodging/ For general information about the conference, visit: http://cppnow.org/about/ Boris
Re: Remove spam in GCC mailing list
GMANE replaces @ with at , so that @#$* becomes at #$*. The wiki.documentfoundation.org site is taking too late to load.
Possible enhancement for RTL data flow?
Hi, I noticed function df_insn_rescan always deletes and re-computes insn_info if any one of defs/uses/eq_uses/mw is verified changed by df_insn_refs_verify, even in some passes (like fwprop), the defs are never changed. Could it be improved to only update the changed part (especially we have df_refs_add_to_chains which already does such thing)? Thanks, bin -- Best Regards.
[Bug fortran/50252] [OOP] Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206382.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the fate of the patches in comments 6, 7, 10, ... ?
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #8 from janus at gcc dot gnu.org --- Right. Like PR 59023, this regression is probably due to r199120. Unfortunately it is not fixed by r206355, but I think the patch in comment 2 does make sense after all.
[Bug fortran/57839] Reallocate on assignment does not work properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57839 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR seems to be fixed for 4.9.0. On darwin with 4.8.2, I get name: name aliases: ?id name: id aliases: name: status aliases: state,validity,test and valgrind complains loudly about invalid reads, while I get name: name aliases: label name: id aliases: name: status aliases: state,validity,test and valgrind reports a memory leak only ==29599== ==29599== HEAP SUMMARY: ==29599== in use at exit: 866 bytes in 6 blocks ==29599== total heap usage: 48 allocs, 42 frees, 10,569 bytes allocated ==29599== ==29599== 589 (336 direct, 253 indirect) bytes in 1 blocks are definitely lost in loss record 4 of 4 ==29599==at 0x100015891: realloc (vg_replace_malloc.c:635) ==29599==by 0x13761: MAIN__ (pr57839.f90:29) ==29599==by 0x13C25: main (pr57839.f90:42) ==29599== ==29599== LEAK SUMMARY: ==29599==definitely lost: 336 bytes in 1 blocks ==29599==indirectly lost: 253 bytes in 3 blocks ==29599== possibly lost: 0 bytes in 0 blocks ==29599==still reachable: 189 bytes in 1 blocks ==29599== suppressed: 88 bytes in 1 blocks
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 31762 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31762action=edit Proposed fix Hi, this patch makes us to look harder for correct virtual table. I walk the stack of binfos with vtables and find first one with matching offset. If I understand thigns right, that should be always the binfo that holds the valid vtable, since these are shared. I will probably need to dive into C++ ABI to double check it.
[Bug c/59039] Undocumented __builtin_longjmp/__builtin_setjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039 --- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I would not say that __builtin_setjmp is more efficient. It really saves just as many registers, except that it has help from the containing function's prologue/epilogue to do so, rather than saving them all within the jmpbuf. [As well as from the register allocator]. I think it's more efficient though, for example if you implement an SJLJ exception scheme on top of it. I'm not keen on encouraging any user to use these functions. It's simply not worth it to us as maintainers. The fact that we've got code in libgcc that uses them means that we must continue to have these functions callable by some means. If folks would be happier if we hid these from users by making them only callable with some special option like -fbuild-libgcc, I could live with that. IMO it's too late to hide them after 2 decades. If people are really afraid of them, then we could keep the status quo.
[Bug tree-optimization/59643] Predictive commoning unnecessarily punts on scimark2 SOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59643 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Should be fixed by proposed fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585. Please help me to test it.
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 31763 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31763action=edit Proposed fix 2 It turns out that in the case of multiple inheritance we may miss vtables on certain paths when it is duplicated binfo for shared base. This patch won't ICE in this case.
[Bug ipa/59226] [4.9 Regression] ICE: in record_target_from_binfo, at ipa-devirt.c:661
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org --- Should be fixed by proposed fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585. Please help me to test it.
[Bug c++/59707] Crash when using std::map with template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59707
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-07
Version|unknown |4.8.2
Summary|[4.8.2] Crash when using|Crash when using std::map
|std::map with template |with template class
|class |
Ever confirmed|0 |1
Known to fail||4.7.4, 4.8.2, 4.9.0
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced:
struct T {
templateclass D operator D*() const;
};
void f(T x) {
x x;
}
4.6 didn't ICE but incorrectly compiled the code
[Bug c++/58140] -Wnon-virtual-dtor shouldn't fire for classes declared final
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58140 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- That's PR 58876, which I intend to fix
[Bug fortran/57965] Allocation of derived type containing an allocatable character component segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57965 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 Known to fail|4.5.3, 4.8.1|4.7.3, 4.8.2 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206385.
[Bug fortran/58667] Add -Wfloat-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58667 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Using -Wfloat-conversion at r206382 gives f951: warning: command line option '-Wfloat-conversion' is valid for C/C++/ObjC/ObjC++ but not for Fortran [enabled by default]
[Bug fortran/56655] [F03] ASSOCIATE construct with OpenMP triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.2 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test in comment 2 compiles with r206348. I doubt the fix (OpenMP 4.0?) will be back ported to 4.8. Closing as FIXED?
[Bug fortran/47928] Gfortran intrinsics documentation paragraph ordering illogical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is it really worth the work? I am voting for no.
[Bug c++/13166] [DR136] not implemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13166 Oliver Freyermuth o.freyermuth at googlemail dot com changed: What|Removed |Added CC||o.freyermuth at googlemail dot com --- Comment #7 from Oliver Freyermuth o.freyermuth at googlemail dot com --- I can still see [DR136] not being implemented in gcc version 4.8.2 , as I just noticed some code not compiling anymore with recent Clang 3.4 which by now implemented DR136: http://llvm.org/viewvc/llvm-project?view=revisionrevision=184889 . g++ still compiles it fine although DR136 is violated (code in question is e.g. string.h of commoncpp2-1.8.0 ).
[Bug fortran/56520] Syntax error causes misleading message: Invalid character in name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56520 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206385.
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Joey Ye joey.ye at arm dot com --- Resolved in trunk
[Bug c++/59707] [4.7/4.8/4.9 Regression] Crash when using std::map with template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59707 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|Crash when using std::map |[4.7/4.8/4.9 Regression] |with template class |Crash when using std::map ||with template class --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- The ICE started with r183221.
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- On my slowest machine (G5 1.8Ghz) I get 49.043u 2.525s 0:56.29 91.5%0+0k 41+25io 2817pf+0w Is it really worth the work? Could you provide a suitable splitting if yes, or close the PR as WONTFIX if no?
[Bug fortran/56342] MATMUL with PARAMETER: Simplification usually doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56342 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still true at r206385.
[Bug fortran/56174] Wrongly accepts INTEGER :: b = HUGE(b)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56174 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206385.
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #13 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #12) Created attachment 31763 [details] Proposed fix 2 It turns out that in the case of multiple inheritance we may miss vtables on certain paths when it is duplicated binfo for shared base. This patch won't ICE in this case. Doesn't (LTO/PGO) bootstrap: lto1: internal compiler error: in hash_type_name, at ipa-devirt.c:225
[Bug target/59710] New: Nios2: Missing gprel optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59710
Bug ID: 59710
Summary: Nios2: Missing gprel optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
The compiler doesn't generate gprel load/store operations for variables
external to the translation unit (this is unlike the PowerPC target for
example). Consider the following test case:
gprel-ok.c:
int iii;
int jjj = 456;
void gprel_ok(void)
{
iii = 123;
jjj = 789;
}
gprel-not-ok.c:
extern int iii;
extern int jjj;
void gprel_not_ok(void)
{
iii = 123;
jjj = 789;
}
nios2-elf-gcc -O2 -fno-common -S gprel-ok.c
nios2-elf-gcc -O2 -fno-common -S gprel-not-ok.c
gprel-ok.s:
.file gprel-ok.c
.section.text
.align 2
.global gprel_ok
.type gprel_ok, @function
gprel_ok:
movir2, 123
stw r2, %gprel(iii)(gp)
movir2, 789
stw r2, %gprel(jjj)(gp)
ret
.size gprel_ok, .-gprel_ok
.global jjj
.section.sdata,aws,@progbits
.align 2
.type jjj, @object
.size jjj, 4
jjj:
.long 456
.global iii
.section.sbss,aws,@nobits
.align 2
.type iii, @object
.size iii, 4
iii:
.zero 4
.ident GCC: (GNU) 4.9.0 20140103 (experimental)
gprel-not-ok.s:
.file gprel-not-ok.c
.section.text
.align 2
.global gprel_not_ok
.type gprel_not_ok, @function
gprel_not_ok:
movir3, 123
movhi r2, %hiadj(iii)
addir2, r2, %lo(iii)
stw r3, 0(r2)
movir3, 789
movhi r2, %hiadj(jjj)
addir2, r2, %lo(jjj)
stw r3, 0(r2)
ret
.size gprel_not_ok, .-gprel_not_ok
.ident GCC: (GNU) 4.9.0 20140103 (experimental)
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Hmm,
markus@x4 gcc % cat test.ii
class A {
void m();
};
void A::m() {}
markus@x4 gcc % /var/tmp/gcc_build_dir_/./prev-gcc/xg++
-B/var/tmp/gcc_build_dir_/./prev-gcc/ -r -nostdlib -flto -O2 -pipe test.ii
lto1: internal compiler error: in hash_type_name, at ipa-devirt.c:225
[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Dominique mentions that the failure of the array test case seems to be a regression between Rev. 188654 and 188694. Well, there was only one commit during that time (Rev. 188692, 2012-06-16): The one for PR 53642 / PR45170: Ensure that the RHS string length is evaluated before the deferred-length LHS is reallocated. I cannot reproduce that any longer. Using my (older) build of Rev. 187316 (2012-05-09), the array test case fails with the same error as today, but the scalar example of comment 0 works. (The dump looks fine and identical to today's trunk plus patch of comment 2.) Thus, the scalar version got broken between 187316 and 188654; the array version got repaired after 187316 and got broken again before 188694 (i.e. with 188692). The second and third tests in comment 0 give respectively function f(a) 1 Error: CHARACTER(*) function 'f' at (1) cannot be array-valued and function return_string(argument) 1 Error: CHARACTER(*) function 'return_string' at (1) cannot be array-valued pr54070_2.f90:3.2: function return_string(argument) 1 Error: CHARACTER(*) function 'return_string' at (1) cannot be array-valued when compiled with 4.7.3 or 4.7.4 (r206161). Should I mark this pr as a 4.8/4.9 regression?
[Bug c/59708] clang-compatible checked arithmetic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/23384] escaped set should be flow sensitive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Summary|Clobber list should be flow |escaped set should be flow
|sensitive |sensitive
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Note implementing a flow-sensitive ESCAPED set is not really possible within
the current framework. Note that all memory operations are not flow-sensitive,
so
int *global;
int kk(void)
{
int j;
j = 1;
g ();
j += 2;
global = j;
}
will still cause g() to clobber j as far as points-to analysis is concerned
(the write to 'global' is not flow-sensitive).
Trivial optimization can avoid refering to ESCAPED in the first basic-block
as long as nothing could have been possibly escaped yet. But that's a hack.
[Bug middle-end/59670] ICE: expected gimple_call(error_mark), have gimple_assign(plus_expr) in gimple_call_internal_p, at gimple.h:2432
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59670 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. The predicate doesn't check the stmt is a call.
[Bug middle-end/59670] ICE: expected gimple_call(error_mark), have gimple_assign(plus_expr) in gimple_call_internal_p, at gimple.h:2432
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59670 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug libfortran/52879] Pathological reseeding of PRNG generator genernates poor sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206385. AFAICT [ x 1 1 1 1 1 1 1 1 1 1 1 ] is next [ x 1 1 1 0 7864504 0 4587601 2097191 3145761 6029545 13238442 ] and [ 1 1 1 1 1 1 1 1 1 1 1 x ] [ 1 1 1 1 0 7864504 0 4587601 2097191 3145761 6095041 y ].
[Bug c/59708] clang-compatible checked arithmetic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Not sure I like their naming though, I'd say they should be type generic builtins handled in the FEs depending on the first argument's type, so that it works even for say __int128_t and similar. For the implementation, we'd need to find out how to represent it in the GIMPLE IL (because the functions have two return values rather than just one and return by reference would be very optimization unfriendly). For expansion, we already handle this for ubsan (well, the signed +/-/* overflow), so that could be just adjusted.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I have noticed these, too (-Og is pessimzed by them). The pattern is generated by gimplifying. I've pondered a bit for a good place to handle this special case (phiopt during early isn't a good option) and the only ones I can think of is cfg-cleanup (ugh) and copyprop (at least looks like a copy-propagation somewhat, but that likely runs too early).
[Bug c++/59659] large zero-initialized std::array compile time excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||compile-time-hog,
||memory-hog,
||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-07
Summary|large zero-initialized |large zero-initialized
|std::array of std::atomic |std::array compile time
|compile time excessive |excessive
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
The frontend generates
struct array arr;
struct array arr;
cleanup_point Unknown tree: expr_stmt
cleanup_point Unknown tree: expr_stmt
arr._M_elems[0] = TARGET_EXPR D.25804, {.D.23130={._M_i=0}} ;
cleanup_point Unknown tree: expr_stmt
arr._M_elems[1] = TARGET_EXPR D.25805, {.D.23130={._M_i=0}} ;
cleanup_point Unknown tree: expr_stmt
arr._M_elems[2] = TARGET_EXPR D.25806, {.D.23130={._M_i=0}} ;
cleanup_point Unknown tree: expr_stmt
arr._M_elems[3] = TARGET_EXPR D.25807, {.D.23130={._M_i=0}} ;
...
instead of generating a loop. Which may be the cause of std::atomic
having some subtle property (thus reproducible with a random class with
that very same property eventually).
Same issue with the following, so it's std::array's fault (or rather
initializer
list support).
#include array
class Foo { public: Foo() {} int i; };
int main() {
std::arrayFoo, 100 arr = {{}}; // Halting problem.
}
[Bug middle-end/59658] Document -f* flags enabled by -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59658 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- But it might be misleading (similar to -O0 vs -O2) - enabling for example -ftree-pre won't enable PRE for -Og as it has a completely different pass pipeline which is not based on -O[123]. Those enumerations are only relevant for the 'numbered' optimization levels (excluding -O0). So we miss to filter options in --help optimizers that can be enabled at all.
[Bug c/59708] clang-compatible checked arithmetic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) Not sure I like their naming though, I'd say they should be type generic builtins handled in the FEs depending on the first argument's type, so that it works even for say __int128_t and similar. For the implementation, we'd need to find out how to represent it in the GIMPLE IL (because the functions have two return values rather than just one and return by reference would be very optimization unfriendly). For expansion, we already handle this for ubsan (well, the signed +/-/* overflow), so that could be just adjusted. If just source compatibility is asked for a functional implementation shouldn't be difficult.
[Bug lto/59626] [4.9 lto] /usr/include/bits/unistd.h:173:1: error: inlining failed in call to always_inline 'readlinkat': recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59626 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/59706] [4.9 Regression] ICE with do concurrent and internal subprogram
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59706 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libstdc++/58764] [4.9 Regression] [lwg/2193] error: converting to ‘const std::vectorstd::basic_stringchar ’ from initializer list would use explicit constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58764 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/59584] [4.9 Regression]: cannot handle define_split for insn emitted for __builtin_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/59652] [4.8 Regression] ICE: in reload_cse_simplify_operands, at postreload.c:411
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59652 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug c++/59645] [4.7/4.8/4.9 Regression] ICE with covariant return and volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59645 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug tree-optimization/59586] [4.8/4.9 Regression] [graphite] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug fortran/59700] [4.8/4.9 Regression] Misleading/buggy runtime error message: Bad integer for item 0 in list input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59700 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3
[Bug c++/59614] [4.9 regression] Explostion in compile time of heavily templated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59614 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/59633] [4.7/4.8/4.9 Regression] ICE with __attribute((vector_size(...))) for enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59633 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug c++/59646] [4.7/4.8/4.9 Regression] ICE with volatile in initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59646 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug rtl-optimization/57320] [4.9 Regression] Shrink-wrapping leaves unreachable blocks in the CFG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57320 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c/59708] clang-compatible checked arithmetic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #4 from Josh Triplett josh at joshtriplett dot org --- (In reply to Jakub Jelinek from comment #2) Not sure I like their naming though, I'd say they should be type generic builtins handled in the FEs depending on the first argument's type, so that it works even for say __int128_t and similar. I'd like to have builtins compatible with the clang versions, but adding a set of type-generic versions sounds like a great idea as well.
[Bug fortran/56132] Lengths incorrect on assignment to an allocatable character scalar.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56132 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.2, 4.9.0 Resolution|--- |FIXED Known to fail||4.7.3 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- ASAICT this is fixed in 4.8.2 and trunk (4.9.0): [Book15] f90/bug% gfortran need_input/pr56132.f90 [Book15] f90/bug% a.out String :_ 0 4 String :_ 4 4 String :_77 4 2 77 String :_why does this happen 2 77 3 why String :_'' [Book15] f90/bug% gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/sw64/lib/gcc4.8/libexec/gcc/x86_64-apple-darwin13.0.0/4.8.2/lto-wrapper Target: x86_64-apple-darwin13.0.0 Configured with: ../gcc-4.8.2/configure --prefix=/sw64 --prefix=/sw64/lib/gcc4.8 --mandir=/sw64/share/man --infodir=/sw64/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw64 --with-libiconv-prefix=/sw64 --with-isl=/sw64 --with-cloog=/sw64 --with-mpc=/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 Thread model: posix gcc version 4.8.2 (GCC) Closing.
[Bug fortran/59706] [4.9 Regression] ICE with do concurrent and internal subprogram
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59706 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Might be least caused by my IVDEP patch, i.e. r204021 (middle-end part) and r204023 (FE part), which fits revision wise.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- I have noticed these, too (-Og is pessimzed by them). The pattern is generated by gimplifying. I wondered why we can't simply update gimplifier to not produce them? (this is what I wanted to look into today, it seems pretty common pattern confusing inliner). For sure we should better also handle it either in cfg-cleanup or copyprop for cases that arrise as a result of other optimizations, but it seems it would speed things up if we did not wrap each predicate calls in its own three BBs.
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz ---
markus@x4 gcc % cat test.ii
class A {
void m();
};
void A::m() {}
markus@x4 gcc % /var/tmp/gcc_build_dir_/./prev-gcc/xg++
-B/var/tmp/gcc_build_dir_/./prev-gcc/ -r -nostdlib -flto -O2 -pipe test.ii
lto1: internal compiler error: in hash_type_name, at ipa-devirt.c:225
Grr, ignore the first hunks replacing DECL_VIRTUAL_P. I added them for
separate
issue (related one though - it happens when you have method virtually
inheriting methods
with virtual calls that is not polymorphic by itself. I will need to figure
out
separate fix for it). I am at meeting now, will prepare updated patch
afterwards.
Honza
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 7 Jan 2014, hubicka at ucw dot cz wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz --- I have noticed these, too (-Og is pessimzed by them). The pattern is generated by gimplifying. I wondered why we can't simply update gimplifier to not produce them? (this is what I wanted to look into today, it seems pretty common pattern confusing inliner). For sure we should better also handle it either in cfg-cleanup or copyprop for cases that arrise as a result of other optimizations, but it seems it would speed things up if we did not wrap each predicate calls in its own three BBs. Not all testcases can be handled at gimplification time IIRC. Which means testcases welcome first, so we can look at them individually.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Bernd Edlinger bernd.edlinger at hotmail dot de --- fixed on trunk
[Bug fortran/58334] preprocessor behavior diffs under line continuation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58334 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r206385.
[Bug fortran/56201] Realloc on assignment: Wrong code when assigning a zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56201 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- WORKSFORME on *-*darwin* from 4.6.4 up to trunk (no error with valgrind of -fsanitize=address).
[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- c) Simply deprecating the -fno-align-commons flag, improving the wording of the diagnostic and the description in the man page. Somehow, I am in favour of (c). Me too.
[Bug libstdc++/59192] error: use of deleted function ‘A::A(const A)’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59192 --- Comment #6 from Rajveer Aujla rajveer_aujla at hotmail dot com --- Thank you for the quick reply. Looking at release dates of previous releases, I'm guessing this will be earliest around next year? Looks like I'd better get coding a workaround :)
[Bug fortran/52884] double precision constants promoted to 16 byte by -fdefault-real-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- If I replace kind(1.d0) with kind(1.0_8), I get '8 16 8' with -fdefault-real-8. I am in favor to replace 'does promote the default width of DOUBLE PRECISION to 16 bytes if possible' with something such as 'does promote the default width of DOUBLE PRECISION to 16 bytes if possible, as well as double real constants like 1.d0' and 'The kind of real constants like 1.d0' with 'The kind of real constants like 1.0_8'.
[Bug fortran/52387] I/O output of write after nonadvancing read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Tobias, any further information on this one? Any news after more than one year?
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
Not all testcases can be handled at gimplification time IIRC. Which
means testcases welcome first, so we can look at them individually.
The GCC one I saw was equivalent of:
#include stdbool.h
bool
m_is_less_than_n (int n, int m)
{
return (n==m || m_is_less_than_n (n-1,m));
}
[Bug middle-end/59711] New: ICE in force_constant_size, at gimplify.c:619 (nested function and variably-modified type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711 Bug ID: 59711 Summary: ICE in force_constant_size, at gimplify.c:619 (nested function and variably-modified type) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fweimer at redhat dot com Created attachment 31764 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31764action=edit u.c The attached test case ICEs on x86_64-redhat-linux-gnu with the following backtrace: #2 0x007f5875 in force_constant_size (var=0x7032a8e8) at ../../trunk/gcc/gimplify.c:619 #3 gimple_add_tmp_var (tmp=0x7032a8e8) at ../../trunk/gcc/gimplify.c:638 #4 0x007d58fb in create_tmp_var (type=type@entry=0x70328000, prefix=optimized out) at ../../trunk/gcc/gimple-expr.c:509 #5 0x007f5b15 in create_tmp_from_val (is_formal=true, val=0x70324990) at ../../trunk/gcc/gimplify.c:457 #6 lookup_tmp_var (is_formal=true, val=0x70324990) at ../../trunk/gcc/gimplify.c:479 #7 internal_get_tmp_var (val=0x70324990, pre_p=0x7fffd968, post_p=optimized out, is_formal=optimized out) at ../../trunk/gcc/gimplify.c:523 #8 0x007f627e in gimplify_expr (expr_p=expr_p@entry=0x703249d8, pre_p=pre_p@entry=0x7fffd968, post_p=post_p@entry=0x7fffd518, gimple_test_f=optimized out, fallback=fallback@entry=3) at ../../trunk/gcc/gimplify.c:8322 #9 0x007fdea2 in gimplify_compound_lval (expr_p=expr_p@entry=0x70305ac0, pre_p=pre_p@entry=0x7fffd968, post_p=post_p@entry=0x7fffd518, fallback=fallback@entry=1) at ../../trunk/gcc/gimplify.c:1976 #10 0x007f73cd in gimplify_expr (expr_p=expr_p@entry=0x70305ac0, pre_p=pre_p@entry=0x7fffd968, post_p=post_p@entry=0x7fffd518, gimple_test_f=optimized out, fallback=fallback@entry=1) at ../../trunk/gcc/gimplify.c:7383 #11 0x008029bb in gimplify_modify_expr (expr_p=expr_p@entry=0x7fffd6b0, pre_p=pre_p@entry=0x7fffd968, post_p=post_p@entry=0x7fffd518, want_value=optimized out) at ../../trunk/gcc/gimplify.c:4493 #12 0x007f771a in gimplify_expr (expr_p=0x7fffd6b0, pre_p=pre_p@entry=0x7fffd968, post_p=0x7fffd518, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x7efef0 is_gimple_stmt(tree), fallback=fallback@entry=0) at ../../trunk/gcc/gimplify.c:7431 #13 0x007fb0f7 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffd6b0, seq_p=seq_p@entry=0x7fffd968) at ../../trunk/gcc/gimplify.c:5334 #14 0x007f970c in gimplify_and_add (seq_p=0x7fffd968, t=0x70305aa0) at ../../trunk/gcc/gimplify.c:384 #15 gimplify_return_expr (pre_p=0x7fffd968, stmt=0x70314a60) at ../../trunk/gcc/gimplify.c:1234 #16 gimplify_expr (expr_p=0x70312bc8, pre_p=pre_p@entry=0x7fffd968, post_p=0x7fffd698, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x7efef0 is_gimple_stmt(tree), fallback=fallback@entry=0) at ../../trunk/gcc/gimplify.c:7671 #17 0x007fb0f7 in gimplify_stmt (stmt_p=optimized out, seq_p=seq_p@entry=0x7fffd968) at ../../trunk/gcc/gimplify.c:5334 #18 0x007f7ee4 in gimplify_statement_list (pre_p=0x7fffd968, expr_p=0x70324a10) at ../../trunk/gcc/gimplify.c:1405 #19 gimplify_expr (expr_p=0x70324a10, pre_p=pre_p@entry=0x7fffd968, post_p=0x7fffd818, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x7efef0 is_gimple_stmt(tree), fallback=fallback@entry=0) at ../../trunk/gcc/gimplify.c:7839 #20 0x007fb0f7 in gimplify_stmt (stmt_p=stmt_p@entry=0x70324a10, seq_p=seq_p@entry=0x7fffd968) at ../../trunk/gcc/gimplify.c:5334 #21 0x007fc01e in gimplify_bind_expr (expr_p=expr_p@entry=0x7030a698, pre_p=pre_p@entry=0x7fffdb58) at ../../trunk/gcc/gimplify.c:1072 #22 0x007f7856 in gimplify_expr (expr_p=0x7030a698, pre_p=pre_p@entry=0x7fffdb58, post_p=0x7fffda28, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x7efef0 is_gimple_stmt(tree), fallback=fallback@entry=0) at ../../trunk/gcc/gimplify.c:7621 #23 0x007fb0f7 in gimplify_stmt (stmt_p=stmt_p@entry=0x7030a698, seq_p=seq_p@entry=0x7fffdb58) at ../../trunk/gcc/gimplify.c:5334 #24 0x007fc9d0 in gimplify_body (fndecl=fndecl@entry=0x7030a600, do_parms=do_parms@entry=true) at ../../trunk/gcc/gimplify.c:8531 #25 0x007fd017 in gimplify_function_tree (fndecl=fndecl@entry=0x7030a600) at ../../trunk/gcc/gimplify.c:8684 #26 0x0068d638 in analyze_function (node=node@entry=0x7032b000) at ../../trunk/gcc/cgraphunit.c:649 #27 0x0068e9f5 in analyze_functions () at ../../trunk/gcc/cgraphunit.c:1017 #28 0x00690036 in finalize_compilation_unit () at ../../trunk/gcc/cgraphunit.c:2310 #29
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #5 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 7 Jan 2014, hubicka at ucw dot cz wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
Not all testcases can be handled at gimplification time IIRC. Which
means testcases welcome first, so we can look at them individually.
The GCC one I saw was equivalent of:
#include stdbool.h
bool
m_is_less_than_n (int n, int m)
{
return (n==m || m_is_less_than_n (n-1,m));
}
That's only optimizable after the 'mergephi' pass. Before the
temporary setting is shared by the n==m code. Thus maybe
'mergephi' itself can handle this ...
[Bug middle-end/59711] ICE in force_constant_size, at gimplify.c:619 (nested function and variably-modified type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711 --- Comment #1 from Florian Weimer fweimer at redhat dot com --- Created attachment 31765 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31765action=edit funcpointer.c Test case without nested function.
[Bug middle-end/59711] ICE in force_constant_size, at gimplify.c:619 with variably-modified return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. Even GCC 3.4 ICEs on it.
[Bug target/58115] testcase gcc.target/i386/intrinsics_4.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115 --- Comment #13 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jan 7 15:26:41 2014 New Revision: 206394 URL: http://gcc.gnu.org/viewcvs?rev=206394root=gccview=rev Log: gcc/ PR target/58115 * target-globals.c (save_target_globals): Remove this_fn_optab handling. * toplev.c: Include optabs.h. (target_reinit): Temporarily restore the global options if another set of options are in force. gcc/testsuite/ * gcc.target/i386/intrinsics_4.c (bar): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/target-globals.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/intrinsics_4.c trunk/gcc/toplev.c
[Bug other/59384] Cilk Plus array notation with for loop after segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 --- Comment #1 from Balaji V. Iyer bviyer at gmail dot com --- Hi Nick, I am sorry for taking a while to get back to you. As you can tell from gcc-patches mailing list, we are actively pursuing to try and push Cilk Plus into trunk. We have submitted a updated patch for _Cilk_for for review for trunk in this thread ( http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00235.html). I looked at this bug and it looks like this bug does not appear if you use _Cilk_for implementation in the thread mentioned above. Thanks, Balaji V. Iyer. PS. The code snippet could have a race-condition. I think if you switch the for and _Cilk_for the race might go away. On Mon, Dec 16, 2013 at 6:09 AM, nick.tomlinson at arm dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59384 Nick Tomlinson nick.tomlinson at arm dot com changed: What|Removed |Added Target||x86_64 Host||x86_64 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug sanitizer/56535] ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- Markus, Are you still seeing the bootstrap failure with --with-build-config=bootstrap-asan and profiled bootstrap? If yes, could you open a new PR for it?
[Bug sanitizer/56535] ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #8) Markus, Are you still seeing the bootstrap failure with --with-build-config=bootstrap-asan and profiled bootstrap? If yes, could you open a new PR for it? I will check this later. Feel free to close this bug anyway.
[Bug middle-end/58956] [4.7 Regression] wrong code at -O1 and above (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jan 7 16:49:22 2014 New Revision: 206396 URL: http://gcc.gnu.org/viewcvs?rev=206396root=gccview=rev Log: Backported from mainline 2013-12-16 Jakub Jelinek ja...@redhat.com PR middle-end/58956 PR middle-end/59470 * gimple.h (walk_stmt_load_store_addr_fn): New typedef. (walk_stmt_load_store_addr_ops, walk_stmt_load_store_ops): Use it for callback params. * gimple.c (walk_stmt_load_store_ops): Likewise. (walk_stmt_load_store_addr_ops): Likewise. Adjust all callback calls to supply the gimple operand containing the base tree as an extra argument. * tree-ssa-ter.c (find_ssaname, find_ssaname_in_store): New helper functions. (find_replaceable_in_bb): For calls or GIMPLE_ASM, only set same_root_var if USE is used somewhere in the stores of the stmt. * ipa-prop.c (visit_ref_for_mod_analysis): Remove name of the stmt argument and ATTRIBUTE_UNUSED, add another unnamed tree argument. * ipa-pure-const.c (check_load, check_store, check_ipa_load, check_ipa_store): Likewise. * gimple.c (gimple_ior_addresses_taken_1): Likewise. * ipa-split.c (test_nonssa_use, mark_nonssa_use): Likewise. (verify_non_ssa_vars, visit_bb): Adjust their callers. * cfgexpand.c (add_scope_conflicts_1): Use walk_stmt_load_store_addr_fn type for visit variable. (visit_op, visit_conflict): Remove name of the stmt argument and ATTRIBUTE_UNUSED, add another unnamed tree argument. * tree-sra.c (asm_visit_addr): Likewise. Remove name of the data argument and ATTRIBUTE_UNUSED. * cgraphbuild.c (mark_address, mark_load, mark_store): Add another unnamed tree argument. * gcc.target/i386/pr59470.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59470.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cfgexpand.c branches/gcc-4_8-branch/gcc/cgraphbuild.c branches/gcc-4_8-branch/gcc/gimple.c branches/gcc-4_8-branch/gcc/gimple.h branches/gcc-4_8-branch/gcc/ipa-prop.c branches/gcc-4_8-branch/gcc/ipa-pure-const.c branches/gcc-4_8-branch/gcc/ipa-split.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-sra.c branches/gcc-4_8-branch/gcc/tree-ssa-ter.c
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jan 7 16:49:22 2014 New Revision: 206396 URL: http://gcc.gnu.org/viewcvs?rev=206396root=gccview=rev Log: Backported from mainline 2013-12-16 Jakub Jelinek ja...@redhat.com PR middle-end/58956 PR middle-end/59470 * gimple.h (walk_stmt_load_store_addr_fn): New typedef. (walk_stmt_load_store_addr_ops, walk_stmt_load_store_ops): Use it for callback params. * gimple.c (walk_stmt_load_store_ops): Likewise. (walk_stmt_load_store_addr_ops): Likewise. Adjust all callback calls to supply the gimple operand containing the base tree as an extra argument. * tree-ssa-ter.c (find_ssaname, find_ssaname_in_store): New helper functions. (find_replaceable_in_bb): For calls or GIMPLE_ASM, only set same_root_var if USE is used somewhere in the stores of the stmt. * ipa-prop.c (visit_ref_for_mod_analysis): Remove name of the stmt argument and ATTRIBUTE_UNUSED, add another unnamed tree argument. * ipa-pure-const.c (check_load, check_store, check_ipa_load, check_ipa_store): Likewise. * gimple.c (gimple_ior_addresses_taken_1): Likewise. * ipa-split.c (test_nonssa_use, mark_nonssa_use): Likewise. (verify_non_ssa_vars, visit_bb): Adjust their callers. * cfgexpand.c (add_scope_conflicts_1): Use walk_stmt_load_store_addr_fn type for visit variable. (visit_op, visit_conflict): Remove name of the stmt argument and ATTRIBUTE_UNUSED, add another unnamed tree argument. * tree-sra.c (asm_visit_addr): Likewise. Remove name of the data argument and ATTRIBUTE_UNUSED. * cgraphbuild.c (mark_address, mark_load, mark_store): Add another unnamed tree argument. * gcc.target/i386/pr59470.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr59470.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cfgexpand.c branches/gcc-4_8-branch/gcc/cgraphbuild.c branches/gcc-4_8-branch/gcc/gimple.c branches/gcc-4_8-branch/gcc/gimple.h branches/gcc-4_8-branch/gcc/ipa-prop.c branches/gcc-4_8-branch/gcc/ipa-pure-const.c branches/gcc-4_8-branch/gcc/ipa-split.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-sra.c branches/gcc-4_8-branch/gcc/tree-ssa-ter.c
[Bug pch/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jan 7 16:50:06 2014 New Revision: 206397 URL: http://gcc.gnu.org/viewcvs?rev=206397root=gccview=rev Log: PR pch/59436 * tree.h (struct tree_optimization_option): Change optabs type from unsigned char * to void *. * optabs.c (init_tree_optimization_optabs): Adjust TREE_OPTIMIZATION_OPTABS initialization. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/optabs.c branches/gcc-4_8-branch/gcc/tree.h
[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jan 7 16:51:16 2014 New Revision: 206398 URL: http://gcc.gnu.org/viewcvs?rev=206398root=gccview=rev Log: PR rtl-optimization/58668 * cfgcleanup.c (flow_find_cross_jump): Don't count any jumps if dir_p is NULL. Remove p1 variable and make USE/CLOBBER check consistent with other places. (flow_find_head_matching_sequence): Don't count USE or CLOBBER insns. (try_head_merge_bb): Adjust for the flow_find_head_matching_sequence counting change. * ifcvt.c (count_bb_insns): Don't count USE or CLOBBER insns. * gcc.dg/pr58668.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr58668.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/cfgcleanup.c branches/gcc-4_8-branch/gcc/ifcvt.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/59470] [4.8 Regression] libstdc++ miscompilation after r205709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug pch/59436] [4.9 Regression] FAIL: 17_intro/headers/c++200x/stdc++.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Hopefully fixed.
[Bug rtl-optimization/58668] [4.8/4.9 regression] internal compiler error: in cond_exec_process_insns, at ifcvt.c:339
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Hopefully fixed.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) This is slightly different from the error message in comment 0, but it still sounds reasonable to me. The error message depends on whether the code is in one or two files and does not change with the patch in comment 2. The wording is reasonable in both cases, but one gets a better locus for the single-file version.
[Bug c/59708] clang-compatible checked arithmetic builtins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #5 from joseph at codesourcery dot com joseph at codesourcery dot com --- See what I said in http://gcc.gnu.org/ml/gcc/2013-10/msg00280.html about the issues with something type-generic regarding detecting overflow on types smaller than int.
[Bug middle-end/58585] [4.9 Regression] ICE in ipa with virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 31766 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31766action=edit Proposed fix 3 Hi, it is still lightly tested due lack of time, but fixes the previous issue with missing vtable.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58182 --- Comment #10 from janus at gcc dot gnu.org --- I think the patch in comment 2 is simple enough to be committed as obvious, which I will do shortly.
