--- Comment #2 from christopher dot kormanyos at al-lighting dot com
2008-06-05 08:21 ---
OK now I understand your strategy. Thanks for the explaination.
But there is still a problem in the community. Two very popular compilers (VC
and GCC) which are often used in cross development pro
--- Comment #20 from pmaydell at chiark dot greenend dot org dot uk
2008-06-05 08:31 ---
I wrote:
>The deferred 'unrecognised -Wno*' output should only be a warning, not an
>error.
I suggested a patch that would correct this:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00139.html
--
[forwarded from http://bugs.debian.org/484569]
seen with 4.3.1 20080523, works with 4.2.4. Replacing -O2 with -O1 lets the
build succeed.
Matthias
g++ -Wall -g -O2 -save-temps -pthread greycstoration4gimp.ii
timed out after 150min on various buildds.
--
Summary: [4.3 regression]
--- Comment #2 from ubizjak at gmail dot com 2008-06-05 11:21 ---
Your testcase works for me on i686-pc-linux-gnu with 'GCC: (GNU) 4.4.0 20080605
(experimental) [trunk revision 136389]', with -mmmx and all optimization
levels:
.L5:
movq%mm1, %mm0
psllq
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-05 11:24 ---
In function cimg_library::CImg& cimg_library::CImg::blur_patch(unsigned
int, float, float, unsigned int, bool), which contains some number of loops
from
macro expansion stuff. -fno-tree-pre "fixes" it. phi-translat
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-05 11:37 ---
Created an attachment (id=15722)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15722&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36439
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #3 from ubizjak at gmail dot com 2008-06-05 11:53 ---
The bug triggers on x86_64-pc-linux-gnu target. I will look into it.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-05 12:07
---
Please find below a proposed patch.
The patch will making GCC aware that shift does set the CC already
and the TST is not needed in this case.
The same example could be used to used to make GCC aware of the CC set
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-06-05 12:24 ---
Use -std=c++0x if you want them in the "correct" location. They are only part
of the C++0x standard and not part of C++98/03 standards.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ubizjak at gmail dot com 2008-06-05 12:50 ---
There is a general problem with vector shifts by scalar operands. The code
assumed that both operands are vector mode operands, so it tries to add both
constant shift operands using V1DImode.
Following patch fixes ICE:
I
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
On powerpc-apple-darwin8.5.0 (see
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00340.html) one has:
FAIL: g++.dg/cdce3.C (test for excess errors)
WARNING: g++.dg/cdce3.C compilation failed to produce executable
FAIL: g++.dg/cdce3.C scan-tree-dump cdce "cdce3.C:68: note: function call is
shrink
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-06-05 14:00
---
> Any ideas about this? Do you think it is ok to just apply 1) or should we
> e.g. try to remove unnecessary stack adjustments before _Unwind_Resume
> (though, _Unwind_Resume is a call, so we probably need to gua
gfortran appears to pick up .mod files from default locations in preference to
directories specified by -I arguments on the command line. So, for example, if
foo.mod is in /usr/include and foo.mod is in /home/bar/somedir and the user
types:
gfortran -I/home/bar/somedir ...
then gfortran will pick
--- Comment #2 from ivan at cvut dot cz 2008-06-05 14:35 ---
This bug is related to x86_64 target. When generating 32bit .o file,
compilations succeds even with 64bit version of g++.
See:
[EMAIL PROTECTED]:/tmp$ g++ -m32 trotl_parser.i
In file included from /usr/include/c++/4.2/ext/new
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-06-05 14:40
---
I have a working backport for 4.3.2 that get's memory usage down.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
--- Comment #1 from David at ham dot dropbear dot id dot au 2008-06-05
14:48 ---
Apologies, this appears to have been caused by idiocy on our part. We now
believe gfortran does the right thing and includes -I first.
--
David at ham dot dropbear dot id dot au changed:
Wha
--- Comment #5 from ubizjak at gmail dot com 2008-06-05 17:05 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00268.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #6 from davidxl at gcc dot gnu dot org 2008-06-05 17:37 ---
(In reply to comment #5)
> Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00268.html
>
Thanks -- same as my local workaround.
David
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36438
--- Comment #2 from pault at gcc dot gnu dot org 2008-06-05 19:45 ---
> At the moment, I cannot see what draws these together. Nor can I see any
> difference in the .mod files for the cases that work
Ah... go it! gcc-4.2 had a derived type list for each namespace and care was
take
I'm using both --with-build-sysroot and --with-sysroot when I compile GCC, so
that I can compile it against a different version of the local system than the
one I'm compiling on. Most of the build works fine, with the exception of the
libraries libgomp, libmudflap, and libssp.
Each of those fails
When --disable-bootstrap, HOST_CC is set to gcc. It is
used in
g++.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]
gcc.dg/compat/struct-layout-1.exp:set status [remote_exec host "$HOSTCC
$HOSTCFLAGS $generator_cmd"]
objc.dg/gnu-encoding/gnu-encoding
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 21:32 ---
--disable-bootstrap should not be used really, why are you using it anyways?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
Testcase:
#define vector __attribute__((vector_size(16) ))
struct struct1 {
union {}vmx;
struct struct2 {
struct2(const struct2& r) {}
} w;
} __attribute__((aligned(16)));
struct struct3 {
vector float vmx;
operator const struct1& () const{
return *reinterpret_cast(this);
--- Comment #2 from hjl dot tools at gmail dot com 2008-06-05 21:34 ---
(In reply to comment #1)
> --disable-bootstrap should not be used really, why are you using it anyways?
>
There is no easy way to debug gcc compiled with -O2.
Why do we put
set GCC_EXEC_PREFIX "$(libdir)/gcc/"
i
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
Another fallout due to the using VCE more patch:
#define vector __attribute__((vector_size(16) ))
struct struct1 {
union { float a[3]; }vmx;
struct struct2 {
struct2(const struct2& r) {}
} w;
} __attribute__((aligned(16)));
struct struct3 {
vector float vmx;
operator const str
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36445
On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
> There is no easy way to debug gcc compiled with -O2.
You know if you compile cc1 manually inside the gcc directory, it will
compile with -O0 -g. Also you can use stage1-gcc directory to debug
and build cc1
--- Comment #3 from pinskia at gmail dot com 2008-06-05 21:42 ---
Subject: Re: HOST_CC doesn't work with --disable-bootstrap
On Thu, Jun 5, 2008 at 2:34 PM, hjl dot tools at gmail dot com
<[EMAIL PROTECTED]> wrote:
> There is no easy way to debug gcc compiled with -O2.
You know if you
--- Comment #4 from hjl dot tools at gmail dot com 2008-06-05 21:58 ---
This behavior was introduced by
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01493.html
I rarely install gcc on my build machines. I am not
sure why they are needed f
/*
gcc -W -c test.c
test.c:18: warning: (near initialization for m1.h.b)
*/
struct h {
int a;
int b;
};
struct m {
struct h h;
int c;
};
struct m m1 = {
.h.a = 1,
.c = 2,
};
struct m m2 = {
.h = {.a = 1},
.c = 2,
};
m1 has t
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 21:59 ---
Also seen on the trunk (4.4.0).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-05 22:01 ---
On the trunk we get:
t.c:13: warning: missing initializer
t.c:13: warning: (near initialization for m1.h.b)
Which seems wrong as we don't get the warning for m2 and if we add an
initializer for m1.h.b we get a dif
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-05 22:56 ---
Fix for at least PowerPC (we should be trying to get the correct sized vector
mode):
Index: expmed.c
===
--- expmed.c(revision 2510)
+++ expmed.c
--- Comment #7 from sje at cup dot hp dot com 2008-06-05 23:02 ---
I now think this is a register scheduling bug. If I use -fno-schedule-insns2
then the bug doesn't happen even with "-O2 fno-automatic -frename-registers".
The problem seems to be scheduling the assignment to TEMP2 and a
--- Comment #7 from r_q_einstein-gccgnuorg at yahoo dot com 2008-06-05
23:07 ---
I've run across this, too.
I agree with Ivan's 2005-06-04 suggestion.
It would be nice if the compiler would emit a warning that the derived class's
constructor's call to the virtual base class's non-defaul
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-05 23:13 ---
And the fix for the second issue:
Index: expr.c
===
--- expr.c (revision 2510)
+++ expr.c (working copy)
@@ -7654,6 +7654,16 @@ expand_expr_re
--- Comment #11 from joel at gcc dot gnu dot org 2008-06-05 23:32 ---
Created an attachment (id=15723)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15723&action=view)
updated patch
Updated to account for changes to s-osinte-vxworks.adb while this PR has
lingered in the queue.
-
--- Comment #12 from joel at gcc dot gnu dot org 2008-06-05 23:34 ---
s-osinte-vxworks.adb is not removed by the patch. For review purposes, you
should diff s-osinte-vxworks.adb to s-osinte-hwint.adb to see what the changes
were.
2008-05-28 Joel Sherrill <[EMAIL PROTECTED]>
*
Works on avr-gcc (GCC) 4.2.2 (WinAVR 20071221). Does not on 4.4 HEAD.
Test results posts show this test failing since AT LEAST SVN rev 132993 on AVR
(March 3 2008) (before that test was not run - so dont know when it started.
gcc-c/toture/unsorted/shm.c
foo (int *p)
{
int a = *p;
return a
--- Comment #1 from hutchinsonandy at aim dot com 2008-06-06 03:08 ---
rev 132971 appears to have created this problem.
Revision: 132971
Author: bonzini
Date: 8:30:10 AM, Thursday, March 06, 2008
Message:
2008-03-06 Paolo Bonzini <[EMAIL PROTECTED]>
* simplify-rtx.c (simplif
43 matches
Mail list logo
