--- Comment #5 from hjl dot tools at gmail dot com 2008-02-13 21:44 ---
(In reply to comment #4)
> This is confirmed. H.J., are you waiting for something to commit to 4.2 or
> should this be closed?
>
I requested it for 4.2:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00471.html
--
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-02-13 21:54
---
> So, what exactly is wrong now?
Oh nothing, just the generated code. :-)
D.375_38 = (system__aux_dec__TsaB) a_3(D);
A.36 = D.375_38;
A.37_35 = (system__address *) &A.36;
ivtmp.34_32 = (unsigned int) A.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-13 21:43 ---
Try 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Version|unkno
--- Comment #2 from tuttle at sandbox dot cz 2008-02-13 21:41 ---
(In reply to comment #1)
> -Wunreachable-code should warn already.
> -- Pinski
I've tried -Wunreachable-code before submitting this enhancement request.
gcc 4.1.3 in Ubuntu GG does not warn.
--
http://gcc.gnu.org/bu
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 21:37 ---
-Wunreachable-code should warn already.
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from joel at gcc dot gnu dot org 2008-02-13 21:38 ---
This failed on psim for me. AFAIK it doesn't have Altivec. Sorry,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34930
--- Comment #5 from steven at gcc dot gnu dot org 2008-02-13 22:04 ---
I also can't reproduce it (neither on native nor with a cross).
Any local patches? Maybe you can reduce it to a set of simpler configuration
options?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-13 22:10 ---
Confirmed in GCC 4.3 revision 132291.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-13 22:24 ---
This is not sufficient.
block_New, nal_get_annexeb, block_ChainGather still don't have prototypes and
thus:
warning: cast to pointer from integer of different size
is reported on each of the casts of these function ca
--- Comment #15 from lennox at cs dot columbia dot edu 2008-02-13 22:27
---
Arguably, the use of static data (possible excepting const static data) or a
non-inline static function is worthy of a pedwarn. But I'd certainly be
inclined to agree for static inline functions.
--
http:/
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-13 22:25 ---
Can you please submit it (or even commit as obvious)?
Sorry for not thinking about this asm needing 6 regs on i?86, where it is
sometimes too much.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2008-02-13 22:25
---
> It is too optimistic about addressability.
It takes the address of non-addressable things:
base &VIEW_CONVERT_EXPR((system__aux_dec__TsaB) a_3(D))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35136
--- Comment #8 from jakub at gcc dot gnu dot org 2008-02-13 22:31 ---
Subject: Bug 35138
Author: jakub
Date: Wed Feb 13 22:30:43 2008
New Revision: 132298
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132298
Log:
PR c++/35138
* parser.c (cp_parser_pseudo_destruc
--- Comment #9 from jakub at gcc dot gnu dot org 2008-02-13 22:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from matz at gcc dot gnu dot org 2008-02-13 23:03 ---
Sigh. I've tested the changed testcase only on 32bit :-( Update to r132300.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
--- Comment #25 from dominiq at lps dot ens dot fr 2008-02-13 23:41 ---
> (Could someone with darwin bootstraps and regtest removal of these defines? Do
> we even have an example of a failure for latest 4.3 if these are not defined?)
I bootstraped without the defines and I have a bus er
[EMAIL PROTECTED] tmp]$ cat y.c
#include
int
main ()
{
#ifdef __SSE__
printf ("SSE\n");
#endif
#ifdef __SSE2__
printf ("SSE2\n");
#endif
#ifdef __SSE3__
printf ("SSE3\n");
#endif
#ifdef __SSSE3__
printf ("SSSE3\n");
#endif
#ifdef __SSE4_1__
printf ("SSE4.1\n");
#endif
#ifdef __SSE4_2__
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 23:49 ---
#define OPTION_MASK_ISA_SSE4_2_UNSET OPTION_MASK_ISA_SSE4A
I don't see this as a bug, if the AMD processors don't have 4.2, they will
never have 4a.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from michael dot meissner at amd dot com 2008-02-13 23:55
---
Umm, SSE4A is completely different from SSE4/SSE4.1/SSE4.2. SSE4A are the
instructions added with AMD's Barcelona machine, while SSE4.1 is the
instructions added with the current generation of Intel machines (
--- Comment #5 from amodra at gcc dot gnu dot org 2008-02-14 00:15 ---
Subject: Bug 34393
Author: amodra
Date: Thu Feb 14 00:14:45 2008
New Revision: 132304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132304
Log:
PR target/34393
* config/rs6000/rs6000.md (rest
--- Comment #6 from amodra at gcc dot gnu dot org 2008-02-14 00:17 ---
Subject: Bug 34393
Author: amodra
Date: Thu Feb 14 00:16:29 2008
New Revision: 132306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132306
Log:
PR target/34393
* config/rs6000/rs6000.md (rest
--- Comment #7 from amodra at gcc dot gnu dot org 2008-02-14 00:17 ---
Subject: Bug 34393
Author: amodra
Date: Thu Feb 14 00:17:11 2008
New Revision: 132309
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132309
Log:
PR target/34393
* config/rs6000/rs6000.md (rest
--- Comment #8 from amodra at bigpond dot net dot au 2008-02-14 00:18
---
fix applied
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
Status
--- Comment #4 from michael dot meissner at amd dot com 2008-02-14 00:20
---
In terms of shipping systems, no AMD system supports SSSE3 right now. As I
understand it, the SSSE3 instructions were inbetween SSE3 and SSE4.1 on Intel
systems, so -mno-sse3 should turn off SSSE3, but -mno-ss
--- Comment #3 from hjl dot tools at gmail dot com 2008-02-14 00:11 ---
-mno-sse4.1 and -mno-sse4.2 shouldn't turn off SSE4A.
-mno-sse3/-mno-sse2/-mno-sse should turn off SSE4A. But
I am not sure about -mno-ssse3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35189
--- Comment #7 from andreasmeier80 at gmx dot de 2008-02-14 00:35 ---
The patch is approved at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00392.html
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
--- Comment #2 from nightstrike at gmail dot com 2008-02-14 01:17 ---
This bug needs to be finished off before 4.3.0 closes...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-14 01:20 ---
(In reply to comment #2)
> This bug needs to be finished off before 4.3.0 closes...
Why? it has been a bug in GCC for a while now. And x86_64-pc-mingw32 is new.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-02-14
01:43 ---
Actually, I see this as unfortunate choice of name for the undocumented
__alloca label rather than as a serious bug.
__alloca is an internal symbol that should have been named _alloca_probe for
consis
--- Comment #5 from hjl dot tools at gmail dot com 2008-02-14 01:44 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00483.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from nightstrike at gmail dot com 2008-02-14 01:53 ---
Can we have this fixed before 4.3.0? x86_64-pc-mingw32 is a new target for
this release, and it shouldn't be delivered completely broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #1 from manu at gcc dot gnu dot org 2008-02-14 02:15 ---
I have a patch for this but it is not suitable for stage3, so it'll have to
wait until 4.4.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
On SH, gcc.dg/tree-prof/bb-reorg.c test fails with assembler
messages like:
/tmp/cc3RtxMk.s: 115: Error: displacement to defined symbol .L27 overflows
12-bit field
It happens with a branch from .text to .text.unlikely section
where the label .L27 is placed on.
I've found that bb-reorder makes cro
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-02-14 06:00
---
Created an attachment (id=15147)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15147&action=view)
Tentative patch
This patch fixes the test case when writing to an actual file, but not to
stdio. Stdout is
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-02-14 06:07
---
Patch in comment #6 has a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34974
--- Comment #26 from ubizjak at gmail dot com 2008-02-14 06:45 ---
(In reply to comment #25)
> > (Could someone with darwin bootstraps and regtest removal of these defines?
> > Do
> > we even have an example of a failure for latest 4.3 if these are not
> > defined?)
>
> I bootstraped
--- Comment #8 from Ralf dot Wildenhues at gmx dot de 2008-02-14 06:46
---
Subject: Re: [4.3 Regression] ICE: in
expand_call_inline, at tree-inline.c:2653
* hubicka at gcc dot gnu dot org wrote on Wed, Feb 13, 2008 at 06:29:51PM CET:
> --- Comment #7 from hubicka at gcc do
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-02-14 06:59
---
It's true that having the new target not work well is embarrassing, but it's
not a regression of any kind. However, if we don't fix this, then we certainly
shouldn't brag about support for this target in the NEWS
Code example:
class Base {
public:
void g(int i) {}
protected:
virtual void g(int i, int j) {}
};
class Derived : public Base {
protected:
virtual void g(int i, int j) {}
};
int main() {
Derived o;
o.g(5);
return 0;
}
Compilation output:
dos/quotas/test.cc: In function 'int ma
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-14 07:50 ---
This is what the C++ standard says.
overloading g will hide all of g functions in the base class. if you want not
to have them hidden you have to add an using statement.
Like:
class Derived : public Base {
public:
--- Comment #21 from tbptbp at gmail dot com 2008-02-14 07:52 ---
I've already submitted PR34864 for the folding but apparently i've overdone the
reduction; it's actually slightly tricky to trigger the issue (i mean i've
obviously hit another problem in that PR).
Right now i'm out of in
101 - 141 of 141 matches
Mail list logo
