--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
a biarch build from trunk (r155486) on x86_64 configured with --enable-gold and
gold providing ld introduces the regressions as shown in the diff.
gold was built from the binutils 2.20 branch.
The two complete test summaries are:
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02390.html
http://
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
10:11 ---
Created an attachment (id=19409)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19409&action=view)
test summary diff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42532
for example, I have a class like this:
class MyClass
{
public:
MyClass() ...
MyClass(IN const MyClass& rhs) ...
MyClass& operator=(IN const MyClass& rhs)...
private:
typedef std::map< string, MyClass > KEYTBL; // Self contains
struct PROP {
...
KEYTBL tblKeys;
--- Comment #11 from ramana at gcc dot gnu dot org 2009-12-29 10:24 ---
(In reply to comment #7)
> (In reply to comment #5)
> > I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
> > the backport of __sync_synchronize() support to regress. I'm currently
> > tes
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
10:30 ---
seen on a ia64-suse-linux-gnu build as well (and on a recent debian build):
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02466.html
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
--- Comment #1 from ramana at gcc dot gnu dot org 2009-12-29 10:35 ---
I can confirm this as a problem on the 4.4 branch and I can see this isn't a
problem on trunk .
.arch armv5te
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_a
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
10:43 ---
seen with 20091228/29 as well:
https://buildd.debian.org/fetch.cgi?&pkg=gcj-4.4&ver=4.4.2-7&arch=s390&stamp=1261836998&file=log
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02429.html
results on the tr
--- Comment #1 from baiyang at gmail dot com 2009-12-29 10:43 ---
PS: the above example is a typical usage of the self contain skill. In this
exapmle, the coder will ensure every really usage point (i.e. every possible
template instantiation point) of 'm_hProp->tblKeys' in the code are a
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-29 10:56
---
After so many years since that idea, we are not interested in squeezing more
from that interesting (but outdated) idea of simulating concept checks in the
library. Long term, we want proper concept checks in th
--- Comment #2 from steven at gcc dot gnu dot org 2009-12-29 11:31 ---
The "if (outcnt == 1) func ();" bit is optimized for me with gcc-4.4.2 on
x86_64 at -O1 and -O2, but not at -Os. I was a bit too hasty to call this alias
related, it seems. The O2 and Os tree dumps start to diverge in
I'm hitting an ICE on gcc svn from 20091229 when building the Linux kernel with
-flto. A cutdown test case:
struct zot
{
void *p;
int *padding;
} __attribute__((__aligned__(128)));
void foo(struct zot *buf)
{
int i;
for (i = 0; i < 4; i++)
--- Comment #7 from schwab at linux-m68k dot org 2009-12-29 11:58 ---
Please report that to the provider of your inofficial builds. Neither
m68k-amigaos nor m68k-atari-mint are supported by the official sources.
--
schwab at linux-m68k dot org changed:
What|Removed
seen with current 4.3 and 4.4 branches, not with trunk. removing
-fschedule-insns lets the build succeed.
Matthias
$ g++-4.4 -c -O1 -fsched-interblock -fsched-spec -fschedule-insns2
-fstrict-aliasing -fstrict-overflow -ftree-pre -ftree-vrp -fcaller-saves
-fcrossjumping -fcse-follow-jumps -fcs
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
12:09 ---
Created an attachment (id=19410)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19410&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42535
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-29 12:17 ---
You shouldn't use -fschedule-insns on i?86/x86_64. Vlad made some changes in
4.5 that make -fschedule-insns work in most cases on these arches, but in
4.3/4.4 you definitely shouldn't use them.
--
jakub at gcc dot
seen with 20091228 trunk and 4.4 branch on i486-linux-gnu, not seen with 4.3
branch (opening new report, because PR39431 is fixed for 4.4 and 4.5). Adding
-fomit-frame-pointer avoids the ice.
Matthias
$ /usr/lib/gcc-snapshot/bin/gcc -g -O2 -fno-gcse -fno-inline-functions
-fno-unit-at-a-time -fs
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
12:41 ---
Created an attachment (id=19411)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19411&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-29 12:44 ---
Steven,
(In reply to comment #2)
> The "if (outcnt == 1) func ();" bit is optimized for me with gcc-4.4.2 on
> x86_64 at -O1 and -O2, but not at -Os. I was a bit too hasty to call this
> alias
> related, it seems.
Misc spelling fixes (found when running the debian lintian tool)
--
Summary: [PATCH] misc spelling fixes
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: documentation
Severity: trivial
Priority: P3
Comp
--- Comment #1 from rmh at gcc dot gnu dot org 2009-12-29 12:46 ---
Created an attachment (id=19412)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19412&action=view)
misc spelling fixes
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-29 12:47 ---
Please submit patches to gcc-patc...@gcc.gnu.org rather than attaching the
patch here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
--- Comment #12 from mikpe at it dot uu dot se 2009-12-29 13:05 ---
Created an attachment (id=19413)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19413&action=view)
pr40134 generic + arm bits
This is the version of the PR40134 patch I intend to submit, unless Matthias
wants to su
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-29 13:11
---
Yes, I think can then go in as obvious. Actually, in my opinion, this kind of
"issue" with zero impact on the end-user experience, should go *only* to
gcc-patches, are not suitable for Bugzilla.
--
paolo do
seen on 4.2, 4.3, 4.4, 4.5 (not checked earlier versions):
$ gzip -9v ~/main.i
$ gcc-4.4 main.i
/home/vladimir/Documents/Sondage/main.c:12: error: declaration of 'Saisie' as
array of voids
/home/vladimir/Documents/Sondage/main.c:12: error: return type is an incomplete
type
/home/vladimir/Documen
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-12-29
13:23 ---
Created an attachment (id=19414)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19414&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42538
--- Comment #13 from debian-gcc at lists dot debian dot org 2009-12-29
13:34 ---
looks fine to me (but I cannot approve). I'm using this patch already for
package builds without seeing regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
I tried to implement C++0x's std::is_explicitly_convertible, but decltype
crashes on my code with an internal compiler error. The code is:
#include
namespace my_std
{
namespace impl
{
template< typename T > T make();
template< typename From, typename To >
decltype( From( make< T
class A {
A();
virtual void B();
};
A::A() {}
/* Whoops, I forgot to define A::B() */
$ g++ -Wall a.cc
/usr/lib/../lib/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/tmp/ccaVlePI.o: In function `A::A()':
a.cc:(.text+0xf): undefined reference to `vtable for A'
--- Comment #1 from gcc at daryl dot haresign dot com 2009-12-29 14:55
---
I've just looked at this again. It seems the is not being printed in the
second case due to the line:
1463 && !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION(t)
in gcc/cp/error.c, in the function dump_functio
--- Comment #1 from simon at pushface dot org 2009-12-29 15:01 ---
Get a similar failure building GCC 4.3.3:
/Users/simon/gcc-build-4.3.3-x86_64/./gcc/xgcc
-B/Users/simon/gcc-build-4.3.3-x86_64/./gcc/
-B/opt/gcc-4.3.3-x86_64/x86_64-apple-darwin10.2.0/bin/
-B/opt/gcc-4.3.3-x86_64/x86_64-
--- Comment #1 from d dot frey at gmx dot de 2009-12-29 15:05 ---
Note that the code is actually quite broken, the main problem which causes the
ICE is:
decltype( impl::select< From, To > )
which should read something like:
decltype( impl::select< From, To >() )
I meanwhile have a wo
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-29 15:05 ---
I don't know if there is anything there could be done here since the linker is
what is producing the error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-29 15:05
---
This doesn't crash in mainline, and I'm pretty sure Jason doesn't mean to fix
this kind of problem in 4_4-branch at this late time in the branch. I'm Cc-ing
him, anyway, because in mainline the first two assert
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-29 15:08
---
Ah, ok, read the other message in the audit trail, we can close this.
Do you have a copyright assignment on file? In that case, your contribution is
certainly welcome, please send your implementation to the li
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-12-29 15:24
---
There is something strange: the report is about a native i386 compiler built on
x86-64 but the configure line is for a native x86-64 compiler. Which one is
correct? Does the base compiler target i386 or x86-64?
--- Comment #26 from debian-gcc at lists dot debian dot org 2009-12-29
15:35 ---
No yet quiet right:
$ cat main.c
int main() {}
$ gcc -c -g -Wall -Wno-long-double main.c
main.c: In function 'main':
main.c:1:1: warning: control reaches end of non-void function
At top level:
cc1: warnin
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-29 15:42 ---
The -flto and -fwhopr are most a GCC bug but the rest of the issues look like
gold ld issue and should be reported to binutils.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2009-12-29 15:48
---
*** Bug 29313 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-12-29 15:48
---
*** This bug has been marked as a duplicate of 41219 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-12-29 15:56
---
> So given the above, I still think the patch from comment 7 will help.
> Because I don't have any access to a non-Linux platform I cannot try
> it myself and thus can only rely on others to test it for me. I'll
Please could you install except.h libfuncs.h version.h in the plugin header
directory? They're necessary for building dragonegg.
--
Summary: [PATCH] install except.h libfuncs.h version.h (plugin
headers)
Product: gcc
Version: 4.5.0
--- Comment #1 from rmh dot gcc at aybabtu dot com 2009-12-29 15:59 ---
Created an attachment (id=19415)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19415&action=view)
makefile patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42541
--- Comment #4 from rmh dot gcc at aybabtu dot com 2009-12-29 16:03 ---
Mail to gcc-patches sent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42537
seen at least on x86_64. bug submitter writes:
g++ appears to be (incorrectly) using a signed int comparison when -O3
optimization is enabled. Compiling with -O2 or lower produces the correct
output.
#include
#include
template
struct maximum
{
T operator()(T& a, T& b)
{
retur
--- Comment #1 from steven at gcc dot gnu dot org 2009-12-29 16:11 ---
I can reproduce the ICE, but unfortunately not inside gdb yet.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-12-29 16:18
---
Appears to be fixed (I can build a bfin-unknown-elf compiler on
x86_64-apple-darwin10.2.0).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from pmaydell at chiark dot greenend dot org dot uk
2009-12-29 16:18 ---
>only when no other warning is present, the warning about the unrecognized
>option vanishes:
Um, that is the correct behaviour as described and implemented in this bug,
isn't it?
--
http://gcc
--- Comment #10 from schwab at linux-m68k dot org 2009-12-29 16:29 ---
m68k-amigaos is not a supported target.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #16 from schwab at linux-m68k dot org 2009-12-29 16:31 ---
m68k-amigaos is not a supported target.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #7 from debian-gcc at lists dot debian dot org 2009-12-29
16:38 ---
this appears to be fixed, at least in 4.3.5 and 4.4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
--- Comment #1 from rwild at gcc dot gnu dot org 2009-12-29 16:42 ---
Created an attachment (id=19416)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19416&action=view)
patch to avoid tr '\n', for Solaris /usr/bin/tr
You can either try the attached patch, or have a POSIX tr early i
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-12-29
16:49 ---
confirmed with trunk 20091228
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26155
--- Comment #5 from rwild at gcc dot gnu dot org 2009-12-29 16:52 ---
What happens if you enter /cygdrive/e/Home/cvsroot/gcc-obj/libgcc, create a
small conftest.c with 'int main () {}' and try to compile it with this command:
/cygdrive/e/Home/cvsroot/gcc-obj/./gcc/xgcc
-B/cygdrive/e/Hom
Hello,
In the past, I was using gcc 3.4.5 and the code was compiled well. I changed my
gcc to version 4.4.1 and this internal compiler occured :
main.c:56: internal compiler error: in gimplify_expr, at gimplify.c:7098
That might be helpfull for you,
Arnaud
--
Summary: internal comp
--- Comment #1 from arnaud dot kodeck at lakoco dot be 2009-12-29 17:09
---
Created an attachment (id=19417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19417&action=view)
Source file where the bug occured
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
--- Comment #2 from arnaud dot kodeck at lakoco dot be 2009-12-29 17:10
---
Created an attachment (id=19418)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19418&action=view)
The preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-29 17:17 ---
The trunk still ICEs:
gimplification failed:
(char *) args2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42543
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-29 17:23 ---
A simple testcase:
[...@gnu-26 rrs]$ cat pr42538.i
void Saisie()[3]{
}
[...@gnu-26 rrs]$ ./143523/usr/bin/gcc -S pr42538.i
pr42538.i:1: error: declaration of Saisie as array of voids
pr42538.i:1: internal compile
--- Comment #3 from jacob dot benoit dot 1 at gmail dot com 2009-12-29
17:27 ---
Could someone confirm that this is a 4.5 ICE regression and tag it as such?
Happy holidays!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42450
--- Comment #17 from ami_stuff at o2 dot pl 2009-12-29 17:29 ---
> m68k-amigaos is not a supported target.
LOL! So you prefere to not get any bugreports? I reported a few bugs which were
next confirmed on the other hardware and after some time fixed, no matter if I
use unsupported m68-a
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-29 17:32 ---
I am not sure if
---
char* FormatStringEx (char str[], size_t max_length, char templ[],
void* args, unsigned int flags)
{
...
void *args2;
char *arg,c;
...
while (index-- > 0 && (arg=va_arg((
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-29 17:33 ---
Icc 11.1 generates:
[...@gnu-6 rrs]$ /opt/intel/Compiler/11.1/059/bin/intel64/icc -S pr42543.c
pr42543.c(55): error: cast to type "va_list" is not allowed
while (index-- > 0 && (arg=va_arg((va_list)arg
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-12-29 17:42
---
I can confirm the segfault at -O3 with current trunk (rev. 155505) on
x86_64-apple-darwin10.2.0. I also generated a (much) reduced testcase:
void K (int *gpwgts, int *badminpwgt, int *badmaxpwgt)
{
int i;
fo
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
GCC build triplet|i686-apple-darwin9 |
GCC
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-12-29 17:48
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build t
--- Comment #18 from bonzini at gnu dot org 2009-12-29 18:01 ---
True, it is P5 but it is not invalid. Andreas, if you want to close this as
invalid you should first follow the target deprecation process and propose to
remove the target for 4.6.
--
bonzini at gnu dot org changed:
--- Comment #1 from foo at mailinator dot com 2009-12-29 18:02 ---
5/9 (usual arithmetic conversions) isn't relevant until after 4.5/1 (integral
promotions) has happened. Unsigned short *always* promotes to int in rvalue
contexts; then *that* int is implicitly converted to double in the
--- Comment #3 from simon at pushface dot org 2009-12-29 18:06 ---
Sorry if I've caused confusion by misunderstanding the reporting system.
I can build GCC4.4.2[i386-apple-darwin10.2.0] using
GNAT-GPL-2009[i386-apple-darwin10.2.0].
I then try to build GCC4.4.2[x86_64-apple-darwin10.2.0
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-29 18:09 ---
(In reply to comment #0)
I believe that this code is doubly invalid:
(i) You cannot have an automatic array in the main program; and
(ii) An automatic array cannot have an initialization expression.
Both g95 and ifort
extern int puts(const char *);
int main() {
signed short 8000 = 0x8000;
if ((unsigned int)8000 >= 0x1uLL) {
puts("FAIL");
}
return 0;
}
% gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is fre
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:25 ---
Are you building on a Core Duo (ie non-EMT64 capable) machine? If not, the
default code generation of the Apple system compiler should be to execute and
generate x86_64 code under 10.6. You can't take the o
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:32 ---
You might try current gcc 4.4.2 branch. It contains the latest config.guess
which determines the architecture type according to the system compiler's
default code generation for intel darwin.
--
http:/
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-12-29
18:33 ---
I meant gcc-4_4-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42518
--- Comment #8 from kargl at gcc dot gnu dot org 2009-12-29 18:37 ---
(In reply to comment #7)
> this appears to be fixed, at least in 4.3.5 and 4.4.2
>
The problem still exist on at least x86_64-*-freebsd.
troutmask:sgk[216] gfc4x -c homework-2.f90
...
Error: Different shape for arr
Reported by Reinhold Bader.
The error occurs for inherited type-bound procedures where the extending type
has "PRIVATE" for the components and the TBP procedure is accessed using the
syntax
% %
The error message is as follows:
mr_shorter.f90:23.14:
call obj%tt%set()
1
Erro
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-12-29 18:39
---
Fixed. Now all fixincludes tests pass on x86_64-apple-darwin10.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from nospamname at web dot de 2009-12-29 18:44 ---
The Problem is fixed in GCC4.5.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
--- Comment #7 from simon at pushface dot org 2009-12-29 18:48 ---
I think the immediate cause is that the alignment for generated tagged type
support objects (see eg exp_disp.adb:4007) is derived from that of
System.Storage_Elements.Integer_Address (defined as mod Memory_Size) which
sho
--- Comment #8 from nospamname at web dot de 2009-12-29 18:52 ---
I have now find out with cflag -m68000 work with -O3.
But it work not with -m68020 or -m68040 or -m68060
Here is a standalone testcode and output with -S
-
struct test{
long dummy;
unsigned long buf;
};
struct una
--- Comment #9 from kargl at gcc dot gnu dot org 2009-12-29 18:58 ---
Some addition information from valgrind.
Error: Different shape for array assignment at (1) on dimension 1 (0 and 2)
==13911== Invalid read of size 8
==13911==at 0x1C108F8: __gmpz_get_si (in /usr/local/lib/libgmp.
As reported by James Van Buskirk
at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3aad8fb30b5174f4
Part of the reported issue is PR 41872. Remaining issue is:
"13.7.9 ALLOCATED (ARRAY) or ALLOCATED (SCALAR)
[...]
Arguments.
ARRAY shall be an allocatable array.
SCA
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-29 19:05 ---
Created an attachment (id=19419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19419&action=view)
Incomplete draft patch (diff) + Test case (bottom, no diff format)
Draft patch.
- Misses modification to trans-i
James reported some documentation issues in post 3 at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3aad8fb30b5174f4
For the first post (ALLOCATE issues), see PR 42546.
--
Summary: Issues in intrinsics.texi documentation
Product: gcc
Ver
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-29 19:12 ---
For the .texi changes, see also
http://gcc.gnu.org/ml/fortran/2009-12/msg00183.html
(I have not checked whether this covers all)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42547
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-29 19:12 ---
For the .texi changes, see also
http://gcc.gnu.org/ml/fortran/2009-12/msg00183.html
(I have not checked whether this covers all). Cf. also PR 42547.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42546
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-29 19:26 ---
In fact it depends on the key function being declared which depends on the ABI
really (ARM EABI has a slightly different key function than the rest of the
abis).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42
--- Comment #6 from bonzini at gnu dot org 2009-12-29 19:29 ---
Causes PR40414 on GCC 4.4.x, reopening to make the other PR depend on this.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2009-12-29 19:29
---
> I then try to build GCC4.4.2[x86_64-apple-darwin10.2.0] using
> GCC4.4.2[i386-apple-darwin10.2.0], with the reported results.
>
> [...]
>
> I've been using --build=x86_64-apple-darwin10.2.0 to indicate that I wa
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-29 19:30 ---
Subject: Bug 42517
Author: janus
Date: Tue Dec 29 19:29:54 2009
New Revision: 155506
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155506
Log:
gcc/fortran/
2009-12-29 Janus Weil
PR fortran/42517
--- Comment #21 from bonzini at gnu dot org 2009-12-29 19:30 ---
Reopening since it is still broken on the other open branches.
--
bonzini at gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from bonzini at gnu dot org 2009-12-29 19:30 ---
Adding dependencies on the patches that fix the bug.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from hjl dot tools at gmail dot com 2009-12-29 19:41 ---
With -Wall, icc 11.1 complains:
pr42542.cc(10): remark #981: operands are evaluated in unspecified order
return (a < b) ? b : a;
^
detected during instantiation of "_Tp std::a
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/16f799318c80df77
If I run the test case, I have the problem that for
call writeit(11) ! write formatted STREAM
call writeit(6) ! write formatted to stdout
I do not get any output to STDOUT -- and a "flush
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-29 19:44 ---
Add "-ftree-vectorize" will cause it to fail.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-29 19:45 ---
It could be a target issue.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2009-12-29 19:51 ---
There are no unsigned integer vector compare insns on x86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-29 19:53 ---
(In reply to comment #0)
> I have not checked for the other issues reported in the thread such as writing
> NUL ('\0') characters instead of spaces (" "). The issue is allegedly related
> to the handling of missing ar
1 - 100 of 159 matches
Mail list logo
