--- Comment #8 from chrbr at gcc dot gnu dot org 2007-10-31 08:01 ---
fixed check_return_expr
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #3 from rsandifo at gcc dot gnu dot org 2007-10-31 08:23
---
Subject: Bug 33948
Author: rsandifo
Date: Wed Oct 31 08:23:30 2007
New Revision: 129794
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129794
Log:
gcc/
PR target/33948
* config/mips/mips.c
--- Comment #4 from rsandifo at gcc dot gnu dot org 2007-10-31 08:23
---
Fixed on mainline.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-31 09:20 ---
Apart from the issue regarding that the last two errors should be notes this
is really impossible to "fix" if -Wfatal-errors should continue to work as
designed. That is, the only way would be to annotate all _calle
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-31 09:13
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 09:47 ---
Uh, the VEC_* stuff used there looks like a mess. It's not clear who allocates
and what the size should be. For example vect_get_vec_defs_for_stmt_copy
doesn't allocate the VECs which is exactly what causes the pro
--- Comment #15 from burnus at gcc dot gnu dot org 2007-10-31 09:59 ---
Subject: Bug 33897
Author: burnus
Date: Wed Oct 31 09:59:16 2007
New Revision: 129795
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129795
Log:
2007-10-31 Paul Thomas <[EMAIL PROTECTED]>
PR fortr
--- Comment #16 from burnus at gcc dot gnu dot org 2007-10-31 09:59 ---
FIXED on the trunk (= 4.3.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2007-10-31 10:25 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from ubizjak at gmail dot com 2007-10-31 10:31 ---
Smaller testcase:
--cut here--
void
blockmove_NtoN_blend_noremap32 (const unsigned int *srcdata, int srcwidth,
int srcheight, int srcmodulo,
unsigned int *ds
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-31 10:37 ---
typedef unsigned int UINT32;
void blockmove_NtoN_blend_noremap32 ( const UINT32 *srcdata,int srcwidth,int
srcheight,int srcmodulo, UINT32 *dstdata,int dstmodulo, int srcshift) {
UINT32 *end;
while (srcheight) {
w
--- Comment #5 from irar at il dot ibm dot com 2007-10-31 10:57 ---
The problem here is that more than one vector stmts are used to vectorize (SLP)
this loop, while only one vector operand is created in case of vector shift
with scalar argument.
I am preparing a patch.
Thanks,
Ira
--
--- Comment #19 from dominiq at lps dot ens dot fr 2007-10-31 11:11 ---
Minimal quick and dirty patch (including Tobias' one) that fixes the composite
relational operators:
--- /opt/gcc/_gcc-clean/gcc/fortran/module.c2007-10-28 21:01:20.0
+0100
+++ /opt/gcc/gcc-4.3-work/gcc/
--- Comment #6 from irar at il dot ibm dot com 2007-10-31 11:22 ---
(In reply to comment #2)
> Uh, the VEC_* stuff used there looks like a mess. It's not clear who
> allocates
> and what the size should be.
I'll take a look and fix if necessary.
> For example vect_get_vec_defs_for_s
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-10-31 12:09 ---
I can duplicate this locally. Here's a smaller test case:
template
struct uncvref
{
typedef T type;
};
template
struct args
{
static const int size = sizeof...(Args);
};
template
struct apply_args;
template
s
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-10-31 12:23 ---
This tiny patch should fix the problem. We weren't digging into TYPENAME_TYPEs
deep enough to find all of the parameter packs. The patch fixes both the
original test case and the reduced one. However, I can't test it
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-10-31 12:24 ---
Another, similar testcase. ICEs at -O and above with
Unable to coalesce ssa_names 23 and 15 which are marked as MUST COALESCE.
SR.8_23(ab) and SR.8_15(ab)
t.ii: In function 'int main(int, char**)':
t.ii:36: intern
gfortran rejects the following:
function bug(i) result(c)
integer, pointer :: i
character(len=merge(1,2, associated(p)) :: c
end function bug
Error: Inquiry function 'associated' at (1) is not permitted in an
initialization expression
However according to 7.1.6.2 of ISO/IEC1539-1 there is no
--- Comment #1 from jakub at gcc dot gnu dot org 2007-10-31 12:31 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-10-31 12:33 ---
Subject: Bug 33779
Author: rguenth
Date: Wed Oct 31 12:33:05 2007
New Revision: 129796
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129796
Log:
2007-10-31 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-10-31 12:34 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from irar at il dot ibm dot com 2007-10-31 12:57 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 129627)
+++ tree-vect-transform.c (worki
--- Comment #1 from anlauf at gmx dot de 2007-10-31 12:59 ---
(In reply to comment #0)
> [...]
>
> (and indeed no other compiler I have access to has complained about this.)
As a side note: xlf 9.1 says this is a F2003 feature and not a F95 feature.
--
http://gcc.gnu.org/bugzilla
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-10-31 13:07
---
The memory is temporarily needed now by solve_graph(), because the graph has
48902 nodes. On the mainline we have only 3 constraints while for 4.2 we have
thousands:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTE
--- Comment #7 from jakub at gcc dot gnu dot org 2007-10-31 13:09 ---
The c#4 testcase fails even on x86_64-linux, with
-m64 -Os -fno-omit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-31 13:17 ---
The test case is bogus (missing closing parenthesis and p is not a pointer). I
hope the following is valid:
! { dg-do compile }
function bug(i) result(c)
integer, pointer :: i
character(len=merge(1,2, associated(
--- Comment #8 from bonzini at gnu dot org 2007-10-31 13:21 ---
Reopening and marking as enhancement.
A patch like this should work:
Index: sparseset.c
===
--- sparseset.c (revision 129768)
+++ sparseset.c (working copy)
@
--- Comment #3 from dominiq at lps dot ens dot fr 2007-10-31 13:33 ---
(7) A specification inquiry where each designator or function argument is
(a) a restricted expression or
(b) a variable whose properties inquired about are not
(i) dependent on the upper bound of the last dimensio
--- Comment #20 from burnus at gcc dot gnu dot org 2007-10-31 13:35 ---
Alternative patch (bootstraps/regtests).
I'm not sure how soon I can submit it.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(Revis
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-31 13:41 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unass
--- Comment #18 from spop at gcc dot gnu dot org 2007-10-31 13:53 ---
Subject: Bug 32377
Author: spop
Date: Wed Oct 31 13:53:03 2007
New Revision: 129797
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129797
Log:
2007-10-31 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-op
--- Comment #19 from spop at gcc dot gnu dot org 2007-10-31 13:53 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from tow21 at cam dot ac dot uk 2007-10-31 13:58 ---
(Sorry for mis-typed example, I can't cut & paste from the VM I'm working in
into my web-browser. Your corrected version is what I meant to type)
Well I'm going from the F95 standard (which is the only one I have to han
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-31 14:04
---
(In reply to comment #20)
> Alternative patch (bootstraps/regtests).
I think it's better to go that way: apparently, care has been taken until now
to keep module files alphanumeric, let's keep it that way.
If y
--- Comment #16 from dberlin at gcc dot gnu dot org 2007-10-31 14:22
---
Subject: Re: [4.2 Regression] memory hog in solve_graph
On 31 Oct 2007 13:07:57 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #15 from rguenth at gcc dot gnu dot org 2007
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2007-10-31 14:27
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Oct 31 14:26:57 2007
New Revision: 129798
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129798
Log:
2007-10-31 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from tromey at gcc dot gnu dot org 2007-10-31 14:50 ---
Subject: Bug 30786
Author: tromey
Date: Wed Oct 31 14:50:13 2007
New Revision: 129800
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129800
Log:
gcc/testsuite
PR preprocessor/30786:
* gcc.dg/c
Starting with r129030 tramp3d-v4 segfaults on startup if compiled statically
with -fopenmp. This can be reproduced with the preprocessed testcase from
http://www.suse.de/~rguenther/tramp3d/tramp3d-v4.ii.gz (x86_64) and compiling
with -fopenmp -static (optimization does not change the effect).
Aut
--- Comment #11 from jakub at gcc dot gnu dot org 2007-10-31 14:47 ---
Created an attachment (id=14449)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14449&action=view)
gcc43-pr31507.patch
That's IMHO wrong, you are changing the meaning of < constraint.
This patch is what I'll boo
--- Comment #10 from rask at gcc dot gnu dot org 2007-10-31 14:44 ---
Oops, I'm sorry about stealing your bug, Jakub. I didn't see you had taken it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-31 14:53 ---
gdb doesn't like static code too much but the following is a backtrace of the
crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x88d8a0 (LWP 8358)]
0x in ?? ()
(gdb) b
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-31 14:37 ---
Created an attachment (id=14448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14448&action=view)
patch for testing
This seems to be a simple mismatch between what push_operand() accepts and what
matches the '<'
g++ -v output:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc4.2.0
Thread model: posix
gcc version 4.2.0
using the following compilation flags:
g++ -Wall -Werror -ansi -pedantic -Wno-long-long -pipe -fmessage-length=0
-funit-at-a-time -mac
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-10-31 14:31
---
Subject: Bug 33162
Author: jvdelisle
Date: Wed Oct 31 14:30:48 2007
New Revision: 129799
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129799
Log:
2007-10-31 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from eran dot nissenhaus at mobileye dot com 2007-10-31
14:34 ---
Created an attachment (id=14447)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14447&action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33958
Error also occurs in g++4.3 in 20071026 snapshot. In that snapshot,
the ice occurred on line 6651 which is a gcc_assert preceded by comment:
/* We should never instantiate a nested class before its enclosing
class; we need to look up the nested class by name before we can
instantiate
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 14:59 ---
Which is
static inline int
__gthread_cond_broadcast (__gthread_cond_t *cond)
{
return __gthrw_(pthread_cond_broadcast) (cond);
}
It looks like pthread_cond_broadcast is not correctly bound, as the disassembly
sho
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-31 15:00 ---
> That's IMHO wrong, you are changing the meaning of < constraint.
Yes, I see what you mean, they ('<' and '>') are defined independently of stack
direction. They should however accept PRE_MODIFY and POST_MODIFY.
--
--- Comment #22 from burnus at gcc dot gnu dot org 2007-10-31 15:10 ---
Subject: Bug 33941
Author: burnus
Date: Wed Oct 31 15:10:12 2007
New Revision: 129801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129801
Log:
2007-10-31 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- Comment #23 from burnus at gcc dot gnu dot org 2007-10-31 15:11 ---
> > Alternative patch (bootstraps/regtests).
> I think it's better to go that way: apparently, care has been taken until now
> to keep module files alphanumeric, let's keep it that way.
> If your patch regetests fine
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-31 15:23 ---
The complete statically linked __cxa_guard_release looks like:
005528d0 <__cxa_guard_release>:
5528d0: 53 push %rbx
5528d1: 48 89 fbmov%rdi,%rbx
5
--- Comment #1 from cppljevans at suddenlink dot net 2007-10-31 15:09
---
I was unable to create attachment; so, here's the source (no #includes).
<-- cut here --
//Purpose:
// Reproduce, with simplified code, the error:
/*
main.cpp:1675: instantiated from here
main.cpp:1277: interna
--- Comment #13 from jakub at gcc dot gnu dot org 2007-10-31 15:08 ---
See md.texi:
@cindex @samp{<} in constraint
@item @samp{<}
A memory operand with autodecrement addressing (either predecrement or
postdecrement) is allowed.
And that's for a reason, post_modify here adjusts it by dif
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 15:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-31 15:46 ---
Works for me. Try a newer 4.2.x release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33958
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-10-31 15:48 ---
What happens if you force libpthreads to be all linked in?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from andreast at gcc dot gnu dot org 2007-10-31 15:58
---
Started a test build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #5 from jakub at gcc dot gnu dot org 2007-10-31 15:58 ---
dwarf2out.c needs to handle DECL_BY_REFERENCE PARM_DECLs (and perhaps also
RESULT_DECLs).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from andrew dot stubbs at st dot com 2007-10-31 16:15
---
This bug appears to be no longer present in GCC 4.2.1.
--
andrew dot stubbs at st dot com changed:
What|Removed |Added
---
--- Comment #20 from jakub at gcc dot gnu dot org 2007-10-31 16:31 ---
What I'd try instead is something like:
--- tree-data-ref.c.jj112007-10-28 19:34:10.0 +0100
+++ tree-data-ref.c 2007-10-31 16:22:21.0 +0100
@@ -629,7 +629,7 @@ dr_analyze_innermost (struct
The attached simple sample application crashes if it is with g++ 4.3 at -O1 or
higher.
To make things even odder, it works as expected when built with g++ 4.3 at -O1
or higher with -DDONTCRASH, even though the #ifdef DONTCRASH codepath is never
actually run.
The problem is reproducable on both x8
--- Comment #2 from jakub at gcc dot gnu dot org 2007-10-31 16:52 ---
But should we really print it? What if this while_stmt contains
say megabyte of source? Wouldn't be better to just print
could not convert expression at [locus] to bool?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-31 16:53 ---
This is the new pass by Matz which is causing the issue. So we have a
conditional write which writes to a read only memory.
Though the warning:
vt.cc: In function 'int main(int, char**)':
t.cc:21: warning: deprecat
--- Comment #1 from bero at arklinux dot org 2007-10-31 16:44 ---
Created an attachment (id=14450)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14450&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33961
--- Comment #3 from bero at arklinux dot org 2007-10-31 17:00 ---
That conversion warning is only in the simplified test case, the original code
it's extracted from (khtml) doesn't pass a string constant (it passes html code
retrieved from a web server) and crashes the same way.
There i
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-31 17:03 ---
Reduced testcase:
void decode(char *d, int len);
void decode(char *d, int len) {
int i = len - 1;
while(i >= 0) {
d[i];
if(d[i] == 0)
d[i]=' '
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|rtl-optimization|tree-optimizat
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-10-31 17:07 ---
So what we have is a conditional store but a non conditional read. So the
store can trap but the read does not. Really using a const_cast does nothing
to change the fact you are passing a readonly memory to somethi
--- Comment #6 from tromey at gcc dot gnu dot org 2007-10-31 17:37 ---
This patch makes gcc enter an infinite loop rather than ICEing.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from maksim at kde dot org 2007-10-31 17:45 ---
The usage scenario of the method pretty much precludes it from being used in a
way where read-only memory would have to be written, except if someone does
something silly with the API. Essentially it is called either with out
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-31 17:46 ---
(In reply to comment #2)
> Works for me. Try a newer 4.2.x release.
I wonder if the fix for PR25413 fixed this problem - it went into 4.2 on July
25th, just shortly after 4.2.1 was released :-( but should be in 4.2.2
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-10-31 17:39 ---
It does not reproduce for me on i686-linux, either. Do you pass any special
flags to configure?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #4 from dj at redhat dot com 2007-10-31 18:03 ---
Subject: Re: iv folding fails with pointer iterations
Oops, sorry, I have a local patch. Apparently I'm trying to support
pointer math the same size as pointers (pointers are 24 bits) as an
option for the future, which low
--- Comment #4 from dje at gcc dot gnu dot org 2007-10-31 18:20 ---
If the "nm found only is a wrapper passing through the arguments, the -B
-X32_64, should not cause an error.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-10-31 18:20 ---
I think the middle-end internal sizetype needs to be at least the same size
as pointer types, otherwise you _will_ definitely see wrong-code in some
circumstances.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #7 from bero at arklinux dot org 2007-10-31 17:54 ---
To clarify, the problem in this usage scenario occurs because the test case
crashes even though the code path that writes to the read-only memory is never
actually run (there is no \0 in the string).
if(d[i] == 0) {
c
--- Comment #5 from dougkwan at google dot com 2007-10-31 18:00 ---
Subject: Re: New: [4.3 Regression] r129030 breaks -fopenmp -static compile of
tramp3d-v4
I'm looking at that.
-Doug
31 Oct 2007 14:52:04 -, rguenth at gcc dot gnu dot org
<[EMAIL PROTECTED]>:
> Starting with r129
--- Comment #4 from bero at arklinux dot org 2007-10-31 18:36 ---
Unfortunately I don't remember what I was trying to compile, but I was trying
to compile some open source code I had downloaded. It was running javac on a
huge list of files, one of which was empty (probably to be implemen
--- Comment #6 from dj at redhat dot com 2007-10-31 18:36 ---
Subject: Re: iv folding fails with pointer iterations
Hmmm... pointers are PSImode (24 bits) with --mcpu=m32c. How do you
make sizetype that size? The chip doesn't have enough 24 bit math
opcodes to do all the things gcc
--- Comment #3 from tromey at gcc dot gnu dot org 2007-10-31 18:26 ---
Confirmed.
I would not mind giving an error for this. We don't necessarily have
to be compatible with javac here.
I wonder, though, whether this is used in a configure script or something
like this. How did the re
--- Comment #3 from cppljevans at suddenlink dot net 2007-10-31 18:49
---
When that following main is used instead of the one posted earlier,
the error no longer occurs.
<-- cut here --
int
main(void)
{
typedef gram_tree gt;
gt::productions prods;
#define INST_SEQ
#ifdef
--- Comment #1 from pthaugen at gcc dot gnu dot org 2007-10-31 19:05
---
Looks like the -fpic/PIC/pie/PIE issue was fixed on mainline with the following
patch.
2007-09-04 Daniel Jacobowitz <[EMAIL PROTECTED]>
* config/rs6000/rs6000.c (rs6000_stack_info): Allocate space for t
--- Comment #7 from tromey at gcc dot gnu dot org 2007-10-31 19:12 ---
I'm testing a revised patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Statu
-languages=c,c++ --enable-long-long --enable-checking
--with-gmp=/home/tmp/u/rjpeters/gmp-4.2.1-install
--with-mpfr=/home/tmp/u/rjpeters/mpfr-2.2.1-install
Thread model: posix
gcc version 4.3.0 20071031 (experimental) [trunk revision 129804] (GCC)
$ cat bug.C
template struct A;
template void foo
--- Comment #3 from pcarlini at suse dot de 2007-10-31 19:23 ---
Good point, Jakub. If you have a patch ready to post, please go ahead, don't be
afraid to reassing. Otherwise, will work along the lines you are suggesting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33495
--- Comment #8 from jakub at gcc dot gnu dot org 2007-10-31 19:25 ---
This is valid code and cselim really has to be changed not to introduce writes
to possibly shared or read-only variables that are otherwise never written
into.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33961
--- Comment #4 from pthaugen at gcc dot gnu dot org 2007-10-31 19:48
---
Subject: Bug 28966
Author: pthaugen
Date: Wed Oct 31 19:48:19 2007
New Revision: 129806
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129806
Log:
2007-10-01 Pat Haugen <[EMAIL PROTECTED]>
Backp
--- Comment #7 from pthaugen at gcc dot gnu dot org 2007-10-31 19:48
---
Subject: Bug 29248
Author: pthaugen
Date: Wed Oct 31 19:48:19 2007
New Revision: 129806
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129806
Log:
2007-10-01 Pat Haugen <[EMAIL PROTECTED]>
Backp
--- Comment #1 from crowl at google dot com 2007-10-31 20:08 ---
The wording in the C++ standard working paper is as follows:
8.5 Initializers [dcl.init]
-8- An object whose initializer is an empty set of parentheses, i.e.,
(), shall be value-initialized.
Therefore, in <<< Stats my
Testcase gcc.dg/attr-invalid.c started failing on mingw32 with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125975
In particular, this delta
* tree.c (handle_dll_attribute): Set DECL_VISIBILITY on the
imported or exported declaration, including type declarations.
made these T
I'm not sure if the following should compile or not, but it certainly should
ICE the compiler. Latest gcc from SVN with vararg template patches from Doug
Gregor. Build with -std=c++0x.
Doug, no rush on this one. Just logging it for posterity.
template
struct foo
{
static bool const value = tr
--- Comment #15 from andreast at gcc dot gnu dot org 2007-10-31 21:06
---
=== libffi Summary for unix/-m64 ===
# of expected passes1108
# of unsupported tests 8
=== libffi Summary for unix ===
# of expected passes1105
#
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
In the following SFINAE scenario involving vararg templates an non-type
template parameters, the compiler ICEs instead of ignoring the specialization.
Latest SVN g++ with patches from Doug Gregor for vararg templates.
template
struct foo
{
static bool const value = false;
};
template class T
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-10-31 22:00 ---
Couldn't we use install_name_tool before installing the binary to fix up the
install name?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
--- Comment #8 from dj at redhat dot com 2007-10-31 22:27 ---
Subject: Re: iv folding fails with pointer iterations
Right, that's why I was trying to use 32 bit math instead, which led
to the original iv bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33915
--- Comment #9 from matz at gcc dot gnu dot org 2007-10-31 21:52 ---
Working on it.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassig
1 - 100 of 121 matches
Mail list logo
