I'll probably have to debug this myself..but compiling Tcl 8.5.8's tclStrToD.c
on alphaev67-dec-osf5.1 takes an inordinately long time. I've left it running
for many minutes. Everything else in Tcl compiled fairly rapidly, just this one
file is going and going. I tried without optimizing too.
gcc
--- Comment #1 from jay dot krell at cornell dot edu 2010-06-09 07:28
---
It is hung here:
#0 0x0001206feb24 in __gmpn_invert_limb ()
#1 0x0001206fd9b0 in __gmpn_divrem_2 ()
#2 0x0001206f1f84 in __gmpn_divrem ()
#3 0x0001206d0e20 in mpfr_div ()
#4 0x0001206d27c4
--- Comment #5 from ubizjak at gmail dot com 2010-06-09 07:46 ---
Looking into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #37 from gcc at breakpoint dot cc 2010-06-09 07:50 ---
Created an attachment (id=20873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873&action=view)
this fails to compile in -O2 with the fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #38 from gcc at breakpoint dot cc 2010-06-09 07:54 ---
(In reply to comment #28)
> Please bootstrap and test this addition to e500.h
>
> /* When setting up caller-save slots (MODE == VOIDmode) ensure we
>allocate space for DFmode. Save gprs in the correct mode too. */
Based on
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cfb5f9dca46d5114#
After ENDFILE for non-streams, the current file position should be at the
endfile record. Thus, running the program below with NAG gives:
READ/WRITE attempted after ENDFILE on unit 10
Program termi
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-09 08:27
---
Janis, this doesn't make sense to me, and for sure happens only with decimal.
Can you have a look?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 08:32
---
Rainer, can you help me on this? I don't even know how to categorize it, if
it's purely an ar issue or what else, I think you know this target...
--
paolo dot carlini at oracle dot com changed:
--- Comment #2 from jay dot krell at cornell dot edu 2010-06-09 08:42
---
Two line repro, no repro with 4.3.5, hangs with 4.5.0.
I'll rebuild the compiler though.
Seem like a gmp bug.
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.3.5 -c 1.c
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.5.0 -c 1.c
bash-
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-09 08:54
---
Non pre-processed testcase. Apparently some buffer is overflowed.
#include
namespace abcdefgxyzzzabb
{
class Aaa { };
namespace klmn
{
class Baaa { };
}
}
namespace boost
{
--- Comment #39 from harry dot he at freescale dot com 2010-06-09 08:59
---
Hi, Kyle Moffett,
in testall.c, r9 is used by a register variable, however, in E500ABI guide,
r9 should be used for parameter passing, this test case seems not reasonable.
Harry He
--
http://gcc.gnu.o
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 09:02
---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I don't think you need flow-sensitivity.
> > >
> > > Basically when you have only aggregate uses (as in this case)
> >
> > V
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-09 09:05
---
(In reply to comment #11)
> > D.2464.m[0] = D.2473_20;
> > D.2464.m[1] = D.2472_19;
> > D.2464.m[2] = D.2471_18;
> > *b_1(D) = D.2464;
> >
> > D.2464 will be dead after scalarization.
>
> If D.2464 was la
--- Comment #3 from rguenther at suse dot de 2010-06-09 09:10 ---
Subject: Re: Redundant looping pure functions
whose return value is dead are not optimized out
On Tue, 8 Jun 2010, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2010-06
--- Comment #4 from mschulze at ivs dot cs dot ovgu dot de 2010-06-09
09:16 ---
I found a way to place data in program memory for C++ without producing the
annoying warnings. The trick is omiting __attribute__((__progmem__)) and
instead always use __attribute__((section(".progmem.someth
--- Comment #6 from paolo at gcc dot gnu dot org 2010-06-09 09:16 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 09:15:51 2010
New Revision: 160456
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160456
Log:
2010-06-09 Paolo Carlini
PR libstdc++/44413
*
--- Comment #40 from harry dot he at freescale dot com 2010-06-09 09:23
---
with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior
with built-in flags(-te500v2), but wrong behaviors with "-fcaller-saves -O
-fno-omit-frame-pointer -fno-dce -fno-split-wide-types". Re
--- Comment #75 from iains at gcc dot gnu dot org 2010-06-09 09:27 ---
Subject: Bug 43170
Author: iains
Date: Wed Jun 9 09:27:04 2010
New Revision: 160457
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160457
Log:
config:
PR bootstrap/43170
* tls.m4 (GCC_CHECK_
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-09 09:29 ---
Please report it to mpfr developers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|c |target
G
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 09:37
---
Recategorizing as other (like 42230)... and maybe HJ is interested in playing a
bit with this one too.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #19 from jakub at gcc dot gnu dot org 2010-06-09 09:39 ---
Created an attachment (id=20874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20874&action=view)
CVE-2010-0831.patch
Just for the record, the patch that went in leaves fastjar still vulnerable.
The main issue
When building a Linux kernel the new default of having
-Wunused-but-set-variable is incredibly noisy in kernel build. I get hundreds
of new warnings from that.
I looked at some of the circumstances and it's typically
int var = VALUE;
#ifdef SYMBOL
if (do something)
var = other value
#endif
wi
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 09:49
---
I'm sure you are right, but I don't understand your explanation: even when
SYMBOL
is undefined, why no code actually uses (roughly speaking, reads) var? That's
the point of the warning and your example doesn't
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 09:53 ---
The warning is useful and can find (and already found) several real bugs e.g.
in gcc itself. Icc has similar warning.
If kernel has lots of useless code like that and doesn't wish to use this
warning, it can add -Wno-
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 10:13 ---
Sorry my example was not very good.
Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could be put a
--- Comment #7 from zsojka at seznam dot cz 2010-06-09 10:14 ---
I have just finished bootstrap of r160198 with valgrind checking, the problem
is no longer reproducible there. I am sorry for the delay, make check with
valgrind checking takes about a month there (1.3GHz), bootstrap about
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:18
---
Subject: Bug 43040
Author: fxcoudert
Date: Wed Jun 9 10:17:56 2010
New Revision: 160459
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160459
Log:
PR fortran/43040
* f95-lang.c (gfc_init_
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:20
---
Checked that it is not an issue.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-09 10:22 ---
(From update of attachment 20871)
attachment's mimetype changed to text/plain
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from hubicka at ucw dot cz 2010-06-09 10:29 ---
Subject: Re: Redundant looping pure functions
whose return value is dead are not optimized out
> > >Why do we remove register LHS in DCE again?
> >
> > Because it reduces the amount of garbage produced by expand :
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-09 10:32 ---
Subject: Bug 44432
Author: amylaar
Date: Wed Jun 9 10:32:23 2010
New Revision: 160460
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160460
Log:
PR bootstrap/44432
* configure.ac: Before usi
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-09 10:40 ---
Subject: Bug 42843
Author: amylaar
Date: Wed Jun 9 10:40:28 2010
New Revision: 160461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160461
Log:
gcc:
PR testsuite/42843
* gcc-plugin.h (int p
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-09 10:47 ---
Fixed in trunk by revision 160460.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-06-09 10:49 ---
Fixed in trunk by revision 160461.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-09 10:52 ---
We don't warn on
void foo (void)
{
int dummy;
asm ("" : "=r" (dummy));
}
- the use in the asm is considered as a use, not just set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
--- Comment #4 from andi-gcc at firstfloor dot org 2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?
Here's a reduced test case with only a single input file (reduced too)
gcc46 -O2 -fwhopr -c igmp.mini.
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 10:56 ---
Created an attachment (id=20875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875&action=view)
reduced input file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #5 from zsojka at seznam dot cz 2010-06-09 11:02 ---
The testcase also fails when it is changed to:
...
{
extern void *bar(void) __attribute__((malloc));
int **pp = bar(), *p = bar();
...
so there isn't any access through NULL pointer.
--
http://gcc.gnu.org/bugzill
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween
unsigned inlinefunc(void)
{
unsigned var;
asm(" ... " : "=r" (var));
return var;
}
#define macro(x,y)
{
unsigned var = inlinefunc();
x = var;
y =
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 11:09 ---
Jakub, for this example: how would you suggest to work around this warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
--- Comment #20 from marcus at jet dot franken dot de 2010-06-09 11:20
---
Jakubs patch looks good to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #13 from jamborm at gcc dot gnu dot org 2010-06-09 11:20
---
Subject: Bug 44423
Author: jamborm
Date: Wed Jun 9 11:20:03 2010
New Revision: 160462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160462
Log:
2010-06-09 Martin Jambor
PR tree-optimization/4
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-09 11:21
---
I don't need a backport to 4.4 and I double checked it works as expected
in gcc 4.5. Closing.
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
-
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
When compiling function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i < 8; i++)
{
a[i] = b[i];
}
}
before sched2 we have:
(note 13 12 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 14 13 15 3 ./a.c:6 (set (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-09 11:28
---
Created an attachment (id=20876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20876&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-09 11:36 ---
Then it has nothing to do with the asm.
If the macro is widely used and very often sets a var that isn't used, all
you can do is add (void) cast to shut the warning up.
(void) (y = var >> 16);
in this case.
--
htt
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-06-09 11:53 ---
Fixed by patch at revision 159965.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-09 11:56 ---
I will have a look at some point.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.0.0 |4.0.0 4.3.5 4.4.3
Target Milestone|4.3.6 |4.5
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-09 11:59 ---
It's now optimized by RTL DSE but we keep the stack allocated.
Re-confirmed on the tree-level. Should be easy to extend DSE to handle this.
--
rguenth at gcc dot gnu dot org changed:
What|Remove
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:01
---
I don't understand what you mean by that: currently, we have the following
typedefs on platforms which support a 128-bit int type:
typedef __int128_t GFC_INTEGER_16;
typedef __uint128_t GFC_UINTEGER_16;
I do
--- Comment #14 from martin at mpa-garching dot mpg dot de 2010-06-09
12:06 ---
SSE performance is fine again, thanks a lot!
One more question, if that's OK...
Depending on ARRSZ the testcase uses wildly varying amounts of CPU time; it's
about half a second for ARRSZ=1024, but almost 1
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:07
---
Hey, I actually have the answer to this one: yes, it is intended as is, and
not, it is a bit more complicated that Jerry says.
We maintain a hash table of identifiers, so that when we have multiple times
the same
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-09 12:08 ---
(In reply to comment #4)
> I was told that the whopr link step would inherit the optimization
> flags from the build step. Is that not true?
That's not true.
> Here's a reduced test case with only a single input fi
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-09 12:15 ---
Actually - we seem to get IPA SRA parm repacements done but the original
parameter SSA names are not released.
(gdb) call debug_function (cfun->decl, 0)
igmp_mc_get_next ( * ISRA.14, struct ip_mc_list * ISRA.15)
{
--- Comment #6 from ubizjak at gmail dot com 2010-06-09 12:15 ---
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
Index: i386.md
==
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-09 12:16 ---
CC'ing martin even.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from andi-gcc at firstfloor dot org 2010-06-09 12:16 ---
Unfortunate. Fixing that in the makefiles would be major effort for all the -f
and -m flags, which sometimes vary by target.
I thought LTO was designed to minimize makefile changes?
--
http://gcc.gnu.org/bug
--- Comment #10 from andi-gcc at firstfloor dot org 2010-06-09 12:18
---
The tree input that leads to the NULL annotation is a "error_mark"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 12:41 ---
Close as WONTFIX.
The int128 changes still do not offer to enter the integer directly (instead of
using 123L with "<<" shifts)
And one issue was fixed as part of
http://gcc.gnu.org/viewcvs?view=revision&revision=1
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 12:51 ---
I guess for empty bbs with no successor where the predecessor ends in an
conditional jump without side-effects try_optimize_cfg can't do just
delete_basic_block, but needs to call some function to actually adjust the
c
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-09 13:01
---
(In reply to comment #10)
> The tree input that leads to the NULL annotation is a "error_mark"
Not for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-06-09 13:03
---
(In reply to comment #9)
> Unfortunate. Fixing that in the makefiles would be major effort for all the
> -f
> and -m flags, which sometimes vary by target.
>
> I thought LTO was designed to minimize makefile ch
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 ---
Created an attachment (id=20877)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view)
e500.h and caller-save.c patch
The ICE in #38 is due to a bug in caller-save.c
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35
---
What happens then when some files need different options that other files?
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles
--
http://gcc.gnu.org/bugz
The current implementation of begin() for unordered associative containers is
linear (a search for the first non-empty bucket is executed each time begin()
is called), yet the C++0x drafts specifiy that this should be constant (23.3.1,
table 93). Boost.Unordered, for instance, caches the first non-
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-09 13:39 ---
The following patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
should fix the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42
---
I found this code in lto.c which seems to disagree:
/* Read the options saved from each file in the command line. Called
from lang_hooks.post_options which is called by process_options
right before all the
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-09 13:43 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 13:50 ---
> The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
> It definitly avoids the ICE, but it would be nice to know if libstdc++
> testsuite passes.
It does fix the bootstrap failure. I am currently r
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 ---
(In reply to comment #41)
> The ICE in #38 is due to a bug in caller-save.c
Thank you for the very quick fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55
---
Ok seems it does not do what I want:
FIXME lto. Currently the scheme is limited in that only the
options saved on the first object file (f1.o) are read back during
the link step. This means that the opt
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-09 13:55 ---
There are more issues:
1) cleanup_barriers seems to do weird things with these empty bbs from
__builtin_unreachable (), I guess it shouldn't reorder anything if prev is a
LABEL_P
2) the reason why this compiles fine on
When compiling the following program with -O2, gcc gives an ICE "internal
compiler error: in trunc_int_for_mode, at explow.c:56".
Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)
static inline unsi
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-09 14:02 ---
Subject: Bug 44413
Author: paolo
Date: Wed Jun 9 14:02:03 2010
New Revision: 160476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160476
Log:
2010-06-09 Paolo Carlini
Revert:
2010-06-
--- Comment #43 from mark dot workman at acm dot org 2010-06-09 14:07
---
(In reply to comment #39)
> Hi, Kyle Moffett,
> in testall.c, r9 is used by a register variable, however, in E500ABI
> guide,
> r9 should be used for parameter passing, this test case seems not reasonable.
>
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
> (In reply to comment #1)
> > It may be broken by revision 160394:
> >
> > http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
>
> The add->lea transformation doesn't even trigger in this
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 14:15 ---
Subject: Bug 44211
Author: janus
Date: Wed Jun 9 14:14:08 2010
New Revision: 160478
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160478
Log:
2010-06-09 Janus Weil
PR fortran/44211
* reso
--- Comment #12 from bergner at gcc dot gnu dot org 2010-06-09 14:15
---
Subject: Bug 44067
Author: bergner
Date: Wed Jun 9 14:15:11 2010
New Revision: 160479
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160479
Log:
Backport from mainline:
2010-06-09 Edmar
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-09 14:16 ---
Fixed with r160478. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 ---
Whatever we do, we need to preserve Atom add->lea optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
"manu at gcc dot gnu dot org" writes:
> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/diagnostics.html.
I guess you are talking about the "automatic macro expansion" section of
that link?
>
> In fact, clang's output actually follows more closely what
--- Comment #27 from dodji at gcc dot gnu dot org 2010-06-09 14:23 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
"manu at gcc dot gnu dot org" writes:
> I find this output a bit confusing. I find clang's output clearer
> http://clang.llvm.org/
"manu at gcc dot gnu dot org" writes:
>>
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expanding macro SHIFTL at test.c:5:14
>> While expanding macro MULT2 at test.c:8:3
>> test.c: In function 'g':
>> test.c:13:3: error: invalid operands to binary << (have 'dou
--- Comment #28 from dodji at gcc dot gnu dot org 2010-06-09 14:32 ---
Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL
constants
"manu at gcc dot gnu dot org" writes:
>>
>> $ ./cc1 -quiet test.c
>> While expanding macro OPERATE at test.c:2:8
>> While expandi
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 14:43
---
OK, I have found the bug and I admit it is rather embarrassing. I'll
submit a patch soon.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-09 15:07 ---
With the patch for PR 44211 (just committed to the 4.6 trunk), the program
compiles and the output is:
shape
In generic_shape_assign
x = 10
y = 20
circle
In generic_shape_assign
x =
--- Comment #9 from jason at gcc dot gnu dot org 2010-06-09 15:12 ---
Subject: Bug 44366
Author: jason
Date: Wed Jun 9 15:11:42 2010
New Revision: 160483
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160483
Log:
PR c++/44366
* g++.dg/cpp0x/decltype23.C: Move to
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:13
---
I gave this more thought, and to be honest, focusing on 64-bit targets - I
think that for 32-bit targets what we have is already good enough - I have no
idea how to substantively improve the code, given that th
--- Comment #6 from ian at rhymneyconsulting dot co dot uk 2010-06-09
15:20 ---
Subject: RE: [OOP] ICE with polymorphic object oriented example
Thanks very much for fixing it.
Cheers
Ian
> -Original Message-
> From: burnus at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
CC|mikestump at comcast dot net|
Target Milestone|--- |4.6.0
http://gcc.gnu.o
--- Comment #5 from paolo at gcc dot gnu dot org 2010-06-09 15:35 ---
Subject: Bug 44461
Author: paolo
Date: Wed Jun 9 15:34:45 2010
New Revision: 160488
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160488
Log:
2010-06-09 Khem Raj
PR libstdc++/44461
* libs
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 15:36
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 15:46
---
I see. Looks like Matt essentially followed in the reference implementation the
legacy HP / SGI, linear, way of computing begin(). I'm asking his opinion on
this, whether we are also going to use caching or so
--- Comment #7 from raj dot khem at gmail dot com 2010-06-09 15:48 ---
thanks Paolo, we would need this patch on 4.5 branch as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:52
---
In general, only if it's a regression. And nobody said that explicitly so far.
If you want to argue for having it anyway in 4_5-branch, please speak on the
mailing list and ask permission to the release manager
note this is later bootstrap stages so shouldn't matter what the bootstrap
compiler was (assuming it compiled the compiler reasonably correctly)
For the missing prototypes, I suggest you just put them right there:
void Foo(void);
void Foo(void)
{
...
}
for the uninitialized I suggest just ini
1 - 100 of 166 matches
Mail list logo
