http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #69 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #22 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #62 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #46 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #16 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #18 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #24 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #27 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #29 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #32 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #34 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #36 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #38 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #40 from Mark Mitchell mark at codesourcery dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #43 from Mark Mitchell mark at codesourcery dot com 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
--- 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
redundant
--- 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_warnings_p (location) should fix
--- 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 warning?
Because, as noted
--- 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 are talking to a GWP and release
--- 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-testresults
doesn't show
--- 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 true.
--
http
--- 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.
FWIW, I
--- 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 no objection
--- 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.
The (someone
--- 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
don't
--- 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 make -i check _PRIOR_
--- 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 exist or a different
--- 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 that Howard
--- Comment #16 from mark at codesourcery dot com 2009-02-02 07:15 ---
Subject: Re: [4.4 regression] Unexplained 'anonymous' is
used uninitialized in this function warning in cc1plus -m64
rguenther at suse dot de wrote:
Ok. But, as opposed to inheritance, inserting empty members
--- 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
--- 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
--- 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
--- 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 calling
cgraph_build_static_cdtor
--- 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 should
go back
--- 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 at code that says:
return
--- 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 for try { X
--- 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 tests
--- 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 compilers
--- 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 fooA0 (BA0, __is_empty (A0)::X*):
_Z3fooI1AILi0EEEiPN1BIT_Xv19builtin16TOS3_EE1XE
int fooint(Bint, !__is_empty
--- 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 #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)
I was also
--- 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? With some good
--- 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 issue
--- 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
---
(In reply
--- 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 don't change from
--- 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
assembler and linker?
Not as far as I
--- 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 directory because
--- 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
following scenario:
1
--- 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}
2. User builds GCC with corresponding
--- 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:
--- Comment #8
--- 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 like simply
--- 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 to avoid
--- 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 particular,
std
--- 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
---
Created an attachment
--- 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-documented
--- 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 narrowing conversions, in the sense
--- 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 course.) Would you
--- 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 public constructor;
I mean
--- 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, that
somebody
--- 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
| complexdouble::complex(int
--- 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 to be unhappy
--- 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 __complex__ by adding
--- 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
bug.
Yeah, it seems
--- 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'd rather distinguish
--- 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 removed
--- 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
---
This is IMHO
--- 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 would
--- 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 progress. All the priority
--- 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 the static_[cd]tors
--- 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 GLOBAL destructor, _GLOBAL__D_1_c1
--- 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
--- 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
--- 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:
templatetypename struct A
{
A operator(void (*)(A));
};
templatetypename T AT operator(AT, const
--- 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 #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 there any
--- 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 ---
Hi Mark
--- 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,
Even though
--- 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 an int. I
--- 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 more
--- 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 PROTECTED
--- 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, this is actually
--- 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. In fact, we
--- 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 dot
--- 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 processor
--- 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-23 19
--- 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:
quote
Gaby's claim is that given an arbitrary
pointer p, saying
--- 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_236.htm
--- 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;
}
under Gaby's interpretation, we
--- 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 new.
Gaby
--- 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.
x = *int
--- 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
void f(int* p
--- 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 to use
--- 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:46
--- 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 make those
--- 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 2000. So
--- 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 ---
The test
--- 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 ---
Re comment
--- 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; }
void g
--- 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 memory
--- 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
TBAA
1 - 100 of 338 matches
Mail list logo
