--- Comment #6 from rschiele at gmail dot com 2007-01-14 08:03 ---
Agreed, but why shouldn't we change the special handling of the default specs
file as suggested in comment #4? I can't see why we should enforce people to
specify _full_ information in the default specs file if they only
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-01-14 11:01 ---
Subject: Bug 30452
Author: tkoenig
Date: Sun Jan 14 11:01:20 2007
New Revision: 120768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120768
Log:
2007-01-14 Thomas Koenig <[EMAIL PROTECTED]>
PR fo
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 11:05 ---
(In reply to comment #3)
> Subject: Bug 24783
>
> Author: aldot
> Date: Mon Nov 20 16:20:33 2006
> New Revision: 119016
Bernhard,
Are you going to apply this to 4.2, or do you want me to do it? It would be
nice to
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 11:13 ---
Why Wall is not in common.opt ? As far as I know, that would be the right fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
--- Comment #4 from uros at gcc dot gnu dot org 2007-01-14 11:14 ---
Subject: Bug 30413
Author: uros
Date: Sun Jan 14 11:14:20 2007
New Revision: 120769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120769
Log:
PR target/30413
* config/i386/i386.c (print_operand
--- Comment #10 from pault at gcc dot gnu dot org 2007-01-14 11:19 ---
(In reply to comment #9)
> It turns out my fix caused PR 29951 which I am testing a fix for PR 29951
> now.
> My new patch does not break this testcase which is a good sign.
>
Andrew,
Were you going to apply this
--- Comment #5 from ubizjak at gmail dot com 2007-01-14 11:32 ---
Although %zN is not documented, we advertise it in config/i386/i386.md:
;; The special asm out single letter directives following a '%' are:
;; 'z' mov%z1 would be movl, movw, or movb depending on the mode of
;; opera
--- Comment #5 from aldot at gcc dot gnu dot org 2007-01-14 11:37 ---
> Bernhard,
>
> Are you going to apply this to 4.2, or do you want me to do it? It would be
> nice to clear the PR.
Please feel free to backport this and (eventually) all other i left unfixed for
non-trunk versions
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-14 11:42 ---
(In reply to comment #6)
> Fixed on trunk, as per commit in #4.
>
Brooks,
Are you going to commit this to 4.2 so that we can clear it?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235
--- Comment #9 from pault at gcc dot gnu dot org 2007-01-14 11:45 ---
(In reply to comment #7)
> Fixed in 4.3; I will commit the patch for 4.2 in about a week; I will not fix
> 4.1.
>
Tobias,
Are you in a position to do that now? The week is up and all is well:)
Paul
--
http://g
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 13:32 ---
I do not seem able to fix the problem with attachments on my machine...
Following yesterday's discussion on the list,
trans-common.c:445
switch (e->ts.type)
{
case BT_INTEGER:
if (WORDS_BIG_ENDIA
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 13:42 ---
Forget the previous; it's wrong!
It does indicate that WORDS_BIG_ENDIAN and friends are available, however.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
--- Comment #7 from rschiele at gmail dot com 2007-01-14 13:52 ---
Created an attachment (id=12904)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12904&action=view)
new version of the fix
This implements my new suggestion on how to fix this. Any comments?
--
rschiele at gmail
--- Comment #7 from andersin at freenet dot de 2007-01-14 14:28 ---
Your are correct, I have C_INCLUDE_PATH set (sorry I forgot to mention it). I
did not think it important, but it is. If C_INCLUDE_PATH ends with a colon,
compilation fails. Removing the colon is not a problem in general,
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 14:43 ---
Subject: Bug 30410
Author: pault
Date: Sun Jan 14 14:43:08 2007
New Revision: 120771
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120771
Log:
2007-01-14 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #10 from pault at gcc dot gnu dot org 2007-01-14 14:50 ---
Subject: Bug 23232
Author: pault
Date: Sun Jan 14 14:49:50 2007
New Revision: 120772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772
Log:
2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]>
Paul
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:50 ---
Subject: Bug 30410
Author: pault
Date: Sun Jan 14 14:49:50 2007
New Revision: 120772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772
Log:
2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]>
Paul T
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:50 ---
Subject: Bug 27998
Author: pault
Date: Sun Jan 14 14:49:50 2007
New Revision: 120772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772
Log:
2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]>
Paul T
--- Comment #7 from pault at gcc dot gnu dot org 2007-01-14 14:50 ---
Subject: Bug 30408
Author: pault
Date: Sun Jan 14 14:49:50 2007
New Revision: 120772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772
Log:
2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]>
Paul T
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-14 14:50 ---
Subject: Bug 27996
Author: pault
Date: Sun Jan 14 14:49:50 2007
New Revision: 120772
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120772
Log:
2007-01-14 Jerry DeLisle <[EMAIL PROTECTED]>
Paul T
--- Comment #11 from pault at gcc dot gnu dot org 2007-01-14 14:51 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-14 14:52 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 14:53 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-01-14 14:55 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-01-14 15:06
---
Can it be the patch changes result of alias analysis? I get (big) runtime
differences (but maybe due to unrelated changes) with the tester from Jan 13
(patched) vs. Jan 14 (unpatched).
--
http://gcc.gnu.org/b
--- Comment #3 from danglin at gcc dot gnu dot org 2007-01-14 15:20 ---
Yes, this is fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-01-14 16:12 ---
This is now fixed for tramp3d.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from danglin at gcc dot gnu dot org 2007-01-14 17:25 ---
Subject: Bug 24107
Author: danglin
Date: Sun Jan 14 17:25:05 2007
New Revision: 120776
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120776
Log:
PR testsuite/24107
Backport from mainline
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-01-14 18:21 ---
"a:" means have a and the current directory.
So this is not a bug, C_INCLUDE_PATH acts just like PATH in that an empty
argument after the colon means the current directory.
>export C_INCLUDE_PATH=/home/cbs/local/in
As no one call call the class methods of Objc directly, they should be marked
as hidden so that they bind locally in a shared library.
--
Summary: Class methods should be marked as hidden
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30461
The libobjc public headers should be wrapped with #pragam visibilitity
push(defualt)/pop so that people (and libobjc) can use -fvisibility=hidden.
--
Summary: libobjc public headers should be wrapped with #pragam
visibilitity push(defualt)/pop
Product:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-14 19:10 ---
Mine, working on it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Assign
Consider the following program:
#include
void f() {
std::vector v;
v.push_back(1);
}
-Wconversion now (as of 2007-01-14) triggers the following warning in
the libstdc++ headers:
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:
In d
Consider the following program:
#include
void f() {
std::deque d;
d.push_back(1);
}
-Wconversion now (as of 2007-01-14) triggers the following warning in
the libstdc++ headers:
/suse/gp/gcc-i686/lib/gcc/i686-suse-linux/4.3.0/../../../../include/c++/4.3.0/bits/deque.tcc:
In membe
paolo:~/Work> more warning.cc
int main()
{
wchar_t wc = ((wchar_t)1 << 31) - 1;
}
paolo:~/Work> g++ warning.cc
warning.cc: In function 'int main()':
warning.cc:3: warning: integer overflow in expression
warning.cc:3: warning: overflow in implicit constant conversion
--
Summary: Dupli
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-14 21:41 ---
This is indeed fixed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from manu at gcc dot gnu dot org 2007-01-14 23:03 ---
Gerald,
One thing is whether the warning was incorrect or not. Looking at the code and
the definition of Wconversion, what do you think?
Another thing is whether we want or not to emit warnings for libstdc++. I don't
--- Comment #2 from pcarlini at suse dot de 2007-01-14 23:08 ---
(In reply to comment #1)
> ...So I guess this is not a system header.
In fact, it *is* a system header :-( See my message to gcc@
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-14 23:15 ---
So I cannot understand why are we warning. Warnings in system headers should
only be emitted when using -Wsystem-headers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30464
--- Comment #4 from pcarlini at suse dot de 2007-01-14 23:22 ---
(In reply to comment #3)
> So I cannot understand why are we warning. Warnings in system headers should
> only be emitted when using -Wsystem-headers.
Did you read my reply? Again: the system_header pragma does *not* work
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-14 23:37 ---
Sorry I read your reply later.
So, that is it, isn't it? Wsystem-headers needs to be fixed since we don't want
to emit warnings for system headers even if those warnings are correct.
--
http://gcc.gnu.org/bugzill
--- Comment #6 from pcarlini at suse dot de 2007-01-15 00:30 ---
(In reply to comment #5)
> Sorry I read your reply later.
>
> So, that is it, isn't it? Wsystem-headers needs to be fixed since we don't
> want
> to emit warnings for system headers even if those warnings are correct.
W
gcj crashes when invoking like 'gcj -Msomething -MT something SomeFile.java'
where SomeFile.java could be any existing file, even empty.
OUTPUT:
$ gcj -Manything -MT anything Test.java -v
Using built-in specs.
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libgcj.spec
rename spec
I am seeing the following bootstrap failure on i386, both
i386-unknown-freebsd5.4 and i386-suse-linux. i686 does not
have this issue on both systems.
/tmp/OBJ-0114-2254/./prev-gcc/xgcc -B/tmp/OBJ-0114-2254/./prev-gcc/
-B/suse/gp/gcc-i686/i386-suse-linux/bin/ -c -O2 -g -fomit-frame-pointer
-DIN_
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-01-15 01:56 ---
since the bug does not reproduce on Linux setup, would be possible to have
preprocessed testcase and possibly also backtrace of the crash?
Thank you,
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30467
--- Comment #2 from gerald at pfeifer dot com 2007-01-15 02:06 ---
It does reproduce on openSUSE 10.2 for me when I configure with
--disable-libgcj i386-suse-linux
I am kicking off a new bootstrap and will provide pre-processed sources
tomorrow.
--
http://gcc.gnu.org/bugzilla/sho
I see -M option for gcc-4.1.1 output chops dirname, but faces below
problem.
$ cat foo.c
#include "foo.h"
$ cat Include/foo.h
/* empty */
$ gcc41 -M -I.//Include foo.c
foo.o: foo.c /Include/foo.h
^
root?
gcc-3.4.4 output was:
$ gcc -M -I.//Include foo.c
foo.o: foo.c
When doing a "make profiledbootstrap", -fprofile-generate is used for libgcc
which is wrong.
--
Summary: [4.3 Regression] profiledbootstrap no longer works
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: n
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 02:29 ---
This was reported here:
http://gcc.gnu.org/ml/java/2007-01/msg00050.html
And I was able to reproduce it with just --enable-languages=c, make
profiledbootstrap on i686-linux-gnu.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-15 02:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-15 03:34 ---
The ICE is happens at ifcvt.c:1901.
if_info->insn_b is NULL.
It looks like it was caused by:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00704.html
Looking to reduce the testcase.
--
pinskia at gcc dot gnu dot
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-15 05:27 ---
Reduced testcase:
struct a
{
unsigned a:7;
unsigned b:1;
};
void g(char*);
void f(struct a *t)
{
char t1 = 1;
if (!t->b)
t1 = 0;
g(&t1);
}
--
pinskia at gcc dot gnu dot org changed:
W
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ---
(In reply to comment #55)
> Created an attachment (id=12879)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) [edit]
> Patch for scheduler dependency lists.
Looks like a pretty good cleanup IMHO.
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-01-15 07:24
---
Reproducible on i586-linux.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Thanks! Very useful comments. I'm continuing to work on cleaning the
patch (especially on writing the comments) and making code more
transparent. Below are my comments on yours:
zaks at il dot ibm dot com wrote:
--- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ---
(
--- Comment #57 from mkuvyrkov at ispras dot ru 2007-01-15 07:52 ---
Subject: Re: [4.1 regression] A file that can not be
compiled in reasonable time/space
Thanks! Very useful comments. I'm continuing to work on cleaning the
patch (especially on writing the comments) and making cod
60 matches
Mail list logo
