bug or idiosyncrasy?
Compiling the following code with D defined works. Leave it out (and
remove the extra dimension which has no influence on the data layout
etc) and it compiles. Is this correct? Why wouldn't a simple use of
an array parameter be sufficient?
#ifdef D
#define XD [1]
#define XR [0]
#define XBB {
#define XBE }
#else
#define XD
#define XR
#define XBB
#define XBE
#endif
int aa XD[10] = { XBB 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 XBE };
int f(int arr XD[10])
{
int s = 0;
for (auto i : arr XR)
s += i;
return s;
}
int main()
{
return f(aa);
}
Re: bug or idiosyncrasy?
On Fri, Aug 17, 2012 at 12:15 AM, Ulrich Drepper wrote: > Compiling the following code with D defined works. Leave it out (and > remove the extra dimension which has no influence on the data layout > etc) and it compiles. Is this correct? Why wouldn't a simple use of > an array parameter be sufficient? It looks like the decaying to a pointer in the function argument is what is causing the issues. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 for other related issues. Thanks, Andrew
Re: The C++ conversion branch has been merged into trunk
On 15 August 2012 03:05, Diego Novillo wrote: > > I have committed rev 190402, which merges the cxx-conversion branch into > trunk. Thanks to everyone who provided review feedback and tested the > branch. > > While we have tested the changes pretty thoroughly, we will monitor results > from testers for any new failures introduced by these changes. Please CC > myself and Lawrence on any issues that may be related to the C++ changes. > > As discussed in http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00711.html, > there are no functional changes to the compiler. We tried very hard to limit > the amount of API changes we introduced to minimize merge conflicts. > > Now that the changes are in trunk we will start changing the APIs to take > advantage of the re-written data structures. > > I have also committed the changes to the home page news section and 4.8 > changes to reflect the new implementation language. I have made Gengtype changes to support methods in structs/classes, and other minor changes, and have modified latest 4.7 parser.c to class'ize cp_parser and cp_lexer. I got operators (new) parsing, but bumped into problems with the gengtype handwritten parser with regard to constructors. So am currently working on a new gengtype frontend to support C++ 2003. Currently I am just waiting on GCC copyright assignment to come through. I will update my changes to SVN head, and give a patch once the copyright assignment has gone through. Regards, Aaron
Steering Committee
Dear SC members, I used to maintain the picochip port of GCC, but I have not been active on the picochip port over the last 8 months. This is unlikely to change in the future, so I would like my name to be removed from the maintainers list as picochip maintainer. I am still actively working on GCC, so I would like to be added to the "Write after approval" list. Thanks Hari
Re: bug or idiosyncrasy?
On 17 August 2012 08:25, Andrew Pinski wrote: > On Fri, Aug 17, 2012 at 12:15 AM, Ulrich Drepper wrote: >> Compiling the following code with D defined works. Leave it out (and >> remove the extra dimension which has no influence on the data layout >> etc) and it compiles. Is this correct? Why wouldn't a simple use of >> an array parameter be sufficient? > > It looks like the decaying to a pointer in the function argument is > what is causing the issues. > > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 for other related > issues. Those are real bugs, but in Ulrich's case the array to pointer conversion is required and I don't believe it's a bug. f(int arr[10]) has a parameter of type "array of int", so [dcl.fct]/5 says it decays to "pointer to int" i.e. the signature is f(int*) and so it's not possible to iterate over the parameter with a range-based for loop. In the working case the parameter has type "array of array of int" which decays to "pointer to array of int" and so the signature is f(int (*)[10]) and dereferencing the parameter gives an array type, which can be iterated over.
Re: New GCC takes 19x as long to compile my program (compared to old GCC), plus void** patch suggestion
On 8/13/12, Elmar Krieger wrote: > Good news, and especially the -ftime-report trick was highly useful. > > For example, I got a huge slowdown also with this compiler: > > gcc44 (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3) > Copyright (C) 2010 Free Software Foundation, Inc. > > which spends all its time in 'variable tracking': > > > variable tracking : 126.07 (89%) usr 0.26 ( 7%) sys 126.50 (87%) > wall 20647 kB ( 6%) ggc > TOTAL : 141.94 3.66 145.61 > 336368 kB > > real2m26.703s > > > And the Google Android compiler I reported originally... > > i686-linux-android-gcc (GCC) 4.6.x-google 20120106 (prerelease) > Copyright (C) 2011 Free Software Foundation, Inc. > > ...which takes more than twice as long spends its time here: > > phase cgraph : 347.75 (100%) usr 10.73 (76%) sys 358.51 (99%) > wall 130837 kB (84%) ggc > phase generate: 347.85 (100%) usr 10.77 (76%) sys 358.64 (99%) > wall 132490 kB (85%) ggc > var-tracking dataflow : 284.34 (82%) usr 0.00 ( 0%) sys 284.21 (78%) > wall 0 kB ( 0%) ggc > TOTAL : 350.0412.53 362.60 > 155292 kB > > real6m3.567s > > I really didn't expect that RedHat and Google both mess up GCC with > their modifications, so I'll report it to them instead ;-) > > Anyway, please send by private email your favorite way of receiving the > promised 100 USD. Could be PayPal, a list of Amazon.com items which are > sent to your address, a direct bank transfer etc.. Huge system times like that are really unusual. The most likely cause is that your system is running out of physical memory and doing lots of paging. If so, there are some solutions. (1) Get more memory for the machine. (2) Compile at lower levels of optimization. (3) Partition your application into smaller source files, as measured by the size of the preprocessed file that they expand into. -- Lawrence Crowl
gcc-4.6-20120817 is now available
Snapshot gcc-4.6-20120817 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120817/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 190493 You'll find: gcc-4.6-20120817.tar.bz2 Complete GCC MD5=ecf4842ed422f5e041c4aeb63e6470d4 SHA1=a5a275740fcbb1e690a97c03184741e9928d79c8 Diffs from 4.6-20120810 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Question about Dejagnu C++ Execution Test
Hello Everyone I have a question regarding a DejaGNU execution tests for C++. For C I used several C-torture routines (e.g. c-torture-execute) to add execution tests into the testsuite. I am not able to find a similar set of routine to use in C++. Can someone please point me if similar functions exists for C++? Also, any advice/pointers on how to write one would be great also. Any help on this topic is greatly appreciated! Thanks, Balaji V. Iyer. PS. Please CC when responding to this message.
Re: Question about Dejagnu C++ Execution Test
On Fri, Aug 17, 2012 at 8:34 PM, Iyer, Balaji V wrote:
> Hello Everyone
> I have a question regarding a DejaGNU execution tests for C++. For C
> I used several C-torture routines (e.g. c-torture-execute) to add execution
> tests into the testsuite. I am not able to find a similar set of routine to
> use in C++. Can someone please point me if similar functions exists for C++?
> Also, any advice/pointers on how to write one would be great also.
Use g++.dg/torture and add one of the following to the beginning:
// { dg-do compile }
// { dg-do link }
// { dg-do assemble }
// { dg-do run }
This can be done for gcc.dg/torture also.
Thanks,
Andrew Pinski
