--- 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
--- 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
--- 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 2
--- 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 2
--- 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
--- 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
> ---
> Mar
--- 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 rea
--- 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]>
>
> * Mak
--- 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
--- 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
--- 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
--- 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 wit
--- 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 strateg
--- 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
--- 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 ---
> C
--- 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
> ---
--- 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
--- 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-li
--- 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
--- 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
&g
--- 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
--- 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 #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 #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 #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 yo
--- 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
> ---
>
--- 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
> ---
--- 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 ---
&
--- 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 loadi
--- 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 200
--- 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 t
--- 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)
>
>>I
--- 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 a
--- 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 3
--- 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)
>
>>
--- 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
--- 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
> {
>
--- 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 test
--- 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
--- 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
--- 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
--- 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
--- 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
> ---
>
--- 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&#
--- 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 fol
--- 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
--- 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
--- 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++
--- 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
--- 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 whi
--- 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 ---
>
--- 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
--- 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
> ---
>
--- 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
--- 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
&g
--- 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 ---
>
--- 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
--- 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
--- 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
--- 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 matte
--- 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. W
--- 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
--- 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
> ---
>
--- 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)
>&
--- 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 c
--- 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
--- 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
> ---
>
--- 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
--- 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
--- 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
--- 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
--- 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 fac
--- 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 #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:
--- 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
>
--- 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
>
--- 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
>
--- 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 expression
--- 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
>>
--- 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 th
--- 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 rep
--- 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
--- 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
--- 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:
--- 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_c
--- 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
--- 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
--- 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:
>
>
>>>>
--- 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
--- 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
> ---
>
--- 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 wit
--- 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
--- 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
> intermit
--- 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"
>>
--- 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
> intermit
--- 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
>
--- 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
> intermit
--- 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
--- 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
--- 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 alter
1 - 100 of 339 matches
Mail list logo
