http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #69 from Mark Mitchell 2011-04-05
00:16:02 UTC ---
On 4/4/2011 3:19 AM, froydnj at codesourcery dot com wrote:
> Do folks think it would be useful to include a breakdown by individual
> TREE_CODE, similar to what's done for RTXes?
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #22 from Mark Mitchell 2011-01-06
03:55:40 UTC ---
On 1/5/2011 5:36 AM, hubicka at gcc dot gnu.org wrote:
> 40259 5.6000 cc1plus cc1plus
> lookup_field_1
I've looked at this, in the distant pas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #62 from Mark Mitchell 2010-12-14
15:17:25 UTC ---
> Having everyone with knowledge of static construction alerted, can't we use
> the
> GNU constructor priorities to solve PR44952?
The two constraints are:
(a) priorities aren't su
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #46 from Mark Mitchell 2010-12-12
18:40:35 UTC ---
On 12/11/2010 4:32 PM, hjl.tools at gmail dot com wrote:
> Mark, I may have misunderstood you. Correct me if I am wrong.
> Currently, it may be possible to interleave constructors
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #43 from Mark Mitchell 2010-12-12
00:24:30 UTC ---
On 12/11/2010 4:20 PM, hjl.tools at gmail dot com wrote:
> That means we only guarantee constructor priorities in one TU and
> my testcase confirms it.
HJ, this isn't true.
The exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #40 from Mark Mitchell 2010-12-12
00:11:56 UTC ---
On 12/11/2010 4:08 PM, hjl.tools at gmail dot com wrote:
> We only support constructor priority in single source file:
H.J., this is false.
Please try writing three constructors, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #38 from Mark Mitchell 2010-12-12
00:03:22 UTC ---
On 12/11/2010 4:00 PM, hjl.tools at gmail dot com wrote:
> Really? Here is a testcase. Do you think goo's constructor
> will be called before another constructor in another file
> w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #36 from Mark Mitchell 2010-12-11
23:54:44 UTC ---
On 12/11/2010 3:48 PM, hjl.tools at gmail dot com wrote:
> 1. __attribute__((init_priority(1005))) doesn't map to
> .ctors.1005 section.
It probably maps to .ctors.(65535-1005). T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #34 from Mark Mitchell 2010-12-11
23:30:19 UTC ---
On 12/11/2010 3:28 PM, hjl.tools at gmail dot com wrote:
> 1. How do you find out what priority "foo" constructor has?
If you're looking at source code, read the source. If you're
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #32 from Mark Mitchell 2010-12-11
23:19:05 UTC ---
On 12/11/2010 2:56 PM, hjl.tools at gmail dot com wrote:
> It works at source code level. I don't believe we ever support
> "interleaving constructor priorities" between object files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #29 from Mark Mitchell 2010-12-11
21:06:41 UTC ---
On 12/11/2010 1:01 PM, hubicka at ucw dot cz wrote:
> So I take that, the ctor order is to support priotities, since the
> .ctor.priority sections get merged into single and ordered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #27 from Mark Mitchell 2010-12-11
20:19:23 UTC ---
On 12/11/2010 12:17 PM, hjl.tools at gmail dot com wrote:
> I don't think GCC really supports interleaving constructor priority
> at binary level. Unless GCC can guarantees one can i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #24 from Mark Mitchell 2010-12-11
19:56:43 UTC ---
On 12/11/2010 11:53 AM, hjl.tools at gmail dot com wrote:
>> You have to be more specific about what you meant by "interleaving".
Constructor priorities are a GNU C extension:
__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #18 from Mark Mitchell 2010-12-11
19:33:17 UTC ---
On 12/11/2010 11:03 AM, hjl.tools at gmail dot com wrote:
> I am not sure about GOLD. But it usually follows GNU linker.
> For GNU linker, the constructor priority is honored within
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #16 from Mark Mitchell 2010-12-11
18:50:11 UTC ---
On 12/11/2010 10:47 AM, hjl.tools at gmail dot com wrote:
> Linker supports sorting .ctors.N and .init_array..
> Within .ctors.N and .init_array., the order is define
--- Comment #15 from mark at codesourcery dot com 2010-04-20 22:18 ---
Subject: Re: [DR 1022] G++ is too aggressive in optimizing
away bounds checking with enums
jason at gcc dot gnu dot org wrote:
> Certainly optimizing away bounds checking is good when it is provably
> red
--- Comment #21 from mark at codesourcery dot com 2010-02-18 19:47 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
manu at gcc dot gnu dot org wrote:
> In any case, using diagnostic_report_warni
--- Comment #15 from mark at codesourcery dot com 2010-01-29 15:12 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
manu at gcc dot gnu dot org wrote:
> Why is this a note and not simply a warn
--- Comment #9 from mark at codesourcery dot com 2010-01-27 20:04 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
paolo dot carlini at oracle dot com wrote:
> If you say 'consider' and
--- Comment #10 from mark at codesourcery dot com 2010-01-15 15:05 ---
Subject: Re: FAIL: g++.dg/tree-ssa/new1.C scan-tree-dump-not
forwprop1 "= .* \+ -"
ramana at gcc dot gnu dot org wrote:
> So yes it does look ARM specific . Also peeking at results on gcc-testresu
--- Comment #15 from mark at codesourcery dot com 2009-11-13 15:07 ---
Subject: Re: [4.3/4.4/4.5 Regression] typedef doesn't fully
expose base class type
jason at gcc dot gnu dot org wrote:
> I'm assuming Mark isn't actually working on this bug.
Sad, but
--- Comment #26 from mark at codesourcery dot com 2009-03-20 20:16 ---
Subject: Re: [4.2/4.3/4.4 regression] Trouble with static
const data members in template classes
jason at gcc dot gnu dot org wrote:
> I don't think the testcase in comment #7 indicates a bug at all.
--- Comment #53 from mark at codesourcery dot com 2009-02-23 16:11 ---
Subject: Re: [4.2/4.3/4.4 Regression] out of memory while
parsing array with many initializers
hubicka at gcc dot gnu dot org wrote:
> Perhaps explicitly freeing would be good idea?
I certainly have
--- Comment #10 from mark at codesourcery dot com 2009-02-19 16:41 ---
Subject: Re: [4.4 Regression] Inconsistent reject / accept
of code
rguenth at gcc dot gnu dot org wrote:
> The ultimate question is of course if the standard allows (or even requires)
> an error here
--- Comment #24 from mark at codesourcery dot com 2009-02-10 06:20 ---
Subject: Re: [4.2/4.3/4.4 regression] ICE on invalid default
template parameter
paolo dot carlini at oracle dot com wrote:
> Mark, can you have a closer look to the draft patch? I'm still looking but I
--- Comment #50 from mark at codesourcery dot com 2009-02-06 19:22 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
hjl dot tools at gmail dot com wrote:
> For most people, GCC_EXEC_PREFIX points to either a directory which
> doesn't exis
--- Comment #48 from mark at codesourcery dot com 2009-02-06 18:35 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
rob1weld at aol dot com wrote:
> One example is inherently derived from where we see it being set (wrongly),
> during &qu
--- Comment #75 from mark at codesourcery dot com 2009-02-02 20:29 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
> Since my suggested patch proved somewhat controversial, for 4.4 I'd like to
> fall back on the simpler solution
--- Comment #16 from mark at codesourcery dot com 2009-02-02 07:15 ---
Subject: Re: [4.4 regression] Unexplained "'' is
used uninitialized in this function" warning in cc1plus -m64
rguenther at suse dot de wrote:
> Ok. But, as opposed to inheritance, insert
--- 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
--- 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
--- 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
--- Comment #23 from mark at codesourcery dot com 2008-11-04 05:51 ---
Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect
library ABI version detected
aph at gcc dot gnu dot org wrote:
> It's quite likely that the Java FE should not be
--- Comment #11 from mark at codesourcery dot com 2008-10-16 20:37 ---
Subject: Re: debug info for class2 in g++.dg/other/unused1.C
requires -femit-class-debug-always
jason at redhat dot com wrote:
> It seems to me that you're arguing that -femit-class-debug-always shou
--- Comment #9 from mark at codesourcery dot com 2008-10-15 22:51 ---
Subject: Re: debug info for class2 in g++.dg/other/unused1.C
requires -femit-class-debug-always
jason at redhat dot com wrote:
>> But, I think it's odd if I'm in the debugger, looking a
--- Comment #57 from mark at codesourcery dot com 2008-09-24 13:03 ---
Subject: Re: exception_defines.h #defines try/catch
jason at gcc dot gnu dot org wrote:
> --- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43
> ---
> It seems reasonable to me fo
--- Comment #8 from mark at codesourcery dot com 2008-08-08 23:40 ---
Subject: Re: [4.4 Regression] test failures between
revs. 134696 and 134717
janis at gcc dot gnu dot org wrote:
> --- Comment #7 from janis at gcc dot gnu dot org 2008-08-08 23:34 ---
> Mark, the
--- Comment #9 from mark at codesourcery dot com 2008-07-14 16:53 ---
Subject: Re: ICE on SFINAE and __is_empty
sebor at roguewave dot com wrote:
> int foo >(B, __is_empty (A<0>)>::X*):
> _Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE
>
--- Comment #7 from mark at codesourcery dot com 2008-07-14 15:28 ---
Subject: Re: ICE on SFINAE and __is_empty
sebor at roguewave dot com wrote:
> My preference would be for gcc to avoid imposing restrictions on the use
> of these helpers to facilitate portability to other com
--- Comment #14 from mark at codesourcery dot com 2008-07-10 14:58 ---
Subject: Re: [4.4 regression] warning "array subscript is
below array bounds" on delete [] with -O2, -Wall
rguenther at suse dot de wrote:
> Can the FE mark this array-access with TREE_NO_WARNING?
--- Comment #9 from mark at codesourcery dot com 2008-07-10 03:42 ---
Subject: Re: [4.4 regression] warning "array subscript is
below array bounds" on delete [] with -O2, -Wall
paolo dot carlini at oracle dot com wrote:
> Mark, could you possibly comment on this PR? W
--- Comment #13 from mark at codesourcery dot com 2008-07-09 19:08 ---
Subject: Re: Simple std::bind use causes warnings with -Wextra
bangerth at dealii dot org wrote:
> --- Comment #10 from bangerth at dealii dot org 2008-07-09 17:04 ---
> (In reply to comment #8)
&g
--- Comment #6 from mark at codesourcery dot com 2008-07-08 16:32 ---
Subject: Re: Simple std::bind use causes warnings with -Wextra
paolo dot carlini at oracle dot com wrote:
> Thanks Tom. In fact, yesterday I was writing without remembering my past
> analyses of this type of
--- Comment #21 from mark at codesourcery dot com 2008-06-10 05:02 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
hjl dot tools at gmail dot com wrote:
>>> --syroot supports libraries and headers. Does it support
>>> assemble
--- Comment #19 from mark at codesourcery dot com 2008-06-10 00:38 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with installed gcc
hjl dot tools at gmail dot com wrote:
> They sound to me the ideal usage for --sysroot. They aren't from
> gcc and they d
--- Comment #17 from mark at codesourcery dot com 2008-06-09 21:16 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
> --- Comment #16 from hjl dot tools at gmail dot com 2008-06-09 14:16
> ---
>
--- Comment #13 from mark at codesourcery dot com 2008-06-09 00:05 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
>>>> 1. User puts libraries/headers in $pefix/{lib,include}
>>>
--- Comment #11 from mark at codesourcery dot com 2008-06-08 21:12 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
>> I suspect that if you remove the setting in site.exp you will break the
>> f
--- Comment #9 from mark at codesourcery dot com 2008-06-08 20:23 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
> How does gcc search the right paths when GCC_EXEC_PREFIX points
> to non-existent direct
--- Comment #10 from mark at codesourcery dot com 2008-02-26 17:57 ---
Subject: Re: [4.1/4.2/4.3/4.4 Regression] With #pragma visibility,
`vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility
relocation
benjamin at smedbergs dot us wrote:
> --- Co
--- Comment #15 from mark at codesourcery dot com 2008-02-19 06:15 ---
Subject: Re: [4.2/4.3 Regression] ICE in svn boost math toolkit
rguenth at gcc dot gnu dot org wrote:
> --- Comment #14 from rguenth at gcc dot gnu dot org 2008-02-12 23:19
> ---
> It looks li
--- Comment #8 from mark at codesourcery dot com 2008-02-13 18:18 ---
Subject: Re: [4.0/4.1/4.2/4.3 regression] ICE with VLA in
template function
jason at gcc dot gnu dot org wrote:
> Either value_dependent_expression_p needs to handle arbitrary VLA bounds, or
> we
> need
--- Comment #38 from mark at codesourcery dot com 2008-01-22 17:47 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
jason at gcc dot gnu dot org wrote:
>> However, this runs into problems with libstdc++. In pa
--- Comment #6 from mark at codesourcery dot com 2008-01-20 20:28 ---
Subject: Re: [4.2/4.3 Regression] bit-fields, references and
overloads
aoliva at gcc dot gnu dot org wrote:
> --- Comment #5 from aoliva at gcc dot gnu dot org 2008-01-17 18:01
> ---
> C
--- Comment #25 from mark at codesourcery dot com 2008-01-16 22:27 ---
Subject: Re: [4.3 Regression] Revision 129442 breaks
libstc++ API
bkoz at gcc dot gnu dot org wrote:
> I believe there is a bit of a bias here, in that it's OK to make FE changes,
> but even well-doc
--- Comment #36 from mark at codesourcery dot com 2008-01-08 03:39 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | (Both have
> | values unrepresentable in the other, of
--- Comment #34 from mark at codesourcery dot com 2008-01-07 16:17 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | What's the likely change?
>
> Ban implicit narro
--- Comment #31 from mark at codesourcery dot com 2008-01-07 07:48 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> But, as that hypothetical user, I would not have any ground
--- Comment #30 from mark at codesourcery dot com 2008-01-07 07:44 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | Is it conceivable that ISO C++ will ever add a
> | comp
--- Comment #26 from mark at codesourcery dot com 2008-01-07 01:16 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> I would not bet money that nobody is not using it. However, th
--- Comment #24 from mark at codesourcery dot com 2008-01-06 21:06 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | I'm not sure what you mean by that. It's a pub
--- Comment #22 from mark at codesourcery dot com 2008-01-05 07:55 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at cs dot tamu dot edu wrote:
> | > I'd rather distinguish the constructor taking
--- Comment #39 from mark at codesourcery dot com 2008-01-04 04:43 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
fche at redhat dot com wrote:
>> Downgrading to P4. We seem to have consensus that this is [not] a GCC
>> wrong-code
>&
--- Comment #18 from mark at codesourcery dot com 2007-12-26 21:19 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
gdr at gcc dot gnu dot org wrote:
> I'm very nervous about adding more constructors.
> I
--- Comment #15 from mark at codesourcery dot com 2007-12-17 04:34 ---
Subject: Re: [4.3 Regression] Revision 129442 breaks
libstc++ API
rguenther at suse dot de wrote:
> Now that we have ext/hash_map and ext/hash_set back (yes, SPEC2000
> eon still is broken, as it uses the r
--- Comment #35 from mark at codesourcery dot com 2007-11-27 19:45 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
bunk at stusta dot de wrote:
> Even if this specific issue in the kernel would turn out as a misoptimization,
> the general problem
--- Comment #30 from mark at codesourcery dot com 2007-11-27 18:58 ---
Subject: Re: [4.3 regression] udivdi3 counterproductive,
unwarranted use
rguenth at gcc dot gnu dot org wrote:
> --- Comment #29 from rguenth at gcc dot gnu dot org 2007-11-27 09:43
> ---
> Thi
--- Comment #12 from mark at codesourcery dot com 2007-11-01 16:50 ---
Subject: Re: INIT_PRIORITY is broken
danglin at gcc dot gnu dot org wrote:
> --- Comment #11 from danglin at gcc dot gnu dot org 2007-11-01 03:05
> ---
> Mark,
>
> This is major pro
--- Comment #8 from mark at codesourcery dot com 2007-10-30 02:50 ---
Subject: Re: INIT_PRIORITY is broken
dave at hiauly1 dot hia dot nrc dot ca wrote:
>> I don't think this will be too hard to implement. In
>> cgraph_build_cdtor_fns, we need to partition/sort th
--- Comment #6 from mark at codesourcery dot com 2007-10-28 22:46 ---
Subject: Re: INIT_PRIORITY is broken
danglin at gcc dot gnu dot org wrote:
> With respect to initpr1.c, it can be seen that only one "GLOBAL" constructor,
> _GLOBAL__I_0_c1, and one &qu
--- 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:
--- 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 ---
--- Comment #7 from mark at codesourcery dot com 2007-07-12 06:20 ---
Subject: Re: [4.1 Regression] ICE in resolve_overloaded_unification
reichelt at gcc dot gnu dot org wrote:
> template struct A
> {
> A& operator<<(void (*)(A&));
> };
>
> te
--- Comment #11 from mark at codesourcery dot com 2007-07-08 18:12 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
pcarlini at suse dot de wrote:
> --- Comment #10 from pcarlini at suse dot de 2007-07-07 22:57
--- Comment #9 from mark at codesourcery dot com 2007-07-07 22:51 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with "complex type" conversion
pcarlini at suse dot de wrote:
> --- Comment #8 from pcarlini at suse dot de 2007-07-07 22:44
--- Comment #11 from mark at codesourcery dot com 2007-07-07 19:18 ---
Subject: Re: [4.1/4.2/4.3 regression] ICE with invalid use
of new
reichelt at gcc dot gnu dot org wrote:
> --- Comment #10 from reichelt at gcc dot gnu dot org 2007-07-07 10:59
> ---
> Mark, is
--- Comment #5 from mark at codesourcery dot com 2007-06-29 19:29 ---
Subject: Re: [4.3 Regression] ICE in build2_stat,
at tree.c:3074
pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-29 19:27
> ---
> Mark,
>
--- Comment #2 from mark at codesourcery dot com 2007-06-26 12:14 ---
Subject: Re: [4.3 Regression] attribute always_inline ->
sorry, unimplemented: recursive inlining
rguenth at gcc dot gnu dot org wrote:
> TYPE_ARG_TYPES says we want a char, but the call expression has
--- Comment #176 from mark at codesourcery dot com 2007-06-09 19:29 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
> So, from my point of view the patch is ready to be exposed to m
--- Comment #9 from mark at codesourcery dot com 2007-05-31 16:32 ---
Subject: Re: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY
is still set for non read only variables causing wrong code
jakub at gcc dot gnu dot org wrote:
> 2007-05-31 Jakub Jelinek <[EMAIL PRO
--- Comment #6 from mark at codesourcery dot com 2007-05-30 23:02 ---
Subject: Re: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY
is still set for non read only variables causing wrong code
mueller at gcc dot gnu dot org wrote:
> --- Comment #5 from mueller at gcc dot gnu
--- Comment #5 from mark at codesourcery dot com 2007-05-30 21:38 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
> --- Comment #3 from pcarlini at suse dot de 2007-05-30 21:25 ---
> Thanks Mark. I
--- Comment #2 from mark at codesourcery dot com 2007-05-30 21:08 ---
Subject: Re: uninitialized_fill compile failure if no default
assignment operator
pcarlini at suse dot de wrote:
> --- Comment #1 from pcarlini at suse dot de 2007-05-30 21:00 ---
> Curious, t
--- Comment #146 from mark at codesourcery dot com 2007-05-23 22:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenther at suse dot de wrote:
> Only so much that we seem to agree on the semantics of placement
--- Comment #143 from mark at codesourcery dot com 2007-05-23 21:27 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenther at suse dot de wrote:
>
>> void f(int *p) {
>> *p = 3;
>>
--- Comment #141 from mark at codesourcery dot com 2007-05-23 21:13 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
joseph at codesourcery dot com wrote:
> DR#236 <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_2
--- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
>
> Gaby's claim is that given an arbitrary
> point
--- Comment #136 from mark at codesourcery dot com 2007-05-23 20:10 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
> --- Comment #134 from rguenth at gcc dot gnu dot org 2007-05
--- Comment #133 from mark at codesourcery dot com 2007-05-23 19:43 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> The case where TBAA is most useful is on a deeply pipelined in-order proces
--- Comment #120 from mark at codesourcery dot com 2007-05-22 18:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> | I would guess
> | that we made this change around the year 200
--- Comment #118 from mark at codesourcery dot com 2007-05-22 18:34 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> Thanks for reminding all those points. I'll ensure that I ma
--- Comment #113 from mark at codesourcery dot com 2007-05-22 17:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17
--- Comment #111 from mark at codesourcery dot com 2007-05-22 17:37 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> | No, I do not. And GCC historically has not; you are only allowed
--- Comment #109 from mark at codesourcery dot com 2007-05-22 17:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> Consider the following instead
>
>// tu-1.C
>v
--- Comment #106 from mark at codesourcery dot com 2007-05-22 16:04 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
> - we _cannot_ sink loads across stores.
>
>
--- Comment #97 from mark at codesourcery dot com 2007-05-18 21:17 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
> But construction/initialization of uninitalized memory in happ
--- Comment #93 from mark at codesourcery dot com 2007-05-18 19:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
>
--- Comment #89 from mark at codesourcery dot com 2007-05-18 17:44 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
&
--- Comment #80 from mark at codesourcery dot com 2007-05-18 07:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #78 from ian at airs dot com 2007-05-18 07:14 ---
> Th
--- Comment #77 from mark at codesourcery dot com 2007-05-17 00:41 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> I don't believe that the C++ standards writers really meant to eliminate
1 - 100 of 339 matches
Mail list logo
