--- Comment #4 from joaquin at tid dot es 2010-07-01 06:56 ---
Hi Paolo, I sent a message to the reflector, answer was that
currently there's no DR or any other type of issue regarding
this that the LWG is aware of, so they have no official stance
on the matter :-/
I don't know what oth
--- Comment #1 from burnus at gcc dot gnu dot org 2010-07-01 06:21 ---
Confirm.
Valgrind shows:
==11328== Invalid read of size 8
==11328==at 0x6CBB86: fold_convert_loc (fold-const.c:1856)
==11328==by 0x58E7A3: allocate_temp_for_forall_nest_1 (trans-stmt.c:2583)
==11328==by
--- Comment #9 from jd at cococo dot de 2010-07-01 05:37 ---
Ok, but in terms of semantics there is only one way of interpreting the
sentence
nr <= left->rows > right->rows ? left->rows : right->rows
because we have to differ between conditions yielding truth values and
expressions y
--- Comment #1 from pinskia at gmail dot com 2010-07-01 05:04 ---
Subject: Re: New: Complex division with NaN produces unexpected result
I think the issue is we don't implement imagainy types so 1 + nan I
turns into nan.
On Jun 30, 2010, at 9:51 PM, "ian at airs dot com" wrote:
>
I think the issue is we don't implement imagainy types so 1 + nan I
turns into nan.
On Jun 30, 2010, at 9:51 PM, "ian at airs dot com" > wrote:
Annex G of the ISO C99 standard says that a complex value with one
part being
infinity is considered an infinity, even if the other part is a
NaN
Annex G of the ISO C99 standard says that a complex value with one part being
infinity is considered an infinity, even if the other part is a NaN. It's not
clearly stated, but presumably if neither part of the number is an infinity,
but one part is a NaN, then the number is a NaN. And presumably
On Linux/ia64, revision 161653 gave:
../../../src-trunk/libgcc/../gcc/config/ia64/unwind-ia64.c: In function
\u2018uw_update_reg_address\u2019:
../../../src-trunk/libgcc/../gcc/config/ia64/unwind-ia64.c:1932:4: warning:
cast discards qualifiers from pointer target type [-Wcast-qual]
../../../src-t
--- Comment #1 from astrange at ithinksw dot com 2010-07-01 03:43 ---
The problem is combine.
This:
int test2( int *b )
{
int b_ = *b;
b_--;
if( b_ == 0 ) {
*b = b_;
return foo();
}
*b = b_;
return 0;
}
works:
_test2:
LFB1:
movl(
-4.6.0-1000/gcc-4.6-20100630/gcc/testsuite/c-c++-common/uninit-17.c
-Wc++-compat -O2 -Wuninitialized -S -o uninit-17.s(timeout = 300)
/sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100630/gcc/testsuite/c-c++-common/uninit-17.c:
In function 'foobar':
/sw/src/fink.build/gcc46-4.6.0-10
On Linux/ia64, revision 161592 gave:
FAIL: 25_algorithms/shuffle/1.cc (test for excess errors)
Revision 161570 is OK.
--
Summary: [4.6 Regression] 25_algorithms/shuffle/1.cc
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
On Linux/x86-64, c-c++-common/uninit-17.c with -m32:
FAIL: c-c++-common/uninit-17.c (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for warnings, line 14)
FAIL: c-c++-common/uninit-17.c -Wc++-compat (test for excess errors)
FAIL: c-c++-common/uninit-17.c (test
--- Comment #15 from changpeng dot fang at amd dot com 2010-07-01 00:34
---
Unrolling of the peeled loop is partially the reason for test_fpu.f90
compilation
time and code size increase. Vectorization peeled a few iteration of the the
loop, the prefetching and unrolling passes does not
--- Comment #2 from opensource3141 at gmail dot com 2010-07-01 00:32
---
Thanks for the lightening fast response. I wouldn't have known to look there,
especially since older GCC versions did not have this problem.
Is it because 4.5.0 has better optimizations such that the code surroun
--- Comment #8 from hjl dot tools at gmail dot com 2010-07-01 00:09 ---
Created an attachment (id=21051)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21051&action=view)
A patch
Here is the a patch. We need
rtx_equal_p (operands[0], operands[3])
Otherwise, I got
FAIL: gcc.targe
--- Comment #14 from rearnsha at gcc dot gnu dot org 2010-06-30 23:55
---
Created an attachment (id=21050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21050&action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.gnu.org/bu
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-06-30 23:52
---
Created an attachment (id=21049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21049&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44737
I came across the attached ICE while trying to reduce a different problem (but
using the wrong test for a build failure).
Crash happens with all optimization levels (and none).
--
Summary: ICE in instantiate_decl
Product: gcc
Version: 4.6.0
Status: U
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-06-30 23:43
---
Created an attachment (id=21048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21048&action=view)
testcase for introduced regression
compiler options in first line of testcase.
--
http://gcc.gnu.org/bu
--- Comment #12 from rearnsha at gcc dot gnu dot org 2010-06-30 23:42
---
(In reply to comment #9)
> Subject: Bug 44694
>
> Author: jakub
> Date: Wed Jun 30 06:12:22 2010
> New Revision: 161587
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161587
> Log:
> PR debug/
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-30 23:42 ---
Stupid glibc extensions.
__malloc_hook and __free_hook are not part of standard C90/C99.
-fno-builtin-malloc will disable this optimization. Basically malloc cannot
touch global memory as far as the compiler kn
--- Comment #7 from matt at use dot net 2010-06-30 23:36 ---
Will this be backported to 4.4 and/or 4.5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
I have found what appears to be a pretty serious issue with the new
optimization algorithms in GCC 4.5.0. The following code (with appropriate
comments inline) demonstrate the problem. Based on a quick search, I don't
think this bug has been reported yet. Note that I have assigned the component
--- Comment #9 from hubicka at gcc dot gnu dot org 2010-06-30 22:30 ---
Subject: Bug 44357
Author: hubicka
Date: Wed Jun 30 22:30:12 2010
New Revision: 161646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161646
Log:
Backport from mainline
2010-06-27 Jan Hubi
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-06-30 22:30 ---
Subject: Bug 44686
Author: hubicka
Date: Wed Jun 30 22:30:12 2010
New Revision: 161646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161646
Log:
Backport from mainline
2010-06-27 Jan Hubi
--- Comment #10 from hubicka at gcc dot gnu dot org 2010-06-30 22:30
---
Subject: Bug 44671
Author: hubicka
Date: Wed Jun 30 22:30:12 2010
New Revision: 161646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161646
Log:
Backport from mainline
2010-06-27 Jan Hu
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-30 22:28 ---
conversion from derived* to vbase* involves adjusting a pointer
in the context of vbase::set_p the value returned from me() is converted to
vbase* so the pointer is adjusted
try changing derived::me() to this:
int
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-30 22:18 ---
(In reply to comment #6)
> Ok, thanks for investigating. I think we may need something like this:
>
> @@ -17574,6 +17574,7 @@ (define_peephole2
> || GET_MODE (operands[0]) == HImode))
> || GET_M
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-30 22:08 ---
Ok, thanks for investigating. I think we may need something like this:
@@ -17574,6 +17574,7 @@ (define_peephole2
|| GET_MODE (operands[0]) == HImode))
|| GET_MODE (operands[0]) == SImode
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-30 22:07
---
Fixed for 4.5.1 and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo at gcc dot gnu dot org 2010-06-30 22:06 ---
Subject: Bug 44628
Author: paolo
Date: Wed Jun 30 22:06:28 2010
New Revision: 161645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161645
Log:
/cp
2010-06-30 Paolo Carlini
PR c++/44628
* t
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-30 21:53 ---
Function get_attribute is miscompiled. The difference is
--
--- /tmp/good.s 2010-06-30 14:36:46.971155015 -0700
+++ /tmp/bad.s 2010-06-30 14:38:49.211031644 -0700
@@ -3966,18 +3966,18 @@ get_attribute:
jne
--- Comment #4 from bernds at gcc dot gnu dot org 2010-06-30 21:52 ---
I can reproduce this. I haven't found the problem, but it seems to go away if
I remove m_ATOM from X86_TUNE_OPT_AGU. Is it possible that there's a bug
related to this in i386.*?
--
http://gcc.gnu.org/bugzilla/s
$ cat bug3.f90
subroutine bug
character(len=10) :: F_string
character(len=1), dimension(:), pointer :: p_chars
forall (i=1:len(F_string))
F_string(i:i) = p_chars(i)
end forall
end subroutine bug
$ /usr/local/gfortran/bin/gfortran -c bug3.f90
bug3.f90: In function bug:
bug3.f90:1:0: i
--- Comment #4 from raj dot khem at gmail dot com 2010-06-30 21:33 ---
just in case here is how the compiler was configured
Using built-in specs.
COLLECT_GCC=mips-oe-linux-uclibc-gcc
COLLECT_LTO_WRAPPER=/scratch/oe/cross/mips/libexec/gcc/mips-oe-linux-uclibc/4.5.1/lto-wrapper
Target: mi
--- Comment #3 from raj dot khem at gmail dot com 2010-06-30 21:31 ---
gcc_assert ((!both_p && !fallback_p)
4a7c: 1684bnezs4,4a90
4a80: 02002021move a0,s0
--- Comment #2 from raj dot khem at gmail dot com 2010-06-30 21:24 ---
Created an attachment (id=21047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21047&action=view)
preprocessed c-common.c
to compile use
mips-oe-linux-uclibc-gcc -march=mips32 -O c-common.i -S
--
http://g
--- Comment #1 from raj dot khem at gmail dot com 2010-06-30 21:22 ---
Created an attachment (id=21046)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21046&action=view)
objdump intermixed with source for the function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44734
There seems to be wrong code generated when cross-gcc (x86_64->mips) is used to
compile gcc for mips target.
Program received signal SIGSEGV, Segmentation fault.
0x004940ac in def_builtin_1 (fncode=BUILT_IN_HUGE_VAL, name=,
fnclass=BUILT_IN_NORMAL, fntype=, libtype=0x0,
both_p=0 '\000',
Compiling and executing this code:
-
#include
using namespace std;
void *p;
struct vbase
{
int a;
virtual vbase* me() = 0;
void set_p() { p = me(); };
};
struct derived : virtual vbase
{
int b;
derived* me()
{
cout << "derived::me() = " << this <<
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-30 21:10 ---
-mtune=atom works with 32bit build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-30 21:02 ---
jcf-parse.o is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
--- Comment #3 from paolo at gcc dot gnu dot org 2010-06-30 20:47 ---
Subject: Bug 44628
Author: paolo
Date: Wed Jun 30 20:46:46 2010
New Revision: 161639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161639
Log:
/cp
2010-06-30 Paolo Carlini
PR c++/44628
* t
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-30 20:31 ---
r161633, 4.1 host compiler.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Targe
During stage1:
gcc -c -DUSE_LIBUNWIND_EXCEPTIONS -g -fkeep-inline-functions -DIN_GCC -W
-Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-30 19:35 ---
Bison test expects:
[...@gnu-6 081]$ gcc -c input.c
input.y:8:2: error: #error "8"
But gcc 4.5 and above generate:
[...@gnu-6 081]$ /usr/gcc-4.5/bin/gcc -c input.c
input.y: In function yyparse:
input.y:8:2: erro
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-30 19:26 ---
-mtune=atom miscompiled gcj.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-06-30 19:08 ---
Patch committed to mainline.
AFAIK the only lingering issue is this one:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03046.html
(And of course the stuff that needs some help from the FSF - PR44035, PR44033,
PR4403
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-06-30 18:48 ---
Subject: Bug 44566
Author: amylaar
Date: Wed Jun 30 18:47:43 2010
New Revision: 161633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161633
Log:
PR other/44566
* coretypes.h [!USED_FOR_TARGE
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-30 18:46 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03173.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-30 18:43
---
Thanks Jason, I'll add the testcase, regtest again and post before committing.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-30 18:39 ---
Subject: Bug 44726
Author: rguenth
Date: Wed Jun 30 18:38:37 2010
New Revision: 161631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161631
Log:
2010-06-30 Sebastian Pop
PR bootstrrap/44726
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-30 18:38 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jason at gcc dot gnu dot org 2010-06-30 18:28 ---
*** This bug has been marked as a duplicate of 44039 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from jason at gcc dot gnu dot org 2010-06-30 18:28 ---
*** Bug 44040 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
--- Comment #8 from jason at gcc dot gnu dot org 2010-06-30 18:27 ---
That patch is OK, it's reasonable for lookup_fnfields to return NULL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44039
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-30 18:15 ---
Created an attachment (id=21045)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21045&action=view)
A patch
Using
(set (match_operand:HI "register_operand" "=a")
(ior:HI (ashift:HI
(zero_extend:HI (
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-30 17:10 ---
(In reply to comment #7)
> Sorry, I was not precise enough. Delphi is the IDE for both, Pascal and C, and
> what I meant by the word are the language(s) Borland C and C++. They have an
> option for Standard C. Maybe I m
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-30 17:09
---
I have a patch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-30 16:54 ---
Testcases are fixed. And according to
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03137.html
we can probably also assume the bootstrap fail is fixed.
--
matz at gcc dot gnu dot org changed:
What|R
--- Comment #7 from jd at cococo dot de 2010-06-30 16:47 ---
Sorry, I was not precise enough. Delphi is the IDE for both, Pascal and C, and
what I meant by the word are the language(s) Borland C and C++. They have an
option for Standard C. Maybe I misunderstood it ...
--
http://gcc
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:41 ---
Subject: Bug 44034
Author: iains
Date: Wed Jun 30 14:33:40 2010
New Revision: 161606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161606
Log:
PR other/44034
* config/darwin.c (darwin_overri
--- Comment #16 from matz at gcc dot gnu dot org 2010-06-30 16:34 ---
Subject: Bug 44699
Author: matz
Date: Wed Jun 30 16:34:22 2010
New Revision: 161614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161614
Log:
PR bootstrap/44699
* tree-vrp.c (vrp_finalize): De
Source file (no preprocessing required): (note, I made it C-compatible so I
could see if the bug is present in the C compiler as well, the answer being no,
for reasons that will become obvious immediately)
struct st{
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-30 16:19 ---
*** This bug has been marked as a duplicate of 44726 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-30 16:19 ---
*** Bug 44730 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:16 ---
This is a duplicate of pr44726.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-30 16:15 ---
This makes it to compile:
--
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index b73517d..c3890ec 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -1779,10 +1779
--- Comment #1 from spop at gcc dot gnu dot org 2010-06-30 16:11 ---
Mine.
Let's transform this code:
base_alias_pair *bap;
if (dr->aux)
bap = (base_alias_pair *)(dr->aux);
into:
base_alias_pair *bap;
gcc_assert (dr->aux);
bap = (base_alias_pair
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
On Linux/x86-64, revision 161606 gave:
../../src-trunk/gcc/graphite-sese-to-poly.c: In function
'build_scop_drs.isra.110':
../../src-trunk/gcc/graphite-sese-to-poly.c:1784:15: error:
'dr_base_object_set' may be used uninitialized in this function
[-Werror=uninitialized]
../../src-trunk/gcc/graphit
On Linux/x86, gcc 4.5/4.6 failed one bison 2.4.2 test:
81: Action synch line FAILED (synclines.at:144)
Gcc 4.4 is OK.
--
Summary: [4.5/4.6 regression] One bison 2.4.2 test failed
Product: gcc
Version: 4.5.1
Status: UNC
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-30 15:54 ---
Created an attachment (id=21044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21044&action=view)
Another testcase.
I believe I ran into this bug when trying WHOPR bootstrap at -O3 (on
x86_64-linux). I narrow
When trying to specify a directory that contains a "." for gcov to look in for
output files, gcov does not act as expected.
Example:
/home/test$ gcc-4.3 main.c -fprofile-arcs -ftest-coverage
/home/test$ ./a.out
/home/test$ gcov-4.3 -o/home/test/ main
/home/test$ mkdir 1.1; cp main.c 1.1; cd 1.1
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44727
On Linux/x86-64, revision 161604 failed to bootstrap with
--with-cpu=atom. I got
Premature end of .class file
../../../../src-trunk/libjava/classpath/lib/java/lang/AbstractStringBuffer.class.
Revision 161569 is OK. It could be related to peephole change.
--
Summary: [4.6 Regression
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-30 15:41 ---
Subject: Bug 44694
Author: jakub
Date: Wed Jun 30 15:40:53 2010
New Revision: 161610
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161610
Log:
Backport from mainline
2010-06-30 Jakub Jelinek
At revision 161606, bootstrap fails with:
...
/opt/gcc/build_w/./prev-gcc/xgcc -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/bin/
-B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.4.0/lib/ -isystem
/opt/gcc/gcc4.6w/x86_64-appl
--- Comment #24 from jakub at gcc dot gnu dot org 2010-06-30 15:34 ---
Subject: Bug 43866
Author: jakub
Date: Wed Jun 30 15:34:09 2010
New Revision: 161609
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161609
Log:
Backport from mainline
2010-06-25 Jakub Jelinek
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-30 15:30 ---
Cf. also http://fortranwiki.org/fortran/show/c_interface_module (long example).
Check that the fix also works with, e.g., IMPORT. (It should!)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44702
in the following example, gcc should report it is using a C++0x extension:
struct ValueInt
{
ValueInt(int v = 0) : ValueLength(v) {}
operator int () const { return ValueLength; }
private:
int ValueLength;
};
int main(int, char *[])
{
int *a = new int[ ValueInt(10) ];
return 0;
}
According
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-30 15:23 ---
Subject: Bug 42278
Author: jakub
Date: Wed Jun 30 15:23:13 2010
New Revision: 161608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161608
Log:
Backport from mainline
2010-05-12 Jakub Jelinek
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-30 15:17 ---
Subject: Bug 44059
Author: jakub
Date: Wed Jun 30 15:16:54 2010
New Revision: 161607
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161607
Log:
Backport from mainline
2010-05-11 Jakub Jelinek
--- Comment #7 from iains at gcc dot gnu dot org 2010-06-30 14:34 ---
Subject: Bug 44034
Author: iains
Date: Wed Jun 30 14:33:40 2010
New Revision: 161606
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161606
Log:
PR other/44034
* config/darwin.c (darwin_overrid
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-30 14:17 ---
Subject: Bug 39799
Author: bernds
Date: Wed Jun 30 14:16:28 2010
New Revision: 161605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161605
Log:
PR tree-optimization/39799
* tree-inline.c (rem
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-30 14:15 ---
(In reply to comment #5)
> Which is the standard C operator precedence?
You can find that for yourself on the web e.g.
http://en.wikipedia.org/wiki/Operator_precedence_in_C
GCC uses the standard precedence.
> It shou
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-30 14:13
---
Created an attachment (id=21043)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21043&action=view)
additional patch
You need the following additional patch. With that the testcase should pass.
--
http:/
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-06-30
14:06 ---
Subject: Re: FAIL: gcc.dg/ipa/ipa-pta-10.c scan-ipa-dump pta "ESCAPED = { }"
> Can you, instead of
>
> /* Copied from va-pa.h, but we probably don't need to align to
> word size, since we g
--- Comment #5 from jd at cococo dot de 2010-06-30 13:43 ---
Which is the standard C operator precedence? It should not depend on the
dialect. Is there a pragma for it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44681
--- Comment #10 from jamborm at gcc dot gnu dot org 2010-06-30 13:27
---
Subject: Bug 43905
Author: jamborm
Date: Wed Jun 30 13:26:17 2010
New Revision: 161604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161604
Log:
2010-06-30 Martin Jambor
PR tree-optimization/4
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-30 12:59 ---
On the link command-line add -r -nostdlib and start removing as many objects
and libraries from the command-line as possible (preserving the crash of
course).
If static libraries remain, open them up and add/remove i
--- Comment #1 from moonshine at kapsi dot fi 2010-06-30 12:27 ---
(In reply to comment #0)
I forgot to add that I configured VICE with a following command:
CFLAGS='-flto -fuse-linker-plugin -O3 -fomit-frame-pointer -march=pentium4'
CXXFLAGS='-O3 -fomit-frame-pointer -funroll-loops -ma
VICE Commodore emulator lto-build fails with a segfault in lto1. The code has
both C and C++ source files so it is linked with g++. As compilation fails
during lto, it is difficult to produce a self-contained testcase, but you
should be able to reproduce the fault by downloading and building VICE
h
--- Comment #12 from ncopa at alpinelinux dot org 2010-06-30 11:52 ---
whats the status on this bug? It still happens on gcc-4.4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32219
--- Comment #5 from bonzini at gnu dot org 2010-06-30 11:51 ---
I agree that the problem is a wrong pattern.
Here you have non-matching mode between the udiv/umod and the first argument:
> (ior:HI (ashift:HI (zero_extend:HI (umod:QI (reg:HI 68)
> (reg:QI 61 [ D.2750 ]))
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-30 11:10 ---
Subject: Bug 44722
Author: rguenth
Date: Wed Jun 30 11:09:37 2010
New Revision: 161597
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161597
Log:
2010-06-30 Richard Guenther
PR target/44722
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-30 11:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from redi at gcc dot gnu dot org 2010-06-30 11:08 ---
(In reply to comment #7)
> > > I tried putting them in the gcc-4.5.0 directory and I tried installing
> > > them
> > > from my distro, but neither of these worked to fix the error.
> >
> > You need to rename them to j
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-30 10:57 ---
Delphi and C have different operator precedence
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jbare7 at gmail dot com 2010-06-30 10:36 ---
> > I tried putting them in the gcc-4.5.0 directory and I tried installing them
> > from my distro, but neither of these worked to fix the error.
>
> You need to rename them to just "gmp" instead of "gmp-4.3.2" etc.
I tr
1 - 100 of 123 matches
Mail list logo
