Tom Tromey wrote:
Gabriele == Gabriele SVELTO [EMAIL PROTECTED] writes:
Gabriele Good to know, TYPE_MAIN_VARIANT () is exactly what I was
Gabriele looking for, unfortunately it's description in tree.def
Gabriele isn't exactly crystal clear :P Thank you very much
This would be a great
Status
==
We are in Stage 3. When we reach 100 open regressions, we will go to
regression-only mode. When we approach the 4.3.0 release, we will
create a branch, and open Stage 1 for 4.4.0.
Quality Data
Significant progress has been made during the last week, also thanks to
Is this proposed patch still being considered, or has it been applied/withdrawn?
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html
--
Cheers,
/ChJ
Hi all
I come to you looking for some light ;) We are developing an application
that needs to link statically math.h. I've been looking for libm.a for
Tru64 Alpha with no success at all. System comes with .so so but i think
it's not possible converting .so into .a
Any help is welcome.
Thanks
On 11/01/2008, Christian Joensson [EMAIL PROTECTED] wrote:
Is this proposed patch still being considered, or has it been
applied/withdrawn?
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html
It hasn't been applied or withdrawn.
From the comments in PR34118, I think the status is:
I
Joe Buck wrote:
On Fri, Jan 11, 2008 at 09:34:29AM +0200, Rehno Lindeque wrote:
Just a note: Operator precedence is taught as logical AND comes before
OR in logic courses. So it is a sort of a standard mathematical
convention just like + and *. In fact, OR is even represented as a +
in some
On 11/01/2008, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
On 11/01/2008, Christian Joensson [EMAIL PROTECTED] wrote:
Is this proposed patch still being considered, or has it been
applied/withdrawn?
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01846.html
It hasn't been applied or
On Fri, Jan 11, 2008 at 09:34:29AM +0200, Rehno Lindeque wrote:
Just a note: Operator precedence is taught as logical AND comes before
OR in logic courses. So it is a sort of a standard mathematical
convention just like + and *. In fact, OR is even represented as a +
in some notations. However
On Fri, Jan 11, 2008 at 05:01:02PM +0100, Adrián Bravo Navarro wrote:
I come to you looking for some light ;) We are developing an application
that needs to link statically math.h. I've been looking for libm.a for
Tru64 Alpha with no success at all. System comes with .so so but i think
it's
Mark Mitchell wrote:
I don't see any a priori problem with changing to match the C front end.
We could of course change some of the pedwarns into errors if we really
think they ought to be errors. Or, some of them could be ordinary
warnings when not -pedantic, and pedwarns when -pedantic.
Mark Mitchell wrote:
I think Jason's input would be helpful. I remember having a discussion
about this years ago (1998?), but I don't remember the complete
rationale. I think the idea was that we wanted many of these things
(ugly old ARM-era C++ things) to be errors, but didn't want to make
Joe Buck wrote:
Mark Mitchell wrote:
I don't see any a priori problem with changing to match the C front end.
We could of course change some of the pedwarns into errors if we really
think they ought to be errors. Or, some of them could be ordinary
warnings when not -pedantic, and pedwarns
--with-mpfr-lib=/home/jerry/gcc/usr/lib
--with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC)
I get the following:
==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1
Suppose we dump the GIMPLE tree into a file by using gcc option. Is it
possible to import the GIMPLE file into the gcc and generate the target
code?
Thanks a lot for your help.
--
View this message in context:
Jerry DeLisle wrote:
With the Fortran test case I am using for PR34722. I did a valgrind
check with the following command:
valgrind --leak-check=full f951 inquire_12.f90
Here is a reduced test case. I will submit a PR. It has nothing to do with my
iostat patch for pr34722.
program
Good morning,
I've got a codebase that's a hundred years old, started in life on Sun3
and have evolved to 32-Bit X86 Linux (Fedora 5). We're trying to move
to 64-Bit now and this same code that has compiled for years is barking
about operators cannot be overloaded.
This is a Fedora 8 x86-64
-libgomp
--with-mpfr-lib=/home/jerry/gcc/usr/lib
--with-mpfr-include=/home/jerry/gcc/usr/include --disable-bootstrap
Thread model: posix
gcc version 4.3.0 20080111 (experimental) [trunk revision 131004] (GCC)
I get the following:
==14240== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5
On Dec 19, 2007 3:02 PM, [EMAIL PROTECTED] wrote:
My specific candidate for exclusion from -Wall is this one:
if (a b || c d)
which yields (as you know) advice to parenthesize the two pairs.
To make this discussion a bit more concrete, the attached patch
removes this particular
Joe Buck [EMAIL PROTECTED] writes:
A warning that flagged code like
if (c1 || c2 c3)
...
would swamp users in warnings, since this kind of code is extremely
common, and this isn't the kind of thing that anyone who's not a total C
beginner has trouble with.
That is what
Haizhou LING [EMAIL PROTECTED] writes:
Suppose we dump the GIMPLE tree into a file by using gcc option. Is it
possible to import the GIMPLE file into the gcc and generate the target
code?
No.
The LTO project is working toward making something like that possible.
Ian
On 1/11/08 3:36 PM, Haizhou LING wrote:
Suppose we dump the GIMPLE tree into a file by using gcc option. Is it
possible to import the GIMPLE file into the gcc and generate the target
code?
Not yet, but it's being worked on.
http://gcc.gnu.org/wiki/LinkTimeOptimization
Diego.
On Fri, Jan 11, 2008 at 03:24:46PM -0800, Ian Lance Taylor wrote:
Joe Buck [EMAIL PROTECTED] writes:
A warning that flagged code like
if (c1 || c2 c3)
...
would swamp users in warnings, since this kind of code is extremely
common, and this isn't the kind of thing that anyone
I would start with Dave's fix, and then see if we can improve it
somehow. Presumably this is talking about Manuel's work, at least
in part?
In part. Actually, the new warnings are all over the place.
I've attached a summary from:
http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/Werror/
On Thu, 2008-01-10 at 19:16 -0500, DJ Delorie wrote:
IIRC, the bug happened building either libgcc or newlib. If you want
to revert my latest patch in a local source tree and just try a build,
it's likely to show you an example ;-)
It was unwind-dw2.c in the m32cm libgcc multilib.
The
Doug Gregor [EMAIL PROTECTED] writes:
To make this discussion a bit more concrete, the attached patch
removes this particular warning from -Wparentheses and puts it into a
new warning, -Wprecedence, that is not enabled by -Wall. This is
slightly more fine-grained than what -Wparentheses does
If the old GNU extern inline behavior is desired, one can use extern
inline __attribute__((__gnu_inline__)). The use of this attribute can
be guarded by #ifdef __GNUC_STDC_INLINE__ which is a macro which is
defined when inline has the ISO C99 behavior, or compiled with
-fgnu89-inline option.
I
Also known as nooo, it's not *inlined*, it's just the call
being removed because the called function was found to be
pure/const. :)
This happens when you try to synthesize executable test-cases
and you need e.g. a call with such-and-such parameters, but the
called function doesn't do anything;
--- Comment #1 from wvangulik at xs4all dot nl 2008-01-11 08:17 ---
Created an attachment (id=14920)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14920action=view)
Test case showing the three cases
Compile using -fno-line.
For the AVR I used: avr-gcc -Wall -Os -fno-inline
Consider the following:
char *x;
volatile int y;
void foo(char *p)
{
y += *p;
}
void main(void)
{
char *p1 = x;
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
foo(p1++);
}
For the AVR target
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-11 08:52
---
I am investigating.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Hallo,
This happens when compiling file src/script/qscriptcontext_p.cpp in trolltech's
qt 4.3.0 sources.
gcc -c -mpowerpc -mminimal-toc -O2 -Wall -W -D_THREAD_SAFE -DQT_SHARED
-DQT_BUILD_SCRIPT_LIB -DQLALR_NO_QSCRIPTGRAMMAR_DEBUG_INFO
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-01-11 08:57
---
Recategorizing as per Ulrich's analysis.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:58
---
Created an attachment (id=14921)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14921action=view)
gzipped preprocessed source (was too big otherwise)
--
--- Comment #2 from T dot Mittelstaedt at cadenas dot de 2008-01-11 08:59
---
Created an attachment (id=14922)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14922action=view)
assembly source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
--- Comment #8 from krebbel at gcc dot gnu dot org 2008-01-11 09:03 ---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00460.html
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-11 09:12 ---
Honza, is this bug fixed by your commit of comment #8?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-11 09:14 ---
Actually, I don't know if --combine is really that obscure. People seem to use
it with some success, see e.g. http://lwn.net/Articles/197097/. Also, others
seem to think IMA is importan enough to upgrade bugs to
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:28 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 09:42 ---
Confirmed.
void foo(char *p);
void test1(char * p)
{
foo(p++);
foo(p++);
foo(p++);
foo(p++);
}
void test2(char * p)
{
foo(p); p++;
foo(p); p++;
foo(p); p++;
foo(p); p++;
}
The
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-11 10:13 ---
I have had a brief attempt to resolve this one and have driven my head against
a brick wall!
Starting with this development of the original testcase:
! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3
! For 4.3
--- Comment #10 from pcarlini at suse dot de 2008-01-11 10:18 ---
(In reply to comment #9)
I don't agree that localeconv()-grouping is garbage just because
thousands_sep
is NUL. I'm not aware of anything in C or POSIX that says that.
We are working on this assumption. You agreed to
--- Comment #3 from steven at gcc dot gnu dot org 2008-01-11 11:24 ---
So where is the a testcase that you found?
And why, pray tell, assign the bug to Richi instead of just trying to backport
it yourself? ;-)
--
steven at gcc dot gnu dot org changed:
What|Removed
Found a testcase that ice's the ppc-darwin backend at -O3 -ffast-math that is
fixed by the full backport of the patches in 28796. In particular, this part:
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118001
Log:
--- Comment #4 from T dot Mittelstaedt at cadenas dot de 2008-01-11 09:54
---
Sorry forgot to add contents of an earlier mail which I sent to gcc-help and
gcc-bugs mailing lists, that version 4.1.1 which I downloaded from ftp.hvcc.edu
(pware) and an earlier 4.1 version, which we built
--- Comment #4 from dominiq at lps dot ens dot fr 2008-01-11 09:35 ---
I see the same problem at any level of optimization I have tried on
i686-apple-darwin9 for the test case gcc.target/i386/asm-3.c:
[ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O0
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-11 09:50 ---
You have not enough memory. 250MB is not unreasonable to compile this file.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-11 11:09 ---
Not a regression, so won't be fixed in 4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-11 11:18 ---
We should at least understand where all the memory is going.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from echristo at apple dot com 2008-01-11 11:19 ---
Doesn't ice under 4.0 so it is a regression.
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #4 from echristo at apple dot com 2008-01-11 11:26 ---
It's in the bug and I have assignment issues currently and he asked me to?
--
echristo at apple dot com changed:
What|Removed |Added
--- Comment #7 from echristo at apple dot com 2008-01-11 11:48 ---
Created an attachment (id=14923)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14923action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-11 11:33 ---
No what happened with 4.0 is rather DOM would prop x+1 for each x.
Really this comes down to scheduling of instructions and moving them closer to
their usage.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-11 11:38 ---
Preprocessed source? The testcase listed here is not going to show the issue
on most targets anyways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34739
--- Comment #6 from ijeukens at yahoo dot com dot br 2008-01-11 11:43
---
Not a bug (wrong variable type (int instead of size_t) triggered strange
behavior.
--
ijeukens at yahoo dot com dot br changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-01-11 11:48 ---
(In reply to comment #4)
It's in the bug and I have assignment issues currently and he asked me to?
You mean Apple has issues, not you technically and legally IIRC.
--
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 ---
Created an attachment (id=14924)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14924action=view)
uninclude
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34738
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-11 13:09 ---
The preprocessed testcase is useless, nobody has ppc-aix5 available. Please
strip system includes with 'uninclude'.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from zadeck at naturalbridge dot com 2008-01-11 13:15
---
stevens patch bootstrapped and regression tested on x86-86, ppc-32 and ia-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #10 from T dot Mittelstaedt at cadenas dot de 2008-01-11 14:10
---
A colleague just told me, that aix only gives an application 256 MB memory
except
if you set a certain environment variable (don't know yet) or
specify something like -Wl,-bmaxdata:0x8000 to the linker.
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-01-11 14:56
---
Subject: Bug 30905
Author: rguenth
Date: Fri Jan 11 14:55:34 2008
New Revision: 131468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131468
Log:
2008-01-11 Steven Bosscher [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 14:51
---
4.0: 448376 kB
4.1: 424788 kB
4.2: 512644 kB
4.3: 249496 kB
I don't have a 64bit 3.4 compiler and 3.3 doesn't grasp the C++ used.
Nothing obvious from the 4.3 numbers, the CU looks simply large:
parser
The test stopped testing what it's supposed to test. The call to function
baz() should not be inlined. This patch to the test exposes the failure. The
operand scanner is adding non-clobbered symbols to the call site.
Details at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00477.html
--
As requested on the mailing list:
Document the kind of integer passed for string lengths
http://gcc.gnu.org/ml/fortran/2008-01/msg00134.html
| The character length variables you mention are always (for gfortran)
| 32-bit integer signed variables, so if you need to address them in
| gfortran, you
--- Comment #4 from hubicka at gcc dot gnu dot org 2008-01-11 15:25 ---
I am testing the attached patch. It disables the transformation and produce:
in_cols.0 = (char *) in_cols;
D.1180 = in_cols.0 + 500;
perhaps more canonical way would be
in_cols.0 = in_cols + 500;
d.1180 =
--- Comment #5 from dgregor at gcc dot gnu dot org 2008-01-11 15:24 ---
Amusingly enough (since this is the second time this has happened today), this
problem occurs both with and without variadic templates. The following code is
ill-formed according to C++98, but GCC accepts it:
The following out-of-bounds problem (in the if clause) is not detected:
character, pointer :: ptr(:)
allocate(ptr(9))
ptr = transfer('Sample#0'//achar(0),ptr) ! Causes ICE
if (any (ptr .ne. ['S','a','m','p','l','e','#','0'])) call abort
end
NAG f95 finds:
Rank 1 of array operand has
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-11 15:57 ---
It's doing the correct thing. We have
p_1, name memory tag: NMT.14, is dereferenced, points-to vars: { SFT.3 SFT.7 }
(SFT.3 is x.x, SFT.7 is z.x)
Now, NMT.14 is marked call clobbered:
NMT.14, UID D.1582, struct
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-11 15:09 ---
Whee, thanks Kenny and Richi!!!
Zapp...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-11 15:39
---
The problem here is really how we handle extern inline functions redefining
non-extern inline functions.
What forntend does is to handle all extern inline or extern functions of same
name in all units as single
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-01-11 14:11 ---
This code is ill-formed, and should be rejected because Args cannot be
deduced from typename Args::is_applied. Interestingly enough, this problem
actually has nothing to do with variadic templates: take away the
For the following program, I expect an out-of-bounds error; NAG f95 shows at
run time:
Rank 1 of array operand has extent 7 instead of 8
character, pointer :: ptr(:)
allocate(ptr(8))
ptr = transfer('Sample'//achar(0),ptr)
end
--
Summary: -fbounds-check with TRANSFER
--- Comment #12 from stevenb dot gcc at gmail dot com 2008-01-11 13:48
---
Subject: Re: [4.3 Regression] Fails to cross-jump
Richi, could you commit it for me?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-11 14:01 ---
What about:
namespace A {
extern C int g (double);
}
namespace B {
extern C int g (int);
}
using namespace A;
using namespace B;
void f ()
{
g (1.0);
}
I don't believe this is valid, as extern C means there is
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-11 13:09
---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates
wrong code for infinitely recursive functions
ghazi at gcc dot gnu dot org wrote:
--- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03:57
--- Comment #9 from T dot Mittelstaedt at cadenas dot de 2008-01-11 12:55
---
(In reply to comment #7)
I have just tried to compile after detarring with GNU tar 1.19, and it
compiled
succesfully! Therefore the problem was a depackaging bug in an older version
of
tar. I'll
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-01-11 13:41
---
The patch is ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #10 from aldot at gcc dot gnu dot org 2008-01-11 13:30 ---
Still fails for me on trunk (revision 131461):
gcc-4.3-HEAD -Os --combine -c -o pr28779.o pr28779a.c pr28779b.c
pr28779b.c: In function 'e1000_write_reg_io':
pr28779b.c:12: internal compiler error: in
--- Comment #12 from sebor at roguewave dot com 2008-01-11 15:59 ---
(In reply to comment #11)
[...]
So while I agree that NUL thousands_sep means no grouping to stdio and to
iostreams in C++,
I should clarify that in C++ it means that only if the NUL comes from libc
(e.g.,
via
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-11 16:39 ---
We even mark all pointed-to vars of value-escaping pointers as call-clobbered.
So I believe NMTs itself need never be call-clobbered. But there's also
hints that we cover bugs somewhere:
FIXME: This is
--- Comment #11 from sebor at roguewave dot com 2008-01-11 15:56 ---
I think the disconnect might be in how each of us is looking at the LC_NUMERIC
data. To me, it's just a bunch of values that are independent of one another.
You, OTOH, seem to view it more as a set of rules described
--- Comment #12 from aldot at gcc dot gnu dot org 2008-01-11 15:21 ---
Honza, the IPA pass reordering also caused PR31529, perhaps they are related?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
--- Comment #8 from T dot Mittelstaedt at cadenas dot de 2008-01-11 13:19
---
Created an attachment (id=14925)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14925action=view)
preprocessed source stripped of system includes via uninclude
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-11 14:21 ---
Paul's patch (approved): http://gcc.gnu.org/ml/fortran/2008-01/msg00131.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34537
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-01-11 18:05 ---
Paolo, as a quick aside, you might find it useful to look at the concept GCC
library sources for stuff like this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
--- Comment #47 from rguenth at gcc dot gnu dot org 2008-01-11 13:29
---
Most of the PRE/FRE memory is spent in copied VOPs VECs. Unfortunately we
cannot move them to heap memory easily as the get shared in the PRE tables...
I tried to be explicit in managing the memory, but it gets
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #11 from hubicka at ucw dot cz 2008-01-11 14:04 ---
Subject: Re: internal compiler error: in cgraph_estimate_size_after_inlining,
at ipa-inline.c:106
The bug re-appeared due to yet another reorganization of IPA pass queue.
The issues with function changing their types are
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:16
---
Subject: Bug 34722
Author: jvdelisle
Date: Fri Jan 11 21:15:41 2008
New Revision: 131475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131475
Log:
2008-01-11 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:18
---
Subject: Bug 34722
Author: jvdelisle
Date: Fri Jan 11 21:18:10 2008
New Revision: 131476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131476
Log:
2008-01-11 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-01-11 21:20
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2008-01-11 21:23
---
I do think this is a bug. It's certainly not going to meet user expectations.
I think this is another case of a GCC extension that could have been
better-designed. If we were starting from scratch, I think
--- Comment #3 from wilson at gcc dot gnu dot org 2008-01-11 21:23 ---
The ia64 code to insert stop bits has a built-in assumption that if we see a
register set twice in the same instruction, then we goofed, and must ICE.
The testcase has an extended asm with 3 outputs and 4 inputs.
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-11 19:12 ---
(In reply to comment #3)
Breaking up the expression for h1, thusly:
hh = (/(exp(-2*pi*(0,1)*mod(k*L,N)/N)*h2(L),L=0,N-1)/)
h1 = (/(sum(hh),k=0,N-1)/)
cures the problem.
Paul
--
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-11 20:21 ---
Subject: Bug 34670
Author: tkoenig
Date: Fri Jan 11 20:21:05 2008
New Revision: 131473
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131473
Log:
2008-01-11 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2008-01-11 14:02 ---
For the following ill-defined program, also a warning should be printed. It
comes from PR 34537 and had before an ICE. NAG f95 prints Intrinsic TRANSFER
has partly undefined result.
program main
implicit none
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-11
21:29 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit
2.6.20 kernel
Eric,
More precisely the QTY is changed after the reg has been entered with a hash.
This is expected, but the
--- Comment #10 from wilson at gcc dot gnu dot org 2008-01-11 21:42 ---
Subject: Bug 26015
Author: wilson
Date: Fri Jan 11 21:42:03 2008
New Revision: 131477
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131477
Log:
PR target/26015
* config/vax/elf.h (FRAME_POINTER_CFA_OFFSET):
--- Comment #12 from wilson at gcc dot gnu dot org 2008-01-11 21:52 ---
Fixed on mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09
---
Obviously, the problem is that the hash of reg 66 is changed after a hash
table element is created for it in the bucket for the original hash. I have
no idea yet whether this is expected, or if not, what is
1 - 100 of 126 matches
Mail list logo
