Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Despite the arch controlling fp difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check is this .set? (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Despite the arch controlling fp difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check is this .set? (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Every case would need to look at set vs module as .set writes to mips_opts and .module writes to things like file_mips_arch? I suppose I could just rework all the global options to be part of a single mips_set_options structure to abstract this. Does that sound OK? The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. Back to one of your questions discussing things like: .module fp=xx .module arch=mips2 An easy option would be to continue to have the arch options infer fp32 or fp64 and require the .module fp=xx to come second. Then we just have error checking on the .module fp= option to ensure it is suitable for use with the previously specified architecture. With .module in place like this then I expect the compiler should then start to record more information in the assembly text to indicate things like arch as well as fp. Obviously this will be tied to a configure time assembler feature test. Regards, Matthew
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. Thanks for the input Joseph and sorry for taking so long to reply. So I checked for the case of __mul* function and I believe there shouldn't be a problem as ARM backend never generate any call to these functions (at least according to my grep). Therefore, the only way these functions could end up being used is if a programmer explicitely call it after declaring its prototype and in such a case the call would appear in gcc as a normal function call and would thus be catched by the checks for normal (non libcall) inter compilation unit function call. I need to check however that all functions defined by libgcc fall in the same category as __mul* functions. With regards to TARGET_LIBCALL_VALUE, I will only have to consider it if there exist some libcall function where the calling convention is decided by the compiler. If all libgcc functions not in the ARM runtime ABI are like __mul, it shouldn't be a problem. Of course, all this is only true for ARM, things would be different for avr for instance (backend generates call to __mul* functions). Best regards, Thomas Preud'homme
Re: [gsoc 2014] moving fold-const patterns to gimple
On Mon, Mar 17, 2014 at 2:22 PM, Richard Biener richard.guent...@gmail.com wrote: On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote: In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand constructor instead of OP_EXPR ? Indeed - I have committed the fix. My earlier mail got rejected (maybe because I attached pdf ?), by mailer daemon, sorry for the double post. I have uploaded the proposal here: https://drive.google.com/file/d/0B7zFk-y3DFiHa1Nkdzh6TFZpVFE/edit?usp=sharing I would be grateful to receive your feedback. Thanks and Regards, Prathamesh Thanks, Richard. This caused segfault for patterns when simplification operand was only c_expr (patch attached). * genmatch.c (c_expr::c_expr): use OP_C_EXPR instead of OP_EXPR in call to operand constructor.
Re: RedHat patch not found in mainline gcc
On Mon, Mar 17, 2014 at 06:12:13PM +0100, Stefan Ring wrote: At the company where I work, we have a large program using Boost Python (1.54). We do our product builds for RHEL 5 and recently started building using gcc 4.8 from RedHat devtoolset 2 for performance. This works well, except for one system where it would deterministically crash. I traced it to an old version of libgcc, and specifically this patch, which RedHat applied to its 5.5 release in 2009: http://sophie.aero.jussieu.fr/distrib/Scientific%20Linux/5x/x86_64/by-pkgid/b5e52bbfb4bb11a6cbed452927fba979/files/118. I built libgcc myself with and without the patch, with the program crashing reliably without the patch, and no crash with the patch applied. Unfortunately, gdb does not show a meaningful stack trace, at least not the old version from RHEL 5. When trying to find out a bit more about the patch, I was rather surprised to see that (1) it is not applied to the mainline gcc code and (2) it still applies cleanly. Since I don't have a good stack trace, I cannot even try to build a suitable reproducer at the moment. Is there a good reason for not having it in mainline gcc? I suppose it got lost or forgotten somehow, and that it would be good to have it applied. I don't remember it well, but from re-reading the gcc-patches threads around that time like: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html it seems that the actually committed fix for the bug that the gcc41-unwind-restore-state.patch was meant to fix was http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as http://gcc.gnu.org/r118068 The reason for not backporting that change was supposedly (my memory is fuzzy about it) to minimize the amount of structure layout changes in what is in the unwinder for buggy programs sometimes semi-public. While the GCC driver will attempt to link the unwinder preferrably only as libgcc_s.so.1 or into executables only to avoid many different copies of the unwinder, possibly from different GCC versions, if one overrides that and exports different versions of the unwinder from different shared libraries, there is always a risk that e.g. a subset of the unwinder symbols from older version of GCC unwinder comes earlier in search scope, and for the rest of symbols (e.g. those added in a newer version of GCC unwinder, though that happens only very rarely) they are exported from the newer GCC unwinder and then can't communicate together because some internal data structure changed. If you are talking about devtoolset, that compiler doesn't come with it's own libgcc_s.so.1, uses the system one, just its own libgcc_eh.a, so e.g. if you'd use the default -shared-libgcc (for g++), then it should make no difference at all, because you'd be using the same system unwinder all the time. Jakub
Re: debug strings output order is arbitrary
On Mon, Mar 17, 2014 at 10:01 PM, Martin Uecker uec...@eecs.berkeley.edu wrote: Am Mon, 17 Mar 2014 09:44:53 +0100 schrieb Richard Biener richard.guent...@gmail.com: On Sun, Mar 16, 2014 at 3:58 AM, Martin Uecker uec...@eecs.berkeley.edu wrote: Hi list, the strings in the .debug_str section are output in an arbitrary order. Could this be changed? The function 'output_indirect_strings' in 'gcc/dwarf2out.c' uses htab_traverse which then outputs the string in the order they appear in the hash table. Instead, it would be nicer to output them based on their labels (which are assigned based on the order of creation). This would minimize differences between builds with slightly different build environments, e.g. directory. Can you propose a patch? Note that at creation time only the string itself is known, so sorting after the string may be another possibility. I will propose a patch. Sorting at the end would be easiest, but one could also keep track of the order. Is this performance critical? Sure it is. Also it seems there is other stuff which is output/indexed in hash table order, maybe this should be changed to. Maybe. Richard. Martin
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. Reading again your email I realized I had missed the best bits of this paragraph. Being able to avoid linking all the support for float in printf and scanf when it is not needed is indeed interesting for embedded use. How does this work by the way? Note that this is an orthogonal issue to the calling convention being used or the use of a FPU. I'll take the example of ARM as it's the one I know best (forgive me if you already know all these details). On ARM, the calling convention for variadic function states that all parameters of primitive type are either passed in GP registers or on the stack, no matter what is their type. That is, you cannot determine whether the float logic of scanf and printf is needed based on the type or parameters. You could have a float passed to printf but only its hexadecimal value being displayed by a %x printf modifier, for instance if you are trying to debug a software implementation of float arithmetic. On the opposite, you could pass an integer and display it as a float, for the same reason of debugging a software implementation of float arithmetic. As to the use of an FPU, consider the case of the -mfloat-abi=softfp switch on ARM target. It makes gcc generate instructions using the FPU to do float arithmetic but still passes float in GP registers for compatibility with systems without an FPU. You can thus see that use of FPU, calling convention and linking float code of printf/scanf or 3 separate issues. The -no-float switch on MIPS seems to conflate these 3 issues by telling gcc not to do any float arithmetic (-nofpu, like if there was a -mfpu=none), that as a consequence the calling convention used does not matter (the thing for which I would like a switch to check that fact and an automatic detection) and that float related code of printf/scanf should not be linked in (this could be useful for other target used in embedded scenarios). Since these three aspects could be useful to several architectures I think they should be implemented in arch independent code. In ARM case the calling convention also determine how to pass structures of 4 or less floats/double so there would also be an arch-dependent part. I am not sure about whether to add a new hook or provide helper function in the middle end for the backend to use. A last word about the linking issue. It would be nice to detect the need for float part of printf/scan automatically. However, I don't think it is possible to detect all cases because, as explained above, you can't deduce what will be displayed based on the type of the parameter. The only reliable way is to parse the format string but if the format string is not hardcoded but constructed then there is nothing you can do. However if all call to printf have a hardcoded format string (should be the case for most programs) then you can say for certain that the float code does not need to be linked. For program where this automatic detection is too conservative it would then still be possible to use the switch to force the float code to be left out. Best regards, Thomas Preud'homme
Re: RedHat patch not found in mainline gcc
I don't remember it well, but from re-reading the gcc-patches threads around that time like: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html That thread is from 2009. it seems that the actually committed fix for the bug that the gcc41-unwind-restore-state.patch was meant to fix was http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as http://gcc.gnu.org/r118068 And this one from 2006. Are you sure they are related? If you are talking about devtoolset, that compiler doesn't come with it's own libgcc_s.so.1, uses the system one, just its own libgcc_eh.a, so e.g. if you'd use the default -shared-libgcc (for g++), then it should make no difference at all, because you'd be using the same system unwinder all the time. I don't quite understand. If -shared-libgcc is default, I certainly have not touched it. And since patching the system unwinder in /lib64/libgcc_s-4.1.2-20080825.so.1 is what affects the crashing behavior, it seems to be using the system unwinder already. To me, it looks like the newer gcc from devtoolset generates unwind instruction that the old unwinder does not understand (or doesn't interpret correctly), whereas with gcc41-unwind-restore-state.patch applied, it does.
Re: RedHat patch not found in mainline gcc
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html That thread is from 2009. it seems that the actually committed fix for the bug that the gcc41-unwind-restore-state.patch was meant to fix was http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as http://gcc.gnu.org/r118068 And this one from 2006. Are you sure they are related? Ok, there is a reference in the newer thread, so it looks like you are right here.
[RFC, MIPS] Relax NaN rules
Hi, I've sent this email to everyone who had opinions about the introduction of nan-2008 for mips according to the mailing list archives... The NaN linkage rules introduced with -mnan=2008 enforce a strict rule that all code be built with either legacy NaN or 2008 NaN. This impacts both static and dynamic link and is implemented via an ELF flag. Two of the original threads about this are copied below for reference. http://sourceware.org/ml/binutils/2013-07/msg00072.html http://sourceware.org/ml/libc-ports/2013-08/msg00030.html There are two limitations with the current support which make it difficult to use in production environments: 1) There is no way to mark a module as don't care/not relevant. At a minimum this could be done via inspection of the GNU FP ABI attribute and when its value is 'Any' then NaNs don't matter. Better still would be that modules with floating point only require a certain NaN state if they use functions like __builtin_[s}nan. This would partially reduce the impact of the strict NaN checks. 2) Independent of (1), the strictness associated with NaN handling is a serious problem for linux distributions where there is slow (if any) acceptance of new build variants. New build variants for distributions cost months to put together (just from build time alone) and then the fractured ecosystem this leads to means they are either unused or at best make users confused. It is also true that linux derivatives like Android (and other projects which seek to be architecture agnostic) simply cannot tolerate incompatibilities like the NaN handling rules and will not introduce more than one variant for native code. I believe that 99% of users don't care about the difference between signalling and quiet NaNs and even fewer actually turn on trapping for signalling NaNs. Those who do use, and rely on, behaviour of signalling NaNs very much know that they need this and can afford some extra effort to ensure that they are handled as expected. The following thread is one discussion about how sNaN is a somewhat pointless concept for most users: http://gcc.gnu.org/ml/gcc/2013-11/msg00106.html My proposal is that NaN handling, as implemented, remains but we turn it off by default (or allow it to be turned off by default at build time). By this I mean that GCC will use the default dynamic linker even in the presence of -mnan=2008 and ld will happily link together legacy and 2008 NaN code and ld.so will happily do the same. If a user really cares about NaNs then they need to firstly find someone who will build them a Linux distribution to support them and secondly pull a link time switch '-mstrict-nan' to enable the NaN checks as currently implemented. The same functionality would then be supported by ld.so via an environment variable (or whatever other runtime configuration source there is) to indicate that it must enforce NaN checks as well. Suggestions for option names are welcome. Initial suggestion: --with-nan-check=no, -m[no-]strict-nan, not sure on env variable for ld.so. Regards, Matthew
RE: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
On Tue, 18 Mar 2014, Thomas Preud'homme wrote: From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers The functions affected use floating-point in their public interfaces - for example, __muldc3. Note that libcalls have a different hook (TARGET_LIBCALL_VALUE, ending up using arm_libcall_uses_aapcs_base) from the ones you mentioned. But if you use only functions that pass arm_libcall_uses_aapcs_base (i.e. the floating-point operations defined in RTABI) or don't involve floating point, then you can be compatible with both calling conventions. Thanks for the input Joseph and sorry for taking so long to reply. So I checked for the case of __mul* function and I believe there shouldn't be a problem as ARM backend never generate any call to these functions (at least according to my grep). Therefore, the only way these functions could end up being used is It's not the backend that generates calls to most libgcc functions, but the core compiler (when the optabs don't define a way of expanding some operation inline), which will happily generate calls to __muldc3 on ARM for multiplication of double _Complex values. -- Joseph S. Myers jos...@codesourcery.com
Re: GCC internal re-architecture proposal
On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod amacl...@redhat.com wrote: [ I foolishly sent this with the document as an attachment... hopefully it gets rejected and anyone interested can simply download the document from the wiki..] Over the past couple of months, I've slowly been putting together an action plan to help modernize GCC's source base. We've had various ideas put forth over the years, and a few of the more meritorious ones have been incorporated. My primary goal is to disentangle the front end from the middle/back ends, giving us better control over their data structures. The biggest challenge is having an executable plan which allows the source to be updated incrementally. Ie, we need a way to get from 'Here' to 'There' that does not impact ongoing normal activities, nor noticeably affect the performance of the compiler. This is a huge effort and it will require a large time commitment on my part to see it through. Sorry for following up on this old e-mail but it just occured to me that the (unfinished) GIMPLE frontend would be a great place to bootstrap the new and shiny GIMPLE data structures. Of course for it to work you need to translate that back to fat-and-old GIMPLE and eventually finish the textual format dumping as well - not sure what the state of the gimple frontend branch is. Richard.
Re: [RFC, MIPS] Relax NaN rules
On Tue, 18 Mar 2014, Matthew Fortune wrote: 1) There is no way to mark a module as don't care/not relevant. At a minimum this could be done via inspection of the GNU FP ABI attribute and when its value is 'Any' then NaNs don't matter. Better still would be that modules with floating point only require a certain NaN state if they use functions like __builtin_[s}nan. This would partially reduce the impact of the strict NaN checks. In general you can't tell whether a module cares. It could have an initializer 0.0 / 0.0, without having any function calls involving floating point (so in principle being independent of hard/soft float, but not of NaN format). Or it could be written with knowledge of the ABI to do things directly with bit patterns (possibly based on a configure test rather than __mips_nan2008). The concept of a don't-care module is meaningful, but while heuristics can reliably tell that a module does care (e.g. GCC generated an encoding of a NaN bit-pattern, whether from __builtin_nan or 0.0 / 0.0) they can't so reliably tell that it doesn't care (although if it doesn't contain NaN bit-patterns, or manipulate representations of floating-point values through taking their addresses or using unions, you can probably be sure enough to mark it as don't-care - note that many cases where there are calls with floating-point arguments and results, but no manipulation of bit-patterns and no NaN constants, would be don't-care by this logic). -- Joseph S. Myers jos...@codesourcery.com
RE: [RFC, MIPS] Relax NaN rules
Joseph Myers jos...@codesourcery.com writes: 1) There is no way to mark a module as don't care/not relevant. At a minimum this could be done via inspection of the GNU FP ABI attribute and when its value is 'Any' then NaNs don't matter. Better still would be that modules with floating point only require a certain NaN state if they use functions like __builtin_[s}nan. This would partially reduce the impact of the strict NaN checks. In general you can't tell whether a module cares. It could have an initializer 0.0 / 0.0, without having any function calls involving floating point (so in principle being independent of hard/soft float, but not of NaN format). Or it could be written with knowledge of the ABI to do things directly with bit patterns (possibly based on a configure test rather than __mips_nan2008). The concept of a don't-care module is meaningful, but while heuristics can reliably tell that a module does care (e.g. GCC generated an encoding of a NaN bit-pattern, whether from __builtin_nan or 0.0 / 0.0) they can't so reliably tell that it doesn't care (although if it doesn't contain NaN bit- patterns, or manipulate representations of floating-point values through taking their addresses or using unions, you can probably be sure enough to mark it as don't-care - note that many cases where there are calls with floating-point arguments and results, but no manipulation of bit-patterns and no NaN constants, would be don't-care by this logic). Thanks Joseph. I guess I'm not really pushing to have don't-care supported as it would take a lot of effort to determine when code does and does not care, you rightly point out more cases to deal with too. I'm not sure if the benefit would then be worth it or not as there would still be modules which do and do not care about old and new NaNs so it doesn't really relieve any pressure on toolchains or linux distributions. The second part of the proposal is more interesting/useful as it is saying I don't care about the impact of getting NaN encoding wrong and a tools vendor/linux distribution then gets to make that choice. Any comments on that aspect? Regards, Matthew
WPA stream_out form memory consumption
Hello, I've been compiling Chromium with LTO and I noticed that WPA stream_out forks and do parallel: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html. I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about 6GB. When WPA start to fork, memory consumption increases so that lto1 is killed. I would appreciate an --param option to disable this WPA fork. The number of forks is taken from build system (-flto=9) which is fine for ltrans phase, because LD releases aforementioned 8GB. What do you think about that? Thanks, Martin
Re: WPA stream_out form memory consumption
On Tue, Mar 18, 2014 at 4:09 PM, Martin Liška mli...@suse.cz wrote: Hello, I've been compiling Chromium with LTO and I noticed that WPA stream_out forks and do parallel: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html. I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about 6GB. When WPA start to fork, memory consumption increases so that lto1 is killed. I would appreciate an --param option to disable this WPA fork. The number of forks is taken from build system (-flto=9) which is fine for ltrans phase, because LD releases aforementioned 8GB. What do you think about that? Hmm, what does cause the memory increase? Are you eventually doing garbage collection after the forks in any of the processes? (just add a global flag may_not_gc_collect and set it to true before the first fork and assert in ggc_collect () that this flag isn't set) Richard. Thanks, Martin
Re: WPA stream_out form memory consumption
On Tue, Mar 18, 2014 at 4:13 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Mar 18, 2014 at 4:09 PM, Martin Liška mli...@suse.cz wrote:
Hello,
I've been compiling Chromium with LTO and I noticed that WPA stream_out
forks and do parallel:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html.
I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about 6GB.
When WPA start to fork, memory consumption increases so that lto1 is killed.
I would appreciate an --param option to disable this WPA fork. The number of
forks is taken from build system (-flto=9) which is fine for ltrans phase,
because LD releases aforementioned 8GB.
What do you think about that?
Hmm, what does cause the memory increase? Are you eventually
doing garbage collection after the forks in any of the processes?
(just add a global flag may_not_gc_collect and set it to true before
the first fork and assert in ggc_collect () that this flag isn't set)
We do. At least here:
lto_wpa_write_files ();
if (!quiet_flag)
fprintf (stderr, \n);
timevar_stop (TV_PHASE_STREAM_OUT);
ggc_collect ();
if (post_ipa_mem_report)
{
fprintf (stderr, Memory consumption after IPA\n);
dump_memory_report (false);
}
try returning early before that ggc_collect () if none of the reports are
requested or move the ggc_collect () before lto_wpa_write_files
(which hopefully doesn't produce any gc garbage).
Richard.
Richard.
Thanks,
Martin
[ANN] Registration for CppCon 2014 is Open
CppCon, The C++ Conference Opening Keynote by Bjarne Stroustrup September 7â12, 2014 Bellevue, Washington, USA Registration is now open for CppCon 2014 to be held September 7â12, 2014 at the Meydenbauer Center in Bellevue, Washington, USA. This year the conference starts with the keynote by Bjarne Stroustrup titled Make Simple Tasks Simple! CppCon is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community. You will enjoy inspirational talks and a friendly atmosphere designed to help attendees learn from each other, meet interesting people, and generally have a stimulating experience. Taking place this year in the beautiful Seattle neighborhood and including multiple diverse tracks, the conference will appeal to anyone from C++ novices to experts. What you can expect at CppCon: * Invited talks and panels: CppCon keynote by Bjarne Stroustrup will start off a week full of insight from some of the worldâs leading experts in C++. Still have questions? Ask them at one of CppCon's panels featuring those at the cutting edge of the language. * Presentations by the C++ community: What do embedded systems, game development, high frequency trading, and particle accelerators have in common? C++, of course! Expect talks from a broad range of domains focused on practical C++ techniques, libraries, and tools. * Lightning talks: Get informed at a fast pace during special sessions of short, informal talks. Never presented at a conference before? This is your chance to share your thoughts on a C++-related topic in an informal setting. * Evening events and unconference time: Relax, socialize, or start an impromptu coding session. CppConâs goal is to encourage the best use of C++ while preserving the diversity of viewpoints and experiences, but other than that it is non-partisan and has no agenda. The conference is a project of the Standard C++ Foundation, a not-for-profit organization whose purpose is to support the C++ software developer community and promote the understanding and use of modern, standard C++ on all compilers and platforms. For more information about the conference and to register, visit: http://cppcon.org
Re: GCC internal re-architecture proposal
On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener richard.guent...@gmail.com wrote: On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod amacl...@redhat.com wrote: [ I foolishly sent this with the document as an attachment... hopefully it gets rejected and anyone interested can simply download the document from the wiki..] Over the past couple of months, I've slowly been putting together an action plan to help modernize GCC's source base. We've had various ideas put forth over the years, and a few of the more meritorious ones have been incorporated. My primary goal is to disentangle the front end from the middle/back ends, giving us better control over their data structures. The biggest challenge is having an executable plan which allows the source to be updated incrementally. Ie, we need a way to get from 'Here' to 'There' that does not impact ongoing normal activities, nor noticeably affect the performance of the compiler. This is a huge effort and it will require a large time commitment on my part to see it through. Sorry for following up on this old e-mail but it just occured to me that the (unfinished) GIMPLE frontend would be a great place to bootstrap the new and shiny GIMPLE data structures. Of course for it to work you need to translate that back to fat-and-old GIMPLE and eventually finish the textual format dumping as well - not sure what the state of the gimple frontend branch is. Work on it stalled sometime last year. I'm not sure if I would mix the re-arch work with the GIMPLE FE work. The parser will take the most benefit out of the new structure, but I think it may be better to make the front end be a sub-branch of the re-architect work so we don't conflate the two. Some work will be independent, but it will be easier to maintain both branches if they are separate. I do like the idea of tying the GIMPLE front end to the re-arch branch, however. So, making it a sub-branch of re-arch is definitely a good idea. Diego.
help me
hi list
I need help
I make Dynamic-link library in c
I want link it from a C++
I Create .h file like this
#ifdef __cplusplus
extern C { // only need to export C interface if
// used by C++ source code
#endif
__declspec( dllimport ) static void flood_loop(MAP *map, int x,
int y, unsigned int dst_c, unsigned int
src_c);
#ifdef __cplusplus
}
#endif
but cannot work
--
Think not of them, thou hast thy music too
#include stdio.h
#include stdlib.h
#include limits.h
#include stddef.h
#define BOARD_WIDTH 10
#define BOARD_HEIGHT 20
typedef struct MAP
{
unsigned char b[BOARD_HEIGHT][BOARD_WIDTH];
} MAP;
static void flood_loop(MAP *map, int x, int y,
unsigned int dst_c, unsigned int src_c)
{
int fillL, fillR, i;
int in_line = 1;
//unsigned char c = src_c, fillC = dst_c;
/* find left side, filling along the way */
fillL = fillR = x;
while( in_line )
{
map-b[y][fillL] = dst_c;
fillL--;
in_line = (fillL 0) ? 0 : (map-b[y][fillL] == src_c);
}
fillL++;
/* find right side, filling along the way */
in_line = 1;
while( in_line )
{
map-b[y][fillR] = dst_c;
fillR++;
in_line = (fillR BOARD_WIDTH-1) ? 0 : (map-b[y][fillR] == src_c);
}
fillR--;
/* search top and bottom */
for(i = fillL; i = fillR; i++)
{
if( y 0 map-b[y - 1][i] == src_c )
flood_loop(map, i, y - 1, dst_c, src_c);
if( y BOARD_HEIGHT-1 map-b[y + 1][i] == src_c )
flood_loop(map, i, y + 1, dst_c, src_c);
}
}
void flood_fill(MAP *map, int x, int y, unsigned int c)
{
flood_loop(map, x, y, c, map-b[y][x]);
map-b[y][x] = c; /* some buggy optimizers needed this line */
}
char Taq(char* number)
{
const char taqDhmd111rr[]=
03175986427092154863420687135917509834266123045978
36742095815869720134894536201794386172052581436790;
char interim='0';
char* p;
for(p=number;*p!='\0';++p){
if((unsigned char)(*p-'0')9)
return '-'; //minus sign indicates an error: character is not a digit
interim=taqDhmd111rr[(*p-'0')+(interim-'0')*10];
}
return interim;
}
char CalculateCheckDigit(char* numberWithoutCheckDigit)
{
return Taq(numberWithoutCheckDigit);
}
typedef int BOOL;
BOOL IsCheckDigitValid(char* numberWithCheckDigit)
{
return Taq(numberWithCheckDigit)=='0';
}
int kmp_search(char W[], char S[])
{
int t[5];
int m = 0;
int i = 0;
while (S[m + i] != '\0' W[i] != '\0') {
if (S[m + i] == W[i]) {
++i;
} else {
m += i - t[i];
if (i 0) i = t[i];
}
}
if (W[i] == '\0') {
return m;
} else {
return m + i;
}
}
void selection_sort (int *a, int n) {
int i, j, m, t;
for (i = 0; i n; i++) {
for (j = i, m = i; j n; j++) {
if (a[j] a[m])
m = j;
}
t = a[i];
a[i] = a[m];
a[m] = t;
}
}
void shell_sort (int *a, int n) {
int h, i, j, k;
for (h = n; h /= 2;) {
for (i = h; i n; i++) {
k = a[i];
for (j = i; j = h k a[j - h]; j -= h) {
a[j] = a[j - h];
}
a[j] = k;
}
}
}
static void insertion_sort(int *a, const size_t n) {
size_t i, j;
int value;
for (i = 1; i n; i++) {
value = a[i];
for (j = i; j 0 value a[j - 1]; j--) {
a[j] = a[j - 1];
}
a[j] = value;
}
}
void gnome_sort(int *a, int n)
{
int i=1, j=2, t;
# define swap(i, j) { t = a[i]; a[i] = a[j]; a[j] = t; }
while(i n) {
if (a[i - 1] a[i]) {
swap(i - 1, i);
if (--i) continue;
}
i = j++;
}
# undef swap
}
#define try_swap { if (aa[ii] aa[ii - 1])\
{ tt = aa[ii]; aa[ii] = aa[ii - 1]; aa[ii - 1] = tt; tt = 0;} }
void cocktailsort(int *aa, size_t len)
{
size_t ii;
int tt = 0;
while (!tt) {
for (ii = 1, tt = 1; ii len; ii++) try_swap;
if (tt) break;
for (ii = len - 1, tt = 1; ii; ii--) try_swap;
}
}
void bubble_sort(int *a, int n) {
int j, t = 1;
while (n-- t)
for (j = t = 0; j n; j++) {
if (a[j] = a[j + 1]) continue;
t = a[j], a[j] = a[j + 1], a[j + 1] = t;
t=1;
}
}
void quick_sort (int *a, int n) {
if (n 2)
return;
int p = a[n / 2];
int *l = a;
int *r = a + n - 1;
while (l = r) {
if (*l p) {
l++;
continue;
}
if (*r p) {
r--;
continue; // we need to check the condition (l = r) every time we change the value of l or r
}
int t = *l;
*l++ = *r;
*r-- = t;
}
quick_sort(a, r - a + 1);
quick_sort(l, a + n - l);
}
void bead_sort(int *a, int len)
{
int i, j, max, sum;
unsigned char *beads;
#define BEAD(i, j) beads[i * max + j]
for (i = 1, max = a[0]; i len; i++)
Re: help me
On 18 March 2014 17:35, Ali Abdul Ghani wrote: hi list I need help This is the wrong list for user support, please use the gcc-help mailing list instead. You will probably want to provide more information that but cannot work if you expect anyone to be able to help.
ARM64 va_list
Hi, I've been porting some software to arm64 and one of their test suites uses va_list as an argument in their function call and I get an error regarding that function when I compile. I was just wondering if va_list has been ported to arm64 yet. Thanks Nick Kemp
Re: ARM64 va_list
On Tue, Mar 18, 2014 at 10:50 AM, Nicholas Robert Kemp
nrk...@myseneca.ca wrote:
Hi,
I've been porting some software to arm64 and one of their test suites uses
va_list as an argument in their function call and I get an error regarding
that function when I compile. I was just wondering if va_list has been
ported to arm64 yet.
It has. Because otherwise even printf/vprintf would fail. What is
the error message you are getting? Also does the code depend on
va_list being an array, on aarch64, it is defined as struct (AAPCS64
\S 7.1.4).
From the aarch64 back-end:
AAPCS64 \S 7.1.4 requires that va_list be a typedef for a type defined as:
struct __va_list
{
void *__stack;
void *__gr_top;
void *__vr_top;
int __gr_offs;
int __vr_offs;
};
Thanks,
Andrew Pinski
Thanks
Nick Kemp
Re: Legitimize address after reload
David Guillen da...@davidgf.net writes:
So far I'm still facing problems regarding memory addresses even with
the most restrictive conditions. The non-recognized instruction is:
../../../libgcc/libgcc2.c: In function '__muldi3':
../../../libgcc/libgcc2.c:559:1: error: insn not satisfying its restrictions:
(insn 130 164 134 4 (set:SI (mem/c:SI (plus:SI (mem/f/c:SI (plus:SI
(reg/f:SI 6 %ebp)
(const_int 8 [0x8])) [6 .result_ptr+0 S4 A32])
(const_int 4 [0x4])) [2 retval+4 S4 A32])
(reg:SI 1 %edx [84])) ../../../libgcc/libgcc2.c:558 9 {*movsi}
(nil))
../../../libgcc/libgcc2.c:559:1: internal compiler error
reload_cse_simplify_operands, at postreload.c:403
I'm using this as TARGET_LEGITIMATE_ADDRESS_P:
bool valid_address (enum machine_mode mode, rtx x, bool strict_p) {
switch (GET_CODE (x)) {
case REG:
case SUBREG:
return REG_P(x);
case PLUS:
return ( REG_P( XEXP(x,0) ) CONST_INT_P( XEXP(x,1) ) );
case CONST_INT:
case CONST:
case LABEL_REF:
case SYMBOL_REF:
return true;
default:
return false;
}
}
So I don't get why the reload pass doesn't force the address to be in
a register.
Any ideas?
And, anyone can give me a hint on how to debug this issues? I'd like
to discover where in the gcc source this memory RTX expression is
created and why it is not expanded to be a valid address.
What DJ meant below was that you should reject all pseudo registers
if strict_p. I.e. REG_P (foo) should be:
REG_P (foo) (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode))
where REGNO_MODE_OK_FOR_BASE_P should only accept hard registers and
where mode is the mode of the memory being accessed.
Thanks,
Richard
2014-03-14 18:56 GMT+01:00 DJ Delorie d...@redhat.com:
David Guillen da...@davidgf.net writes:
In any case I'm not using the restrict variable and I'm assuming
strict is zero, this is, not checking the hard regsiters themselves.
This is because any reg is OK for base reg. I'm pretty sure I'm
behaving similarly to arm, cris or x86 backends.
strict doesn't mean which hard register it is, strict means whether
or not it's a hard register at all.
If strict is true, you must assume any REG which isn't a real hard
register (i.e. REGNO = FIRST_PSEUDO_REGISTER) does NOT match.
Re: [RFC][ARM] Naming for new switch to check for mixed hardfloat/softfloat compat
Thomas Preud'homme thomas.preudho...@arm.com writes: From: Richard Sandiford [mailto:rdsandif...@googlemail.com] -mno-float as it stands today is really just -msoft-float with some floating-point support removed from the library to save space. One of the important examples is that the floating-point printf and scanf formats are not supported, so printf and scanf do not pull in large parts of the software floating-point library. Reading again your email I realized I had missed the best bits of this paragraph. Being able to avoid linking all the support for float in printf and scanf when it is not needed is indeed interesting for embedded use. How does this work by the way? -mno-float causes gcc to define the macro __mips_no_float, which the implementation can use when deciding whether to bother handling %f, etc. I'm afraid there's nothing more sophisticated to it than that. Note that this is an orthogonal issue to the calling convention being used or the use of a FPU. I'll take the example of ARM as it's the one I know best (forgive me if you already know all these details). Well, maybe orthogonal in concept, but as above, not in implementation :-) -mno-float really means does not use floating point in any form, so has a stricter requirement than what you wanted. On ARM, the calling convention for variadic function states that all parameters of primitive type are either passed in GP registers or on the stack, no matter what is their type. That is, you cannot determine whether the float logic of scanf and printf is needed based on the type or parameters. You could have a float passed to printf but only its hexadecimal value being displayed by a %x printf modifier, for instance if you are trying to debug a software implementation of float arithmetic. On the opposite, you could pass an integer and display it as a float, for the same reason of debugging a software implementation of float arithmetic. As to the use of an FPU, consider the case of the -mfloat-abi=softfp switch on ARM target. It makes gcc generate instructions using the FPU to do float arithmetic but still passes float in GP registers for compatibility with systems without an FPU. You can thus see that use of FPU, calling convention and linking float code of printf/scanf or 3 separate issues. The -no-float switch on MIPS seems to conflate these 3 issues by telling gcc not to do any float arithmetic (-nofpu, like if there was a -mfpu=none), that as a consequence the calling convention used does not matter (the thing for which I would like a switch to check that fact and an automatic detection) and that float related code of printf/scanf should not be linked in (this could be useful for other target used in embedded scenarios). Since these three aspects could be useful to several architectures I think they should be implemented in arch independent code. Definitely. The reason -mno-float is restricted to certain MIPS configurations rather than being a general MIPS option is because the current option is a hack. It ought to offer at least some help in enforcing the restrictions, whereas instead it just allows any floating-point operations to be used and compiles them in the same way as -msoft-float. In ARM case the calling convention also determine how to pass structures of 4 or less floats/double so there would also be an arch-dependent part. I am not sure about whether to add a new hook or provide helper function in the middle end for the backend to use. I assume for most cases the restriction is of the form calling this function must not use registers in class X. I think we can detect that using the existing hooks. A more general restriction would be must pass arguments in the same way for both option set A and option set B. That too could be done using existing hooks and SWITCHABLE_TARGET, although it might not be hyper-efficient. A last word about the linking issue. It would be nice to detect the need for float part of printf/scan automatically. However, I don't think it is possible to detect all cases because, as explained above, you can't deduce what will be displayed based on the type of the parameter. The only reliable way is to parse the format string but if the format string is not hardcoded but constructed then there is nothing you can do. Agreed. However if all call to printf have a hardcoded format string (should be the case for most programs) then you can say for certain that the float code does not need to be linked. For program where this automatic detection is too conservative it would then still be possible to use the switch to force the float code to be left out. I agree it's possible. FWIW, as things stand, MIPS just treats hard-float and soft-float code as link-incompatible, so I don't think we could use it there. Thanks, Richard
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Despite the arch controlling fp difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check is this .set? (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Every case would need to look at set vs module as .set writes to mips_opts and .module writes to things like file_mips_arch? I suppose I could just rework all the global options to be part of a single mips_set_options structure to abstract this. Does that sound OK? Yeah, that's the kind of thing I was thinking of. FWIW, if this is feeling like feature creep then I have a go this weekend. The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. Right. But like I say, that's good IMO, since the differences become more obvious than they'd be with two different implementations. Back to one of your questions discussing things like: .module fp=xx .module arch=mips2 An easy option would be to continue to have the arch options infer fp32 or fp64 and require the .module fp=xx to come second. Then we just have error checking on the .module fp= option to ensure it is suitable for use with the previously specified architecture. I don't think it's a good idea for the order of the .modules to matter. I think as far as possible, putting .module in the code should be the same as passing the associated command-line option. It probably makes sense to prohibit .module after an instruction has been assembled or after .set has been seen. We could then handle the .module-adjusted options at those points (or at the end, if there are no .sets and no instructions). With .module in place like this then I expect the compiler should then start to record more information in the assembly text to indicate things like arch as well as fp. Obviously this will be tied to a configure time assembler feature test. Agreed. Thanks, Richard
Re: Legitimize address after reload
Richard Sandiford rdsandif...@googlemail.com writes: What DJ meant below was that you should reject all pseudo registers if strict_p. I.e. REG_P (foo) should be: REG_P (foo) (!strict_p || REGNO_MODE_OK_FOR_BASE_P (foo, mode)) sorry: REG_P (foo) (!strict_p || REGNO_MODE_OK_FOR_BASE_P (REGNO (foo), mode)) where REGNO_MODE_OK_FOR_BASE_P should only accept hard registers and where mode is the mode of the memory being accessed. Thanks, Richard
Re: New .rodata section.
Umesh Kalappa umesh.kalap...@gmail.com writes: Hi All , We are porting gcc4.8.1 to the new target and we created the new .rodata section w.r.t flags by get_unnamed_section() . Now we need to associate the global %object data of type .word or .byte to the created .rodata section and also we need to emit the .rodata section in the asm file . Anyone can share their experice or some inputs or reference for the same will be appreciated. Thank you for the patience. I'm not sure what the properties of this new section are compared to plain .rodata, but you can select a section using hooks like TARGET_ASM_SELECT_SECTION. Thanks, Richard
RE: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Despite the arch controlling fp difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check is this .set? (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Every case would need to look at set vs module as .set writes to mips_opts and .module writes to things like file_mips_arch? I suppose I could just rework all the global options to be part of a single mips_set_options structure to abstract this. Does that sound OK? Yeah, that's the kind of thing I was thinking of. FWIW, if this is feeling like feature creep then I have a go this weekend. Although it does seem like feature creep, I'm happy to do it as it gives a smaller problem for me to work on and submit to go through the motions. It may however be worthwhile tying this in with the introduction of -mfpxx to allow one assembler feature test to infer that both the new .module support and fpxx are implemented (or would you do this as two tests anyway?). The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. Right. But like I say, that's good IMO, since the differences become more obvious than they'd be with two different implementations. Back to one of your questions discussing things like: .module fp=xx .module arch=mips2 An easy option would be to continue to have the arch options infer fp32 or fp64 and require the .module fp=xx to come second. Then we just have error checking on the .module fp= option to ensure it is suitable for use with the previously specified architecture. I don't think it's a good idea for the order of the .modules to matter. I think as far as possible, putting .module in the code should be the same as passing the associated command-line option. It probably makes sense to prohibit .module after an instruction has been assembled or after .set has been seen. We could then handle the .module-adjusted options at those points (or at the end, if there are no .sets and no instructions). With .module in place like this then I expect the compiler should then start to record more information in the assembly text to indicate things like arch as well as fp. Obviously this will be tied to a configure time assembler feature test. Agreed. Fantastic. I think the only loose end is: http://gcc.gnu.org/ml/gcc/2014-03/msg00204.html I'm concerned about the program loader and dynamic linker having to read a segment as well as the header to get the feature bits when the program header fields could be interpreted specially for a new program header type. With 7 32-bit fields there are 224 bits of data available which seems quite generous and would be simple to read. As it stands ld.so carries around a pointer to and quantity of the program headers which means the data directly present in the headers is exceptionally easy to read, a segment is harder. (I hope I have the right terminology there with 'segment'). Regards, Matthew
Re: [RFC] Introducing MIPS O32 ABI Extension for FR0 and FR1 Interlinking
Matthew Fortune matthew.fort...@imgtec.com writes: Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: Richard Sandiford rdsandif...@googlemail.com writes: Matthew Fortune matthew.fort...@imgtec.com writes: As it stands I wasn't planning on supporting .module arch= I was just going to add .module fp= and leave it at that. The only thing I need to give assembly code writers absolute control over is the overall FP mode of the module. I don't currently see any real need to increase the control a user has over architecture level. If we had .module arch= then having it just set the arch ignorant of FP mode seems fine, checking for erroneous combinations would be difficult due to some chicken and egg scenarios. Do you think I need to add .module arch= if I add .module fp= or can I take the easy option? Despite the arch controlling fp difference, I think .set and .module should use common parsing code. I.e. we should generalise s_mipsset to handle both of them rather than write a second parsing function for .module. There will be some cases where the function has to check is this .set? (e.g. push/pop), but that's good IMO, because it makes the differences obvious. If we do have a common routine then we should make .module handle everything it can handle rather than just fp=. Every case would need to look at set vs module as .set writes to mips_opts and .module writes to things like file_mips_arch? I suppose I could just rework all the global options to be part of a single mips_set_options structure to abstract this. Does that sound OK? Yeah, that's the kind of thing I was thinking of. FWIW, if this is feeling like feature creep then I have a go this weekend. Although it does seem like feature creep, I'm happy to do it as it gives a smaller problem for me to work on and submit to go through the motions. It may however be worthwhile tying this in with the introduction of -mfpxx to allow one assembler feature test to infer that both the new .module support and fpxx are implemented (or would you do this as two tests anyway?). Yeah, .module should be a different configure test. I don't think we need an fpxx test though. We don't usually do configure checks for passed-down -m* options since it's really the assembler's job to say what it accepts. It also means users can upgrade binutils without rebuilding GCC. We only need configure tests (like .module) for optional enhancements that get used under the covers. The push/pop case (and perhaps some others) will still need special handling to prohibit them for .module. Right. But like I say, that's good IMO, since the differences become more obvious than they'd be with two different implementations. Back to one of your questions discussing things like: .module fp=xx .module arch=mips2 An easy option would be to continue to have the arch options infer fp32 or fp64 and require the .module fp=xx to come second. Then we just have error checking on the .module fp= option to ensure it is suitable for use with the previously specified architecture. I don't think it's a good idea for the order of the .modules to matter. I think as far as possible, putting .module in the code should be the same as passing the associated command-line option. It probably makes sense to prohibit .module after an instruction has been assembled or after .set has been seen. We could then handle the .module-adjusted options at those points (or at the end, if there are no .sets and no instructions). With .module in place like this then I expect the compiler should then start to record more information in the assembly text to indicate things like arch as well as fp. Obviously this will be tied to a configure time assembler feature test. Agreed. Fantastic. I think the only loose end is: http://gcc.gnu.org/ml/gcc/2014-03/msg00204.html I'm concerned about the program loader and dynamic linker having to read a segment as well as the header to get the feature bits when the program header fields could be interpreted specially for a new program header type. With 7 32-bit fields there are 224 bits of data available which seems quite generous and would be simple to read. As it stands ld.so carries around a pointer to and quantity of the program headers which means the data directly present in the headers is exceptionally easy to read, a segment is harder. (I hope I have the right terminology there with 'segment'). Like you say, it'd be good to hear other people's thoughts. I think in practice a loader is going to have a reasonable interface for accessing a given segment, so it should just be a setup call, some error checking, and a tear-down call. The advantage of encoding it directly in header types is that it avoids having to do those things. The advantage of a single header is that all the data is directly
Re: [gsoc 2014] moving fold-const patterns to gimple
On Mar 18, 2014, at 9:13 PM, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote: On Mon, Mar 17, 2014 at 2:22 PM, Richard Biener richard.guent...@gmail.com wrote: On Sun, Mar 16, 2014 at 1:21 PM, Prathamesh Kulkarni bilbotheelffri...@gmail.com wrote: In c_expr::c_expr, shouldn't OP_C_EXPR be passed to operand constructor instead of OP_EXPR ? Indeed - I have committed the fix. My earlier mail got rejected (maybe because I attached pdf ?), by mailer daemon, sorry for the double post. I have uploaded the proposal here: https://drive.google.com/file/d/0B7zFk-y3DFiHa1Nkdzh6TFZpVFE/edit?usp=sharing I would be grateful to receive your feedback. Prathamesh, I will let Richard to comment on the proposal contents, but make sure you have formally applied on the GSoC website and uploaded some version of your proposal by end of Thursday (only 2 days left!). You will be able to update details of the proposal later. Thank you, -- Maxim Kuvyrkov www.linaro.org
Re: GSoC Concepts - separate checking
On Mar 12, 2014, at 12:19 PM, Braden Obrzut ad...@maniacsvault.net wrote: My name is Braden Obrzut and I am a student from the University of Akron interested in contributing to GCC for GSoC. I am interested in working on a project related to the c++-concepts branch. In particular, I am interested in implementing mechanisms for checking the safety of constrained templates (separate checking). I have discussed the project with Andrew Sutton (who maintains the c++-concepts branch and happens to be a professor at Akron) and believe that some aspects of the work would be feasible within the three month time span. I also hope to continue working on the project as my honors thesis project. As a hobby I usually design and implement declarative languages for content definition in old video games. While I currently may have limited experience with GCC internals, I think this would be a great opportunity for me to learn how real compilers works and help with the development of the C++ programming language. Braden, Do you have a proposal for a GSoC GCC project? If you do want to apply, please make sure you are registered at the GSoC website and have a application filed by end of Thursday (only 2 days left!). Thank you, -- Maxim Kuvyrkov www.linaro.org
Re: GSoC 2014 C++ Concepts project
On Mar 12, 2014, at 11:42 AM, Thomas Wynn tw...@programmer.net wrote: Hello, my name is Thomas Wynn. I am a junior in pursuit of a B.S. in Computer Science at The University of Akron. I am interested in working on a project with GCC for this year's Google Summer of Code. More specifically, I would like to work on support for concept variables and shorthand notation of concepts for C++ Concepts Lite. I am currently doing an independent study with Andrew Sutton in which I have been porting and creating various tests for concepts used in the DejaGNU test suite of an experimental branch of GCC 4.9, and will soon be helping with the development of features in branch. I would greatly appreciate any suggestions or feedback for this project so that I may write a more detailed, relevant, and accurate proposal. Hi Thomas, Do you have a proposal for a GSoC GCC project? If you do want to apply, please make sure you are registered at the GSoC website and have a application filed by end of Thursday (only 2 days left!). -- Maxim Kuvyrkov www.linaro.org
Re: About gsoc 2014 OpenMP 4.0 Projects
On Feb 26, 2014, at 12:27 AM, guray ozen guray.o...@gmail.com wrote: Hello, I'm master student at high-performance computing at barcelona supercomputing center. And I'm working on my thesis regarding openmp accelerator model implementation onto our compiler (OmpSs). Actually i almost finished implementation of all new directives to generate CUDA code and same implementation OpenCL doesn't take so much according to my design. But i haven't even tried for Intel mic and apu other hardware accelerator :) Now i'm bench-marking output kernel codes which are generated by my compiler. although output kernel is generally naive, speedup is not very very bad. when I compare results with HMPP OpenACC 3.2.x compiler, speedups are almost same or in some cases my results are slightly better than. That's why in this term, i am going to work on compiler level or runtime level optimizations for gpus. When i looked gcc openmp 4.0 project, i couldn't see any things about code generation. Are you going to announce later? or should i apply gsoc with my idea about code generations and device code optimizations? Guray Do you have a proposal for a GSoC GCC project? If you do want to apply, please make sure you are registered at the GSoC website and have a application filed by end of Thursday (only 2 days left!). Thank you, -- Maxim Kuvyrkov www.linaro.org
Re: Google Summer of Code
On Mar 17, 2014, at 2:39 AM, Mihai Mandrescu mihai.mandre...@gmail.com wrote: Hello, I just enrolled in Google Summer of Code and would like to contribute to GCC. I'm not very familiar with the process of getting a project for GSoC nor with free software development in general, but I would like to learn. Can someone give me some hints please? Hi Mihai, There is very little time left for student application -- only 2 days. In general, by now you should have a specific idea that you want to work on, it doesn't have to be your own, there are many ideas for potential GSoC projects at http://gcc.gnu.org/wiki/SummerOfCode . You need to be realistic about your experience in compiler development and GCC development. It is better to apply for an easier/smaller project and successfully finish it, than to work on a complicated project and not get it done. Finally, please don't cross-post to several lists, gcc@gcc.gnu.org is the correct list for development discussions (with gcc-patc...@gcc.gnu.org being the list for discussion of specific patches). Thank you, -- Maxim Kuvyrkov www.linaro.org
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
What is not satisfying?
struct QualifiedNameComponents {
StringImpl* m_prefix;
StringImpl* m_localName;
StringImpl* m_namespace;
};
...
templatetypename T, UChar Converter(T) static inline unsigned
computeHash(const T* data, unsigned length)
{
StringHasher hasher;
bool rem = length 1;
length = 1;
while (length--) {
hasher.addCharacters(Converter(data[0]), Converter(data[1]));
data += 2;
}
if (rem)
hasher.addCharacter(Converter(*data));
return hasher.hash();
}
...
templatesize_t length static inline unsigned hashMemory(const void* data)
{
typedef int dummylength_must_be_a_multible_of_four [(!(length % 4)) ? 1
: -1];
return computeHashUChar(static_castconst UChar*(data), length /
sizeof(UChar));
}
...
inline unsigned hashComponents(const QualifiedNameComponents buf)
{
return StringHasher::hashMemorysizeof(QualifiedNameComponents)(buf);
}
struct QualifiedNameHash {
static unsigned hash(const QualifiedName name) { return hash(name.impl());
}
static unsigned hash(const QualifiedName::QualifiedNameImpl* name)
{
QualifiedNameComponents c = { name-m_prefix.impl(),
name-m_localName.impl(), name-m_namespace.impl() };
return hashComponents(c);
}
static bool equal(const QualifiedName a, const QualifiedName b) { return
a == b; }
static bool equal(const QualifiedName::QualifiedNameImpl* a, const
QualifiedName::QualifiedNameImpl* b) { return a == b; }
static const bool safeToCompareToEmptyOrDeleted = false;
};
is a clear aliasing violation and thus undefined behavior when called.
The `c' object has object type QualifiedNameComponents, whose subobjects have
type pointer to StringImpl. In computeHash you are then reading the object
using the UChar (unsigned short) effective type, only char or unsigned char
types can be used for that, see e.g. [basic.types]/2, or read -fstrict-aliasing
documentation in info gcc.
For g++, you could read the object through say typedef UChar UCharMayAlias
__attribute__((__may_alias__));, or you can say std::memcpy the object into an
correspondigly sized array of UChar and hash that rather than the original
object, etc.
[Bug middle-end/60546] [4.8/4.9] O2 asan enable generates wrong insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60546
--- Comment #22 from linzj manjian2006 at gmail dot com ---
(In reply to Jakub Jelinek from comment #21)
What is not satisfying?
struct QualifiedNameComponents {
StringImpl* m_prefix;
StringImpl* m_localName;
StringImpl* m_namespace;
};
...
templatetypename T, UChar Converter(T) static inline unsigned
computeHash(const T* data, unsigned length)
{
StringHasher hasher;
bool rem = length 1;
length = 1;
while (length--) {
hasher.addCharacters(Converter(data[0]), Converter(data[1]));
data += 2;
}
if (rem)
hasher.addCharacter(Converter(*data));
return hasher.hash();
}
...
templatesize_t length static inline unsigned hashMemory(const void*
data)
{
typedef int dummylength_must_be_a_multible_of_four [(!(length % 4))
? 1 : -1];
return computeHashUChar(static_castconst UChar*(data), length /
sizeof(UChar));
}
...
inline unsigned hashComponents(const QualifiedNameComponents buf)
{
return StringHasher::hashMemorysizeof(QualifiedNameComponents)(buf);
}
struct QualifiedNameHash {
static unsigned hash(const QualifiedName name) { return
hash(name.impl()); }
static unsigned hash(const QualifiedName::QualifiedNameImpl* name)
{
QualifiedNameComponents c = { name-m_prefix.impl(),
name-m_localName.impl(), name-m_namespace.impl() };
return hashComponents(c);
}
static bool equal(const QualifiedName a, const QualifiedName b) {
return a == b; }
static bool equal(const QualifiedName::QualifiedNameImpl* a, const
QualifiedName::QualifiedNameImpl* b) { return a == b; }
static const bool safeToCompareToEmptyOrDeleted = false;
};
is a clear aliasing violation and thus undefined behavior when called.
The `c' object has object type QualifiedNameComponents, whose subobjects
have type pointer to StringImpl. In computeHash you are then reading the
object using the UChar (unsigned short) effective type, only char or
unsigned char types can be used for that, see e.g. [basic.types]/2, or read
-fstrict-aliasing documentation in info gcc.
For g++, you could read the object through say typedef UChar UCharMayAlias
__attribute__((__may_alias__));, or you can say std::memcpy the object into
an correspondigly sized array of UChar and hash that rather than the
original object, etc.
Thank you for your reply.It helps me a lot.
I have found a virtual register table_26 coming from hell,no one generates
this register but use as the base of the m_table.Tree representation must have
damages because that violation.
[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32380 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32380action=edit gcc49-pr60557.patch This should hopefully fix it.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 Mike Frysinger vapier at gentoo dot org changed: What|Removed |Added CC||vapier at gentoo dot org --- Comment #2 from Mike Frysinger vapier at gentoo dot org --- *** Bug 60558 has been marked as a duplicate of this bug. ***
[Bug target/60558] building glibc-2.19 w/gcc-4.8.x on ia64 produces bad ld.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60558 Mike Frysinger vapier at gentoo dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mike Frysinger vapier at gentoo dot org --- ugh forgot there was one already opened *** This bug has been marked as a duplicate of bug 60465 ***
[Bug target/60558] New: building glibc-2.19 w/gcc-4.8.x on ia64 produces bad ld.so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60558
Bug ID: 60558
Summary: building glibc-2.19 w/gcc-4.8.x on ia64 produces bad
ld.so
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vapier at gentoo dot org
CC: toolchain at gentoo dot org
Host: ia64-linux-gnu
Target: ia64-linux-gnu
Build: ia64-linux-gnu
if you build current master glibc w/gcc-4.8.2 binutils-2.23.2 like so:
../configure --prefix=/usr libc_cv_ehdr_start=no
make -j4
then try to run a simple app like so:
echo 'main(){puts(HI);}' | gcc -x c - -o a.out
./elf/ld.so --library-path $PWD ./a.out
it crashes like so:
Segmentation fault (core dumped)
i suspect bad code generation because:
- recompiling only elf/rtld.c w/gcc-4.7.3 produces a working build
- the C code looks correct (via poking; see below)
- tweaking the code slightly produces a working build w/4.8:
- else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
-info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
- + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
+{
+ size_t i = DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
+ + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM;
+ info[i] = dyn;
+}
throwing it into a debugger shows:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.
(gdb) run
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x2008b010 in elf_get_dynamic_info (temp=0x0, l=0x200800051b08
_rtld_local+2456) at get-dynamic-info.h:61
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
(gdb) list
56else if ((d_tag_utype) DT_VALTAGIDX (dyn-d_tag) DT_VALNUM)
57 info[DT_VALTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
58 + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
59else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
60 info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
62++dyn;
63 }
64
65 #define DL_RO_DYN_TEMP_CNT 8
the info pointer is sane:
(gdb) p _rtld_global._dl_rtld_map.l_info
$1 = (Elf64_Dyn *(*)[77]) 0x2008000515d8 _rtld_local+2520
(gdb) print info
$2 = (Elf64_Dyn **) 0x2008000515d8 _rtld_local+2520
as is the dyn tag:
(gdb) print dyn
$3 = (Elf64_Dyn *) 0x20080004c8d8
(gdb) print *dyn
$4 = {
d_tag = 0x6ef5,
d_un = {
d_val = 0x2d8,
d_ptr = 0x2d8
}
}
that calculated offset is 0x4c and the link map is big enough to hold it:
(gdb) print sizeof(_rtld_local._dl_rtld_map.l_info) /
sizeof(_rtld_local._dl_rtld_map.l_info[0])
$5 = 0x4d
but the assembly is clearly wrong:
(gdb) display/i $pc
1: x/i $pc
= 0x2008b271 _dl_start+2737: (p07) st8 [r14]=r15
(gdb) p $r15
$6 = 0x20080004c8d8
(gdb) p $r14
$7 = 0x51838
$r15 is set to the right value (dyn), but r14 is now incomplete. stepping
through the previous ~20 insns shows that the right value doesn't get near $r14
... but my ia64 asm skills are not great, so i could be missing something.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465
devurandom at gmx dot net changed:
What|Removed |Added
Target||ia64-unknown-linux-gnu
Known to work||4.7.3
Host||ia64-unknown-linux-gnu
Known to fail||4.8.2
Build||ia64-unknown-linux-gnu
--- Comment #3 from devurandom at gmx dot net ---
Mike Frysinger 2014-03-18 07:17:05 UTC
if you build current master glibc w/gcc-4.8.2 binutils-2.23.2 like so:
../configure --prefix=/usr libc_cv_ehdr_start=no
make -j4
then try to run a simple app like so:
echo 'main(){puts(HI);}' | gcc -x c - -o a.out
./elf/ld.so --library-path $PWD ./a.out
it crashes like so:
Segmentation fault (core dumped)
i suspect bad code generation because:
- recompiling only elf/rtld.c w/gcc-4.7.3 produces a working build
- the C code looks correct (via poking; see below)
- tweaking the code slightly produces a working build w/4.8:
- else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
-info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
- + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
+{
+ size_t i = DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
+ + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM;
+ info[i] = dyn;
+}
throwing it into a debugger shows:
$ gdb --args ./elf/ld.so --library-path $PWD ./a.out
Reading symbols from /home/vapier/glibc/build/elf/ld.so...done.
(gdb) run
Starting program: /home/vapier/glibc/build/./elf/ld.so --library-path
/home/vapier/glibc/build ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x2008b010 in elf_get_dynamic_info (temp=0x0, l=0x200800051b08
_rtld_local+2456) at get-dynamic-info.h:61
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
(gdb) list
56else if ((d_tag_utype) DT_VALTAGIDX (dyn-d_tag) DT_VALNUM)
57 info[DT_VALTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
58 + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn;
59else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM)
60 info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM
61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn;
62++dyn;
63 }
64
65 #define DL_RO_DYN_TEMP_CNT 8
the info pointer is sane:
(gdb) p _rtld_global._dl_rtld_map.l_info
$1 = (Elf64_Dyn *(*)[77]) 0x2008000515d8 _rtld_local+2520
(gdb) print info
$2 = (Elf64_Dyn **) 0x2008000515d8 _rtld_local+2520
as is the dyn tag:
(gdb) print dyn
$3 = (Elf64_Dyn *) 0x20080004c8d8
(gdb) print *dyn
$4 = {
d_tag = 0x6ef5,
d_un = {
d_val = 0x2d8,
d_ptr = 0x2d8
}
}
that calculated offset is 0x4c and the link map is big enough to hold it:
(gdb) print sizeof(_rtld_local._dl_rtld_map.l_info) /
sizeof(_rtld_local._dl_rtld_map.l_info[0])
$5 = 0x4d
but the assembly is clearly wrong:
(gdb) display/i $pc
1: x/i $pc
= 0x2008b271 _dl_start+2737: (p07) st8 [r14]=r15
(gdb) p $r15
$6 = 0x20080004c8d8
(gdb) p $r14
$7 = 0x51838
$r15 is set to the right value (dyn), but r14 is now incomplete. stepping
through the previous ~20 insns shows that the right value doesn't get near $r14
... but my ia64 asm skills are not great, so i could be missing something.
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #12 from Magnus Reftel magnus.reftel at gmail dot com --- Any suggestions on how to progress with this one?
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #8 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Mikael Pettersson from comment #5) Sorry, no joy. With Eric's suggested patch I still got: Correction: Eric's suggested patch does work. In my previous attempt I applied his patch and only did an incremental rebuild, and that didn't resolve all testsuite regressions. Now I've done a clean build from scratch and the testsuite regressions are in fact gone.
[Bug tree-optimization/60559] New: g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60559 Bug ID: 60559 Summary: g++.dg/vect/pr60023.cc fails with -fno-tree-dce (ICE) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: enkovich.gnu at gmail dot com Test gcc/testsuite/g++.dg/vect/pr60023.cc -fno-tree-dce fails with ICE if executed with additional -fno-tree-dce flag. As I can see the problem is in generated mask load which operated with integer types: int * _13; int _14; ... _14 = MASK_LOAD (_13, 0B, _ifc__37); With DCE we have LHS of this call removed and then statement ignored in expand_MASK_LOAD. But with no DCE we get ICE because there is no proper code in optab. I use gcc (GCC) 4.9.0 20140317 (experimental). gcc -O2 -ftree-vectorize -fno-vect-cost-model -msse2 -fdump-tree-vect-details -O3 -std=c++11 -fnon-call-exceptions -mavx2 -S -o pr60023.s pr60023.cc -fno-tree-dce /export/users/ienkovic/gcc/gcc/testsuite/g++.dg/vect/pr60023.cc: In function 'void f1(int*, int*, int*)': /export/users/ienkovic/gcc/gcc/testsuite/g++.dg/vect/pr60023.cc:14:17: internal compiler error: in maybe_gen_insn, at optabs.c:8250 p[i] = q[i] + 1; ^ 0xc421d0 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/optabs.c:8250 0xc42629 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/optabs.c:8294 0xc426bd expand_insn(insn_code, unsigned int, expand_operand*) /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/optabs.c:8325 0xb27d95 expand_MASK_LOAD /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/internal-fn.c:837 0xb2807f expand_internal_call(gimple_statement_base*) /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/internal-fn.c:886 0x8f483f expand_call_stmt /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:2190 0x8f815a expand_gimple_stmt_1 /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:3160 0x8f87a4 expand_gimple_stmt /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:3312 0x8febbd expand_gimple_basic_block /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:5152 0x9006a5 gimple_expand_cfg /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:5731 0x900d20 execute /gnumnt/msticlxl7_users/ienkovic/point-lookout/gcc-pl/gcc/cfgexpand.c:5951
[Bug tree-optimization/57521] [4.7 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 18 08:46:21 2014 New Revision: 208632 URL: http://gcc.gnu.org/viewcvs?rev=208632root=gccview=rev Log: 2014-03-18 Richard Biener rguent...@suse.de Backport from mainline 2013-08-27 Richard Biener rguent...@suse.de PR tree-optimization/57521 * tree-if-conv.c (if_convertible_bb_p): Verify that at least one edge is non-critical. (find_phi_replacement_condition): Make sure to use a non-critical edge. Cleanup and remove old bug workarounds. (bb_postdominates_preds): Remove. (if_convertible_loop_p_1): Do not compute post-dominators. (combine_blocks): Do not free post-dominators. (main_tree_if_conversion): Likewise. * gcc.dg/torture/pr57521.c: New testcase. 2013-09-03 Richard Biener rguent...@suse.de PR middle-end/57656 * fold-const.c (negate_expr_p): Fix division case. (negate_expr): Likewise. * gcc.dg/torture/pr57656.c: New testcase. 2013-11-19 Richard Biener rguent...@suse.de PR tree-optimization/57517 * tree-predcom.c (combinable_refs_p): Verify the combination is always executed when the refs are. * gfortran.fortran-torture/compile/pr57517.f90: New testcase. * gcc.dg/torture/pr57517.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57517.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57521.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57656.c branches/gcc-4_7-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr57517.f90 Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/fold-const.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-if-conv.c branches/gcc-4_7-branch/gcc/tree-predcom.c
[Bug tree-optimization/57656] [4.7 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 18 08:46:21 2014 New Revision: 208632 URL: http://gcc.gnu.org/viewcvs?rev=208632root=gccview=rev Log: 2014-03-18 Richard Biener rguent...@suse.de Backport from mainline 2013-08-27 Richard Biener rguent...@suse.de PR tree-optimization/57521 * tree-if-conv.c (if_convertible_bb_p): Verify that at least one edge is non-critical. (find_phi_replacement_condition): Make sure to use a non-critical edge. Cleanup and remove old bug workarounds. (bb_postdominates_preds): Remove. (if_convertible_loop_p_1): Do not compute post-dominators. (combine_blocks): Do not free post-dominators. (main_tree_if_conversion): Likewise. * gcc.dg/torture/pr57521.c: New testcase. 2013-09-03 Richard Biener rguent...@suse.de PR middle-end/57656 * fold-const.c (negate_expr_p): Fix division case. (negate_expr): Likewise. * gcc.dg/torture/pr57656.c: New testcase. 2013-11-19 Richard Biener rguent...@suse.de PR tree-optimization/57517 * tree-predcom.c (combinable_refs_p): Verify the combination is always executed when the refs are. * gfortran.fortran-torture/compile/pr57517.f90: New testcase. * gcc.dg/torture/pr57517.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57517.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57521.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57656.c branches/gcc-4_7-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr57517.f90 Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/fold-const.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-if-conv.c branches/gcc-4_7-branch/gcc/tree-predcom.c
[Bug tree-optimization/57517] [4.7 Regression] internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/57521] [4.7 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/57517] [4.7 Regression] internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 18 08:46:21 2014 New Revision: 208632 URL: http://gcc.gnu.org/viewcvs?rev=208632root=gccview=rev Log: 2014-03-18 Richard Biener rguent...@suse.de Backport from mainline 2013-08-27 Richard Biener rguent...@suse.de PR tree-optimization/57521 * tree-if-conv.c (if_convertible_bb_p): Verify that at least one edge is non-critical. (find_phi_replacement_condition): Make sure to use a non-critical edge. Cleanup and remove old bug workarounds. (bb_postdominates_preds): Remove. (if_convertible_loop_p_1): Do not compute post-dominators. (combine_blocks): Do not free post-dominators. (main_tree_if_conversion): Likewise. * gcc.dg/torture/pr57521.c: New testcase. 2013-09-03 Richard Biener rguent...@suse.de PR middle-end/57656 * fold-const.c (negate_expr_p): Fix division case. (negate_expr): Likewise. * gcc.dg/torture/pr57656.c: New testcase. 2013-11-19 Richard Biener rguent...@suse.de PR tree-optimization/57517 * tree-predcom.c (combinable_refs_p): Verify the combination is always executed when the refs are. * gfortran.fortran-torture/compile/pr57517.f90: New testcase. * gcc.dg/torture/pr57517.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57517.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57521.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57656.c branches/gcc-4_7-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr57517.f90 Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/fold-const.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-if-conv.c branches/gcc-4_7-branch/gcc/tree-predcom.c
[Bug tree-optimization/57656] [4.7 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/60560] New: Problem allocating character array with assumed length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60560 Bug ID: 60560 Summary: Problem allocating character array with assumed length Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com The following code does not compile with gfortran (either 4.7.3 or trunk). My understanding is that the code is legal but gfortran is confused by the fact that: s_tmp takes its length from s s is allocated to size(s_tmp) The point is, the lengths of both s and s_tmp are fixed on entry in the subroutine, and the allocation statement uses size(s_tmp) which has nothing to do with s. (For what is worth, the code compiles with ifort). module mstr implicit none contains subroutine sub(s) character(len=*), allocatable, intent(out) :: s(:) character(len=len(s)), allocatable :: s_tmp(:) ! does not work !character(len=10), allocatable :: s_tmp(:) ! this works allocate(s_tmp(5)) allocate(s(size(s_tmp))) end subroutine sub end module mstr gfortran -c mstr.f90 mstr.f90:11.12: allocate(s(size(s_tmp))) 1 Error: 's' must not appear in the array specification at (1) in the same ALLOCATE statement where it is itself allocated
[Bug fortran/60561] New: ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 Bug ID: 60561 Summary: ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org A similar backtrace one gets for PR c++/58907. Compiling the testsuite's gfortran.dg/associate_1.f03 with gfortran leads to an ICE. The is no ICE if one runs gfortran -std=f2003 -fall-intrinsics -cpp associate_1.f03 as it is done in the test suite itself. $ gfortran associate_1.f03 Warning: associate_1.f03:97: Illegal preprocessor directive Warning: associate_1.f03:112: Illegal preprocessor directive associate_1.f03: In function ‘test_char’: associate_1.f03:104:0: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1721 str = foobar ^ 0x8a998a gimplify_var_or_parm_decl ../../gcc/gimplify.c:1721 0x8b0424 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:7879 0x8b8edd gimplify_addr_expr ../../gcc/gimplify.c:4801
[Bug sanitizer/60557] UBSAN: ICE after ubsan_expand_null_ifn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60557 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) This should hopefully fix it. Looks good to me. For the testcase of comment 1, it also gives the expected run-time diagnostic: test.f90:19: runtime error: signed integer overflow: 809078955 * 65539 cannot be represented in type 'integer(kind=4)'
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- So it should be rejected without -std=f2003?
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-18 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.6 to trunk. The -cpp option is enough to let the code compile.
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- So it should be rejected without -std=f2003? Compiling the code with -std=f2003 -fall-intrinsics gives the ICE (without -fall-intrinsics there is a link error Undefined symbols for architecture x86_64: _abort_, referenced from: ).
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE is in the following subroutine SUBROUTINE test_char (n) INTEGER, INTENT(IN) :: n CHARACTER(LEN=n) :: str str = foobar ASSOCIATE (my = str) END ASSOCIATE END SUBROUTINE test_char
[Bug target/60562] New: ’4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562 Bug ID: 60562 Summary: ’4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test on x86_64-apple-darwin13 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, rth at gcc dot gnu.org Host: x86_64-apple-darwin1* Target: x86_64-apple-darwin1* Build: x86_64-apple-darwin1* The test gcc.target/i386/excess-precision-3.c has started to fail at run time on x86_64-apple-darwin1* between revisions r208581 (pass) and r208594 (fail). AFAICT the only relevant changes in this range are in r208587.
[Bug target/60039] sh3 optimisation bug with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039 --- Comment #8 from Nick Hudson skrll at netbsd dot org --- On 03/18/14 02:34, kkojima at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60039 --- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Ugh, then this is an old problem and we've missed to give a correct clobber information to udivsi3_i1 insn for PIC. Does the patch below fix the issue? --- gcc/config/sh/sh.md.orig2013-09-13 17:38:22.0 +0900 +++ gcc/config/sh/sh.md2014-03-18 11:08:19.868887133 +0900 @@ -2152,6 +2152,7 @@ (udiv:SI (reg:SI R4_REG) (reg:SI R5_REG))) (clobber (reg:SI T_REG)) (clobber (reg:SI PR_REG)) + (clobber (reg:SI R1_REG)) (clobber (reg:SI R4_REG)) (use (match_operand:SI 1 arith_reg_operand r))] TARGET_SH1 TARGET_DIVIDE_CALL_DIV1 yes, this patch helps ld.elf_so. I seem to have a different problem in libc now. Thanks, Nick
[Bug target/60563] New: FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563 Bug ID: 60563 Summary: FAIL: g++.dg/ext/sync-4.C on *-apple-darwin* Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, ian at gcc dot gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* Running target unix/-m32 FAIL: g++.dg/ext/sync-4.C -std=gnu++98 execution test FAIL: g++.dg/ext/sync-4.C -std=gnu++11 execution test FAIL: g++.dg/ext/sync-4.C -std=gnu++1y execution test Running target unix/-m64 FAIL: g++.dg/ext/sync-4.C -std=gnu++98 (test for excess errors) UNRESOLVED: g++.dg/ext/sync-4.C -std=gnu++98 compilation failed to produce executable FAIL: g++.dg/ext/sync-4.C -std=gnu++11 (test for excess errors) UNRESOLVED: g++.dg/ext/sync-4.C -std=gnu++11 compilation failed to produce executable FAIL: g++.dg/ext/sync-4.C -std=gnu++1y (test for excess errors) UNRESOLVED: g++.dg/ext/sync-4.C -std=gnu++1y compilation failed to produce executable There is no failure at r204199, but I see them at r204372. Since the test has been introduced in r204360, it is likely that it has never worked on darwin. For -m32 the run time failure is terminate called after throwing an instance of 'int' For -m64 the compilation aborts on /opt/gcc/work/gcc/testsuite/g++.dg/ext/sync-4.C:12:47: error: conflicting declaration 'typedef long int int64_t' In file included from /opt/gcc/build_w/gcc/include-fixed/stdint.h:30:0, from /opt/gcc/build_w/gcc/include/stdint.h:9, from /usr/include/sys/resource.h:72, from /usr/include/sys/wait.h:110, from /usr/include/stdlib.h:65, from /opt/gcc/work/gcc/testsuite/g++.dg/ext/sync-4.C:8: /usr/include/sys/_types/_int64_t.h:30:20: note: previous declaration as 'typedef long long int int64_t'
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #14 from Rainer Orth ro at gcc dot gnu.org --- The new testcase FAILs on Solaris 9/x86 on mainline: FAIL: gfortran.dg/fmt_en.f90 -O0 execution test FAIL: gfortran.dg/fmt_en.f90 -O1 execution test FAIL: gfortran.dg/fmt_en.f90 -O2 execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_en.f90 -O3 -g execution test FAIL: gfortran.dg/fmt_en.f90 -Os execution test E.g. at -O0: (en15.0)999.E-03 expected: 1.E+00 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0)999.E+00 expected: 1.E+03 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 9.E+00 expected: 10.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0) 99.E+00 expected: 100.E+00 (en15.0)999.E+00 expected: 1.E+03 (en15.0)999.E+00 expected: 1.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.2)9.99E+03 expected:10.00E+03 (en15.3) 9.999E+03 expected: 10.000E+03 (en15.1) 9.4E+00 expected: 9.5E+00 (en15.1)99.9E-03 expected:100.0E-03 (en15.1) 9.9E-03 expected: 10.0E-03 (en15.1) 999.9E-06 expected: 1.0E-03 (en15.0) -999.E-03 expected: -1.E+00 (en15.0) -9.E+00 expected: -10.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -9.E+00 expected: -10.E+00 (en15.0) -9.E+00 expected: -10.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0)-99.E+00 expected:-100.E+00 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -999.E+00 expected: -1.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.2) -9.99E+03 expected: -10.00E+03 (en15.3) -9.999E+03 expected: -10.000E+03 (en15.1)-9.4E+00 expected: -9.5E+00 (en15.1) -99.9E-03 expected: -100.0E-03 (en15.1)-9.9E-03 expected:-10.0E-03 (en15.1) -999.9E-06 expected: -1.0E-03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.2) 98.73E+03 expected:98.74E+03 (en15.3) 9.873E+03 expected:9.874E+03 (en15.1)93.7E-03 expected: 93.8E-03 (en15.2) 46.87E-03 expected:46.88E-03 (en15.3) 23.437E-03 expected: 23.438E-03 (en15.6)2.929687E-03 expected: 2.929688E-03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.2) -98.73E+03 expected: -98.74E+03 (en15.3) -9.873E+03 expected: -9.874E+03 (en15.1) -93.7E-03 expected:-93.8E-03 (en15.2) -46.87E-03 expected: -46.88E-03 (en15.3) -23.437E-03 expected: -23.438E-03 (en15.6) -2.929687E-03 expected:-2.929688E-03 Program aborted. Backtrace: #0 0xB5C343F6 #1 0xB5C35D66 #2 0xB5CF6223 #3 0x8051C27 in MAIN__ at fmt_en.f90:? Rainer
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
next_variant-type_name-type-next_variant-type-name-decl_original_type-type_name-decl_context-next_variant-type_context-next_variant-next_variant-next_variant-type_fields-type-...
it's walking a type hierarchy, up-and-down. Ideally the GC walking would
be more structured here, but ...
Can you try if sth as simple as
Index: gcc/tree-core.h
===
--- gcc/tree-core.h (revision 208615)
+++ gcc/tree-core.h (working copy)
@@ -1265,11 +1265,11 @@ struct GTY(()) tree_type_common {
const char * GTY ((tag (TYPE_SYMTAB_IS_POINTER))) pointer;
struct die_struct * GTY ((tag (TYPE_SYMTAB_IS_DIE))) die;
} GTY ((desc (debug_hooks-tree_type_symtab_field))) symtab;
- tree name;
+ tree canonical;
tree next_variant;
tree main_variant;
tree context;
- tree canonical;
+ tree name;
};
struct GTY(()) tree_type_with_lang_specific {
helps? That makes sure to first walk fields that point us downward the
type hierarchy and then those that point us upward?
With LTO it may be the case that TYPE_CANONICAL connects very many types
that are otherwise unrelated ...
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- How about showing the previous ~20 insns here.
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Correction: Eric's suggested patch does work. In my previous attempt I applied his patch and only did an incremental rebuild, and that didn't resolve all testsuite regressions. Now I've done a clean build from scratch and the testsuite regressions are in fact gone. That's good news, thanks. Did you do a testsuite run for all languages?
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any reason why tho PR is not closed as fixed?
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 58339 has been marked as a duplicate of this bug. ***
[Bug fortran/58339] ASSOCIATE construct to arrays: Wrong results (pointer to array/array descriptor issue?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58339 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR has been fixed between r207428 and r207996 (likely r207646). It looks like a duplicate of pr57522. Possibly related to PR 58085. IMO pr58085 is a different issue (yet another off by one bug). *** This bug has been marked as a duplicate of bug 57522 ***
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Paul Thomas pault at gcc dot gnu.org --- No reason whatsoever, except that I forgot! Thanks for the report. Paul
[Bug middle-end/58941] [4.7 Regression] value modification on zero-length array optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 18 10:58:22 2014 New Revision: 208640 URL: http://gcc.gnu.org/viewcvs?rev=208640root=gccview=rev Log: 2014-03-18 Richard Biener rguent...@suse.de Backport from mainline 2013-11-05 Richard Biener rguent...@suse.de PR middle-end/58941 * tree-dfa.c (get_ref_base_and_extent): Merge common code in MEM_REF and TARGET_MEM_REF handling. Make sure to process trailing array detection before diving into the view-converted object (and possibly apply some extra offset). * gcc.dg/torture/pr58941.c: New testcase. 2012-05-07 Eric Botcazou ebotca...@adacore.com * tree-dfa.c (get_ref_base_and_extent) ARRAY_REF: Do the offset computation using the precision of the index type. 2012-05-31 Eric Botcazou ebotca...@adacore.com * tree-dfa.c (get_ref_base_and_extent): Compute the offset using double ints throughout. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr58941.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-dfa.c
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- FYI, since r208573 the reduced ppc64 testcase no longer reproduces, but the #c0 still does.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the output of write(*,(en15.1)) 9.4905 end ? If it is 9.4, it means that your snprintf is not rounding to nearest but to zero.
[Bug fortran/60561] ICE in gimplify_var_or_parm_decl, at gimplify.c:1721 for gfortran.dg/associate_1.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60561 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords|accepts-invalid,|ice-on-valid-code |ice-on-invalid-code | --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) So it should be rejected without -std=f2003? As -std=f2003 is implied by the default -std=gnu: No. In any case, the code in comment 4 looks valid. - Changed to ice-on-valid-code.
[Bug c++/60553] segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60553
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Another idea would be (many next-variant walks in the call stack)
Index: lto/lto-tree.h
===
--- lto/lto-tree.h (revision 208615)
+++ lto/lto-tree.h (working copy)
@@ -48,7 +48,7 @@ enum lto_tree_node_structure_enum {
};
union GTY((desc (lto_tree_node_structure (%h)),
- chain_next (CODE_CONTAINS_STRUCT (TREE_CODE (%h.generic),
TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN (%h.generic)) : NULL)))
+ chain_next (CODE_CONTAINS_STRUCT (TREE_CODE (%h.generic),
TS_TYPE_COMMON) ? ((union lang_tree_node *) TYPE_NEXT_VARIANT (%h.generic)) :
CODE_CONTAINS_STRUCT (TREE_CODE (%h.generic), TS_COMMON) ? ((union
lang_tree_node *) TREE_CHAIN (%h.generic)) : NULL)))
lang_tree_node
{
union tree_node GTY ((tag (TS_LTO_GENERIC),
[Bug middle-end/58941] [4.7 Regression] value modification on zero-length array optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the output of write(*,(en15.1)) 9.4905 end ? If it is 9.4, it means that your snprintf is not rounding to nearest but to zero. No, that's not it: I get 9.5E+00 Rainer
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- Could your repeat the test for write(*,(en15.1)) 9.4905_8 end write(*,(en15.1)) 9.4905_10 end and write(*,(en15.1)) 9.4905_16 end ?
[Bug ipa/60325] [4.9 Regression] ICE in ipa_modify_formal_parameters, at ipa-prop.c compiling g++.dg/cilk-plus/CK/lambda_spawns.cc with LTO-profiledbootstrap build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60325 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Thus fixed?
[Bug ipa/60325] [4.9 Regression] ICE in ipa_modify_formal_parameters, at ipa-prop.c compiling g++.dg/cilk-plus/CK/lambda_spawns.cc with LTO-profiledbootstrap build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60325 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #3) Thus fixed? Hard to say, but the testsuite failure is gone and we have no testcase...
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #10 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Eric Botcazou from comment #9) That's good news, thanks. Did you do a testsuite run for all languages? Sorry, didn't have time for that -- the repeated 4.9 builds and tests caused other build-and-test jobs to pile up and I need to get those done first.
[Bug c/55896] Annoying compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think there's a bug in the program. We inline w_strlen function. Now, if buffer is NULL, we don't compute w_strlen, as the result is 0. But since the call to strncat is strncat(content_2, content_1, w_strlen(content_1) - 1);, we pass -1 as n to strncat, which is casted to size_t, that means we end up with __builtin___strncat_chk (content_2, content_1, 18446744073709551615, 1024);.
[Bug other/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Hasn't this been fixed by r208383 and r208384 ?
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Mar 18 11:31:04 2014 New Revision: 208641 URL: http://gcc.gnu.org/viewcvs?rev=208641root=gccview=rev Log: PR ipa/58721 gcc/ * internal-fn.c: Include diagnostic-core.h. (expand_BUILTIN_EXPECT): New function. * gimplify.c (gimplify_call_expr): Use false instead of FALSE. (gimplify_modify_expr): Gimplify 3 argument __builtin_expect into IFN_BUILTIN_EXPECT call instead of __builtin_expect builtin call. * ipa-inline-analysis.c (find_foldable_builtin_expect): Handle IFN_BUILTIN_EXPECT. * predict.c (expr_expected_value_1): Handle IFN_BUILTIN_EXPECT. Revert 3 argument __builtin_expect code. (strip_predict_hints): Handle IFN_BUILTIN_EXPECT. * gimple-fold.c (gimple_fold_call): Likewise. * tree.h (fold_builtin_expect): New prototype. * builtins.c (build_builtin_expect_predicate): Add predictor argument, if non-NULL, create 3 argument __builtin_expect. (fold_builtin_expect): No longer static. Add ARG2 argument, pass it through to build_builtin_expect_predicate. (fold_builtin_2): Adjust caller. (fold_builtin_3): Handle BUILT_IN_EXPECT. * internal-fn.def (BUILTIN_EXPECT): New. gcc/fortran/ * trans.c (gfc_unlikely, gfc_likely): Don't add __builtin_expect if !optimize. 2014-03-18 Tobias Burnus bur...@net-b.de PR ipa/58721 gcc/ * predict.def (PRED_FORTRAN_OVERFLOW, PRED_FORTRAN_FAIL_ALLOC, PRED_FORTRAN_FAIL_IO, PRED_FORTRAN_WARN_ONCE, PRED_FORTRAN_SIZE_ZERO, PRED_FORTRAN_INVALID_BOUND, PRED_FORTRAN_ABSENT_DUMMY): Add. gcc/fortran/ * trans.h (gfc_unlikely, gfc_likely): Add predictor as argument. (gfc_trans_io_runtime_check): Remove. * trans-io.c (gfc_trans_io_runtime_check): Make static; add has_iostat as argument, add predictor to block. (set_parameter_value, gfc_trans_open, gfc_trans_close, build_filepos, gfc_trans_inquire, gfc_trans_wait, build_dt): Update calls. * trans.c (gfc_unlikely, gfc_likely): Add predictor as argument. (gfc_trans_runtime_check, gfc_allocate_using_malloc, gfc_allocate_allocatable, gfc_deallocate_with_status): Set explicitly branch predictor. * trans-expr.c (gfc_conv_procedure_call): Ditto. * trans-stmt.c (gfc_trans_allocate): Ditto. * trans-array.c (gfc_array_init_size, gfc_array_allocate): Ditto. 2014-03-18 Jan Hubicka hubi...@ucw.cz PR ipa/58721 gcc/ * predict.c (combine_predictions_for_bb): Fix up formatting. (expr_expected_value_1, expr_expected_value): Add predictor argument, fill what it points to if non-NULL. (tree_predict_by_opcode): Adjust caller, use the predictor. * predict.def (PRED_COMPARE_AND_SWAP): Add. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-io.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/gimple-fold.c trunk/gcc/gimplify.c trunk/gcc/internal-fn.c trunk/gcc/internal-fn.def trunk/gcc/ipa-inline-analysis.c trunk/gcc/predict.c trunk/gcc/predict.def trunk/gcc/tree.h
[Bug c/55896] Annoying compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896 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 --- But there is content_1[0] == '[' guard around it, but likely just no optimization figures out that the inlined w_strlen (why aren't you using strlen???) will always return at least 1 and thus the jump threaded variant with zero length is dead. I suppose instead of using w_strlen (contents_1) - 1 you could just use w_strlen (contents_1 + 1) and the warning could go away.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 Bug 59487 depends on bug 58721, which changed state. Bug 58721 Summary: [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org --- Hopefully fixed.
[Bug ipa/60315] [4.8/4.9 Regression] template constructor switch optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- BTW, the #c0 testcase regressed with r179083.
[Bug target/60562] [4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|’4.9 Regression] FAIL: |[4.9 Regression] FAIL: |gcc.target/i386/excess-prec |gcc.target/i386/excess-prec |ision-3.c execution test on |ision-3.c execution test on |x86_64-apple-darwin13 |x86_64-apple-darwin13
[Bug c/55896] Annoying compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896 --- Comment #3 from sworddragon2 at aol dot com --- why aren't you using strlen??? Because of this bug (if it should be still valid): https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1035321
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- Could your repeat the test for write(*,(en15.1)) 9.4905_8 end 9.5E+00 write(*,(en15.1)) 9.4905_10 end 9.5E+00 write(*,(en15.1)) 9.4905_16 end 9.4E+00 Rainer
[Bug c/55896] Annoying compiler warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55896 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to sworddragon2 from comment #3) why aren't you using strlen??? Because of this bug (if it should be still valid): https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1035321 That is a valgrind issue, not a GCC bug though.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr --- write(*,(en15.1)) 9.4905_16 end 9.4E+00 So the test fails due to a bug in the rounding of real(16) in your lib. Do you have any idea about how the tests for real(16) can be skipped on Solaris 9/x86?
[Bug libstdc++/60564] New: [C++11] The std::packaged_task constructor taking a reference to a functor does not copy its argument.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564
Bug ID: 60564
Summary: [C++11] The std::packaged_task constructor taking a
reference to a functor does not copy its argument.
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ralph.tandetzky at gmail dot com
The following code compiles successfully:
~
#include future
#include iostream
using namespace std;
struct Test
{
Test() { cout constructed. endl; }
Test( const Test ) { cout copied. endl; }
Test( Test ) { cout moved.endl; }
void operator()() const {}
};
int main()
{
Test t;
packaged_taskvoid() pt1( t );
}
~
It produces the following output:
~
constructed.
moved.
~
However, the constructor of std::packaged_taskvoid() should copy it's
argument into its internally stored task object according to 30.6.9.1 of the
C++11 standard (I'm referring to N3485, actually).
Settings: I've used the online-compiler of http://en.cppreference.com/ with the
compiler GCC 4.8 (C++11). GCC 4.7 (C++11) does not have the bug, but produces a
correct output copying the object passed into the constructor.
[Bug c/55383] -Wcast-qual reports incorrect message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55383 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Magnus Reftel from comment #12) Any suggestions on how to progress with this one? Looking at the testcases modified by the patch, I don't know why there is no test for volatile (which is what triggers this bug). I will take a look at the output of the testsuite this weekend. It is probable that there is a testcase for this, but the test matching text is not precise enough. Once I check this, I will commit the patch since it was approved by Joseph here: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00532.html
[Bug target/60459] Crash seen in _Unwind_VRS_Pop() for ARM platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60459 Raghu raghupv30 at gmail dot com changed: What|Removed |Added Severity|normal |critical
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #37 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Richard Henderson from comment #35) Author: rth Date: Thu Mar 13 20:24:56 2014 New Revision: 208556 Hi, this seems to have created a new regression: FAIL: gcc.target/i386/excess-precision-3.c execution test
[Bug libstdc++/60564] [C++11] The std::packaged_task constructor taking a reference to a functor does not copy its argument.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60564 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-18 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Oops, yes, it uses std::move when it should be std::forward
[Bug target/60562] [4.9 Regression] FAIL: gcc.target/i386/excess-precision-3.c execution test after r208587
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60562 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Target|x86_64-apple-darwin1* | Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-18 Host|x86_64-apple-darwin1* | Summary|[4.9 Regression] FAIL: |[4.9 Regression] FAIL: |gcc.target/i386/excess-prec |gcc.target/i386/excess-prec |ision-3.c execution test on |ision-3.c execution test |x86_64-apple-darwin13 |after r208587 Ever confirmed|0 |1 Build|x86_64-apple-darwin1* | --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also seen on linux: http://gcc.gnu.org/ml/gcc-regression/2014-03/msg00088.html
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #38 from Dominique d'Humieres dominiq at lps dot ens.fr --- Hi, this seems to have created a new regression: FAIL: gcc.target/i386/excess-precision-3.c execution test pr60562
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #20 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- We can xfail the test case if we are certain of the problem.
