I have built a static runtime library and i want the linker to access
it automatically without having to pass it explicitly.
Wrong list, this one is for GCC development, not development with GCC.
Try [EMAIL PROTECTED] instead.
--
Eric Botcazou
Currently, the way the native CPU detection code in driver-i386.c
is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
the correct setting for this chip? There seems to be a lot of confusion
across the net as to
Dear All,
Sorry to disturb uninterested people with following information
For information (and for future reference) my employing organisation CEA
http://www.cea.fr/ Commissariat a l'Energie Atomique, a French state-owned
research entity with a scientific, technical, and industrial activity
Hello,
While working on our CLI port, I realized that we were missing, among
others, the block reordering pass. This is because we emit CLI code
before the RTL passes are reached.
Looking at the backend optimizations, it is clear that some modify the
CFG. But my understanding is that loop
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
Currently, the way the native CPU detection code in driver-i386.c
is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
the correct setting for this
Looking at the backend optimizations, it is clear that some modify the
CFG. But my understanding is that loop optimizations and unrolling are
also being moved to GIMPLE. I do not know about others.
Loop optimizations are performed on GIMPLE only because they are really
hard to perform on
Hi,
I know little about CLI, but assuming that your backend is nonstandard
enought so it seems to make sense to replace the RTL bits I guess it
would make sense to make the bb-reorder run on GIMPLE level too, while
keeping bb-reorder on RTL level for common compilation path. This
is example of
BTW, I am surprised that it is not easy to know which organizations exactly
has signed such legal papers. It could happen (in big organizations) that
such an assignment has been signed, and a putative minor contributor to GCC
does not know about it yet.
There is a copyright list on gnu.org
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
Currently, the way the native CPU detection code in driver-i386.c
is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
Core 2 Duo*) processor will result in
Personally, I think the list should be somewhere that *all* gcc
maintainers have access to (not all of us have gnu.org accounts).
I agree that in principle, GCC code maintainers would need to check it
after approving a patch of somebody who has no CVS access. But the FSF
does not care about
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
Using quick (in theory) and trusty cpgram.ii, I get:
tree PTA :1135.48 (88%) usr 5.47 (55%) sys1168.23
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?) regressed in that time frame.
[1]
On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
Using quick (in theory) and trusty cpgram.ii, I get:
Paolo Bonzini wrote:
The legislation in the US, however, is
probably very different: for example, the copyright assignment form
would have a separate signature, or a click-through if done via web,
where you accept that the FSF keeps the data on a computer in order to
process the assignment.
On Fri, 2006-12-01 at 10:56 -0500, Andrew MacLeod wrote:
On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
On 12/1/06, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?)
* Alan Ong ([EMAIL PROTECTED]) [20061201 03:35]:
Hello,
I am trying to compile my code with hard-coded Japanese Kanji and
full-width katakana string text but the compiler view some of the text
as escape characters.
Please ask on [EMAIL PROTECTED] This list deals with the development
On 12/1/06, Richard Guenther [EMAIL PROTECTED] wrote:
On 12/1/06, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron,
Sure. Sorry for the huge log.
I will use your method for the merge commit message in the future.
Thanks a lot!
Regards,
Chao-ying
- Original Message -
From: Jakub Jelinek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Sent: Thursday, November 30, 2006 11:24 PM
Subject: Re:
FYI, I created an IA64 psABI discussion group:
http://groups-beta.google.com/group/ia64-abi
H.J.
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
10 hours?
Using quick (in theory) and trusty cpgram.ii, I get:
On Fri, Dec 01, 2006 at 04:35:32PM +0100, Paolo Bonzini wrote:
There could be privacy problems too. I don't know the relevant
legislation, but the [copyright assignment] list includes personal data
(year of birth, citizenship, employer) and, in Italy, I would have to
sign a form if I had
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
10
On Fri, 2006-12-01 at 11:45 -0500, Daniel Berlin wrote:
On 12/1/06, Richard Guenther [EMAIL PROTECTED] wrote:
On 12/1/06, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
until we can deal with the register pressure (though i thought we had
out-of-ssa changes to help with this now).
I don't
Hello,
In accordance with http://gcc.gnu.org/ml/gcc/2006-09/msg00454.html, I am
looking for a reviewer for patches that add tuning for AMD's new
AMDFAM10 architecture to gcc.
The changes are all confined to the i386 backend and are only turned on
with -march=amdfam10 and/or -mtune=amdfam10. The
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
On 01/12/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
On 12/1/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
My bootstrap/make
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
First of all, in theory the timers in kernel are done that way:
* they have callback of type void (*)(unsigned long)
* they have data to be passed to it - of type unsigned long
Snapshot gcc-4.1-20061201 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061201/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
I have noticed that the INSN_CODE for all patterns in the rtl dumps
.00.expand are -1 ... does this mean that the .md file was not used for the
initial RTL generation?
best regards
Andrija Radicevic
On 12/1/06, Andrija Radicevic [EMAIL PROTECTED] wrote:
Hi,
I have noticed that the INSN_CODE for all patterns in the rtl dumps
.00.expand are -1 ... does this mean that the .md file was not used for the
initial RTL generation?
It was used, but it is assumed that the initial RTL produced by
The message for the following error:
enum e { E3 = 1 / 0 };
is in C: error: enumerator value for 'E3' not integer constant
and in C++: error: enumerator value for 'E3' is not an integer constant
The code in C is error (enumerator value for %qE is not an integer
constant, name);
and in C++ is
:8192.55user 2751.37system 56:20.08elapsed 323%CPU
(0avgtext+0avgdata 0maxresident)k
nohup.20061127:7177.19user 1295.59system 45:34.88elapsed 309%CPU
(0avgtext+0avgdata 0maxresident)k
nohup.20061127:8173.81user 2752.39system 57:50.67elapsed 314%CPU
(0avgtext+0avgdata 0maxresident)k
nohup.20061201
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit - 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
Hi all,
I understand that all template functions in GCC should have vague
linkage and thus may be exported into numerous translation units where
they are used. I have been attempting to use a few different macros on
both an instanciated template functions FUNCTION_DECL node and a normal
functions
On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
I don't really see how this is a GCC question, rather I see this
as a C question which means this should have gone to either
[EMAIL PROTECTED] or
On 12/1/06, Al Viro [EMAIL PROTECTED] wrote:
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
First of all, in theory the timers in kernel are done that way:
* they have callback of type void (*)(unsigned long)
* they have data
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:08
---
Fixed in current version. FI: this was ACT bug E103-008.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from baldrick at gcc dot gnu dot org 2006-12-01 08:31
---
None of the examples provided in this bug report generate
an overlapping memcpy with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from baldrick at gcc dot gnu dot org 2006-12-01 08:38
---
Does not occur with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 08:43
---
Does not happen with current gcc.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 09:07
---
While this doesn't happen with GNAT-GPL 2006 or GNAT Pro 5.05w (20060118),
that's not surprising because they are compiled with --disable-checking.
Here are the details of the compiler for which I get this ICE:
Please find below ada code that compiles and executes on 2 machines with
different gcc versions
Machine1 has gcc 3.3.3 and compiles and executes correctly
Machine2 has gcc 4.1.1 and compiles without warnings. It executes but produces
the wrong result. As you can see the code zeroes SL(1) and
See also: http://gcc.gnu.org/ml/fortran/2006-12/msg0.html
Tim Prince's analysis why ifort needs 8.77s and gfortran 12.16s for one
program:
My copy of gfortran makes separate scalar calls to sin and cos, where ifort
makes a vector sincos call. 2 seconds to be gained there
In the Fortran
--- Comment #1 from ubizjak at gmail dot com 2006-12-01 10:14 ---
Depends on PR tree_optimization/17687. I guess it is a time to finally resolve
that one...
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from bonzini at gnu dot org 2006-12-01 10:57 ---
Not only that; the glibc sincos, for example, would not gain anything. ifort
gains because it basically computes the sine and cosine using two halves of an
XMM register.
Richard had a really gross ;-) patch to do this.
--- Comment #3 from bonzini at gnu dot org 2006-12-01 11:04 ---
We need multiple steps here to solve this bug and 17687:
1) change sincos (x, s, c) to
sincos (x, t1, t2);
s = t1;
c = t2;
Don't know the best place to do this.
2) alternatively, change sincos (x, s, c)
--- Comment #5 from pedro dot lamarao at mndfck dot org 2006-12-01 11:37
---
Ah, just as I thought, but I was too sleepy to find about that function on my
own.
Must someone present this to gcc-patches or will you do it yourself?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30033
--- Comment #3 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 ---
*** This bug has been marked as a duplicate of 29867 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dfranke at gcc dot gnu dot org 2006-12-01 11:41 ---
*** Bug 30008 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #7 from burnus at gcc dot gnu dot org 2006-12-01 12:17 ---
I wonder whether this is bug is not identically to PR 21466 sqrt() function
not vectorized
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30032
--- Comment #14 from pluto at agmk dot net 2006-12-01 12:24 ---
no backport to 4.1/4.2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-01 12:25 ---
I wonder whether this is bug is not identically to
PR 21466 sqrt()function not vectorized
I mean for the Fortran test case:
gastest.f90:8: note: LOOP VECTORIZED.
gastest.f90:9: note: LOOP VECTORIZED.
--- Comment #10 from pault at gcc dot gnu dot org 2006-12-01 13:16 ---
Created an attachment (id=12722)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12722action=view)
This patch fixes the testcase of #6 and regtests on Cygwin_NT/PIV
Joost,
I am not sure that I see how the test
Use of long long constants produces incorrect code when cross compiling for the
hppa target on a 64 bit host
$ hppa--linux-gcc -v
Using built-in specs.
Target: hppa--linux
Configured with: /home/nick/gnu/gcc/configure --target=hppa--linux
--prefix=/home/nick/gnu/path --enable-languages=c :
--- Comment #1 from skrll at netbsd dot org 2006-12-01 13:40 ---
Created an attachment (id=12723)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12723action=view)
reduced test case from netbsd src/sys/kern/kern_uuid.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
--- Comment #13 from hjl at gcc dot gnu dot org 2006-12-01 14:49 ---
Subject: Bug 29921
Author: hjl
Date: Fri Dec 1 14:49:15 2006
New Revision: 119401
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119401
Log:
2006-12-01 Zdenek Dvorak [EMAIL PROTECTED]
PR
--- Comment #14 from hjl at lucon dot org 2006-12-01 14:51 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|ASSIGNED
On Core 2 Duo, I got
[EMAIL PROTECTED] tmp]$ /usr/gcc-4.2/bin/gcc -mtune=native -S x.i -v
...
/usr/gcc-4.2/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -fpreprocessed x.i
-mtune=nocona -quiet -dumpbase x.i -auxbase x -version -o x.s
...
On Core Duo, I got
[EMAIL PROTECTED] tmp]$
--- Comment #1 from baldrick at gcc dot gnu dot org 2006-12-01 15:24
---
The uninitialized bytes are normal: the Unit_Type structure is 16 bytes long:
type Unit_Type is
record
Position : Natural := 19;
String_Value : String (1..9) := (others =
When bootstrapping GCC trunk on Solaris 10 x86, sse3-movddup.c gives an ICE.
However, this test shouldn't even be running since I don't think my CPU has
sse3.
dev-zero:{bretta}$ isainfo -v
64-bit amd64 applications
sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc
--- Comment #5 from paolo at gcc dot gnu dot org 2006-12-01 15:55 ---
Subject: Bug 29066
Author: paolo
Date: Fri Dec 1 15:55:11 2006
New Revision: 119403
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119403
Log:
2006-12-01 Ryan Mansfield [EMAIL PROTECTED]
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-01 16:00 ---
My gross patch will still work ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-01 16:03 ---
Btw, the gross patch is attached to PR17687.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-12-01 16:04
---
Not a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29512
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-12-01 16:37
---
Subject: Bug 29433
Author: rguenth
Date: Fri Dec 1 16:37:38 2006
New Revision: 119404
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119404
Log:
2006-12-01 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-12-01 16:38
---
Improved for the case of building with -g, which should now be as bad as with
plain -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29433
--- Comment #11 from burnus at gcc dot gnu dot org 2006-12-01 17:20 ---
Created an attachment (id=12724)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12724action=view)
test case for interface bl_copy
(In reply to comment #10)
This patch fixes the testcase of #6 and regtests on
g++ --save-temps -W -Wall bug.cc
bug.cc: In function `void p(T)':
bug.cc:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into
--- Comment #1 from bagnara at cs dot unipr dot it 2006-12-01 17:25 ---
Created an attachment (id=12725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12725action=view)
The file g++ asked me to attach.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30042
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-01 18:04 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-01 18:05 ---
(In reply to comment #5)
Btw, the gross patch is attached to PR17687.
If you mean attachment (id=12055; patch using cexp) then note that it no longer
applies cleanly:
2 out of 5 hunks FAILED -- saving rejects to
--- Comment #6 from pinskia at gmail dot com 2006-12-01 18:19 ---
Subject: Re: ICE on valid with --std=c++0x (static_assert)
On Fri, 2006-12-01 at 11:37 +, pedro dot lamarao at mndfck dot org
wrote:
Must someone present this to gcc-patches or will you do it yourself?
I am going
--- Comment #15 from elizabeth dot l dot yip at boeing dot com 2006-12-01
20:24 ---
One of my colleaques said my test code in Bug 30025 works on his MAC OS X
system at home. He has an older version of gfortran. Here is what he wrote:
It worked using gfortran on my OS X system.
--- Comment #9 from ubizjak at gmail dot com 2006-12-01 20:54 ---
(In reply to comment #8)
I wonder whether this is bug is not identically to
PR 21466 sqrt()function not vectorized
Have you tried patch at
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01819.html?
The VLA - normal
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01
21:01 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 MRO
No problem. If the compiler is not being miscompiled, I will be able to
look at it
--- Comment #32 from tkoenig at gcc dot gnu dot org 2006-12-01 21:04
---
Subject: Bug 29568
Author: tkoenig
Date: Fri Dec 1 21:04:38 2006
New Revision: 119412
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119412
Log:
2006-12-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #33 from tkoenig at gcc dot gnu dot org 2006-12-01 21:18
---
Fixed on trunk.
I'll be waiting for some time for any regressions before
backporting to 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
when a coder writes (erroneously) such a code:
char *m_strrtrim(char *s) __attribute__((nonull(1));
char *m_strrtrim(char *s)
{
int len = s ? strlen(s) : 0;
while (len 1 isspace((unsigned char)s[len - 1]))
len--;
return s + len;
}
Then gcc uses the
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:28
---
Subject: Bug 30021
Author: reichelt
Date: Fri Dec 1 21:28:35 2006
New Revision: 119415
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119415
Log:
PR c++/30021
* c-common.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 21:29
---
Fixed on mainline.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-12-01 21:35
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 21:35:25 2006
New Revision: 119416
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119416
Log:
PR c++/30022
* typeck.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-01 22:01 ---
nonnull attribute to the function says the function's argument is non null at
the time we enter the function so assuming that is correct.
Also this is documented this way:
nonnull (arg-index, ...)
The nonnull
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-01 22:06 ---
Fixed on the branch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-01
22:22 ---
Subject: Re: [4.3 Regression] build/genconditions
../../gcc/gcc/config/pa/pa.md tmp-condmd.c: /bin/sh: 13354 MRO
DF_REF_INSN (def) is 0. It looks like the ICE can be avoided by
a check on def_insn.
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-12-01 22:27
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:27:03 2006
New Revision: 119418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119418
Log:
PR c++/30022
* typeck.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-12-01 22:29
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:29:13 2006
New Revision: 119419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119419
Log:
PR c++/30022
* typeck.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-12-01 22:32
---
Subject: Bug 30022
Author: reichelt
Date: Fri Dec 1 22:32:00 2006
New Revision: 119420
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119420
Log:
PR c++/30022
* typeck.c
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-12-01 22:33
---
Fixed on mainline, 4.2 branch, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from madcoder at debian dot org 2006-12-01 22:45 ---
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo' function from the bug report.
When you
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-01 22:49 ---
(In reply to comment #2)
Please, I'm not telling the behaviour is crazy, it's indeed correct.
I'm just asking for a smallish warning that I may be shooting myself in the
foot when I do sth like my 'foo'
--- Comment #4 from manu at gcc dot gnu dot org 2006-12-01 23:36 ---
I am working in a patch but don't expect it too soon. Yet, I am quite advanced,
that is why I am accepting it. If this is not the proper way to do it, please
let me know.
--
manu at gcc dot gnu dot org changed:
$ gcj -c /usr/share/java/seda.jar
seda/sandStorm/internal/AggTPSThreadManager.java: In class
'seda.sandStorm.internal.AggTPSThreadManager$governorThread':
seda/sandStorm/internal/AggTPSThreadManager.java: In method
'seda.sandStorm.internal.AggTPSThreadManager$governorThread.run()':
--- Comment #6 from dfranke at gcc dot gnu dot org 2006-12-02 00:12 ---
Fixed on trunk, closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2006-12-02 02:15 ---
Subject: Bug number PR c++/28284
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00064.html
--
--with-mpfr=/tmp/gcc-inst --enable-languages=c,c++
Thread model: posix
gcc version 4.3.0 20061201 (experimental)
--
Summary: ICE in tsubst, at cp/pt.c:7359
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority
1 - 100 of 115 matches
Mail list logo
