Re: compile time regression
This is now in bugzilla as: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871 -benjamin
Re: regress and -m64
When I run bootstrap and make check, I check the -m64 option (only). Check gcc-testresults. Currently, the results don't look very good. Maybe I'm doing something wrong. Brad
Re: regress and -m64
Brad,
Why don't you try a normal multi-lib build without any
extra flags. At the moment, considering how much noise is on
the testsuite results on Darwin due to this linker warnings, I
don't think its really helpful to bother exploring corner cases
of building gcc trunk with unique flags. Make sure you have...
--- gcc-4.2-20060825/libstdc++-v3/testsuite/lib/prune.exp.org 2006-08-26
11:22:52.0 -0400
+++ gcc-4.2-20060825/libstdc++-v3/testsuite/lib/prune.exp 2006-08-26
11:23:39.0 -0400
@@ -29,5 +29,7 @@
regsub -all (^|\n)\[^\n\]*: Additional NOP may be necessary to workaround
Itanium processor A/B step errata $text text
regsub -all (^|\n)\[^\n*\]*: Assembler messages:\[^\n\]* $text text
+regsub -all (^|\n)can't find atom for N_GSYM stabs \[^\n\]* in \[^\n\]*
$text text
+
return $text
}
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
18:41:28.0 -0400
@@ -43,6 +43,7 @@
regsub -all (^|\n)\[^\n\]*file path prefix \[^\n\]* never used $text
text
regsub -all (^|\n)\[^\n\]*linker input file unused since linking not
done $text text
+regsub -all (^|\n)can't find atom for N_GSYM stabs \[^\n\]* in \[^\n\]*
$text text
#send_user After:$text\n
return $text
...applied. You will also need to apply Geoff's proposed TImode patch
from http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00581.html. Without
the TImode patch, libgfortran at least will be horribly broken since
it relies on libgcc being able to provide the TImode symbols for its
long long math operations. This will eliminate about 800 failures
from the gfortran testsuite. You need the patches above for ignoring
the linker warnings from ld64 to eliminate the remaining 40 some
false failures from the gfortran testsuite. The same is true for
libstdc++ which only really has 4 additional failures under -m64.
Jack
ps I have only patched the prune.exp to fix the builds of the
c,c++ and fortran languages. If you see massive failures for
any other language's testsuite, just look in the log for errors
of the form...
can't find atom for N_GSYM stabs
...if you seem them, the prune.exp being used for that
section of the testsuite needs a patch like those above.
Oh, when you do your make check from the top level of the
build directory use this form of the command...
make -k check RUNTESTFLAGS='--target_board=unix{,-m64}'
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote: This posting is a progress report of my task of encoding and decoding the GIMPLE stream into LTO. Included in this posting is a patch that encodes functions and dumps the result to files. Interesting email. One question: how big are the files you're generating? For example, how much space does it take to store the body of a function with 100 add operations in it (before gzip'ing it)? What is the size proportional to? # instructions, # basic blocks, what else? -Chris
Re: regress and -m64
On Aug 28, 2006, at 12:10 PM, Jack Howarth wrote:
Why don't you try a normal multi-lib build without any
extra flags.
What extra flags? The configure command is
../configure --prefix=/pkgs/gcc-mainline --with-gmp=/opt/local/ --
with-mpfr=/opt/local/
which is totally generic (one needs to specify gmp and mpfr libraries
to get fortran to build).
I build with
make -j 4 bootstrap build.log
which is completely generic.
Or do you mean the -mcpu=970 in the test options?
Oh, when you do your make check from the top level of the
build directory use this form of the command...
make -k check RUNTESTFLAGS='--target_board=unix{,-m64}'
my make check is
make -k -j 8 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
I don't see any reason to check the 32-bit stuff that the regression
checker checks at least once a day.
Brad
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Chris Lattner wrote: On Aug 28, 2006, at 6:57 AM, Kenneth Zadeck wrote: This posting is a progress report of my task of encoding and decoding the GIMPLE stream into LTO. Included in this posting is a patch that encodes functions and dumps the result to files. Interesting email. One question: how big are the files you're generating? For example, how much space does it take to store the body of a function with 100 add operations in it (before gzip'ing it)? What is the size proportional to? # instructions, # basic blocks, what else? -Chris The size will be large because the trees are still large. Encoding everything in a bootstrap for the three languages was on the order of 60mb. As you know, size is a well known problem in gcc. The plan is to track the changes in gimple and as that gets smaller, this will get smaller. I would like to get the types and perhaps the flags out of the internal nodes of the trees. when that gets done, these operations should be small. I actually do not think that it is productive to spend that much time measuring this until we first assure ourselves that we are getting all of the information output correctly. That 60mb number will change a lot (both up and down) as we get closer to getting everything tied together. Then we can spend more time looking at the pieces and seeing where we need to do better.
Re: Potential fix for rdar://4658012
Richard Kenner wrote: I disagree. Testing is not, and should never be, a substitute for analysis. A patch is proposed because we have a reason to believe it's correct. Then we test to increase our confidence that it is, indeed, correct. But both parts are essential for any patch. Here we have a situation where we'd like to see some optimization done (the merging of temporaries). There's some code that suppresses that optimization in one case because that optimization was unsafe in that case. It is not acceptable to find out whether that code is still needed by merely running a test suite: there has to be some analysis that says what changed to make that code no longer needed. The burden of proof on that analysis has to be on the person who's proposing that the code is no longer needed. Richard - I agree with you -- my intent for originally posting was to hopefully find that understanding of why the code had originally been added. Perhaps I should have better explained my own understanding, so that you could help identify if this was a conceptual mistake on my part. I think I had too much confidence that this would be an easy question to answer, but it appears that the code is quite dated and not well understood. So, without further ado, let me provide my analysis, and hopefully those who understand this code best can help point out if I've gone astray. Here is my interpretation of this code: In the code for managing middle-end-generated temps, it appears that push/pop_temp_slots is used to create nested contexts into which unique temps are generated. When I need a temp, I call push_temp_slots, allocate a temp, perform my calculation, and call pop_temp_slots when I'm done. The one exception to this is if the address of the temp is taken before I call pop_temp_slots. In that instance, even though I may be done with the temp, it needs to live until the end of the high-level-language scope, and so it is marked with addr_taken and is pushed up in the temp scopes using preserve_temp_slots. It is this logic that is used for function calls that return a value on the stack. However, in the case where we're passing the address of a temp slot to a function, it doesn't make sense to me that this is the same as other address-of operations on a stack slot. The function call (at least in C and C++) cannot preserve this address, and it is reasonable to say that attempts to access this address after the caller is done with the location, are invalid. So, for these reasons, marking the temp for a lifetime longer than what is needed by the middle-end for copying it into the destination, appeared to be excessive. Hopefully this is enough of an explanation to reveal whether my understanding is consistent or inconsistent with the experts, and can move the discussion forward. Thanks again for all of the time looking at this - it's very much appreciated. - Josh
Re: regress and -m64
Brad, I was confusing your use of -mcpu=970 in the make check with the build flags...sorry. You might stop using that flag for now until you get a baseline of how many additional failures seen in -m64 compared to -m32 are not due to the linker warnings (after you apply the TImode patch). I'll look at my last make check when I get home tonight but I don't think you should see more than an additional 20 failures for g++ and an additional 4 failures for libstdc++. The bulk of the failures are seeing must be either due to 1) the use of -mcpu=970, 2) the absence of the TImode patch or 2) not pruning the linker warnings. Jack ps I would first try retesting your current build without -mcpu=970 and then rebuild with the TImode patch and test again without -mcpu=970. Then you can patch the prune.exp and test a third time. This should give you how many failures are due to each cause.
Re: regress and -m64
On Aug 27, 2006, at 7:24 AM, Jack Howarth wrote: Can one of you remind me who we need to lobby at Apple In the gcc project, contributions are generally speaking, made by an individual. Geoff operates a regression tester, probably the one you're thinking of. In the past, he has considered building/testing non-default things, and has generally shied away from non-default things. Bear in mind, the addition of -m64 comes at the cost of being able to test less often. He isn't the only one known to contribute test results on darwin however. I'd certainly welcome a contribution of testing that included -m64, if someone has the time, resources and motivation.
Re: regress and -m64
Mike, Do you know if regress is used for anything other than building and checking gcc? Also is it a dual G5 by any chance? I ask because it is unclear if regress is doing a 'make -k -j 2 check' or not? Might that not increase the rate of testing on regress? I haven't tried that myself because I tend to use my machine during builds and make checks. However if regress is just sitting there doing gcc builds/checks, it might be worth trying that. It appears to be completeing a build/check cycle every 30 hours. Perhaps that could be significantly cut back if both processors were used. Jack
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
On Aug 28, 2006, at 10:36 AM, Kenneth Zadeck wrote: I actually do not think that it is productive to spend that much time measuring this until we first assure ourselves that we are getting all of the information output correctly. That 60mb number will change a lot (both up and down) as we get closer to getting everything tied together. Then we can spend more time looking at the pieces and seeing where we need to do better. Okay, thanks! -Chris
Re: regress and -m64
On Aug 28, 2006, at 1:20 PM, Jack Howarth wrote: Might that not increase the rate of testing on regress? Sorry, nope.
Re: gcc trunk vs python
On 8/27/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... I have not received reports about bugs in the offending code when compiled with other compilers. I do know at least one another compiler that does this, and at least one significant project (which is actually quite a bit larger than Python) that suffered similar problem as Python's suffering - in short, this isn't new and this isn't even something gcc specific (or fault). And Python isn't the first program that suffers from this either. code. But this particular optimization will let us do a much better job on very simple loops like for (int i = 0; i != n; i += 5) The issue with a loop like this is that if signed overflow is defined to be like unsigned overflow, then this loop could plausibly wrap around INT_MAX and then terminate. If signed overflow is undefined, then we do not have to worry about and correctly handle that case. That seems to me rather obviously broken code unless the programmer has proven to himself that n is a multiple of 5. So why bother attempting to optimize it? There are legitimate code with similar form, like pointer increment compared against the end pointer which happens often in string manipulation or buffer management code. More importantly some of C++ STL iterators often end up in such a form. -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
Re: regress and -m64
Mike, Well then alternatively, might not 'make -j 2' increase the rate at which gcc is built on regress? Or doesn't Darwin support parallel builds? If we can't speed up the testing then we could at least speed up the build process to free up time for -m64. After all, we are already building -m64 so it is more important to actually test what we build than to add new languages to the build process on regress. Jack
Re: regress and -m64
On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote: Well then alternatively, might not 'make -j 2' increase the rate at which gcc is built on regress? Yes, we know about -j2. When I said, sorry, nope, I meant to convey the idea that in fact that adding a -j2 won't speed it up. Or doesn't Darwin support parallel builds? Yes, of course it does. If we can't speed up the testing ? -j2 makes testing go faster as well. then we could at least speed up the build process to free up time for -m64.
Re: regress and -m64
Mike, Now I totally confused. Are you saying that '-j 2' only speeds up testing but not builds? In one sentence you say it won't speed things up and in the next you say of course it speeds things up. Which is it? Jack On Aug 28, 2006, at 3:32 PM, Jack Howarth wrote: Well then alternatively, might not 'make -j 2' increase the rate at which gcc is built on regress? Yes, we know about -j2. When I said, sorry, nope, I meant to convey the idea that in fact that adding a -j2 won't speed it up. Or doesn't Darwin support parallel builds? Yes, of course it does. If we can't speed up the testing ? -j2 makes testing go faster as well. then we could at least speed up the build process to free up time for -m64.
Re: regress and -m64
On Aug 28, 2006, at 3:57 PM, Jack Howarth wrote: If we can't speed up the testing ? -j2 makes testing go faster as well. Sigh, I misstated that one. My comment in that case was about the general case. I meant to say that -j2 is as applicable to testing as it is to building. Let me try once more, yes, we already know about adding -j2, no, it won't help.
Re: regress and -m64
Mike, Okay. How about this. Have regress set to at least do a -m64 make check once a week. At least that would show some interest in the status of gcc at 64-bit. It is baffling to most people how we can make any progress on such issues if the status isn't sampled at least once every blue moon. Jack
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Kenneth Zadeck wrote: This posting is a progress report of my task of encoding and decoding the GIMPLE stream into LTO. Included in this posting is a patch that encodes functions and dumps the result to files. I have only a limited understanding of GIMPLE and LTO, but here are my comments regarding DWARF. DWARF is a debugging format used to describe a program's source and how it is represented in an executable file. GIMPLE is an intermediate representation, not program source. It's always interesting to see one tool used in a different context, but I'm not clear that in this case you are using the right tool for the right task in the way that it was designed. Speaking on behalf of the DWARF Standards Workgroup, we welcome suggestions for extensions or improvements in the DWARF standard. I wasn't able to identify any specific extension in your email (although I didn't look at the patch in detail). If there are specific areas where DWARF can be improved, please let me know. 1) ABBREV TABLES ARE BAD FOR LTO. The abbrev table is a mechanism for making a DWARF3 file self descriptive. It contains a set of templates that are used to describe the records and attributes that are written to describe the object module. This self description mechanism is much weaker (an therefor much more compact) than an XML file's schemata because it depends on a common understanding of the meaning of the tags and attributes that describe the pieces of the data. The tags them selves can be thought of as characters, and an abbrev entry is a magic cookie that tells you how to break the characters into words. DWARF is not self-descriptive, except in the very limited sense that several sections contain version numbers. The DWARF abbreviation table is not intended to be self-descriptive or to be descriptive of the DWARF data. It is a simple compression scheme which compacts the Tag/Attribute/Value structure of a DWARF DIE into a much more condensed format. Certainly the DWARF Abbrev table makes no pretense of being anything similar to an XML schema. I wouldn't use an XML schema for debugging information (it would be huge and slow), and I wouldn't expect to use DWARF abbreviation tables to describe anything at all. However, this mechanism is only self descriptive if you do not extend the set of tags. That is not an option for LTO. While the DWARF3 designers seem to have added every conceivable tag to describe object code, it is not be surprising that this comes up short when describing GIMPLE. While some of GIMPLE could be shoe-horned into the existing tags, all of it will not fit, so anyone who wants to understand GIMPLE, will need to use the GCC headers. The DWARF standard provides for a consistent means to extend the debugging format. If you extend DWARF beyond the standard, as has often been done, you will need to provide descriptions (in some form) of what these extensions mean. You can provide this as written material, or you can have the implementer read the code. In either case, the Abbrev tables only provide compression for the Tag/Attr/Val structure of a DIE. They do no provide any semantic description. Using the abbrev tables also add a lot of complexity. It should be understood that while the abbrev table for two separate files encodes the same information, the way that the abbrev tables are generated almost guarantees that the abbrev table will be encoded differently for each file. The abbrev table is a sequential list of record descriptors. The way that the list is generated is first needed, first output, and you only output the records you need. Each of these records is numbered sequentially. So the numbering of the abbrev records will generally be different for the two created object files since they reference different GIMPLE nodes. There is no need for Abbrev tables to be generated differently for each object file. Several compilers generate a standard Abbrev table and then generate DWARF using these predefined abbreviations. The DWARF standard also allows the Abbrev table to be stored in a shared object and referenced by individual object files. I'm not aware of any actual implementation of this, but the structure is there. I strongly believe that for LTO to work, we are going to have to implement some mechanism where the function bodies are loaded into the compiler on demand (possibly kept in cache, but maybe not). This will be more cumbersome if we have to keep reloading each object file's abbrev table just to tear apart a single function in that .o file. While the abbrev sections average slightly less than %2 of the of the size of the GIMPLE encoding for an entire file, each abbrev table averages about the same size as a single function. Thus, we will either have to keep all the abbrev entries for an entire compilation, implement a second caching mechanism, or do about twice the file reading to load a single function. I'm not exactly sure what you are trying to
Re: regress and -m64
Mike, Sure. I am actually doing a build right now to demonstrate the baseline we have for c, c++, and fortran with just the TImode patch and the prune.exp patches I use. Hmm, regress is a G4...surely you can find a G5 laying around Apple to replace it with since PowerPC is so passe there (grin). Jack ps I'll start a make check for both -m32/-m64 and post it as soon as its done.
Re: First cut on outputing gimple for LTO using DWARF3. Discussion invited!!!!
Michael Eager wrote: Kenneth Zadeck wrote: This posting is a progress report of my task of encoding and decoding the GIMPLE stream into LTO. Included in this posting is a patch that encodes functions and dumps the result to files. I have only a limited understanding of GIMPLE and LTO, but here are my comments regarding DWARF. DWARF is a debugging format used to describe a program's source and how it is represented in an executable file. GIMPLE is an intermediate representation, not program source. It's always interesting to see one tool used in a different context, but I'm not clear that in this case you are using the right tool for the right task in the way that it was designed. Speaking on behalf of the DWARF Standards Workgroup, we welcome suggestions for extensions or improvements in the DWARF standard. I wasn't able to identify any specific extension in your email (although I didn't look at the patch in detail). If there are specific areas where DWARF can be improved, please let me know. Michael, My original posting was primarily intended for the gcc developer community which is familiar with gimple and not so familiar with dwarf. I actually think that dwarf is probably pretty good for what it was designed for and it is also documented much better than most of the internals of gcc. The task I was given was to encode gimple into dwarf, something that looked like it might be a reasonable idea, but is, in fact, a bad idea. My posting was to tell the gcc community, been there, done that, now lets move on. I will respond to many of your points but you should not take this as criticism of dwarf, these are mostly just places where the interface between gimple and dwarf was particularly troublesome and unless you want to get in the transporting intermediate code business, which I strongly suggest you avoid, you can just ignore most of these problems. 1) ABBREV TABLES ARE BAD FOR LTO. The abbrev table is a mechanism for making a DWARF3 file self descriptive. It contains a set of templates that are used to describe the records and attributes that are written to describe the object module. This self description mechanism is much weaker (an therefor much more compact) than an XML file's schemata because it depends on a common understanding of the meaning of the tags and attributes that describe the pieces of the data. The tags them selves can be thought of as characters, and an abbrev entry is a magic cookie that tells you how to break the characters into words. DWARF is not self-descriptive, except in the very limited sense that several sections contain version numbers. The DWARF abbreviation table is not intended to be self-descriptive or to be descriptive of the DWARF data. It is a simple compression scheme which compacts the Tag/Attribute/Value structure of a DWARF DIE into a much more condensed format. Certainly the DWARF Abbrev table makes no pretense of being anything similar to an XML schema. I wouldn't use an XML schema for debugging information (it would be huge and slow), and I wouldn't expect to use DWARF abbreviation tables to describe anything at all. While I understand your point, from a language theoretic point of view, they really can be thought of a schemata. They are a description of the records types that have been written by the compiler (or some other tool) for the tags and attributes in this module. This may not be the way that they evolved in your community, but for someone coming from the outside with no knowledge of your history, this is what they are. However, this mechanism is only self descriptive if you do not extend the set of tags. That is not an option for LTO. While the DWARF3 designers seem to have added every conceivable tag to describe object code, it is not be surprising that this comes up short when describing GIMPLE. While some of GIMPLE could be shoe-horned into the existing tags, all of it will not fit, so anyone who wants to understand GIMPLE, will need to use the GCC headers. The DWARF standard provides for a consistent means to extend the debugging format. If you extend DWARF beyond the standard, as has often been done, you will need to provide descriptions (in some form) of what these extensions mean. You can provide this as written material, or you can have the implementer read the code. In either case, the Abbrev tables only provide compression for the Tag/Attr/Val structure of a DIE. They do no provide any semantic description. What I did was add 4 new DW_FORMS. This is one of the areas that, I assume, users are not supposed to extend. My assumption is based on the fact that the standard says how to extend tags and attributes, but is silent on how to extend forms. The four forms that I added are: 1) counted list of udata. 2) counted list of sdata. 3) flag with false value. 4) flag with true value. These are things that made my life simpler and provided for a more
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintation the PHIs which have the same agruments
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 06:01 --- This is weird, this code is a regression also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |minor Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 ||3.0.4 Known to work||3.3.3 3.2.3 2.95.3 Summary|Not elimintation the PHIs |[4.0/4.1/4.2 Regression] Not |which have the same |elimintation the PHIs which |agruments |have the same agruments Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintation the PHIs which have the same agruments
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 06:06 --- Evening adding one more variable causes 3.2.3 to optimize this. I don't know what does the optimization on the rtl level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #18 from bernie at develer dot com 2006-08-28 06:18 --- (In reply to comment #17) And that is Redhat's branch which has the patch which caused this in the first place on it. Thus, I've filed a bug report in RedHat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204277 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintation the PHIs which have the same agruments
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-28 06:43 ---
If I do this:
int f(int t, int a, int b)
{
int c, d, e;
if (t)
{
c = a+1;
d = a+1;
e = a+1;
}
else
{
c = b+1;
d = b+1;
e = b+1;
}
return c+d+e;
}
We get the extra moves elimintated (though not at the tree level).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug middle-end/26632] [4.1/4.2 Regression] spurious warning: value computed is not used
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||08/msg01041.html Status|NEW |ASSIGNED GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug c++/21308] [4.0 Regression] Very high compile time
--- Comment #17 from laurent dot deniau at cern dot ch 2006-08-28 07:42 --- Subject: Re: [4.0 Regression] Very high compile time echristo at apple dot com wrote: --- Comment #16 from echristo at apple dot com 2006-08-26 00:10 --- Should this be closed as unlikely to fix in 4.0? No idea. I am not the poster of this bug report. Regards, Laurent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21308
[Bug c/27184] [4.0/4.1 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #12 from christian dot joensson at gmail dot com 2006-08-28 08:12 --- (In reply to comment #11) Fixed on the mainline, will apply to the branches after a week or so. So, how's this going for 4.1? -- christian dot joensson at gmail dot com changed: What|Removed |Added CC||christian dot joensson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug c++/26670] attribute((packed)) sometimes not ignored for non-PODs
--- Comment #7 from jason at gcc dot gnu dot org 2006-08-28 08:31 --- Or perhaps we should ignore the __attribute__ ((packed)) on nonpod_pack, since one of its fields isn't safe to pack. Yes, that seems like the right way to handle this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26670
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #29 from rguenth at gcc dot gnu dot org 2006-08-28 08:42 --- I completely agree with Dan's analysis. Note that for the patch in comment #20 we can hoist the loop adding all addressable vars to the call clobbering list out of the loop iterating over all analyzed pointers by only remembering if one had pt_anything set. My preferred solution would be to develop the correct fix for 4.3 and eventually allow backporting that to the release branch(es) and not hold the release of 4.2 for this bug. In fact, the usual try of adding -fno-strict-aliasing if one faces a subtle bug will fix it, so it's not harder to detect than a strict aliasing violation by the user. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug java/28869] New: gcc-4.1.1 fails to build with java language on Solaris 2.8
When building gcc-4.1.1 with the following configuration: ../gcc-4.1.1/configure --prefix=/opt --with-local-prefix=/opt/include --with-cpu=ultrasparc --enable-languages=c,c++,java The build fails to build libjava with the following error: Adding multilib support to Makefile in /lhome/gcc/gcc-4.1.1/libjava with_multisubdir=sparcv9 configure: configuring in classpath configure: running /bin/sh '/lhome/gcc/gcc-4.1.1/libjava/classpath/configure' --prefix=/opt '--with-multisubdir=sparcv9' '--with-multisrctop=' '--cache-file=./config.cache' '--build=sparc-sun-solaris2.8' '--host=sparc-sun-solaris2.8' '--target=sparc-sun-solaris2.8' '--enable-multilib' '--prefix=/opt' '--with-local-prefix=/opt/include' '--with-cpu=ultrasparc' '--enable-languages=c,c++,java' '--program-transform-name=s,y,y,' '--with-target-subdir=sparc-sun-solaris2.8' '--srcdir=/lhome/gcc/gcc-4.1.1/libjava' 'CPPFLAGS=' 'build_alias=sparc-sun-solaris2.8' 'host_alias=sparc-sun-solaris2.8' 'target_alias=sparc-sun-solaris2.8' '--disable-load-library' '--disable-debug' '--enable-default-toolkit=' '--with-vm-classes=/lhome/gcc/gcc-4.1.1/libjava:/lhome/gcc/SunOS-5.8.sun4u/sparc-sun-solaris2.8/libjava' '--disable-core-jni' '--disable-examples' '--with-glibj=build' '--disable-gtk-peer' '--disable-qt-peer' '--enable-ltdl-convenience' '--with-auxdir=/lhome/gcc/gcc-4.1.1' '-srcdir=/lhome/gcc/gcc-4.1.1/libjava' --disable-load-library --disable-debug --enable-default-toolkit= --with-vm-classes=/lhome/gcc/gcc-4.1.1/libjava:/lhome/gcc/SunOS-5.8.sun4u/sparc-sun-solaris2.8/sparcv9/libjava --disable-core-jni --disable-examples --with-glibj=build --disable-gtk-peer --disable-qt-peer --with-auxdir=/lhome/gcc/gcc-4.1.1 --cache-file=.././config.cache --srcdir=/lhome/gcc/gcc-4.1.1/libjava/classpath /lhome/gcc/gcc-4.1.1/libjava/classpath/configure: syntax error at line 11740: `QT_INCLUDE_DIR=$' unexpected configure: error: /bin/sh '/lhome/gcc/gcc-4.1.1/libjava/classpath/configure' failed for classpath make[1]: *** [configure-target-libjava] Error 1 make[1]: Leaving directory `/lhome/gcc/SunOS-5.8.sun4u' make: *** [all] Error 2 I have had no trouble building for just C and C++ -- Summary: gcc-4.1.1 fails to build with java language on Solaris 2.8 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bob at digilink dot net GCC build triplet: sparc-sun-solaris2.8-gcc GCC host triplet: sparc-sun-solaris2.8-gcc GCC target triplet: sparc-sun-solaris2.8-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28869
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #13 from bkoz at gcc dot gnu dot org 2006-08-28 09:49 --- Just a note. The current behavior is as intended, although perhaps not documented. I'll be fixing that later today. Here's a message from last month detailing in advance this exact bug report: http://gcc.gnu.org/ml/libstdc++/2006-07/msg00084.html What this means is that people building gcc with -march flags then need to consistently pass those same flags around when using the compiler. Yes, this is a pain. We're working on a better way to do this. The real issue is: code independent from the atomicity model. The only way to have this is to not inline the atomic helper functions in atomicity.h. I am willing to revert that part of my July atomics config change. Although I would prefer not to. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #14 from pcarlini at suse dot de 2006-08-28 09:58 --- (In reply to comment #13) The real issue is: code independent from the atomicity model. The only way to have this is to not inline the atomic helper functions in atomicity.h. I am willing to revert that part of my July atomics config change. Although I would prefer not to. Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only option, at the moment. For ia64, powerpc, s390, etc, etc, when the atomic functions are always available, irrespective of the subtarget, that's fine of course. I thinh we can leave with that, frankly: for strings we are moving away from reference counting anyway; when running single-thread now we don't call the atomic functions; finally, for things like shared_ptr we can have the fine-grained preprocessor builtin and everything is nice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #15 from pcarlini at suse dot de 2006-08-28 10:02 --- (In reply to comment #14) Sorry about my crazy english today, I'm concentrated on something else... Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only option, at the moment. For ia64, powerpc, s390, etc, etc, when the atomic functions are always available, irrespective of the subtarget, that's fine of course. Here of course I meant: everything is fine, of course. I think we can leave with that, frankly: ... and here I meant: live with that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug fortran/28788] [gfortran: 4.1, 4.2 regression] ICE on valid code
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-08-28 11:56 --- Created an attachment (id=12146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12146action=view) Fix and two test cases for the latest regressions I post this now, as a prelude to submitting the patch in the next 24 hours. Before doing so, I want to check that all the derived type symbols get cleaned up and to try a last ditch attemt to identify the references that cause these regressions. The patch regtests on Cygwin_NT/PIV and Martin Reinecke confirms that it compiles his real-life code correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28788
[Bug c++/21764] visibility attributes on namespace scope
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:22 --- Subject: Bug 21764 Author: jakub Date: Mon Aug 28 12:22:14 2006 New Revision: 116504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116504 Log: 2006-03-20 Jason Merrill [EMAIL PROTECTED] PR c++/21764 * c-pragma.c (visstack): Move out of handle_pragma_visibility. (push_visibility, pop_visibility): Likewise. * c-pragma.h: Declare them. cp/ PR c++/21764, c++/19238 * decl.c (cp_finish_decl): Call determine_visibility later. (start_preparsed_function): Likewise. * cp-tree.h (CP_TYPE_CONTEXT, TYPE_NAMESPACE_SCOPE_P): New macros. (TYPE_CLASS_SCOPE_P, TYPE_FUNCTION_SCOPE_P): New macros. * name-lookup.h (struct cp_binding_level): Add has_visibility bitfield. * name-lookup.c: Include c-pragma.h. (push_namespace_with_attribs): Split out from push_namespace. Push visibility if appropriate. Set TREE_PUBLIC on namespaces. (leave_scope): Pop visibility if appropriate. * decl2.c (determine_visibility_from_class): Split out from... (determine_visibility): ...here. Handle function scope and nested classes. (import_export_decl): Move visibility handling to determine_visibility_from_class. * parser.c (cp_parser_declaration, cp_parser_namespace_name): Allow attributes on namespace declarations. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/local1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/namespace1.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/c-pragma.c branches/redhat/gcc-4_1-branch/gcc/c-pragma.h branches/redhat/gcc-4_1-branch/gcc/cp/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/cp-tree.h branches/redhat/gcc-4_1-branch/gcc/cp/decl.c branches/redhat/gcc-4_1-branch/gcc/cp/decl2.c branches/redhat/gcc-4_1-branch/gcc/cp/name-lookup.c branches/redhat/gcc-4_1-branch/gcc/cp/name-lookup.h branches/redhat/gcc-4_1-branch/gcc/cp/parser.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21764
[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 28279 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/26612] visibility and ODR
--- Comment #6 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 26612 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/28215] [4.2 regression] Bootstrap failure on arm-eabi
--- Comment #4 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 28215 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/19134] Class visibility of templated classes can't be overridden for function specializations
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 19134 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/26905] default-visibility class symbol improperly resolved as hidden-visibility
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 26905 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/26984] link error with (typeid(int)) in anonymous namespace
--- Comment #7 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 26984 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/27000] visibility push/pop and templates go crazy
--- Comment #11 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 27000 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/17470] Visibility attribute ignored for explicit template instantiation
--- Comment #11 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 17470 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/21675] -fvisibility : misleading documentation and low QoI
--- Comment #3 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 21675 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/21581] (optimisation) Functions in anonymous namespaces should default to hidden visibility
--- Comment #19 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 21581 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug c++/25915] use ODR rules to make C++ objects not be TREE_PUBLIC
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:27 --- Subject: Bug 25915 Author: jakub Date: Mon Aug 28 12:26:41 2006 New Revision: 116505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116505 Log: 2006-07-06 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. 2006-07-01 Jason Merrill [EMAIL PROTECTED] cp/ PR c++/28215 * method.c (make_thunk): Unset DECL_USE_TEMPLATE and DECL_TEMPLATE_INFO. 2006-06-30 Jason Merrill [EMAIL PROTECTED] objcp/ * objcp-decl.c (objcp_start_struct): Pass null attributes argument to begin_class_definition. 2006-06-29 Jason Merrill [EMAIL PROTECTED] PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * tree.c (build_decl_stat): Don't hande #pragma visibility here. * c-common.c (c_determine_visibility): Handle it here. * c-decl.c (finish_decl): Call c_determine_visibility for functions, too. * flags.h (enum symbol_visibility): Sort from most to least visibility. * tree.h: Likewise. * varasm.c (default_assemble_visibility): Likewise. * c-common.c (handle_visibility_attribute): Complain about trying to give visibility to an already defined class, or trying to change declared visibility. Always attach the attribute. PR c++/26905 PR c++/21675 PR c++/17470 * attribs.c (decl_attributes): Ignore type-in-place attributes once the type has been defined. cp/ PR c++/26905 PR c++/26612 PR c++/27000 PR c++/26984 PR c++/19134 * decl2.c (determine_visibility): Overhaul. (determine_visibility_from_class): Likewise. (min_vis_r, type_visibility, constrain_visibility): New fns. (constrain_visibility_for_template): Likewise. (constrain_class_visibility): Likewise. * decl.c (cp_finish_decl): Call determine_visibility for function decls, too. * name-lookup.c (pushtag): Call determine_visibility. * decl.c (duplicate_decls): Don't copy visibility from template to specialization. * pt.c (check_explicit_specialization): Likewise. (lookup_template_class, tsubst_decl): Call determine_visibility. * class.c (finish_struct_1): Call constrain_class_visibility. PR c++/26905 PR c++/21675 PR c++/17470 * parser.c (cp_parser_explicit_instantiation): Pass the attributes to grokdeclarator. (cp_parser_type_specifier): Allow 'enum __attribute ((...)) E'. (cp_parser_enum_specifier): Likewise. (cp_parser_elaborated_type_specifier): Apply attributes if this declares only the class. (cp_parser_class_specifier): Apply leading attributes immediately. * semantics.c (begin_class_definition): Add attributes parameter, apply them to the type. PR c++/21581 PR c++/25915 * tree.c (decl_anon_ns_mem_p): New function. * cp-tree.h: Declare it. * decl2.c (determine_visibility): Make anonymous namespace members static. (min_vis_r, constrain_visibility): Likewise. * rtti.c (create_pseudo_type_info): Set TREE_PUBLIC on pseudo-types. * decl.c (cxx_init_decl_processing): Set TREE_PUBLIC on global_namespace. * name-lookup.c (push_namespace_with_attribs): Don't set TREE_PUBLIC on anonymous namespaces. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/anon2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/class1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/prop1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/redecl1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn1.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn4.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon2.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/attribs.c branches/redhat/gcc-4_1-branch/gcc/c-common.c
[Bug testsuite/28870] New: configuring, over-riding timeout values in testsuite
This change: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01487.html Has caused problems with people who set a custom timeout value in .exp files. Examples include: http://gcc.gnu.org/ml/gcc/2006-08/msg00371.html and http://gcc.gnu.org/ml/libstdc++/2006-08/msg00027.html Mike's suggestion to do timeout=timeout*2 is interesting, but I don't know if that really solves the issue. Perhaps the answer that I'm searching for is to see if timeout has been set, if so, use it. If not, set it. I'm hoping that some of the testsuite maintainers can figure out a better way to approach this whole issue. -benjamin -- Summary: configuring, over-riding timeout values in testsuite Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC host triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28870
[Bug c++/28370] [4.2 Regression] undefined reference to template class static variable in an anonymous namespace
--- Comment #13 from jakub at gcc dot gnu dot org 2006-08-28 12:29 --- Subject: Bug 28370 Author: jakub Date: Mon Aug 28 12:28:55 2006 New Revision: 116506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116506 Log: PR c++/28370 * decl2.c (note_vague_linkage_var): Removed. (finish_static_data_member_decl): Add decl to pending_statics vector directly. Do it even for non-public decls. * g++.dg/template/anon3.C: New test. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon3.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/decl2.c branches/redhat/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28370
[Bug c++/28409] [4.2 Regression] extern C and anonymous namespace
--- Comment #5 from jakub at gcc dot gnu dot org 2006-08-28 12:31 --- Subject: Bug 28409 Author: jakub Date: Mon Aug 28 12:31:26 2006 New Revision: 116507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116507 Log: 2006-07-20 Jason Merrill [EMAIL PROTECTED] * tree.c (remove_attribute): New fn. PR c++/28407 * decl.c (grokvardecl): Set DECL_THIS_STATIC on file-scope const variables with implicit internal linkage. * tree.c (decl_linkage): Only return lk_external if it's set. PR c++/28409 * decl2.c (constrain_visibility): Ignore the anonymous namespace for extern C decls. (VISIBILITY_STATIC): Rename to VISIBILITY_ANON. * decl2.c (constrain_visibility): Remove specified and reason parameters. Don't touch decls that already have explicit visibility. (determine_visibility): Do copy DECL_VISIBILITY_SPECIFIED from template. (determine_visibility_from_class): Reverse sense of DECL_VISIBILITY_SPECIFIED test for target-specific visibility rules. (constrain_class_visibility): Only complain about member visibility if the member type is another class. Don't change visibility of the current class. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template6.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/lookup/anon5.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon4.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/decl.c branches/redhat/gcc-4_1-branch/gcc/cp/decl2.c branches/redhat/gcc-4_1-branch/gcc/cp/pt.c branches/redhat/gcc-4_1-branch/gcc/cp/tree.c branches/redhat/gcc-4_1-branch/gcc/doc/extend.texi branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/tree.c branches/redhat/gcc-4_1-branch/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409
[Bug c++/28407] [4.2 regression] Issue with anonymous namespace
--- Comment #12 from jakub at gcc dot gnu dot org 2006-08-28 12:31 --- Subject: Bug 28407 Author: jakub Date: Mon Aug 28 12:31:26 2006 New Revision: 116507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116507 Log: 2006-07-20 Jason Merrill [EMAIL PROTECTED] * tree.c (remove_attribute): New fn. PR c++/28407 * decl.c (grokvardecl): Set DECL_THIS_STATIC on file-scope const variables with implicit internal linkage. * tree.c (decl_linkage): Only return lk_external if it's set. PR c++/28409 * decl2.c (constrain_visibility): Ignore the anonymous namespace for extern C decls. (VISIBILITY_STATIC): Rename to VISIBILITY_ANON. * decl2.c (constrain_visibility): Remove specified and reason parameters. Don't touch decls that already have explicit visibility. (determine_visibility): Do copy DECL_VISIBILITY_SPECIFIED from template. (determine_visibility_from_class): Reverse sense of DECL_VISIBILITY_SPECIFIED test for target-specific visibility rules. (constrain_class_visibility): Only complain about member visibility if the member type is another class. Don't change visibility of the current class. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/template6.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/lookup/anon5.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/template/anon4.C Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/ChangeLog branches/redhat/gcc-4_1-branch/gcc/cp/decl.c branches/redhat/gcc-4_1-branch/gcc/cp/decl2.c branches/redhat/gcc-4_1-branch/gcc/cp/pt.c branches/redhat/gcc-4_1-branch/gcc/cp/tree.c branches/redhat/gcc-4_1-branch/gcc/doc/extend.texi branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn2.C branches/redhat/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/visibility/warn3.C branches/redhat/gcc-4_1-branch/gcc/tree.c branches/redhat/gcc-4_1-branch/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28407
[Bug c++/28871] New: massive C++ compile time slowdown
Sometime between Aug 1, 2006 and Aug 22, 2006 the time needed to run the g++ and libstdc++ testsuite ballooned. See this message and followups: http://gcc.gnu.org/ml/gcc/2006-08/msg00398.html Here are the specifics that I have: 20060724, make check-target-libstdc++ 1145.687u 137.804s 23:13.98 92.0% 0+0k 0+0io 23pf+0w 20060822, make check-target-libstdc++ 2624.876u 247.539s 55:42.82 85.9% 0+0k 0+0io 45pf+0w Ouch. In that time, there have been some additions in the libstdc++ testsuite, however it did not double in size. I've been trying to compile mainline libstdc++ with 4.1.1 g++ to see if I can pin down the issue to a particular component but there are a lot of incompatible changes, so comparing directly is difficult to impossible. -- Summary: massive C++ compile time slowdown Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
[Bug target/28872] New: ARM inline assembly can be mispredicated.
I had a conversation with Russell King about asm() and historical problems with it. He told me that in old versions of GCC, it was necessary to either clobber conds or else use %?; otherwise GCC could mistakenly omit a branch around the inline asm. When (around GCC 3.0) we started to use final.c in addition to arm_final_prescan_insn, this changed. Suddenly %? could be filled in by a bogus condition more easily. So using %? in inline asm is no longer viable. However, the old code, which predicated instructions unless they clobbered conds, is still present. We don't know exactly why, but Paul tells me that it still triggers once in a while. I believe that if it triggers, it may mistakenly conditionalize instructions which don't use %?. I don't have a testcase. The simplest fix is probably to check the relatively new predicable attribute. A more complete fix might be to figure out when the old code triggers, adjust the rest of the compiler to handle those cases if desired, and remove the ARM backend-specific bits entirely. -- Summary: ARM inline assembly can be mispredicated. Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drow at gcc dot gnu dot org GCC target triplet: arm-none-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28872
[Bug c++/28871] massive C++ compile time slowdown
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 13:23 --- It might not have doubled but one testcase that was added might have been always slow. We really need one testcase that has slowed down or one testcase that has always been slow that was added. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
[Bug java/28869] gcc-4.1.1 fails to build with java language on Solaris 2.8
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 13:26 --- configure: error: /bin/sh '/lhome/gcc/gcc-4.1.1/libjava/classpath/configure' You forgot to do CONFIG_SHELL=/bin/ksh as mentioned by: http://gcc.gnu.org/install/specific.html#x-x-solaris2 The Solaris 2 /bin/sh will often fail to configure libstdc++-v3, boehm-gc or libjava. We therefore recommend using the following initial sequence of commands % CONFIG_SHELL=/bin/ksh % export CONFIG_SHELL -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28869
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintation the PHIs which have the same agruments
--- Comment #4 from steven at gcc dot gnu dot org 2006-08-28 13:59 --- From the hammer branch for AMD64: .globl f .type f, @function f: .LFB4: testl %edi, %edi movl%esi, %eax jne .L3 movl%edx, %esi movl%edx, %eax .L3: leal(%rax,%rsi), %eax ret .LFE4: .size f, .-f .p2align 4,,15 .globl f1 .type f1, @function f1: .LFB5: testl %edi, %edi cmove %edx, %esi leal(%rsi,%rsi), %eax ret .LFE5: .size f1, .-f1 And from gcc 4.2 20060818: .globl f .type f, @function f: .LFB2: testl %edi, %edi movl%esi, %eax cmove %edx, %esi cmove %esi, %eax addl%esi, %eax ret .LFE2: .size f, .-f .p2align 4,,15 .globl f1 .type f1, @function f1: .LFB3: testl %edi, %edi cmove %edx, %esi leal(%rsi,%rsi), %eax ret .LFE3: .size f1, .-f1 So not all gcc3 releases do so well. Are there GCC releases that optimize the two functions to identical code? In any case, this is a missed optimization. I suppose the trick in this case is to recognise that c + d == c + c (perhaps during value numbering?), but the first step to analyze this bug would be to figure out where gcc3 (supposedly) performs this optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug tree-optimization/28868] [4.0/4.1/4.2 Regression] Not elimintation the PHIs which have the same agruments
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 14:37 --- (In reply to comment #4) So not all gcc3 releases do so well. Are there GCC releases that optimize the two functions to identical code? Yes (FSF) 3.2.3. .globl f .type f,@function f: movl4(%esp), %eax testl %eax, %eax movl12(%esp), %eax cmovne 8(%esp), %eax addl%eax, %eax ret .Lfe1: .size f,.Lfe1-f .p2align 4,,15 .globl f1 .type f1,@function f1: movl4(%esp), %edx movl12(%esp), %eax testl %edx, %edx cmovne 8(%esp), %eax addl%eax, %eax ret .Lfe2: .size f1,.Lfe2-f1 .ident GCC: (GNU) 3.2.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug fortran/28873] New: Cannot resolve subroutine calls when modules are used in different scopes
gfortran reports the following error: call create() 1 Error: Generic subroutine 'create' at (1) is not an intrinsic subroutine when trying to compile the following code: module A private interface create module procedure create1 end interface public :: create contains subroutine create1 end subroutine end module module B private interface create module procedure create1 end interface public :: create contains subroutine create1(a) integer a end subroutine end module module C use A private contains subroutine useCreate use B call create() end subroutine end module The call to the overloaded routine 'create' should be resolved to create1 in module A, but an error results. This error only occurs when module B is used in the subroutine, and module A is used at the top level of module C. If you move the 'use B' statement to the top level of module C, it resolves fine. -- Summary: Cannot resolve subroutine calls when modules are used in different scopes Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: gcc version 4.2.0 20060805 (experimental) GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
[Bug fortran/28874] New: gfortran confuses 'cycle' keyword for subroutine call in subroutine called 'cycle'
The following code: subroutine cycle implicit none integer :: nsos, isym, nsym = 10 integer :: norb(10) isym_: do isym = 1, nsym nsos = norb(isym) if (nsos==0) cycle isym_ enddo isym_ end subroutine causes this compile time error: if (nsos==0) cycle isym_ 1 Error: Expected VARIABLE at (1) The confusion seems to arise because the subroutine is called 'cycle'. Other compilers do handle this correctly. -- Summary: gfortran confuses 'cycle' keyword for subroutine call in subroutine called 'cycle' Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: gcc version 4.2.0 20060805 (experimental) GCC target triplet: powerpc-apple-darwin8.7.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28874
[Bug target/26504] compute_frame_pointer_to_cfa_displacement error for avr target with --with-dwarf2
--- Comment #11 from clemens dot koller at anagramm dot de 2006-08-28 15:37 --- Same bug occures with 4.1.1 too, verified on an x86 and ppc host, cross compiling for Atmel AVR: configure --target=avr --with-dwarf2 triggers the bug. -- clemens dot koller at anagramm dot de changed: What|Removed |Added CC||clemens dot koller at ||anagramm dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #16 from sje at cup dot hp dot com 2006-08-28 16:07 --- Yes, I did some performance measurements with SPEC2000. Allowing any (symbol + offset) resulted in slightly slower code overall, allowing no (symbol + offset) resulted in slightly faster code overall. I will be submitting a patch to do this but probably not until next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug java/28663] [4.2 regression] gcj fails to binary-compile eclipse's javac
-- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug java/1305] [JSR133] GCJ ignores volatile modifier
-- aph at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1305
[Bug java/28458] [ecj] Fails to build gnu.awt.LightweightRedirector
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-28 16:54 --- . -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28458
[Bug java/27754] Stack overflow in gcj
--- Comment #4 from aph at gcc dot gnu dot org 2006-08-28 16:55 --- . -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27754
[Bug middle-end/27590] [4.1/4.2 Regression] ICE when compiling catalina.jar from tomcat 5.0.30
--- Comment #9 from aph at gcc dot gnu dot org 2006-08-28 16:56 --- Should be fixed on trunk. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27590
[Bug java/24442] wrong inner class instantiated
--- Comment #2 from aph at gcc dot gnu dot org 2006-08-28 16:57 --- This will be fixed with ecj. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24442
[Bug middle-end/26632] [4.1/4.2 Regression] spurious warning: value computed is not used
--- Comment #9 from kazu at gcc dot gnu dot org 2006-08-28 17:18 --- Subject: Bug 26632 Author: kazu Date: Mon Aug 28 17:18:29 2006 New Revision: 116510 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116510 Log: gcc/ PR middle-end/26632 * convert.c (convert_to_integer): Set TREE_NO_WARNING to 1 on an implicit conversion. gcc/testsuite/ PR middle-end/26632 * gcc.dg/pr26632.c: New. Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #50 from amacleod at redhat dot com 2006-08-28 17:18 --- Subject: Bug 28071 Author: amacleod Date: Mon Aug 28 17:18:33 2006 New Revision: 116511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116511 Log: revert 116257 which is the rewrite_liverange_info patch, so be replaced with the two patches I created for bug 28071. Modified: branches/out-of-ssa-the-sequel/gcc/ChangeLog branches/out-of-ssa-the-sequel/gcc/tree-outof-ssa.c branches/out-of-ssa-the-sequel/gcc/tree-ssa-live.c branches/out-of-ssa-the-sequel/gcc/tree-ssa-live.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug tree-optimization/17506] [4.0/4.1/4.2 regression] warning about uninitialized variable points to wrong location
--- Comment #27 from kazu at gcc dot gnu dot org 2006-08-28 17:28 --- The real fix it to issue uninitialized warnings before the inliner kicks in but after we go into SSA, which is impossible until we start doing early SSA. As Nathan suggests, this caveat should be mentioned in the release notes. -- kazu at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kazu at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #51 from amacleod at redhat dot com 2006-08-28 17:37 --- Huh. I didn't realize bugzilla scanned the entire checkin message looking for bug numbers This has been checked in on a branch, so you can ignore the preceeding note's commentary. it's just a note to myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug fortran/28874] gfortran confuses 'cycle' keyword for subroutine call in subroutine called 'cycle'
--- Comment #1 from kargl at gcc dot gnu dot org 2006-08-28 17:55 --- This is my screw. *** This bug has been marked as a duplicate of 28866 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28874
[Bug fortran/28866] [Regression] Simple if statements are not so simple
--- Comment #2 from kargl at gcc dot gnu dot org 2006-08-28 17:55 --- *** Bug 28874 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||drewmccormack at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28866
[Bug c++/23287] [4.0/4.1/4.2 regression] Explicitly invoking destructor of template class in a template and is dependent
-- nathan at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-27 21:45:45 |2006-08-28 17:56:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug c/28875] New: -Wextra -Wno-unused-parameter -Wall doesn't work as expected
The above sequence of warning flags causes unused-parameters to be reported, while one expects it to not. The fact that -Wextra and -Wall together magically turn unused-parameter on is shadowing the effect of the explicit -Wno-unused-parameter. It took me quite a while to figure that out. -- Summary: -Wextra -Wno-unused-parameter -Wall doesn't work as expected Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28875
[Bug c/28875] -Wextra -Wno-unused-parameter -Wall doesn't work as expected
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 19:40 --- I don't think this is a bug since the behavior is documented: In order to get a warning about an unused function parameter, you must either specify `-Wextra -Wunused' (note that `-Wall' implies `-Wunused'), or separately specify -Wunused-parameter. So you have -Wextra -Wno-unused-parameter -Wall so the -Wno-unused-parameter does not have an effect as it is not turned on by -Wextra but instead by -Wall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28875
[Bug java/28869] gcc-4.1.1 fails to build with java language on Solaris 2.8
--- Comment #2 from bob at digilink dot net 2006-08-28 19:45 --- I'm sorry - I thought I had looked through all of the Solaris build issues but there it is plain as day - If it was a snake it would have bit me! Thank you for pointing me in the right direction and for your patience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28869
[Bug c/28876] New: Provide -W options for all warnings enabled by -Wextra
There are some really useful warnings enabled by -Wextra that don't have separate -W enablers. They should, as not everyone likes all the noise that -Wextra generates. These two are the ones I failed to find how to enable other than by using -Wextra: warning: comparison of unsigned expression = 0 is always true warning: variable 'status' might be clobbered by 'longjmp' or 'vfork' -- Summary: Provide -W options for all warnings enabled by -Wextra Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28876
[Bug libstdc++/23773] Improve abi.html
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-08-28 20:18 --- Subject: Bug 23773 Author: bkoz Date: Mon Aug 28 20:18:22 2006 New Revision: 116527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116527 Log: 2006-08-28 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/23773 partial * docs/html/abi.html: Update. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/docs/html/abi.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23773
[Bug c/28876] Provide -W options for all warnings enabled by -Wextra
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 20:33 --- *** This bug has been marked as a duplicate of 7651 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28876
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-28 20:33 --- *** Bug 28876 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gnu at behdad dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-28 20:36 --- (In reply to comment #6) The log message and the ChangeLog entry don't mention it, but this patch also modifies gcc/dwarf2out.c. It was backed out right after the commit: http://gcc.gnu.org/viewcvs?view=revrevision=112362 But that would mean it was caused by the revision which I had mentioned in comment #5 as that revision put the code back in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug libgomp/25259] [4.2 Regression] bootstrap failures on non-C99 platforms (no stdint.h)
--- Comment #20 from janis at gcc dot gnu dot org 2006-08-28 20:42 --- Subject: Bug 25259 Author: janis Date: Mon Aug 28 20:42:12 2006 New Revision: 116528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116528 Log: Backport from mainline (part of r198241) 2006-01-02 Paolo Bonzini [EMAIL PROTECTED] libdecnumber/ChangeLog PR target/25259 * configure.ac: Use GCC_HEADER_STDINT. * decContext.h: Include gstdint.h. * aclocal.m4: Regenerate. * configure: Regenerate. config/ChangeLog PR target/25259 * Makefile.in (DECNUMINC): Include libdecnumber's build directory. Modified: branches/ibm/gcc-4_1-branch/config/ChangeLog branches/ibm/gcc-4_1-branch/config/stdint.m4 branches/ibm/gcc-4_1-branch/configure branches/ibm/gcc-4_1-branch/gcc/Makefile.in branches/ibm/gcc-4_1-branch/libdecnumber/ChangeLog branches/ibm/gcc-4_1-branch/libdecnumber/aclocal.m4 branches/ibm/gcc-4_1-branch/libdecnumber/configure.ac branches/ibm/gcc-4_1-branch/libdecnumber/decContext.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25259
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-08-28 20:44 --- (In reply to comment #3) Created an attachment (id=12037) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12037action=view) [edit] patch It looks like we should bite the bullet and let cgraph code to output the debug info I am testing the attached patch It looks like this patch will prevent the output of debug information for variables that are optimized out, but that's wrong; the variables should be visible to the user in the debugger even if they are optimized away. I think the actual problem is that reference_to_unused in dwarf2out.c is checking TREE_USED and expecting all used variables to be output, but that doesn't seem to be happening in this case. Perhaps there is something in cgraph which can be called to ask if a variable is *really* going to be output? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug c++/26102] [4.1/4.2 regression] using Base::member nonsense
--- Comment #6 from janis at gcc dot gnu dot org 2006-08-28 21:03 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=110017 r110017 | mmitchel | 2006-01-20 03:07:58 + (Fri, 20 Jan 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26102
[Bug tree-optimization/28411] [4.1/4.2 Regression] Illegal instruction error with -ftrapv
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-08-28 21:15 --- Subject: Bug 28411 Author: rakdver Date: Mon Aug 28 21:15:19 2006 New Revision: 116529 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116529 Log: PR tree-optimization/28411 * double-int.c (double_int_div): Use double_int_divmod. (double_int_divmod, double_int_sdivmod, double_int_udivmod, double_int_mod, double_int_smod, double_int_umod): New functions. * double-int.h (double_int_divmod, double_int_sdivmod, double_int_udivmod, double_int_mod, double_int_smod, double_int_umod): Declare. * tree-ssa-loop-ivopts.c (constant_multiple_of): Returns the result in double_int. (get_computation_aff, get_computation_cost_at): Handle double_int return type of constant_multiple_of. Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28411
[Bug java/28663] [4.2 regression] gcj fails to binary-compile eclipse's javac
--- Comment #7 from h dot mth at web dot de 2006-08-28 21:45 --- I stored my broken ecj-3.2.jar here: http://geki.ath.cx/hacks/ecj.jar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28663
[Bug c++/25868] [4.0/4.1 Regression] Multiple templates and typedefs cause function prototype not to match
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-28 22:14 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=116409 r116409 | nathan | 2006-08-25 16:56:07 + (Fri, 25 Aug 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25868
[Bug fortran/28873] Cannot resolve subroutine calls when modules are used in different scopes
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-28 22:15 --- The problem lies in resolve.c (resolve_generic_s):1623 On the face of it, if (sym-ns-parent != NULL !sym-attr.use_assoc) seems to be wrong. if (sym-ns-parent != NULL) fixes the problem and is regtesting as I write. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-28 22:15:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
[Bug fortran/28873] Cannot resolve subroutine calls when modules are used in different scopes
--- Comment #2 from pault at gcc dot gnu dot org 2006-08-28 22:22 --- The problem lies in resolve.c (resolve_generic_s):1623 yes, definitely. resolve_generic_f is not so prissy about use association and has a somewhat different structure. If I were to transport this to subroutines, the PR would be fixed The morning will bring enlightenment. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
[Bug fortran/28873] Cannot resolve subroutine calls when modules are used in different scopes
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2006-08-28 22:15:42 |2006-08-28 22:23:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28873
[Bug driver/28877] New: gcc file1.c file2.c file3.c -o file.o fails
This doesn't work on my apple gcc. If you inspect with -v, it compiles each file in turn and writes to file.o, each file overwriting the one before it, rather than combining the three .c files into one .o. I can think of some pretty good reasons to do this, including cross compilation-unit inlining. Is/should this be a supported feature? -- Summary: gcc file1.c file2.c file3.c -o file.o fails Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: iano at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
[Bug c++/28860] [4.0/4.1/4.2 regression] Trouble with bound template template parameter in specialization
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-08-28 22:35 --- Subject: Bug 28860 Author: reichelt Date: Mon Aug 28 22:34:55 2006 New Revision: 116541 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116541 Log: PR c++/28860 * cp-tree.h (maybe_process_partial_specialization): Return tree instead of void. * parser.c (cp_parser_class_head): Use return value of maybe_process_partial_specialization. * pt.c (maybe_process_partial_specialization): Return error_mark_node for broken specializations, TYPE otherwise. Check for template template parameters. * g++.dg/template/ttp22.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/ttp22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28860
[Bug driver/28877] gcc file1.c file2.c file3.c -o file.o fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-28 22:49 --- This was a bug in 4.0.0-4.0.2, it was fixed for 4.0.3 by me never the less. To get IMA, you need -combine. *** This bug has been marked as a duplicate of 22544 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
[Bug driver/22544] [4.0/4.1 Regression] gcc ignores input file given on the command line
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-08-28 22:49 --- *** Bug 28877 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||iano at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22544
[Bug driver/28877] gcc file1.c file2.c file3.c -o file.o fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-28 22:50 --- PS please report Apple GCC bugs to Apple first and if you want to report a GCC bug to the FSF, please test on the branch (and/or the latest release). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
[Bug c++/28860] [4.0/4.1/4.2 regression] Trouble with bound template template parameter in specialization
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-08-28 22:51 --- Subject: Bug 28860 Author: reichelt Date: Mon Aug 28 22:51:17 2006 New Revision: 116543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116543 Log: PR c++/28860 * cp-tree.h (maybe_process_partial_specialization): Return tree instead of void. * parser.c (cp_parser_class_head): Use return value of maybe_process_partial_specialization. * pt.c (maybe_process_partial_specialization): Return error_mark_node for broken specializations, TYPE otherwise. Check for template template parameters. * g++.dg/template/ttp22.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/ttp22.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/cp-tree.h branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28860
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #9 from janis at gcc dot gnu dot org 2006-08-28 22:58 --- I can confirm that the latest regression is from r112408. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug c++/28860] [4.0/4.1/4.2 regression] Trouble with bound template template parameter in specialization
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-08-28 23:12 --- Subject: Bug 28860 Author: reichelt Date: Mon Aug 28 23:12:32 2006 New Revision: 116544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116544 Log: PR c++/28860 * cp-tree.h (maybe_process_partial_specialization): Return tree instead of void. * parser.c (cp_parser_class_head): Use return value of maybe_process_partial_specialization. * pt.c (maybe_process_partial_specialization): Return error_mark_node for broken specializations, TYPE otherwise. Check for template template parameters. * g++.dg/template/ttp22.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/ttp22.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/cp-tree.h branches/gcc-4_0-branch/gcc/cp/parser.c branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28860
[Bug driver/28877] gcc file1.c file2.c file3.c -o file.o fails
--- Comment #3 from iano at apple dot com 2006-08-28 23:13 --- Thanks for fixing it Andrew. I can confirm that -combine works. Hopefully Apple will get around to updating to 4.0.3 one of these days. ...and really, you should be thrilled to get duplicate bug reports! They are sooo much easier to fix. -- iano at apple dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28877
