--- Comment #10 from irar at il dot ibm dot com 2008-04-10 07:10 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:31 ---
*** Bug 35894 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:31 ---
*** This bug has been marked as a duplicate of 35869 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from victork at gcc dot gnu dot org 2008-04-10 10:36 ---
The problem in reduced testcase is that loop gets vectorized by gcc 4.2 despite
a dependency between iterations with distance 1.
compute_data_dependences_for_loop () returns "chrec_known" for DDR {
ivec(iclass), ivec
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-10 10:40 ---
Your exception specification on small, medium and large makes throws from the
recursively called dummy_test bogus.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Adde
I get an ICE on some filesystem code I'm developing when trying to compile it
with GCC 4.3.0.
[EMAIL PROTECTED]:~/gcc-bug$ gcc-4.3 -v -save-temps -o sfs_unittests.o -O2 -g
-I.
-std=c99 -Wall -W -c sfs_unittests.c
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure lin
--- Comment #1 from megari at mbnet dot fi 2008-04-10 12:09 ---
Created an attachment (id=15464)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15464&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35899
In the following example the typecast (sign extension) from int
(32bit) to long (64bit) is missing. Before the compare the signed i1
is < 0 and unsigned u2 is > 0 and this should be kept when casting to
64bit long. Same issue for long long (also 64bit).
So we get correct ov=1 with gcc version <= 4.
--- Comment #3 from hjl dot tools at gmail dot com 2008-04-10 13:32 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00837.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-04-10 13:45 ---
I belive this was fixed by
Author: rguenth
Date: Tue Apr 8 22:03:33 2008
New Revision: 134110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134110
Log:
2008-04-08 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #4 from hjl at gcc dot gnu dot org 2008-04-10 14:06 ---
Subject: Bug 35897
Author: hjl
Date: Thu Apr 10 14:05:52 2008
New Revision: 134163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134163
Log:
2008-04-09 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/35897
Hi,
Hi,
I have installed gnat-gpl on my Linux machine. And then from the same directory
under sources folder I extracted the xml-ada library. And started to install
it. I executed the configure command successfully.
But then I tried to make by executing "make -f Makefile.314 install" command.
Then
--- Comment #1 from charlet at gcc dot gnu dot org 2008-04-10 14:41 ---
You should probably report this to slackware then.
Note that you are not using gnat gpl in your report, but a very old GCC version
(3.3.6), so I'd suggest trying with a newer version, where things will
very likely w
--- Comment #2 from holger dot hopp at sap dot com 2008-04-10 16:15 ---
You're right!
Great - the fix is faster available than expected!
Thank you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35900
--- Comment #2 from pcarlini at suse dot de 2008-04-10 17:05 ---
Seems doable...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-10 17:40 ---
The i?86 Linux kernel just got bitten by this again, see
https://bugzilla.redhat.com/show_bug.cgi?id=427707
In this case, it wasn't about a tail call, but I believe high register pressure
that caused modification of t
--- Comment #16 from jakub at gcc dot gnu dot org 2008-04-10 18:09 ---
>From the kernel people it would be interesting to hear on which targets they
actually need it (e.g. if it is i?86 only, it would be better implemented as
i?86 specific syscall_linkage attribute).
--
jakub at gcc
--- Comment #17 from jakub at gcc dot gnu dot org 2008-04-10 18:13 ---
x86_64 actually isn't a problem, as it passes integral arguments in registers
(and kernel only uses at most 6 syscall arguments). Structures aren't passed
by value.
--
jakub at gcc dot gnu dot org changed:
When building libm-test.c (part of the GLIBC make check math test suite for
GLIBC CVS head as of April 10, 2008) with GCC 4.3 I get the following warning:
math/libm-test.c: In function 'parse_opt':
math/libm-test.c:6102: warning: array subscript is above array bounds
In relation to the following
--- Comment #1 from rsa at us dot ibm dot com 2008-04-10 18:57 ---
Created an attachment (id=15465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15465&action=view)
preprocessed test-ildouble.c file.
strcmp on line 16036 seems to be the problematic one.
--
http://gcc.gnu.org/
--- Comment #2 from rsa at us dot ibm dot com 2008-04-10 18:58 ---
Compiled with:
cd /home/ryanarn/glibc/stages/stage_lround/glibc/math
/opt/at43/bin/gcc -m32 test-ildoubl.c -save-temps -c -std=gnu99 -fgnu89-inline
-O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -mcpu=power4
--- Comment #4 from jaydub66 at gmail dot com 2008-04-10 21:09 ---
To me it's also not completely clear what the standard says on this, but the
way to fix it would probably be to insert some additional check into
operator_correspondence (interface.c), where currently only the type and ra
The code:
void grab(int& i);
int main(void)
{ grab(1); }
Produces the useful and informative error:
invalid initialization of non-const reference of type int& from a temporary
of type int
Whereas the code:
template
void grab(T t, int& i);
int main(void)
{ grab(1,1); }
Produces the much
--- Comment #8 from danglin at gcc dot gnu dot org 2008-04-10 22:51 ---
Subject: Bug 35768
Author: danglin
Date: Thu Apr 10 22:50:49 2008
New Revision: 134182
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134182
Log:
PR target/35768
* pa.md: Define mode iterator
--- Comment #9 from danglin at gcc dot gnu dot org 2008-04-10 22:52 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
I just downloaded GCC 4.2.3, and discovered that it states in several places
that it's using GPL v2 instead of v3; my impression from following the mailing
lists is that it (and even 4.2.2) should be GPL v3.
One example (a particularly important one, since it's most exposed to the user)
is the man
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-10 23:17 ---
>(Though, given the presence of the exception there, there's
probably little difference between v2 and v3...)
Actually this is why those have not been moved yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-10 23:19 ---
(In reply to comment #1)
> Actually this is why those have not been moved yet.
And more to the point, the FSF lawyers have not decided how to word the
exception for the GPLv3.
Now Copying.html is a different story
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-10 23:20 ---
(In reply to comment #2)
> Now Copying.html is a different story and I think was already fixed.
And has: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00106.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-04-10 23:21 ---
I don't think we should keep this bug opened any more as the only issue left to
"fix" is really in the FSF hands and they are already working on it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35905
--- Comment #5 from carlton at bactrian dot org 2008-04-10 23:30 ---
Thanks for the info. I just did a spot check on the trunk and
4.2 branch: it looks like all the currently fixable issues I raised are fixed
in the trunk, and Copying.html is probably fixed in the branch (I saw
gpl_v3.t
--- Comment #12 from ian at airs dot com 2008-04-10 23:33 ---
Note that bug 35878, which was closed as a duplicate of this one, was a case of
placement new. For placement new the check for a NULL pointer is particularly
useless, as the language standard says that placement new is requir
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-10 23:34 ---
>(Is 4.1 still open? I don't remember.)
Yes but no see the thread starting at
http://gcc.gnu.org/ml/gcc/2008-03/msg00163.html .
4.3 branch should be have already COPYING3{,.LIB} as it was the trunk when they
w
--- Comment #2 from stdin at stdin dot me dot uk 2008-04-11 03:36 ---
You define __need_size_t when you want to pull in the definition of size_t but
not other typedefs/functions. It's the standard way to get the size_t type.
--
stdin at stdin dot me dot uk changed:
What
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-11 06:45 ---
No, that is a way how the implementation does that internally. That's
certainly not something you are allowed to do in random applications or
libraries.
--
jakub at gcc dot gnu dot org changed:
What
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-04-11 06:56
---
Subject: Bug 35744
Author: reichelt
Date: Fri Apr 11 06:55:38 2008
New Revision: 134193
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134193
Log:
PR c/35744
* attribs.c (decl_attributes):
36 matches
Mail list logo
