[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #34 from mark at codesourcery dot com 2006-04-17 15:37 --- Subject: Re: [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets edmar at freescale dot com wrote: > --- Comment #33 from edmar at freescale dot com 2006-04-17 15:22 --- > The latest round of patches cured the original problem. Unfortunately, the > target itself is still broken. This time because of a bug originaly reported > for the e500v1 target. (27075). > I am not sure what is the right administrative thing to do. This one was a P3, > 27075 was changed to P2 recently. > Perhaps a comment on 27075 that it also affects e500v2 target ? I will leave > to > you guys to decide... If the problem reported in PR 26459 is resolved, then we should close PR 26459. If the problem in PR 27075 also effects E500v2, then we should not that there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug c++/27102] [4.0/4.1/4.2 regression] ICE with invalid class name in function template
--- Comment #5 from mark at codesourcery dot com 2006-04-18 19:41 --- Subject: Re: [4.0/4.1/4.2 regression] ICE with invalid class name in function template reichelt at gcc dot gnu dot org wrote: > --- Comment #4 from reichelt at gcc dot gnu dot org 2006-04-18 10:43 > --- > Hi Mark, > I was just testing the following btw.: Thanks. I've got a rather more involved changed (with some other good cleanups) that I think is almost ready. I'm concerned that your change wouldn't be correct for friends in templates, which is usually the nasty case for these kinds of things. For example, I think "friend void T::f();" is valid, even if "T" is a template type parameter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27102
[Bug c++/26036] [4.0/4.1/4.2 Regression] Treating a class object as a function with member variables causes hang
--- Comment #7 from mark at codesourcery dot com 2006-04-19 16:57 ---
Subject: Re: [4.0/4.1/4.2 Regression] Treating a class object
as a function with member variables causes hang
reichelt at gcc dot gnu dot org wrote:
> --- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-19 09:34
> ---
> Mark,
> are you really working on this one or did you only accidentally assign the PR
> to
> you?
Well, I planned to fix it before the next release, but I wasn't actually
doing anything on it. You're always welcome to fix my bugs. :-)
> The following fixes the problem for me and allows to get rid of
> error_mark_list as it is then unused:
>
> ===
> --- gcc/gcc/cp/typeck.c 2006-04-18 17:32:06 +0200
> +++ gcc/gcc/cp/typeck.c 2006-04-18 17:32:31 +0200
> @@ -2788,7 +2788,7 @@ convert_arguments (tree typelist, tree v
> }
> else
> error ("too few arguments to function");
> - return error_mark_list;
> + return error_mark_node;
> }
> }
I can't argue with that. :-) This patch, and the removal of
error_mark_list are fine.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26036
[Bug bootstrap/27334] [4.0/4.1 onlly] gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes
--- Comment #3 from mark at codesourcery dot com 2006-04-28 05:02 --- Subject: Re: gcc/Makefile.in:s-macro_list sed fails with make 3.81 due to POSIX support changes debian-gcc at lists dot debian dot org wrote: > --- Comment #1 from debian-gcc at lists dot debian dot org 2006-04-27 > 07:33 --- > thanks for pointing that out, my mistake to check that in. Mark, ok keep that > change and document that change in the existing changelog entry? > > * Makefile.in (s-macro_list): Conform to POSIX rules in single quoted > strings Yes, that's OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27334
[Bug c++/24561] no static definition at -O0
--- Comment #10 from mark at codesourcery dot com 2006-04-30 16:50 --- Subject: Re: no static definition at -O0 hubicka at gcc dot gnu dot org wrote: > I don't quite see reason for outputting unneeded static functions even at -O0 > that it mostly just slows down the compilation process, but I am testing patch > that makes cgraph believe that every function passed to it should be output > unless it is extern inline and will post it for consideration once testing > converge. The reason for emitting all static functions at -O0 is that, historically, most compilers have done that. People tend to call these functions from the debugger. Of course, in GCC, we have attributes to say that a function should be kept, even though it's static, but some other compilers don't, so people tend to rely on the fact that these functions are emitted when optimization is disabled. We could document that GCC no longer keeps static functions at -O0. As you say, dropping these functions should improve compile times, although we don't really know by how much. My guess would be that there aren't very many unnecessary static functions. Please do be careful that your patch doesn't cause cgraph to emit all COMDAT functions. COMDAT functions (or weak/linkonce) functions should not be emitted at -O0, if they are not needed, because there tend to be *tons* of them; that would probably impact compile-time a lot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24561
[Bug c++/27309] [4.0/4.1 regression] ICE on invalid constructor definition
--- Comment #7 from mark at codesourcery dot com 2006-05-03 14:51 --- Subject: Re: [4.0/4.1 regression] ICE on invalid constructor definition reichelt at gcc dot gnu dot org wrote: > --- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-03 10:38 > --- > Mark, do you want to add some of the testcases from PR27379 and PR27380 > to the testsuite as their mode of failure is a little bit different > although the underlying problem seems to be the same? There's certainly no harm in that, but I don't think we'll increase coverage in any interesting way; the underlying cause really was the same for all of those failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27309
[Bug target/26885] [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object
--- Comment #11 from mark at codesourcery dot com 2006-05-16 16:51 --- Subject: Re: [4.1/4.2 regression] -m64 -m32 no longer creates 32-bit object hjl at lucon dot org wrote: > --- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 --- > Hi Mark, > > I realized that I had an updated patch > > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00090.html > > to address a concern from > > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00050.html > > Can I update gcc/doc/invoke.texi? OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
[Bug bootstrap/27644] [4.1 regression] Bootstrap failure on native ARM targets
--- Comment #1 from mark at codesourcery dot com 2006-05-17 17:38 --- Subject: Re: New: [4.1 regression] Bootstrap failure on native ARM targets rearnsha at gcc dot gnu dot org wrote: > This patch: > 2006-05-16 H.J. Lu <[EMAIL PROTECTED]> > > * Makefile.in (GCC_OBJS): Replace options.o with gcc-options.o. > (gcc-options.o): New rule. > > * optc-gen.awk: Protect variables for gcc-options.o with > #ifdef GCC_DRIVER/#endif. > > is causing bootstrap failures: OK, that's enough alarm bells for me. HJ, please revert this series of patches on the 4.1 branch. I think it's likely that there will be fallout on other architectures as well. Please investigate the ARM failure on mainline ASAP. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27644
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #6 from mark at codesourcery dot com 2006-05-21 17:07 --- Subject: Re: install failure due to unconditional invocation of makeinfo for treelang.texi aldot at gcc dot gnu dot org wrote: > --- Comment #5 from aldot at gcc dot gnu dot org 2006-05-21 12:16 --- > Setting Target Milestone to 4.1.1. > > Ok for trunk and the 4.1 branch? Wouldn't it be better just to modify gcc/Makefile.in to do: ifneq($(BUILD_INFO),) info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo else info: fi Then, in the subdirectory Makefiles we can avoid checking BUILD_INFO at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug bootstrap/27516] install failure due to unconditional invocation of makeinfo for treelang.texi
--- Comment #8 from mark at codesourcery dot com 2006-05-21 17:58 --- Subject: Re: install failure due to unconditional invocation of makeinfo for treelang.texi aldot at gcc dot gnu dot org wrote: > --- Comment #7 from aldot at gcc dot gnu dot org 2006-05-21 17:46 --- >> Wouldn't it be better just to modify gcc/Makefile.in to do: >> >> ifneq($(BUILD_INFO),) >> info: $(INFOFILES) lang.info @GENINSRC@ srcinfo lang.srcinfo >> else >> info: >> fi >> >> Then, in the subdirectory Makefiles we can avoid checking BUILD_INFO at all. > > Agree, but i thought that this may be a bit more intrusive than touching the > one invalid invocation. Your original patch is OK for 4.1 -- but I would like the fix I suggested for 4.2. Also, we don't like to fix a problem on a release branch without also having a fix in mainline. Therefore, would you please test: (a) for 4.1, your original patch (b) for 4.2/mainline, a patch along the lines I suggested above, together with removing checks for BUILD_INFO from */Make-lang.in ? > OTOH, html is apparently not in the default install target, so if somebody > requests it explicitely, it may be ok to fail noisily. Yes, I think we can avoid this complication for HTML. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27516
[Bug c++/20103] [4.0/4.1/4.2 regression] ICE in create_tmp_var with C99 style struct initializer
--- Comment #51 from mark at codesourcery dot com 2006-05-22 02:15 --- Subject: Re: [4.0/4.1/4.2 regression] ICE in create_tmp_var with C99 style struct initializer pinskia at gcc dot gnu dot org wrote: > --- Comment #50 from pinskia at gcc dot gnu dot org 2006-05-21 20:51 > --- > Any news on this one? No. It's still in my queue, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/14494] Rejected valid specialization of member template
--- Comment #5 from mark at codesourcery dot com 2006-05-24 15:09 --- Subject: Re: Rejected valid specialization of member template reichelt at gcc dot gnu dot org wrote: > --- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-24 09:51 > --- > The case with A<0>::B() instead of A<0>::B() which was also > rejected was fixed with Mark's patch for PR20173. > > The original testcase with A<0>::B() still fails, though. > > Mark, would you mind having a look at this one, too, as you > were just working in that area? I probably won't get there any time soon, sadly; too many regressions to which I'm already assigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14494
[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression
--- Comment #8 from mark at codesourcery dot com 2006-05-31 22:56 ---
Subject: Re: [4.0/4.1/4.2 Regression] C++ error recovery regression
sabre at nondot dot org wrote:
> --- Comment #7 from sabre at nondot dot org 2006-05-31 22:17 ---
> Ok, makes sense. The strategy that made sense to me was "If I see a
> definition
> for something that obviously has to be at global scope, but is defined inside
> of a function, pop all the way out to global scope and continue, there must be
> a missing }".
One could attempt that -- but it would be hard. It would also fall
afoul of code like this:
void f() {
void g() {} // Must be at global scope, but I didn't know that.
g();
}
which is likely to be another common error mode, since:
void f() {
void g();
g();
}
is valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #12 from mark at codesourcery dot com 2006-06-01 14:59 --- Subject: Re: [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong jakub at gcc dot gnu dot org wrote: > --- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48 > --- > Does the C++ FE need the exact decl after gimplification? If not, perhaps > as a workaround pushdecl_maybe_friend could together with duplicating DECL_UID > also populate a hash table and cp-gimplify.c would use that hash table to make > sure only one of the decls with the same DECL_UID ever makes it into gimple. That's a good idea! I would still like to fix this "the right way" at some point (because there are other problems that would solve as well), but your idea would probably move the hack from the middle end into the front end. To answer your question directly, since the C++ front end is always unit-at-a-time, it doesn't care at all what happens after gimplification; by the time it's gimplifying, it's done all the semantic analysis it's going to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #14 from mark at codesourcery dot com 2006-06-06 16:37 --- Subject: Re: [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong amacleod at redhat dot com wrote: > --- Comment #13 from amacleod at redhat dot com 2006-06-06 14:43 --- > Created an attachment (id=11609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11609&action=view) > assert to add if Jakub's idea is implemented. > > So do you want to fix it Jakub's way instead of hacking up the tree optimizer? > or would you still prefer to simply apply my patch for now in 4.1 and 4.2? Please go ahead and apply your patch. (It's ready now, and Jakub's idea isn't.) > If/when Jakub's suggestion is implemented, I suggest adding the following > assert so you will know you have actually fixed it. This assert will trigger > whenever there is a duplicate DECL_UID on a variable. It triggers on > testcases from both this PR and 26757. Thanks!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #4 from mark at codesourcery dot com 2006-06-06 22:35 ---
Subject: Re: [4.0/4.1/4.2 regression] ICE with volatile in
conditional expression
reichelt at gcc dot gnu dot org wrote:
> --- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-06 22:12
> ---
> The following code is accepted. Shouldn't it be rejected then?
>
> ===
> struct A
> {
> A(int);
> };
>
> void foo(volatile A a) { 1 ? a : a; }
> ===
No, in that case the expression is an lvalue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #13 from mark at codesourcery dot com 2006-06-15 15:27 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer dj at redhat dot com wrote: > --- Comment #12 from dj at redhat dot com 2006-06-15 15:19 --- > Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from > 4 to 8 bytes in initializer > > >> I don't understand the assertion, given that removing it seems to >> generate correct output for this test case. > > The problem is that this function PADS rather than EXTENDS data that's > shorter than it's supposed to be, and it always pads in the same > direction - IIRC little endian. Thus, it breaks on big endian > machines, or machines that require sign extension. So, you believe that initializer_constant_valid_p should reject this initializer then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug c++/28113] vectors initialized in ctors, not at compile time, cause altivec-3.C failure
--- Comment #1 from mark at codesourcery dot com 2006-06-20 20:37 ---
Subject: Re: New: vectors initialized in ctors, not at compile
time, cause altivec-3.C failure
janis at gcc dot gnu dot org wrote:
> Test g++.dg/ext/altivec-3.C has been failing for mainline on powerpc64-linux
> systems without VMX hardware since this patch, a fix for PR20103, was added:
>
> http://gcc.gnu.org/viewcvs?view=rev&rev=114119
>
> r114119 | mmitchel | 2006-05-25 20:18:26 + (Thu, 25 May 2006)
>
> The test calls a function at runtime to determine if VMX hardware is available
> and if not, skips the rest of the test. It now fails because vector global
> variables are initialized by constructors instead of at compile time. Here's
> a
> minimal example:
>
> __vector signed int vsi = (__vector signed int) {40, 41, 42, 43};
> int main () { return 0; }
>
> If the new behavior is expected then I'll change the test to be compile-only
> on
> systems without VMX hardware.
Ideally, the compiler would recognize that this initialization can be
done statically, but I don't think that the code as written is in any
way guaranteed to do a static initialization. So, yes, I think you
should change the test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28113
[Bug c++/28113] [4.2 Regression] vectors initialized in ctors, not at compile time, cause altivec-3.C failure
--- Comment #3 from mark at codesourcery dot com 2006-06-20 21:00 --- Subject: Re: [4.2 Regression] vectors initialized in ctors, not at compile time, cause altivec-3.C failure pinskia at gcc dot gnu dot org wrote: > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-20 20:56 > --- > (In reply to comment #1) >> Ideally, the compiler would recognize that this initialization can be >> done statically, but I don't think that the code as written is in any >> way guaranteed to do a static initialization. So, yes, I think you >> should change the test case. > > Also is the initializer become a VECTOR_CST so it is easy to detect? No, it will be an lvalue as required by the C standard. The compiler would have to realize that an un-addressed temporary may be used as a static initializer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28113
[Bug libstdc++/28145] libstdc++ and pthread cancellation are incompatible (at least with NPTL)
--- Comment #1 from mark at codesourcery dot com 2006-06-23 18:14 ---
Subject: Re: New: libstdc++ and pthread cancellation
are incompatible (at least with NPTL)
drow at gcc dot gnu dot org wrote:
> On targets using a recent version of glibc and the NPTL threading package, if
> you cancel a thread using pthread_cancel while it is writing to an ostream,
> you'll get a fatal error and an abort from glibc.
> This problem has been discussed at length on the c++-pthreads list, but I
> don't
> think a consensus was really reached.
I believe that to solve this particular problem, a possible compromise
might be:
(1) Give the thread-cancellation exception a well-known name.
(2) Permit catching that exception -- but only if it is rethrown.
The point of (2) is that it avoids the controversy about whether or not
you are permitted to catch, and then not rethrow, the exception.
Then, you could write:
try {
io ();
} catch (__thread_cancel&) {
throw;
} catch (...) {
/* Normal catch handling. */
}
That would provide a mechanism for making libstdc++ (and other
applications) cancel-safe. It would still not solve the general
philosophical issues about whether or not you should be allowed to fail
to "eat" the cancellation exception, but I think it would be a step forward.
Another way to do this, instead of having a named exception, would be to
have a "__uncaught_cancellation()" function, similar to
"std::__uncaught_exception()". Then, you would do:
try {
io ();
} catch (...) }
if (__uncaught_cancellation ())
throw;
/* Normal catch handling. */
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)
--- Comment #4 from mark at codesourcery dot com 2006-06-24 04:10 ---
Subject: Re: C++ (throw() and catch(...) {/* fall through
*/ } ) and pthread cancellation are incompatible (at least with NPTL)
drow at gcc dot gnu dot org wrote:
> --- Comment #3 from drow at gcc dot gnu dot org 2006-06-24 02:52 ---
> No, that was not the consensus, and I reported this bug specifically because
> the coding practices used in libstdc++ cause problems with cancellation...
> progress was being made, the last time I read c++-pthreads, but trailed off.
I don't think it's necessary (or even useful) to wait for the standards
bodies to solve this problem. In practice, the c++-pthreads discussion
died off, and the C++ POSIX reflector has had no activity since January.
So, it's certainly going to be a while before we have standards
documents to rely upon.
However, we know that it should be possible to write cancel-safe C++
libraries (including, in particular, libstdc++); otherwise, it's hard to
use C++ in a multi-threaded application. And, we know that we can do it
with a very simple hook: we just need a way to ask whether the current
thread is being cancelled. GLIBC has lots of extensions; if we can have
__thread_cancelled(), we've got enough, without having to solve the
problem of whether or not it should be possible to catch (and not
rethrow) the thread-cancellation exception. (I'd rather have a name for
the thread exception, as that seems more natural, but this is a
difference only of syntax; the hook function would be a perfectly
satisfactory way to make progress.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145
[Bug c++/34269] [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof expressions accepted
--- Comment #6 from mark at codesourcery dot com 2008-11-11 20:09 ---
Subject: Re: [4.2/4.3/4.4 regression] Incomplete __decltype/__typeof
expressions accepted
jason at redhat dot com wrote:
> This seems right to me. It's even what the comment at the top of the
> file says we do:
>
> Then, while we attempt to parse the construct, the parser queues
> up
> error messages, rather than issuing them immediately, and saves
> the
> tokens it consumes. If the construct is parsed successfully, the
>
> parser "commits", i.e., it issues any queued error messages and
>
> the tokens that were being preserved are permanently discarded.
>
> The simulate_error business only works for parse errors that indicate
> that this line of parsing won't work; it doesn't work for code that
> parses fine, but violates semantic rules and therefore needs an error.
I forgot that comment was still there. I think it's a lie, reflecting
an earlier implementation state. I found queuing up the messages to be
really difficult.
For a syntactically broken construct, we can just issue the error and
commit to the tentative parse at that point. I believe we do that in
some other places. It doesn't matter what top-level construct
(declaration or expression-statement) we might be looking at; something
like "__decltype( ;" is always invalid. Once you see "decltype (" , if
the parsing of the operand to decltype fails, we can commit to the
current tentative parse, issue the error, and move on.
However, I think the core bug here may be that the code you mention in
cp_parser_simple_declaration doesn't check to see if the parse has
already failed. Committing to the tentative parse is reasonable in that
situation if the parsing has succeeded thus far -- but if we've actually
hit a *parse* error, rather than a *semantic* error, we could safely
give up.
That will result in trying to parse the decltype again (now as an
expression statement), and we'll get an error that time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34269
[Bug inline-asm/33932] miscalculation of asm labels with -g3
--- Comment #22 from mark at codesourcery dot com 2008-12-29 23:48 --- Subject: Re: miscalculation of asm labels with -g3 stsp at users dot sourceforge dot net wrote: > Can this possibly be solved by emitting > a warning if the asm in global scope is > used with -ffunction-sections? I think the generalization of Steven's point is that we can't really know what section the user's assembly code should go in: text, data, or something else, and therefore we'd better depend on the user to tell us. I still think it would be an OK idea to try to reduce the chances of something bad happening -- and the inconsistency between -g levels -- by popping back from the debug section, but the fundamental point is that if the user wants full robustness they need to say what section in which to put the assembly code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33932
[Bug middle-end/38851] [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #16 from mark at codesourcery dot com 2009-01-25 20:03 --- Subject: Re: [4.4 regression] Compiler warns about uninitialized variable that is an object with a constructor rguenther at suse dot de wrote: >> Therefore, I don't think that the key here is "zero-size". Instead, it's the >> fact that structure cannot be initialized. That's useful both for warnings >> and >> for optimization; it can't be initialized, so there's no point about warning >> about uninitialized uses, and there's no reason to actually generate code for >> the copies. > > Ok, I think mapping cannot be initialized to zero-size is ok, as that is > the only thing we can currently query (and we even specialize this > for C++ to deal with the 1 byte vs. empty case). Yes, I think it's OK to approximate "logically empty" by "zero-size" at present. It might be worth either changing the zero-size documentation/name to reflect that it means "logically empty" (if we think these are the same concept) or else defining a separate LOGICALLY_EMPTY_P predicate (implemented by checking for zero size) as a hedge against separating them (if we think they are usefully distinct concepts). > It's a P1 defect as we didn't warn for uninitialized structure > uses in any previous relelase. While we can argue that it is safe > to downgrade this to P2 I think we should at least try to fix this > issue for 4.4.0. I don't mind fixing it, of course, and it would certainly be better to do so. But, at the end of the day, if everything else is ready, I'd be opposed to holding up the release for this. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug c++/24780] [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos
--- Comment #5 from mark at codesourcery dot com 2005-11-11 06:26 --- Subject: Re: [4.0/4.1 Regression] ICE set_mem_attributes_minus_bitpos pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-10 23:20 > --- > Mark do you know if your patch for PR 20912 would fix this? I don't know one way or the other. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24780
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #10 from mark at codesourcery dot com 2005-11-14 17:59 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer giovannibajo at libero dot it wrote: > --- Comment #9 from giovannibajo at libero dot it 2005-11-14 00:30 > --- > Mark, do you believe that the introduction of COMPOUND_LITERAL_EXPR in the C++ > frontend could be feasable for 4.1? It's possible, but I somewhat doubt it. I'm afraid we won't know all the places that need to change. I'd actually like to understand better why the middle-end is no longer able to handle CONSTRUCTORs as it used to; this was a change in the middle-end interface at some point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug c++/23171] [4.1 Regression] ICE on pointer initialization with C99 initializer
--- Comment #12 from mark at codesourcery dot com 2005-11-14 18:27 --- Subject: Re: [4.1 Regression] ICE on pointer initialization with C99 initializer dberlin at gcc dot gnu dot org wrote: > --- Comment #11 from dberlin at gcc dot gnu dot org 2005-11-14 18:14 > --- > Mark, the frontend is producing the address of a constructor, and nothing in > the middle end used to be really analyzing static iniatlizers which is why it > didn't break before (those that do try to look at them would give up in this > case, but static vars analysis can't give up without destroying the results of > the entire analysis) OK, that's a good summary of the key change. My point was simply that this is not something new the front-end started doing; it's been using this construct to mean "address of a temporary" for a long time. > IMHO, this easier to fix in the frontend than in the middle end, by simply not > producing &CONSTRUCTOR. I agree that, at least, the best fix is in the front-end. However, it probably won't be trivial to do. If the problem only affects static initializers, then we should probably try to localize the change to that code, rather than trying to introduce COMPOUND_LITERAL_EXPR throughout the front end at this point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #25 from mark at codesourcery dot com 2005-11-16 16:53 --- Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex schwab at suse dot de wrote: > --- Comment #23 from schwab at suse dot de 2005-11-16 14:20 --- > (In reply to comment #22) > >>Note I never said __imag__ a should not act like an lvalue. I just said that >>__imag__ a = b; acts like a = COMPLEX, b> which is just like what >>a = (a&0x)|(b&0x) does. If the compiler wants to implement it that way, that's OK. What's not OK is to warn about the fact that the real part is uninitialized. There is no user out there anywhere that wants to be warned about this case; it is in fact valid code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #31 from mark at codesourcery dot com 2005-11-16 18:58 --- Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex pinskia at gcc dot gnu dot org wrote: > From the C perspective the warning is correct as you are loading piece wise > which is not really supported at all, even shown by my integer testcase. This is not a valid argument. The point of warnings is not to tell the user how the compiler works; it's to tell the user that their code is in some way suspect. Please explain why a user would want a warning on this code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Comment #33 from mark at codesourcery dot com 2005-11-16 20:08 --- Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex pinskia at gcc dot gnu dot org wrote: > --- Comment #32 from pinskia at gcc dot gnu dot org 2005-11-16 19:58 > --- > (In reply to comment #31) > >>This is not a valid argument. > > What would you consider a valid argument for an extension which is not that > well documented? We're not talking about the extension; we're talking about the warning. Your job is to explain why a user wants to see that warning on that code. Thankfully, RTH is going to eliminate the warning. You can file a bug about the "missing" warning, if you think it's important. You can also lobby for removing the extension, if you like -- but please don't do it in this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug target/24934] [4.1 Regression] profilebootstrap failure
--- Comment #15 from mark at codesourcery dot com 2005-11-19 17:34 --- Subject: Re: [4.1 Regression] profilebootstrap failure rguenth at gcc dot gnu dot org wrote: > --- Comment #13 from rguenth at gcc dot gnu dot org 2005-11-19 10:38 > --- > Changing the summary to reflect reality and remove some of the obscure-ness. > Mark, what was the obscureness you are refering to? Sorry, that was indeed unclear. I don't consider building the compiler with profiledbootstrap to be a fundamental usage model. Most people don't do it, and there's an easy work-around: build with normal bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug c++/24199] [3.4 Regression] Segfault with -frepo -g
--- Comment #5 from mark at codesourcery dot com 2005-11-22 05:17 --- Subject: Re: [3.4 Regression] Segfault with -frepo -g gdr at gcc dot gnu dot org wrote: > --- Comment #4 from gdr at gcc dot gnu dot org 2005-11-21 02:39 --- > (In reply to comment #3) > >>It looks like it was fixed on mainline by this patch from mmitchel: >> >> http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01218.html > Do you believe your patch is also good for GCC-3.4.x? Yes, that looks safe to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24199
[Bug middle-end/24998] [4.2 Regression] Build failure on sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
--- Comment #16 from mark at codesourcery dot com 2005-11-26 21:48 --- Subject: Re: Patch for ia64-hpux problems Joseph S. Myers wrote: > This patch fixes the ia64-hpux problems with my __floatun* patch. It adds > a full set of C implementations of __floatunsi* which should also be > usable to solve the arm-netbsdelf problems. > > Bootstrapped with no regressions on ia64-hp-hpux11.23. OK to commit? OK, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24998
[Bug middle-end/25125] [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type
--- Comment #11 from mark at codesourcery dot com 2005-12-19 18:40 --- Subject: Re: [4.1/4.2 Regression] (short) ((int)(unsigned short) + (int)) is done in the wrong type Kazu Hirata wrote: > Hi Mark, > >> (Why should we get 1? Upon entry to f, a will be 1, since 32769 will be >> reduced modulo 2^16. Then, b will be 1 - 32768, or -32767. I don't >> see why >> that should be converted to 1 -- but I certainly don't see why it >> should be >> 32768 either.) >> >> In any case, wrong-code: P1. > > First, 32769 will be reduced to -32767. > (int) -32767 + -(int)32768 = -65535. > If we take the lowest 16 bits of -65535, we get 1, and that's what f > should be returning. I believe you. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25125
[Bug bootstrap/25502] Werror problem in build
--- Comment #5 from mark at codesourcery dot com 2005-12-22 08:19 --- Subject: Re: Werror problem in build fxcoudert at gcc dot gnu dot org wrote: > --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-22 07:35 > --- > (In reply to comment #3) > >>So, on MinGW, you should --disable-werror. > > > I can understand the why, but I don't think it should be required (because > that > means other warnings will not be spotted). There is no way around this; if you do not use the special Microsoft formats you will not get incorrect results; there are places where GCC must print a 64-bit integer, especially when configured with 64-bit HOST_WIDE_INTs, which is required for some targets. > And anyway, it should at least be release-noted. Good idea! Care to submit a patch for the caveats page? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions rakdver at gcc dot gnu dot org wrote: > --- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40 > --- > Patch: > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html This patch is not OK, but it's close. We should not call unshare_expr on DECL_INITIAL until after the mark_used call, as static data members in templates will not have proper initializers until after that point. Also, there's no need to unshare *before* calling fold_non_dependent_expr. In fact, there's no need to unshare before the return statement at the end of the function. That will avoid creating trees that will only be thrown away later. So, why not just do: return unshare_expr (decl); at the end of the function? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #10 from mark at codesourcery dot com 2006-01-04 00:01 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied
into two different functions
rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
>tree const_expr = expr;
>do
> {
>expr = fold_non_dependent_expr (const_expr);
>const_expr = integral_constant_value (expr);
> }
>while (expr != const_expr);
>
> and if constant_value_1 (called by integral_constant_value) unshares the
> expression unconditionally (not only when it processes DECL_INITIAL),
> this loop never ends.
OK; then call unshare_expr after the "break" statement in
constant_value_1, and before "decl = init;".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug c++/25632] [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions
--- Comment #11 from mark at codesourcery dot com 2006-01-04 00:02 --- Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two different functions rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > what about this patch, then (assuming it passes testing)? Better -- but there's no reason to do it before the break statement; if we're not going to use init, then we don't neeed to unshare it. I think you can do it right *after* the break statement. > Index: cp/init.c > === > *** cp/init.c (revision 109271) > --- cp/init.c (working copy) > *** constant_value_1 (tree decl, bool integr > *** 1503,1508 > --- 1503,1510 > mark_used (decl); > init = DECL_INITIAL (decl); > } > + init = unshare_expr (init); > + > if (!(init || init == error_mark_node) > || !TREE_TYPE (init) > || (integral_p > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25632
[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls
--- Comment #5 from mark at codesourcery dot com 2006-01-14 04:56 --- Subject: Re: [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls Richard -- First, please respect my request that only the RM set priority fields for bugs. Therefore, please set this back to P3, until I have time to look at it. Second, please give me some time to look at; I've just returned from a one-week offsite. I've not forgotten about this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25663
[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls
--- Comment #9 from mark at codesourcery dot com 2006-01-14 18:44 --- Subject: Re: [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls rguenth at gcc dot gnu dot org wrote: > --- Comment #7 from rguenth at gcc dot gnu dot org 2006-01-14 10:55 > --- > (ignoring Pinskias valid but not helpful comments) > > Sorry Mark, it was not meant as a personal offense No offense taken! > I have reverted the priority to P3. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25663
[Bug c++/25663] [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls
--- Comment #10 from mark at codesourcery dot com 2006-01-14 18:48 --- Subject: Re: [4.0/4.1/4.2 Regression] Trouble parsing nested templated constructor calls steven at gcc dot gnu dot org wrote: > --- Comment #8 from steven at gcc dot gnu dot org 2006-01-14 12:22 > --- > Mark, > > Re. your comment #5, I think everyone respects your request that only the RM > sets priorities. But right now the RM fails to do so. I think that's an overly strong statement. I try to make a pass over the open bugs every few weeks. But, I will try to increase the frequency at which I do this. > In this case, you don't comment at all on a regression that you caused, until > Richard escalates the issue and sets the priority higher himself. Richard > reported the problem 12 days ago today. Do you think it is strange that > people > get annoyed with you if you cause regressions and then essentially disappear > for 12 days? I wish I'd been able to fix this more quickly, but there are certainly other regressions that have been open longer than 12 days. > Had it been someone else instead of you who caused this bug, > people would have reverted the patch causing this bug long ago. I don't think that's true; it's not that critical of a bug. However, we do have a process in place for reversions, and it's certainly reasonable to invoke that process if you think that's appropriate. In this case, however, it looked like Richard was not aware of the process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25663
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #29 from mark at codesourcery dot com 2006-01-18 23:00 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) I think that we should do as follows. Preserve the original value of maximum_field_alignment when doing #pragma pack. Then, for zero-width bitfields, we should align to the minimum of the original maximum_field_alignment and the otherwise natural alignment. The difference between this and the last proposed patch is that I don't think we should entirely ignore maximum_field_alignment for zero-width bitfields; if "long long" as a field will only have (say) 2-byte alignment on some embedded target where structure-packing is the default, then a "long long : 0;" bitfield should only force 4-byte alignment. However, that's an abstract argument; I'm not actually sure what existing practice was with older versions of GCC. Again, in the abstract, I think the example in Comment #12 ought to have size 8 on both IA32 and AMD64 architectures. I can't see any good justification for size 12, with a PCC_BITFIELD_TYPES_MATTER ABI. And, I think that the size of the structure with #pragma pack(1) ought to be the same as with __attribute__((packed)). So, my concern with the patch in Comment #12 is that it would ignore the pre-set maximum_field_alignment on targets with default structure packing; other than that, I think it looks fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #31 from mark at codesourcery dot com 2006-01-18 23:28 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > --- Comment #30 from steven at gcc dot gnu dot org 2006-01-18 23:08 > --- > We should at least avoid introducing a third variant of how we lay out these > nasty zero-sized friends. People actually use them. For example Wine uses > them to enforce compatible alignment and data layout with MS Windows > datastructure. Wine has a bunch of #ifdefs spread around in its sources to > make it work with the pre- and post-GCC 3.4 layout. Adding a third would > drive > those poor people nuts. I agree -- but I don't think we're talking about a third variant. Michael's patch looks to me like it will restore the pre-3.4 behavior, which everyone agrees makes more sense. My issue with respect to maximum_field_alignment doesn't really apply to pre-4.0 toolchains, since they didn't have default structure packing for targets, AFAICT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #33 from mark at codesourcery dot com 2006-01-19 16:59 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) matz at suse dot de wrote: > --- Comment #32 from matz at suse dot de 2006-01-19 14:44 --- > Mark, I agree that it's saner when both structures (with #pragma pack and > attribute packed) have the same length of 8 on i686 and x86_64 (because > the bitfield was declared 'int' in difference to 'long' for instance). > > Then I have a question to clarify if I understood correctly: by remembering > the original maximum_field_alignment and using that for zero-sized bitfields > you want to use the absolute first, default, m_f_a, or the one last set > before the innermost #pragma pack? Consider an example like so, and lets > assume the initial max field alignment was 4: > > mfa == 4 > #pragma pack(2) // 1 mfa == 2 > #pragma pack(1) // 2 mfa == 1 > #pragma pack() // 3 mfa == 4 > #pragma pack (push,2) // 4 mfa == 2 > #pragma pack (push,1) // 5 mfa == 1 > #pragma pop // 6 mfa == 2 > #pragma pop // 7 mfa == 4 > > With what would you constrain the alignment of a zero sized bitfield > at each of the seven points? I'm suggesting that a zero-width bitfield have the same alignment influence at all 7 points. In your example, mfa would be effectively four at all 7 points. > What if the initial mfa is 0 (i.e. not set)? Then, it should be zero at all seven points, meaning that a zero-width bitfield of type T would force alignment to whatever alignment a field of type T would have. > Should -fpack-struct=... (which influences the initial mfa) influence > that constraint too, or not? That's harder, but I think it should. The point is basically that, independent of #pragma pack, a zero-width bitfield should give you the alignment it would give you oustide of the #pragma packs. > My opinion is, that at each of the seven points above we should constrain > with the initial mfa (i.e. 4 in the example above), as adjusted by > the -fpack-struct command line option. Good, we agree! > Another point: If we make the structure with attribute packed on both x86 and > x86-64 be eight long (to agree with the behaviour of using pragma), then we > do add another variant unfortunately. In pre 3.4 that structure was 12 on > x86-64 (which I think was an actual error). That's unfortunate, but given that things are moving around, I think we should go for maximum sanity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #35 from mark at codesourcery dot com 2006-01-19 19:14 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?) steven at gcc dot gnu dot org wrote: > - Older HP compilers and MS compilers use zero-length bit-fields to force > the following member of a struct to the next natural (is that GCC's > BITS_PER_WORD?) boundary. > - XLC and HP on IA-64 force alignment corresponding to the type of the bit > field, of which IBM says it is essentially the same, but this is not true > for GCC with e.g. long long on ix86. That's essentially the PCC_BITFIELD_TYPE_MATTERS distinction; the HP/MS compilers in the first bullet point are not using the pcc-style bitfields. Your research is interesting. However, I'm not too worried about our handling of zero-width bitfields by themselves; the various psABIs specify that behavior, so we have a clear guideline. It's when we throw in various GCC extensions (#pragma pack, __attribute__((aligned)), etc.) that it gets complicated and hard. I'm hoping that since Michael and I independently came to the same conclusion about how things should work, and since there were no objections to my initial proposal to change things back on the mailing list, we're actually pretty close to a patch. Michael, do you plan to revise your patch to implement the semantics on which we've agreed? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change (regression?)
--- Comment #38 from mark at codesourcery dot com 2006-01-20 18:02 ---
Subject: Re: [3.4/4.0/4.1/4.2 Regression] bitfield
layout change (regression?)
matz at suse dot de wrote:
> --- Comment #37 from matz at suse dot de 2006-01-20 16:36 ---
> Hmpf. One more difficulty. x86 uses the ADJUST_FIELD_ALIGN macro
> to further fiddle with alignments of fields. On x86 this is used to
> adjust the alignment of long long to 4 (instead of the natural 8).
> This is used only when the field is not DECL_PACKED (makes sense).
> This has the funny side-effect that a struct containing a long long zero-width
> bitfield aligns to 4 for unpacked and to 8 for packed structs
Ugh. I think we can all agree that these issues had not been well
thought through previously. :-)
> if (! DECL_USER_ALIGN (decl) && ! DECL_PACKED (decl))
> {
> #ifdef ADJUST_FIELD_ALIGN
> DECL_ALIGN (decl) = ADJUST_FIELD_ALIGN (decl, DECL_ALIGN (decl));
> #endif
> }
>
> Now, I could just ignore DECL_PACKED for zero-width bitfields, then the
> adjustment would be done for both cases and we had a size of 12 with
> attribute or pragma, i.e. not the same as pre 3.4 in both.
I don't think a zero-width bitfield should ever be DECL_PACKED. (In
this case, it's DECL_PACKED because the structure is in the scope of
#pragma pack(1).)
In other words, I think a zero-width bitfield should always be subject
to ADJUST_FIELD_ALIGN; the meaning of a zero-width bitfield of type T
(for PCC_BITFIELD_TYPE_MATTERS) should be "align the next field as you
would a field of type T".
> I'm leaning towards not doing field adjustments for zero-width bitfields
> at all, having the effect that a zero-width bitfield has a user-alignment
> set explicitely (of it's base type).
Careful! That would be an ABI change even in the non-packed case, which
we don't want to do.
I think the best change would be just not to mark zero-width bitfields
as DECL_PACKED in the first place; a second choice, if easier, would be
to disregard the DECL_PACKED setting in stor-layout.c. Please add a
test case for this new oddity you discovered, if you would.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern "C"
--- Comment #15 from mark at codesourcery dot com 2006-07-19 06:00 --- Subject: Re: [4.0 Regression] rejects valid code with some extern "C" tbm at cyrius dot com wrote: > So apparently this is invalid code. However, I feel very strongly that a > point > release of GCC should *not* introduce a new error - Mark, please modify the > patch applied to the 4.1 branch in a way to allow this code. As a matter of policy, we don't intentionally introduce errors on release branches. However, it is far too strong a statement to say that we should never introduce an error. In many such cases, the new error is either indicative of a situation in which the compiler was behaving randomly (i.e., in which the generated code made no sense) or the new error is a side-effect of some other important change. In this case, we were rejecting valid code. We no longer reject valid code; instead we reject invalid code. (Andrew's comment about the DR being open is accurate, but the DR will almost certainly be resolved so as to make this code invalid.) If you want to find a way to accept the invalid code on the release branch, that's your privilege. I consider it a better use of my (very limited) time to fix places where the compiler fails to conform to the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #2 from mark at codesourcery dot com 2006-07-23 15:59 --- Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE drow at gcc dot gnu dot org wrote: > --- Comment #1 from drow at gcc dot gnu dot org 2006-07-23 00:12 --- > Mark, did the old C++ parser have TYPE_CONTEXT == NULL for the global scope > and > the new one have it pointing to the global namespace, or something like that? No, I don't think so. The representation has "always" (i.e., for as long as I can remember) been that the global namespace was represented as NULL_TREE, while other namespaces are represented by NAMESPACE_DECL. (One could argue that's a silly non-uniformity, but that's how it's always been.) > If so, I guess we'll have to strip that out in dwarf2out. We can't compare > against global_namespace, so do you have a recommendation on how to identify > it? If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++ front end bug. Which type is getting set up like that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug debug/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #4 from mark at codesourcery dot com 2006-07-23 16:48 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
> --- Comment #3 from drow at gcc dot gnu dot org 2006-07-23 16:44 ---
> Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
>
> On Sun, Jul 23, 2006 at 03:59:58PM -0000, mark at codesourcery dot com wrote:
>> If we're setting TYPE_CONTEXT to global_namespace, I think that's a C++
>> front end bug. Which type is getting set up like that?
>
> I was wrong; TYPE_CONTEXT looks OK. How about for DECLs?
The same rule applies; DECL_CONTEXT should also be NULL_TREE for an
entity in the global namespace.
> (gdb) call debug_tree (decl.decl_minimal.context)
> line 0
> align 1
>>
>
> So, the variable is in the global namespace explicitly.
Ugh. I'm not surprised that this works (in the C++ front end) since we
have logic that basically equates NULL_TREE with global_namespace, for
those situations in which we explicitly need to have a namespace around.
However, the global_namespace should never end up as
{DECL,TYPE}_CONTEXT of anything.
So, I think you should reclassify this as a C++ front end bug. You're
still free to fix it of course. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #8 from mark at codesourcery dot com 2006-07-23 20:17 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
drow at gcc dot gnu dot org wrote:
> It did so by introducing FROB_CONTEXT. Right now, FROB_CONTEXT is used at a
> number of places which set DECL_CONTEXT, but not at a number of others (13
> with, 55 without). Some of those without obviously don't need it. Others are
> less clear. But after going through them all, I think only two need it. The
> obvious patch works for my testcase. I will regression test it more
> thoroughly.
It sounds to me like the best thing might be to have:
#define SET_CP_DECL_CONTEXT(NODE, CONTEXT) \
(DECL_CONTEXT (NODE) = FROB_CONTEXT (NODE, CONTEXT))
and use that everywhere. I'd rather not be clever about where we might
have to use it and where we might not.
(IMO, the ideal representation would have global_namespace for
DECL_CONTEXT -- but that's not a change we can make without affecting
the middle end, as you've noticed, so I think having
{SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug c++/28460] [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
--- Comment #11 from mark at codesourcery dot com 2006-07-24 00:05 ---
Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace
DIE
gdr at integrable-solutions dot net wrote:
> --- Comment #10 from gdr at integrable-solutions dot net 2006-07-23
> 23:47 ---
> Subject: Re: [4.0/4.1/4.2 Regression] g++ emits bogus namespace DIE
>
> "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | (IMO, the ideal representation would have global_namespace for
> | DECL_CONTEXT -- but that's not a change we can make without affecting
> | the middle end, as you've noticed, so I think having
> | {SET_,}CP_DECL_CONTEXT to insulate us would be a nice improvement.
>
> I agree that is the correct representation. Can we agree to have it
> for GCC-4.3 or higher?
Not necessarily. It depends on the middle-end impact. This is just a
cleanup; the current representation is certainly adequate to represent
C++, despite having a special case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28460
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #11 from mark at codesourcery dot com 2006-08-02 03:29 --- Subject: Re: [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088 steven at gcc dot gnu dot org wrote: > Why is this a P1 regression? ia-64 is not a primary platform. True -- but IA64 is a secondary platform, and this looks like relatively straightforward code. I think it's important. If we get all the other P1s done, we can argue about whether or not to ship the compiler. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #5 from mark at codesourcery dot com 2006-09-01 22:30 --- Subject: Re: [4.1/4.2 regression] Template specialization with array rejected pinskia at gcc dot gnu dot org wrote: > --- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 22:24 > --- > (In reply to comment #3) >> There shouldn't be a NON_LVALUE_EXPR here at all; non-type template >> parameters >> are lvalues only if they have reference type. > > fold produces it because maybe_lvalue_p returns true for Language specific > trees > and fold is folding (template_parameter+1)-1. So, that's what should be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug c++/28886] [4.1/4.2 regression] Template specialization with array rejected
--- Comment #8 from mark at codesourcery dot com 2006-09-02 03:50 --- Subject: Re: [4.1/4.2 regression] Template specialization with array rejected pinskia at physics dot uc dot edu wrote: > --- Comment #7 from pinskia at physics dot uc dot edu 2006-09-02 01:39 > --- > Subject: Re: [4.1/4.2 regression] Template specialization > with array rejected > > On Fri, 2006-09-01 at 22:30 +, mark at codesourcery dot com wrote: >> So, that's what should be fixed. > Except that means introducing a language hook which > is only to be useful in one place. That's not necessarily a bad thing. But, introducing NON_LVALUE_EXPRs that we are just going to throw away is a bad thing. And, yes, if we can avoid generating MINUS_EXPRs, that would be even better. In general, it might be better if range types were expressed as half-open intervals, rather than closed intervals, since then the number of elements in the array would be immediately available, and that's something often wants. > The real real way of fixing this is to move the C++ > front-end's templates from using trees You bring this up every so often, but I am totally unpersuaded. Using trees is just fine for C++. The advantages to not using trees would be interfacing to things other than GCC itself; there are no advantages within the compiler. For example, if we didn't have trees for C++, we'd be totally unable to use fold. In any case, this is entirely orthogonal to the issue at hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28886
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #20 from mark at codesourcery dot com 2006-10-03 16:13 --- Subject: Re: [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should ian at airs dot com wrote: > Fortunately I believe that in a correct program we only have a problem when we > can actually see the placement new (can any disprove that)? I personally > don't > have a problem with saying that placement new is special. When placement new > is used, it has to move the pointer into alias set 0. What about in C, as opposed to C++? I agree that the obvious special cases are access through char*, arrays of characters, and placement new. But, I'm afraid that there are lots of other allocation functions out there that are not spelled "operator new", and requiring decoration for them isn't something that (as far as I know) other compilers require. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2 Regression] placement new does not change the dynamic type as it should
--- Comment #22 from mark at codesourcery dot com 2006-10-04 05:39 ---
Subject: Re: [4.0/4.1/4.2 Regression] placement new
does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #21 from ian at airs dot com 2006-10-03 23:44 ---
> In C a general allocation function should work with a char array. A specific
> allocation function should use a union. I don't think there are many existing
> exceptions to these guidelines.
> So I don't see a serious problem in C either. Am I missing something/
I think there are two remaining issues:
int i;
*(float*)(&i) = 7.0;
IIUC, Mike's position is that this is valid -- and that, in fact, after
this point "i" can no longer be accessed as an int. Do you agree? Or
do you think that this is (should be?) undefined behavior?
I think you are saying that:
int i;
new (&i) float;
is valid, and that after this point accessing "i" as an int is invalid.
Is that correct? If so, I assume that you conider the following C
code valid as well:
int i;
float f;
memcpy (&i, &f, sizeof (i));
?
Also, in C++, given:
extern void f(int *);
void g() {
int i;
f(&i);
/* HERE */
}
do you believe that at the point marked HERE the dynamic type of "i" is
indeterminate? I think that if we allow the examples above, we have to
assume that something may have reset the dynamic type of "i" here,
meaning that we cannot assume that future stores through "float *" in
the function do not alias "i".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c++/29236] [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend
--- Comment #7 from mark at codesourcery dot com 2006-10-10 16:23 --- Subject: Re: [4.0/4.1/4.2 Regression] Bogus ambiguity with templates + friend bangerth at dealii dot org wrote: > We've been over that before, Andrew. It has always been the case that > bugmasters do the initial triage, including setting an initial priority. > We've done that at least back to 2002, when we were still using GNATS instead > of bugzilla. It is also true that the RM has the prerogative to downgrade > priorities if he doesn't deem things that important. I have asked that all bugs be left at P3, and that I set their initial priority. I also welcome input about what the priority should be, ideally in the audit trail for the PR itself. But, looking at P3 bugs is how I see what the new bugs are. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29236
[Bug middle-end/29683] [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption
--- Comment #12 from mark at codesourcery dot com 2007-01-30 06:39 --- Subject: Re: [4.1/4.2 Regression] Arg split between stack/regs can cause stack corruption ebotcazou at gcc dot gnu dot org wrote: > --- Comment #11 from ebotcazou at gcc dot gnu dot org 2007-01-30 06:17 > --- >> Same fix that was applied to mainline resolved the issue in 4.1 and 4.2 >> branches. Checked in to both of those branches. > > You probably shouldn't have do that on the 4.1 branch: > http://gcc.gnu.org/ml/gcc/2007-01/msg01151.html > > Mark, does the RC1 contain the patch? No, it does not. The RC1 sources were from yesterday afternoon, and Josh's patch was not committed until today. (Both times are PST.) It's pretty hard to keep track of all the GCC mail to see when things are frozen, etc. And, I did approve the patch for 4.1, prior to the freeze. So, it's a very easy mistake to make. Josh, please leave the patch checked in. If we need an RC2 anyhow, then having this patch in is fine. If not, then I may pull it out before the official release. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29683
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #15 from mark at codesourcery dot com 2007-02-04 22:53 --- Subject: Re: Shared libstdc++ fails to link danglin at gcc dot gnu dot org wrote: > Personally, I believe that the fix for PR 29323 was wrong and has > bloated the EH data emitted by GCC. The EH data for a module are > only relevant to the functions in the module itself. If a function > in a module can't throw, then we don't need EH exception data for > it. I'm not sure what "EH data" is being described here. Certainly, it makes no sense at all to emit EH unwind information for functions which are not part of the current object file; their unwind information will be emitted with those function. What sort of data is being emitted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #17 from mark at codesourcery dot com 2007-02-05 03:06 ---
Subject: Re: Shared libstdc++ fails to link
dave at hiauly1 dot hia dot nrc dot ca wrote:
> Unwind data. We're talking about functions compiled in the
> current object.
OK.
I'm not sure it matters, but if these functions don't throw exceptions,
I don't understand why we're not marking them TREE_NOTHROW. I suspect
there's something that I'm just not following.
The fact that linker semantics allow you to replace a function at the
object level do not make it valid at the language level.
So, for example, I would expect:
void f () throw () {}
and:
void g() {}
to both be TREE_NOTHROW, independent of linkage, weakness, etc.
Certainly, not marking such functions as TREE_NOTHROW will inhibit
optimization of their callers, which seems bad.
Why aren't the functions being marked TREE_NOTHROW?
> There are numerous "one-only/weak" functions which don't bind locally
> in libstdc++. Previously, *ALL* these functions were determined to be
> nothrow and no unwind data was emitted for them. Now, unwind
> data is being emitted because these functions don't bind locally.
> This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a
> latent bug) because of the relocation issue mentioned above.
I understand that this is a latent bug in the HP-UX linker.
To be honest, I'm less concerned about HP-UX 10.10 per se than about the
possible bloat on other targets. (HP-UX 10 is not a primary or
secondary target.) At the same time, I certainly don't want to
gratuitously break any target.
Assuming that the changes in TREE_NOTHROW and emission of exception
information make sense, what solution would you implement for HP-UX 10?
Use SJLJ exception handling?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #13 from mark at codesourcery dot com 2007-02-05 03:18 --- Subject: Re: C++ FE emitting assignments to read-only global symbols steven at gcc dot gnu dot org wrote: > Mark was going to leave this for GCC 4.2, but hasn't fixed this for GCC 4.2 > yet, either. What's going to happen with this bug? After Diego's comments, it didn't sound like it was still important to fix it. Does the patch in Comment #6 still apply? It looks like to me as if it would (at least in principle; the code affected still looks the same). If so, it's OK to apply to mainline, assuming test results go OK. Would you like to test it? If that fix will also fix PR 23777, then the same fix is also OK for 4.2. If not, then is there any compelling reason to apply it to 4.2? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #19 from mark at codesourcery dot com 2007-02-05 05:40 --- Subject: Re: Shared libstdc++ fails to link dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05 > 04:02 --- > Subject: Re: Shared libstdc++ fails to link > >> I'm not sure it matters, but if these functions don't throw exceptions, >> I don't understand why we're not marking them TREE_NOTHROW. I suspect >> there's something that I'm just not following. > > See the testcase for PR 29323 and the initial problem description. Thanks. The fact that the declaration is explicitly declare weak seems somewhat persuasive. C++ has no notion of weak symbols, so once you declare a function weak, you're outside the standard anyhow, and it's reasonable to say that you can replace such a function with one of the same type. However, that doesn't mean that the check for binds_local makes sense. In particular, a COMDAT template instantiation may not bind locally (IIUC), but it's invalid to replace the template instantiation with one that behaves differently. So, it sounds like the change that's been made unduly pessimizes C++ template instantiations, which would plausibly result in the behavior you're seeing. And, as you say, even for explicitly weak functions, it doesn't make sense to emit EH unwind information if the functions never throw. That's just a pessimization. So, as has been said elsewhere, that suggests that -- for the weak function case -- we need to distinguish "body of this function needs unwind information" from "callers of this function must assume it throws exceptions". Frankly, my inclination would be to just declare that in GNU C++, replacing a "weak" function with an implementation that throws more exceptions than the version in the current translation unit is invalid, no diagnostic required. This doesn't seem like a case worth twisting our internal representations around to support. >> Assuming that the changes in TREE_NOTHROW and emission of exception >> information make sense, what solution would you implement for HP-UX 10? >> Use SJLJ exception handling? > > Yes, config.gcc could be modified to force SJLJ exception handling. > Of course, I'm hoping for a better fix to PR 29323. Right. I've CC'd Richard G on the PR. Richard, what are your thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #25 from mark at codesourcery dot com 2007-02-05 19:33 ---
Subject: Re: Shared libstdc++ fails to link
rguenth at gcc dot gnu dot org wrote:
[Paolo, see below for question.]
> --- Comment #20 from rguenth at gcc dot gnu dot org 2007-02-05 09:06
> ---
> What we want to prevent with the patch for PR29323 is the TREE_NOTHROW flag
> propagating to a locally binding function. Consider
>
> void foo() nothrow __attribute__((weak)) {}
>
> void bar()
> {
> foo();
> }
>
> we need EH unwind data emitted for bar() even if foo() is marked or
> analyzed as nothrow as at run time bar() might call a foo() that throws.
>
> At least if using C and -fexceptions this is a valid use (we of course
> can declare this invalid for C++, but this can be a runtime error only
> which will then be hard to diagnose).
I think I agree that the C -fexceptions example is compelling, and I
find the same example in C++ reasonably compelling too, the ODR
notwithstanding, since that's clearly the intent of __attribute__((weak)).
> I'm in no way expert enough to say if we can omit EH data for foo() in
> the above case (we probably can), but if so then splitting the TREE_NOTHROW
> flag into two is probably the right thing to go.
I don't think there's any reason we should need EH data for foo. I
would think that it is in fact reasonable to mark "foo" TREE_NOTHROW.
However, when analyzing bar() (which we do by walking its body, looking
for calls, to work out whether anything that bar calls can throw an
exception), we should avoid marking "bar" TREE_NOTHROW in this case.
I think the analysis should be deeper than just "binds_local_p", though;
I think it should be based on whether "attribute ((weak))" (or
equivalent) explicitly appears, so that we don't pessimize bar if foo is
in a template function, out-of-line inline, or other such function. The
test ought to be based on the demonstrable intent of the user to replace
the function, not on whether or not the function happens to be weak.
> I suppose PR29323 was found by inspection of GCC code rather than a real-world
> testcase so the option to revert that patch on the 4.1 branch looks appealing.
I agree. If my suggestion above seems correct, then the first step is
to undo the change that make "foo" not marked TREE_NOTHROW. Since that
restores the 4.1.1 status quo, will presumably fix HP-UX 10.10, and
eliminate any pessimization in 4.1.2, I think we should do that. The
same reversion should be applied to mainline and 4.2, since the same
considerations apply there. If we get excited about fixing the
pre-existing problem with weak functions, we can do that later.
Paolo, would you be able to undo the change to make "foo" not marked
TREE_NOTHROW? IIUC, that would be different than the patch you posted
in Comment #22, which appears to affect "bar". Also, I didn't quite
understand your patch, in that it would appear to result in fewer
functions being marked TREE_NOTHROW, whereas we want more functions to
be so marked to restore status quo? I would think we want to remove the
check for binds_local_p at the top of set_nothrow_function_flags?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #28 from mark at codesourcery dot com 2007-02-05 20:08 ---
Subject: Re: Shared libstdc++ fails to link
amylaar at gcc dot gnu dot org wrote:
> --- Comment #27 from amylaar at gcc dot gnu dot org 2007-02-05 19:52
> ---
> (In reply to comment #25)
>> I think the analysis should be deeper than just "binds_local_p", though;
>> I think it should be based on whether "attribute ((weak))" (or
>> equivalent) explicitly appears, so that we don't pessimize bar if foo is
>> in a template function, out-of-line inline, or other such function. The
>> test ought to be based on the demonstrable intent of the user to replace
>> the function, not on whether or not the function happens to be weak.
>
> What about an exported definition in a shared library? Users expect to be
> able to replace such definitions. Should we constrain them in what they
> can replace these definitions with by requiring them not to extend the
> throw specification beyond what gcc could figure out about it using data
> and control flow analysis on the original definition?
Yes, I believe that we should forbid this kind of replacement. We can,
if necessary, make GCC not be more conservative than the original
exception-specification if present, so that:
void foo() throw (X) {}
still results in the compiler thinking that "foo" may throw "X", but we
should not extent that to thinking that:
void foo() {}
can throw anything. That's making the compiler generate inferior code,
for a corner-case situation, outside the realm of the language. Making
the user use an attribute to declare what they mean is not unreasonable.
> That defeats the purpose of defining an interface with prototypes.
> >
>> I agree. If my suggestion above seems correct, then the first step is
>> to undo the change that make "foo" not marked TREE_NOTHROW.
>
> Sorry, but at the moment we have no way of making "foo" marked TREE_NOTHROW.
> We can only mark its declaration TREE_NOTHROW, which then causes all the
> callers to assume that the function of that name doesn't throw.
Yes, which was the status quo before your patch. I don't see any good
argument for exchanging the relatively obscure problem fixed by the
patch for a different set of problems: broken HP-UX 10.10, and inferior
code for C++ applications that are not using either weak functions or
shared libraries. Therefore, I think we should go back to marking "foo"
TREE_NOTHROW, and look for a more a complete fix to both your original
problem and the other cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #28 from mark at codesourcery dot com 2007-02-12 01:11 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) tobi at gcc dot gnu dot org wrote: > --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- > (In reply to comment #6) >> Fortran is not release-critical and this bug appears to be purely within the >> Fortran front end. > > Should I commit the patch for the next release candidate once the branch is > unfrozen? Personally, I don't believe this a sufficiently important bug > (being > an ICE on weird invalid code designed deliberately to break the compiler), but > if you don't want this regression in the release, I'll happily commit it in > time for the next release candidate. No, please leave any non-critical issues until after 4.1.2 is released. Then, when the 4.1 branch is reopened, you may check in the the patch for a possible future 4.1.3 release. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug middle-end/30768] [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc
--- Comment #12 from mark at codesourcery dot com 2007-02-14 23:56 --- Subject: Re: [4.3 regression]: ICE in ext/pb_ds/regression/list_update_data_map_rand.cc dnovillo at gcc dot gnu dot org wrote: > --- Comment #11 from dnovillo at gcc dot gnu dot org 2007-02-14 23:54 > --- > (In reply to comment #10) > >> Diego, is this something that you might be able to help with? >> > Sure. Thanks! Let me know if you get sick of it and want to punt it back. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30768
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
--- Comment #11 from mark at codesourcery dot com 2007-02-21 00:02 --- Subject: Re: Libiberty doesn't honor the multi-os-directory settings ebotcazou at gcc dot gnu dot org wrote: > --- Comment #9 from ebotcazou at gcc dot gnu dot org 2007-02-20 15:25 > --- >> Looks OK to me. > > Thanks. Would you recommend it for 4.2 too? Mark, what do you think? Yes, this is OK for 4.2, once it has been on mainline for a couple of days. This is essentially a packaging bug, and fixing those is useful, even on release branches. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #15 from mark at codesourcery dot com 2007-03-13 21:46 --- Subject: Re: [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890 pinskia at gcc dot gnu dot org wrote: > --- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 > --- > (In reply to comment #13) >> I think this patch causes the regression reported in PR 31165. copy_node is >> incorrect as it will even copy decls, I think copy_node should be replaced >> with >> unshare_expr instead. > > A quick run with that change, fixes 31165. Thanks for that testing. That patch is pre-approved. If you don't want to handle it, let me know, and I will do it. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #5 from mark at codesourcery dot com 2007-03-23 02:44 --- Subject: Re: [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument bangerth at dealii dot org wrote: > --- Comment #4 from bangerth at dealii dot org 2007-03-23 02:37 --- > Without wanting to be a distractor, but can variables of a type that > was declared in an anonymous namespace really have external linkage? That's not the case here; the class is in the global namespace. Only the variable is in the anonymous namespace, and entities in anonymous namespaces do have external linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #3 from mark at codesourcery dot com 2007-04-06 22:09 ---
Subject: Re: [4.3 Regression] ld: Invalid symbol type
for plabel (.libs/debug_list.o, __gxx_personality_v0).
dave at hiauly1 dot hia dot nrc dot ca wrote:
> Looking at this a bit, I think the fix is to add
>
> if (eh_personality_libfunc)
> assemble_external_libcall (eh_personality_libfunc);
>
> to output_call_frame_info in dwarf2out.c.
That makes sense to me. I think you could do it just in the
for_eh/eh_personality case here:
> if (eh_personality_libfunc)
> {
> *p++ = 'P';
> augmentation_size += 1 + size_of_encoded_value (per_encoding);
> }
That would emit the reference only in situations where we're actually
going to need the personality routine. The reason for my earlier change
was that we were referencing it even when we'd optimized away all of the
EH information in the module. I'm sorry this broke HP-UX; let me know
if I can help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug middle-end/31322] [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0).
--- Comment #5 from mark at codesourcery dot com 2007-04-07 00:01 --- Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel (.libs/debug_list.o, __gxx_personality_v0). dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-04-06 > 23:44 --- > Subject: Re: [4.3 Regression] ld: Invalid symbol type for plabel > (.libs/debug_list.o, __gxx_personality_v0). > >> That would emit the reference only in situations where we're actually >> going to need the personality routine. The reason for my earlier change >> was that we were referencing it even when we'd optimized away all of the >> EH information in the module. I'm sorry this broke HP-UX; let me know >> if I can help. > > I must admit I'm to blame for this ;( > > Importing functions that aren't used doesn't cause a problem on HP-UX, > but I can see that it might cause the routine to be unnecessarily included > in an executable on other systems. Yes, the standard behavior for GNU as/ld on ELF systems is that a .globl emission in the .as file becomes an undefined symbol in the ELF object file, and the linker then pulls in files from an archive to satisfy that reference at link-time, even if there are no relocations against the symbol. One could reasonably argue that the linker shouldn't do this, but it does, and changing it might break things; people may well be relying on this trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31322
[Bug libstdc++/31638] [4.0/4.1/4.2 Regression] string usage leads to warning with -Wcast-align
--- Comment #5 from mark at codesourcery dot com 2007-04-23 02:19 --- Subject: Re: [4.0/4.1/4.2 Regression] string usage leads to warning with -Wcast-align pcarlini at suse dot de wrote: > --- Comment #3 from pcarlini at suse dot de 2007-04-22 01:19 --- > In fact, the problem cannot be reproduced on ia64, with current mainline. I > agree that the warning can be very annoying (the underlying issue was already > there before 4.0 and will be there until we break the ABI), therefore I would > be in favor of porting the fix for C++/30500, very small and non-invasive, > IMHO, to 4_2-branch, let's ask Mark. It is OK with me. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31638
[Bug libstdc++/31906] "-Xcompiler" is inserted after "-Xlinker" when building libstdc++
--- Comment #12 from mark at codesourcery dot com 2007-07-15 19:27 --- Subject: Re: "-Xcompiler" is inserted after "-Xlinker" when building libstdc++ pcarlini at suse dot de wrote: > --- Comment #11 from pcarlini at suse dot de 2007-07-14 23:51 --- > I advice against committing anything to 4_2-branch, at this time. In any case, > we don't have a regression wrt 4.2.0 - only wrt 4.1.x if confirmed - and we > have a workaround. I agree. I'd certainly like to see this fixed in 4.2.2 (or whatever the version number ends up being for the release following 4.2.1) but I don't think we should make this change for 4.2.1, at this very late date. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug c++/19163] __attribute__((aligned)) not working in template
--- Comment #11 from mark at codesourcery dot com 2007-09-06 06:16 --- Subject: Re: __attribute__((aligned)) not working in template jason at gcc dot gnu dot org wrote: > --- Comment #10 from jason at gcc dot gnu dot org 2007-09-06 05:50 > --- > Vague references: > > http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00247.html > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743 > > Seems like Mark and/or Nathan have/had state on this that they haven't shared > with the lists. I don't think so, but I'm not quite sure I understand. Anyhow, I'm sure I don't have any uncontributed patches for this, and I don't think Nathan has either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19163
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 18:47 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: > 2. The tree-inliner inlines the call. Since the same tree is referenced twice > in the expression, the inlined body is also referenced twice is the expression > and, therefore, expanded twice to RTL. However labels are not expanded > multiple > times but reused, so the second block of RTL ends up referencing the first and > all hell breaks loose. It really seems like the C++ front end is doing the right thing, abstractly -- these functions don't have side-effects! So, either the inliner or stabilize reference seems like it needs fixing. Maybe the latter should recognize CALL_EPRs? If it's not possible to fix this, then what we should do is modify build3 to mark CALL_EXPRs as having side-effects. Right now, it makrs them based on the flags for the function, so this problem isn't really C++-specific; it probably effects all languages except those whose front ends set TREE_SIDE_EFFECTS additionally themselves. (Unless C++ is changing out the operands to the CALL_EXPR after its created.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 19:34 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: > --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 > 19:25 --- > >>It really seems like the C++ front end is doing the right thing, >>abstractly -- these functions don't have side-effects! So, either the >>inliner or stabilize reference seems like it needs fixing. Maybe the >>latter should recognize CALL_EPRs? > > > I agree that the C++ FE is theoritically right, but other FEs appear to > already > have realized that the implementation constraints trumpet the theory here: on > mainline, the C, Java and Fortran 95 FEs set TREE_SIDE_EFFECTS on CALL_EXPRs. Interesting. So, we have some checks in gcc/tree.c to try to avoid setting TREE_SIDE_EFFECTS, and then the FEs all set it anyhow. :-( > Special-casing CALL_EXPRs in stabilize_reference could indeed be the > solution. > We could even be clever and check whether tree inlining is enabled and, if so, > whether it has already occurred. Does that sound plausible? I don't think I'd try to be that clever. We might want the stabilization to occur even in other cases. In looking at it more closely, it definitely looks like stabilize_reference should deal with CALL_EXPRs. (I guess I was thinking that the problem with the duplicate labels could be avoided in the inliner by generating fresh labels. But, maybe that's not going to work for other reasons.) >>If it's not possible to fix this, then what we should do is modify >>build3 to mark CALL_EXPRs as having side-effects. Right now, it makrs >>them based on the flags for the function, so this problem isn't really >>C++-specific; it probably effects all languages except those whose front >>ends set TREE_SIDE_EFFECTS additionally themselves. (Unless C++ is >>changing out the operands to the CALL_EXPR after its created.) > > Right. OK, that's the fallback. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/17972] [3.4 Regression] const/pure functions result in bad asm
--- Additional Comments From mark at codesourcery dot com 2005-03-03 21:19 --- Subject: Re: [3.4 Regression] const/pure functions result in bad asm ebotcazou at gcc dot gnu dot org wrote: > --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03 > 21:12 --- > >>I don't think I'd try to be that clever. We might want the >>stabilization to occur even in other cases. In looking at it more >>closely, it definitely looks like stabilize_reference should deal with >>CALL_EXPRs. > > > But then what's the difference with setting TREE_SIDE_EFFECTS on CALL_EXPRs? > Also for 3.4.x some FE don't use tree inlining at all so I don't think they > should be penalized because of the C++ FE. There are other places where TREE_SIDE_EFFECTS matters. (Like, "do we have to emit this expression at all, if its result is not used?") The counter to your argument is that I don't see why the C++ front end should be penalized because other front ends have a workaround for what seems to be a bug in the middle end. The stated purpose for stabilize_reference is to make it possible to use an expression more than once. If CALL_EXPRs can't be used more than once (which your research would seem to prove), then it seems like stabilize_reference should handle that. >>(I guess I was thinking that the problem with the duplicate labels could >>be avoided in the inliner by generating fresh labels. But, maybe that's >>not going to work for other reasons.) > > How would you do that exactly? In our present case, the inliner inlines > exactly > one CALL_EXPR, but it is referenced twice in another tree. OK, I'm confused, then -- I think that either we have to fix this problem in stabilize_reference (which seems better to me) or always set TREE_SIDE_EFFECTS on CALL_EXPRs in build3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From mark at codesourcery dot com 2005-03-04 01:36 --- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs Alexandre Oliva wrote: \ > I went ahead and verified that I didn't break bit-field lvalues in > conditional expressions (my first attempt did), but I was surprised to > find out that the calls to h() pass. I understand why they do (we > create a temporary and bind to that), but I'm not sure this is correct > behavior. Opinions? > + // Hmm... I don't think these should be accepted. The conditional > + // expressions are lvalues for sure, and 8.5.3/5 exempts lvalues > + // that are bit-fields, but not lvalues that are conditional > + // expressions involving bit-fields. > + h (b ? x.i : x.j); > + h (b ? x.i : x.k); > + h (b ? x.j : x.k); That's legal because "h" takes a "const &", which permits the compiler to create a temporary. If it takes a non-const reference, you should get an error. And, I think these kinds of transformations (if necessary) should be done in a langhook during gimplification, not at COND_EXPR-creation time. We really want the C++ front-end's data structures to be an accurate mirror of the input program for as long as possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Additional Comments From mark at codesourcery dot com 2005-03-04 07:26 --- Subject: Re: [PR c++/20280] hoist indirect_ref out of addressable cond_exprs Alexandre Oliva wrote: > >>>+ // Hmm... I don't think these should be accepted. The conditional >>>+ // expressions are lvalues for sure, and 8.5.3/5 exempts lvalues >>>+ // that are bit-fields, but not lvalues that are conditional >>>+ // expressions involving bit-fields. >>>+ h (b ? x.i : x.j); >>>+ h (b ? x.i : x.k); >>>+ h (b ? x.j : x.k); > > >>That's legal because "h" takes a "const &", which permits the compiler >>to create a temporary. > > > Yeah, it permits, but only in certain circumstances that AFAICT aren't > met. This expression AFAICT is an lvalue that isn't a bit-field, so > it has to bind directly, per the first bullet in 8.5.3/5. Since it > meets the conditions of this first bullet, it doesn't get to use the > `otherwise' portion of that paragraph, that creates a temporary. Or > am I misreading anything? The situation is a little unclear. EDG also accepts this code, which is part of what confused me. Your reading is logical, but it depends on exactly what "lvalue for a bit-field" means. (Note that it does not say "lvalue *is* a bit-field"; it says "lvalue *for* a bit-field".) Consider: h((0, x.i)); It would be odd not to allow that, but to allow "h(x.i)". The comma-expression isn't changing what's being passed to "h". The same goes for "h((x.i = 3))". I think that, if anything, there's a possible defect in the standard here, not a defect in the compiler. >>And, I think these kinds of transformations (if necessary) should be >>done in a langhook during gimplification, not at COND_EXPR-creation >>time. We really want the C++ front-end's data structures to be an >>accurate mirror of the input program for as long as possible. > > Err... But in what sense does my patch change that? See, what I'm > doing is hoisting the indirect_refs that are inserted by > stabilize_reference out of the cond_expr. They weren't in the > original code. There's no dereferencing going on unless the whole > expression undergoes lvalue-to-rvalue decay, so I'd argue that the > transformation I'm proposing actually matches even more accurately the > meaning of the original source code. Actually, looking at this more closely, I think that something is forgetting to call rationalize_conditional_expr, which is normally called from unary_complex_lvalue. When the conditional expression is used in the lvalue context, something should be calling that. Normally, that happens because something calls build_unary_op (ADDR_EXPR, ...) on the COND_EXPR. It may be that I changed something to call build_addr (instead of build_unary_op) in a case where that's not safe. Can you confirm or deny that hypothesis? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-04 23:29
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
> On Mar 3, 2005, Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
>
>>I think this is the wrong approach. The front-end and not
>>the gimplifier should be creating these temporaries, I mentioned
>>this already in the bug.
>
>
> How about this?
>
> I tried with the TARGET_EXPR by itself, but it failed to be recognized
> as an lvalue, so I introduced the compound expr.
Introducing a TARGET_EXPR makes sense to me.
> Testing on x86_64-linux-gnu. Ok to install if it passes?
> +foo ((B){x});
I don't think (B){x} should be an lvalue, C99 notwithstanding. B(3) is
not be an lavalue; I don't see why "(B){x}" should be. Conceptually,
the compound-literal syntax is just a way of invoking an imaginary
constuctor that has an argument corresponding to each non-static data
member.
Has there been any discussion of this in the ISO committee? Or prior
are in other compilers? Including previous versions of G++?
(These are not rhetorical questions; I really don't know.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-05 21:47 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > Testing now. I was a bit surprised that the casts to (const B&) > weren't reported as faulty, but didn't check the standard on it. I'd have to check the rules -- but I'm sure it's not a problem with your patch. Either its correct, or an already-present bug. > Ok > to install if testing passes? Yes. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mark at codesourcery dot com 2005-03-06 00:14 --- Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue (continued from PR c++/20280) Alexandre Oliva wrote: > Here's a patch that fixes PR c++/19199, by avoiding the transformation > from: > > > > > > > > > into: > > > > > > > since the latter is clearly not an lvalue, and > rationalize_conditional_expr doesn't manage to turn it back into one > (I don't think it should). I realize we might miss some optimization > opportunities because of this change in C, because the optimization > would be valid there, but I suppose we could arrange for cond_expr > operands in C to be forced into rvalues. Roger has objected to this change in the past. As I noted in the audit trail for 19199, there's stuff in build_modify_expr to handle MIN_EXPR/MAX_EXPR as lvalues -- but, if Roger wants to stick with that approach, it needs to be spread throughout the C++ front end. I'd be happier with your approach overall, in part because I think fold is doing too much, too early, in general, but I don't feel comfortable approving the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-06 18:02
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
Alexandre Oliva wrote:
> +case TARGET_EXPR:
> + {
> + tree r = tsubst_copy (t, args, complain, in_decl);
> +
> + TREE_TYPE (r) = RECUR (TREE_TYPE (t));
> + TARGET_EXPR_SLOT (r) = RECUR (TARGET_EXPR_SLOT (t));
> + TARGET_EXPR_INITIAL (r) = RECUR (TARGET_EXPR_INITIAL (t));
> + TARGET_EXPR_CLEANUP (r) = RECUR (TARGET_EXPR_CLEANUP (t));
> +
> + if (TREE_TYPE (TARGET_EXPR_SLOT (t))
> + == TREE_TYPE (TARGET_EXPR_INITIAL (t)))
> + TREE_TYPE (TARGET_EXPR_SLOT (r)) =
> + TREE_TYPE (TARGET_EXPR_INITIAL (r));
> +
> + if (TREE_TYPE (t) == TREE_TYPE (TARGET_EXPR_SLOT (t)))
> + TREE_TYPE (r) = TREE_TYPE (TARGET_EXPR_SLOT (r));
> +
> + return r;
This doesn't look quite right. First, we're trying to get rid of
tsubst_copy; we should not add new calls. You should do the RECURs
here, and then build up the new node. And, the manipulations of
TREE_TYPE don't make sense: (a) using "==" to compare types is almost
always wrong, and (b) the RECURs should already maintain the invariant
you're trying to maintain.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mark at codesourcery dot com 2005-03-07 04:19 --- Subject: Re: [PR c++/19199] don't turn cond_expr lvalue into min_expr rvalue (continued from PR c++/20280) Alexandre Oliva wrote: > On Mar 5, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >>Roger has objected to this change in the past. As I noted in the >>audit trail for 19199, there's stuff in build_modify_expr to handle >>MIN_EXPR/MAX_EXPR as lvalues > > > Problem is, with the transformation performed by fold, it's no longer > an lvalue, and forcing it back into an lvalue just because it looks > like it should be one could break other programs. Yes, I understand. You still need to take it up with Roger, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-07 04:44 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: >>This doesn't look quite right. First, we're trying to get rid of >>tsubst_copy; we should not add new calls. You should do the RECURs >>here, and then build up the new node. > > > I'd have to use build3 (TARGET_EXPR...) or introduce a new call to > create a target_expr with given slot, initial and cleanup, because > AFAICT there isn't any that takes a cleanup. Yes, you should use build3. > They don't, and they can't without this piece of code. When we tsubst > INITIAL, an incomplete array type (T[]), that had been used as the > type of the slot and the target_expr itself in > finish_compound_literal(), called while processing a template, > digest_init() (or something else; I no longer remember exactly) > completes the array type with the number of entries in the INITIAL > CONSTRUCTOR. Then you should tsubst the INITIAL first, and unconditionally copy the type to the TARGET_EXPR when you use build3. Or, even better, call the same functions in semantics.c that the parser would call if not in a template. In other words, call finish_compound_literal again, from pt.c. That's the overall design: we try to reuse the same semantic routines again at template instantiation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-07 16:05 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: >>Then you should tsubst the INITIAL first, and unconditionally copy the >>type to the TARGET_EXPR when you use build3. > > > But what if the TARGET_EXPR had been created for different purposes, > and did have a different type than that of the initializer? Say, a > Base& being bound to a Derived TARGET_EXPR? That's why I'm performing > the tests the way I am. Are you sure that we can use TARGET_EXPR as a type-conversion node? I would think in that case that the INITIAL for the TARGET_EXPR would be a call to the derived class constructor. Hmm. I suppose the type of such a constructor is "void", so it may indeed be the case that there's really no relationship between the types. Good point. > Yeah, I know we'd like to do that, but we can't. At that point we > have no clue what that TARGET_EXPR or the CONSTRUCTOR in its initial > came from. We'd have to create a new tree node type for compound > literals to be able to call finish_compound_literal at that point. Then we really should do that. We could have COMPOUND_LITERAL_EXPR whose type would be the type in the (syntactic) cast, and whose argument would be the CONSTRUCTOR for the brace-enclosed initializer. We'd create one of these things if the TYPE, or any of the initializers, was dependent. The games that you want to play with type-equality are just too fragile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-07 18:05 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >>Are you sure that we can use TARGET_EXPR as a type-conversion node? > > > Actually, no. I was led to believe so because there is a function > that creates a TARGET_EXPR given an initializer and a type, in > addition to the one that takes the type from the initializer. OK, so if there's no conversion, then my suggestion (i.e., copy the type from the substituted initializer) should work fine. > I was thinking references, actually, so there wouldn't be a > constructor involved. I.e., I was trying to preserve the earlier > behavior of TARGET_EXPRs (i.e., mostly do nothing with them), while > adjusting the behavior only as much as needed for this new use. TARGET_EXPRs create objects. I'm not sure if we ever create TARGET_EXPRs with REFERENCE_TYPE, but if so, there initializers should have the same type. >>Then we really should do that. > > Eek. What for? All we need to do is adjust its type. A new tree > node scattered all over the place feels like way too much overhead for > this. There are two situations: 1. The type is derivable from the operands. In that case, you can do that, as I've suggested above, by creating the operands, and then applying a *uniform, unconditional* operation to the type of the operands to determine the type of the TARGET_EXPR. 2. The type is not derivable from the operands. In that case, you should be going through the same semantics.c routines that we do at parse time. The truth is that (2) is a better choice no matter what, because we really want dependent expressions to have a representation that is very nearly isomorphic to the source code. We have to introduce nodes corresponding to G++ extensions in other places (like statement-expressions); this is no different. However, I can live with (1), for expediency sake. >>The games that you want to play with type-equality are just too fragile. > > I still don't see why. First, you're using "==". As I've told you, that's incredibly fragile. You're depending on a very non-local property that in the case that you're interested in, the types will always be ==. But, minor changes elsewhere might make them same_type_p, but not ==, in some cases. Then, your code breaks, probably undetectably. To a first approximation, the only place == should be used for types is in same_type_p itself. Second, you're applying a non-uniform manipulation on the types of the TARGET_EXPR, based on a non-local property about how TARGET_EXPRs are created, without actually checking that the condition you're interested in (incomplete array types) applies. This is not an approach that's going to be robust over time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-07 22:39 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > On Mar 7, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > >>>>The games that you want to play with type-equality are just too fragile. >>> >>>I still don't see why. > > >>First, you're using "==". As I've told you, that's incredibly >>fragile. > > > Not for the purpose I've been trying to describe. We're at risk of descending into "Yes. No. Yes. No." I think it's fragile. Now, reasonable people can disagree about software engineering -- it's an art form, not a science -- but my opinion is that this is fragile. I've explained why: (a) we should never use "==" to compare types, because there's no guarantee that the compiler will continue to use "==" types in places where it does at present; it might instead switch one of them to be same_type_p. Think about it this way: == has no semantic meaning in C++; the only relationship the language knows about is same_type_p. So, using == means that you're doing something with types that doesn't have semantics grounded in the language, which doesn't make sense, except in places that are trying to get debugging information correct, etc. (b) you're applying a non-uniform transformation depending on non-local knowledge. What I mean by "non-uniform" is that the assignment to the type of the TARGET_EXPR is conditional. If it were an unconditional assignment, I'd be less nervous; then, you'd be asserting that the type of the TARGET_EXPR should always be the type of its initializer, which might make sense. What I mean by "non-local" is that your transformation only works because of some far-off logic that determins how TARGET_EXPRs are created. It doesn't depend on any documented property of TARGET_EXPRs that is enforced throughout the compiler. Consider the comments you should write for your code: /* Code in creates TARGET_EXPRs with "==" types, and that must be preserved here. If you change that code, don't forget to update this code! */ And, then, you should add something to the TARGET_EXPR documentation along the lines of: /* Some TARGET_EXPRs have the same TREE_TYPE as their initializers; some don't. The kinds that do are ...; the kinds that don't are ... When instantiating templates, we preserve equality for types that "==", but not necessarily those that are same_type_p. */ Finally, I've explained that the entire approach is contrary to the way we want to do things in templates, which is that you keep a syntactic form for dependent expressions until instantiation time, and then run through the same exact routines you would have in the parser. That's really the only way we can be sure that the semantics match up. I'm sorry you're frustruated, but I don't think that your approach is the right way to go. >>But, minor changes elsewhere might make them same_type_p, but not >>==, in some cases. > > If that's fine for those cases, it will remain so after template > substitution. Sounds *exactly* like what I want. Why would you want that? If before substitution, the operand had a typedef type for the incomplete array, and the TARGET_EXPR had a different typedef type for the same incomplete array, wouldn't you want to update the type of the TARGET_EXPR? In the context of a 4.0 patch, I'd be willing to consider a patch like yours, using same_type_p instead of "==", and with suitable comments explaining what's going on. For 4.1, we should do better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20103] [4.0/4.1 regression] ICE in create_tmp_var with C99 style struct initializer
--- Additional Comments From mark at codesourcery dot com 2005-03-08 07:45 --- Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable types Alexandre Oliva wrote: > So think of it this way: if we adopted COMPOUND_LITERAL_EXPR like > you're inclined to do, we'd have to do the very same kind of type > propagation after resolving the complete type of the initializer. > This is no different from what I'm proposing to do here. Except that (a) we'd have no change of doing it when we don't want to do it (which we do with your patch, because if the two things just happen to have the same type before substitution, we'll preserve that, even if we shouldn't, perhaps for some case/language feature/extension that hasn't even been invented yet), and (b) we'd be guaranteed to keep doing it when we do want it to happen (which we won't, with your patch, if something changes in get_target_expr). > And there's more: since there's no compiler-enforced equality AFAICT > between the type of the COMPOUND_LITERAL_EXPR and that of the VAR_DECL > enclosed in it, we'd have o make the propagation conditional in just > the same way. No, because there would be no TARGET_EXPR. In a template, you would just have a COMPOUND_LITERAL_EXPR, with no TARGET_EXPR, because we want a syntactic representation of the input program. > Note that we never needed this condition to hold before; TARGET_EXPRs > just were not handled at all: we never emitted TARGET_EXPRs whose > types were arrays of unknown bounds, to be inferred from the > initializer length, before this change. Yes, and introducing TARGET_EXPRs into templates *is a bug* because in templates we want a syntactic representation. The closest thing we have to a syntactic representation of a compound literal is a CONSTRUCTOR; it's certainly not a TARGET_EXPR wrapped around a CONSTRUCTOR. It may be just fine to use CONSTRUCTOR, instead of introducing COMPOUND_LITERAL_EXPR, but TARGET_EXPRs should not be appearing here at all. > Further investigation has shown that TARGET_EXPR's SLOTs always have > the same type as the enclosing TARGET_EXPR. Whether SLOTs and > INITIALs always have the same type is not as obvious, but it appears > to hold as well. How about making the assignments unconditional, > then, with an assertion that the equality holds? Copying the SLOT type to the EXPR type would make a lot more sense. That's along the lines of what I originally suggested: substitute into the operands, and then form the TARGET_EXPR with an appropriate type. You've just demonstrated a way to do that, in a uniform way. Unfortunately, you've also caused me to think about this long enough to realize that having the TARGET_EXPR here is wrong in the first place, as per above. > /* If the type of the initializer was used to create the original >TARGET_EXPR, make sure we adjust the type of the tsubsted >TARGET_EXPR, should the type of the initializer change in >unpredictable ways during tsubsting (e.g., the range of an array is >inferred from a CONSTRUCTOR length). */ > > See? No need to change any other piece of code anywhere else. It's > really that simple. That's not a justification; that's just a statement of what the code does. Why would we copy this type sometimes and not others? Fundamentally, what your patch says is that the semantics of TARGET_EXPR depend on whether or not the type of INITIAL matches the type of the TARGET_EXPR. If that weren't true, then we wouldn't have to check that condition before doing whatever we do. But, there's nothing about the actual semantics of TARGET_EXPR that depend on this type equality; ergo, the patch does not make sense. But, as I've said above, I think this is all moot; TARGET_EXPRs should not appear in template bodies at all. I think you've confirmed that by saying that you had to add this code. If you look at the other code that handles expressions in templates, you'll see how we preserve the syntactic form, precisely so that we can reuse the appropriate semantics.c routines at the time of instantiation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
[Bug c++/20589] error: '' is/uses anonymous type'
--- Additional Comments From mark at codesourcery dot com 2005-03-23 19:28 --- Subject: Re: error: '' is/uses anonymous type' bangerth at dealii dot org wrote: > --- Additional Comments From bangerth at dealii dot org 2005-03-23 19:24 > --- > That has been subject to discussion (i.e. whether the attempt to use an > unnamed enum as a template argument should just silently fail as a > substitution failure). However, it has been decided that this is a hard > error, not only a substitution failure. > > I am presently not quite sure about the reasoning, and I believe that there > was a DR or something still pending. Mark, do you remember the details? I > think this came up in a different PR before... It's swapped out of my brain, but there was another PR, and I did raise the issue for Steve Adamczyk, to be added to the core issue list. The basic point is that the SFINAE rules simply do not cover this case; they precisely describe a set of situations in which no error should be issued, and trying to use an anonymous type as a template parameter is not among them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mark at codesourcery dot com 2005-03-25 06:29 --- Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary > Alex, could you confirm that the above suggestion resolves the PR when used > in combination with your maybe_lvalue_p split? Mark, do you agree that this > is a reasonable (the most reasonable?) compromise in the 4.0 timeframe? Thank you for looking at this again. Yes, I think your patch is a reasonable solution in the 4.0 timeframe. It does, of course, mean that there will be programs that are less well-optimized in C++ than in C, but I agree with you that there's no good way around that in the short term. If you're worried about the cost of the strcmp, you could cache the result, but I have no reason to think that's a real problem. Also, I think this patch should go on the mainline too, until we get a better fix -- but I think we should work on that, so that this doesn't actually make it into 4.1. (In 4.1, I disagree that we need new tree codes. I think all we need to do is wait to call fold until gimplification time in C++; then, the middle end will never see COND_EXPRs used as lvalues. In C++, conditionals can be lvalues, but we actually fix that up before passing them to the middle end. The middle end sees COND_EXPRs that would be lvalues in C++, but they are only used as rvalues, so the transformation in fold would be fine. But, we can have that debate later!) Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mark at codesourcery dot com 2005-03-30 07:20 --- Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary aoliva at gcc dot gnu dot org wrote: > --- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-30 > 02:55 --- > Excuse me for asking, but what is it that makes the latest patch I posted not > reasonable for the 4.0 timeframe? I'm not sure if there is anything that makes it unreasonable; I don't know either way. I hope Roger will comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From mark at codesourcery dot com 2005-03-30 18:22 --- Subject: Re: New: make install failure building abi_check with leftover libv3test janis at gcc dot gnu dot org wrote: > Nightly mainline bootstraps for powerpc64-linux have been failing > intermittently since changes went in last week to allow running > libstc++ tests on installed tools. For "make bootstrap", abi_check > is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float. > "make install" tries to build it again, but a 32-bit build of > abi_float tries to use the existing libv3test, and the link fails if > the type of the leftover library (e.g. 64-bit) doesn't match the type > of the new abi_check. All of the abi_check builds appear to be done > in the same directory. I will look into this today. Is it considered desirable behavior to build abi_check at "make install" time? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From mark at codesourcery dot com 2005-03-30 18:32 --- Subject: Re: New: make install failure building abi_check with leftover libv3test Benjamin Kosnik wrote: >>Is it considered desirable behavior to build abi_check at "make install" >>time? > > > No, this doesn't make any sense, as abi_check is not installed. > > It was/is built at "make all" time. I believe you wanted to build this > as part of "make check" or "make check-abi" either of which is fine for > me. OK, that makes sense. (I didn't actually change this particularly thing; it was probably getting built at make install time all along. But, my changes are causing the make install rebuild not to work.) I'll see what I can do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From mark at codesourcery dot com 2005-03-30 22:45 --- Subject: Re: New: make install failure building abi_check with leftover libv3test janis at gcc dot gnu dot org wrote: > Nightly mainline bootstraps for powerpc64-linux have been failing > intermittently since changes went in last week to allow running > libstc++ tests on installed tools. For "make bootstrap", abi_check > is built three times: for 32-bit bit, 64-bit, and 32-bit soft-float. > "make install" tries to build it again, but a 32-bit build of > abi_float tries to use the existing libv3test, and the link fails if > the type of the leftover library (e.g. 64-bit) doesn't match the type > of the new abi_check. All of the abi_check builds appear to be done > in the same directory. Janis, am I correct in assuming that you're running "make check" between "make bootstrap" and "make install"? If so, I think I understand what's happenning, and I can work on fixing it. Otherwise, I've got to dig a little deeper. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug c++/20607] [3.4 Regression] -fstrict-aliasing causes incorrect scheduling
--- Additional Comments From mark at codesourcery dot com 2005-03-31 00:54
---
Subject: Re: [3.4 Regression] -fstrict-aliasing causes incorrect
scheduling
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-30
> 10:53 ---
> Hum... type-punning simply doesn't work in this case with the C++ compiler,
> but
> does work with the C compiler. The problem is that:
>
> union u {
> x_uint64_t first;
> x_uint32_t second;
> };
> union u conv;
> conv.first = arg1;
> result = conv.second;
>
> is translated into:
>
> *(&conv.first) = *(&arg1);
> *(&result) = *(&conv.second);
>
> and type-punning cannot work in this case (that's the counter-example provided
> in the manual). I guess the problem comes the fields being of aggregate
> types.
>
> Mark, is that fixable or should we document the limitation?
I think it's fixable. I'm not sure exactly why the C++ front-end is
inserting the additional operations, but they're certainly not essential
from a C++ semantics point of view. Please reassign the bug to me; I'll
try to take a look.
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20607
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From mark at codesourcery dot com 2005-03-31 00:10 --- Subject: Re: New: make install failure building abi_check with leftover libv3test janis at gcc dot gnu dot org wrote: > Nightly mainline bootstraps for powerpc64-linux have been failing > intermittently since changes went in last week to allow running > libstc++ tests on installed tools. I would like to solve this problem by moving the compilation and execution of abi_check.cc into DejaGNU, and check having "make abi_check" invoke DejaGNU appropriate to run just that test. Benjamin, any objections to that plan? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug libstdc++/20694] [4.1 Regression] make install failure building abi_check with leftover libv3test
--- Additional Comments From mark at codesourcery dot com 2005-03-30 23:41 --- Subject: Re: [4.1 Regression] make install failure building abi_check with leftover libv3test janis at gcc dot gnu dot org wrote: > --- Additional Comments From janis at gcc dot gnu dot org 2005-03-30 > 23:33 --- > Aha! The failures occur with "make bootstrap" followed by "make check" > followed by "make install"; without "make check" in between the install > works fine. Good! That's what I expected. I'll now be able to fix it, I'm sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
--- Additional Comments From mark at codesourcery dot com 2005-04-01 21:17 --- Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining Alexandre Oliva wrote: > TYPE_STUB_DECL was NULL in the testcase given in the bug report > because tree inlining failed to remap TYPE_STUB_DECL. This patch > reverts the patch that hides the problem, that AFAICT was checked in > by accident, and installs a proper (IMHO :-) fix. Bootstrapping on > amd64-linux-gnu. Ok to install if it passes regtesting? Yes! This looks very sensible. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
--- Additional Comments From mark at codesourcery dot com 2005-04-04 00:37 --- Subject: Re: [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary roger at eyesopen dot com wrote: > I'd hoped I'd made this clear when I proposed the alternate strategy of only > disabling this optimization *only* in the C++ front-end, and *only* prior to > tree-ssa. Roger, Alexandre, will you to please coordinate to determine who will take responsibility for preparing a patch? What's difficult for me is that I can't quite figure out who's going to actually take this bug and run with it. I think Alexandre is trying hard to fix it, but I'm not confident that he understands what Roger wants. If you two aren't able to work through the issues, or don't have time, please let me know; I want to find some way to get this problem dealt with before 4.0. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
