--- Comment #31 from rsandifo at nildram dot co dot uk 2008-03-03 09:21
---
Subject: Re: [4.3/4.4 Regression] libstdc++ linked to system
/usr/lib/libgcc_s.1.dylib not new gcc4.3 libgcc_s.1.dylib
howarth at nitro dot med dot uc dot edu [EMAIL PROTECTED] writes:
--- Comment #25
--- Comment #8 from manu at gcc dot gnu dot org 2008-03-03 10:56 ---
This is fixed for 4.4 by introducing permerror which makes -fpermissive
completely independent of -pedantic and -pedantic-errors.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #32 from agn at noc dot soton dot ac dot uk 2008-03-03 11:33
---
Again, thanks for sorting this out so quickly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #5 from tim dot vanholder at anubex dot com 2008-03-03 12:03
---
This issue with pthread_getaffinity_np also occurs on i686 debian, when
building with --enable-targets=all (to get 64-bit output support). I have
kernel 2.4, with glibc 2.3.6 (can't upgrade due to hardware
--- Comment #2 from ubizjak at gmail dot com 2008-03-03 13:20 ---
(In reply to comment #1)
Created an attachment (id=15223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15223action=view) [edit]
Trivial Patch
Please post this patch together with appropriate ChangeLog entry to
--- Comment #2 from loki at gcc dot gnu dot org 2008-03-03 13:51 ---
I can confirm the unrecognizable insn too (r132833).
I am going to look into it.
--
loki at gcc dot gnu dot org changed:
What|Removed |Added
Jakub wrote:
BTW, omp workshare is implemented the same as omp single and this is the
first time I see somebody actually using that construct anywhere. I don't
have plans to implement omp workshare more efficiently, at least in the
foreseeable future. So ATM !$omp parallel workshare is just a
--- Comment #37 from alexandre dot nunes at gmail dot com 2008-03-03 14:30
---
If PR31849 is right, shouldn't this be reopened or marked as something other
than fixed ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #6 from burnus at gcc dot gnu dot org 2008-03-03 14:40 ---
Initial patch by Franc,ois-Xavier:
http://gcc.gnu.org/ml/fortran/2008-03/msg7.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112
Both tests show the same failure:
terminate called after throwing an instance of 'std::runtime_error'
what(): allocation/deallocation count isn't zero
operator new is called
operator new is called
operator new is called
operator new is called
operator new is called
operator new is called
bash-3.2$ touch x.c
bash-3.2$ /usr/gcc-4.3/bin/gcc -mpcfooo -S x.c
x.c:1: error: pc0 is not valid precision setting (32, 64 or 80)
bash-3.2$ /usr/gcc-4.3/bin/gcc -mpc80x -S x.c
bash-3.2$
There are 2 issues:
1. pc0 isn't specified.
2. -mpc80x should be an error.
--
Summary:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-03-03 16:21
---
Subject: Bug 35262
Author: hubicka
Date: Mon Mar 3 16:20:31 2008
New Revision: 132838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132838
Log:
PR c++/35262
* ipa-inline.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35193
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-03-03 16:29 ---
(In reply to comment #6)
gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
applied.
yes and 3.4.x is no longer maintained (4.0.x likewise).
--
pinskia at gcc dot gnu dot org
--- Comment #3 from olafvdspek at gmail dot com 2008-03-03 16:30 ---
Hmm, should I change the status back to NEW manually?
--
olafvdspek at gmail dot com changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-03
16:33 ---
Subject: Re: [4.3/4.4 Regression] EH output contains procedure label without
P' selector
The same fail occurs on hpux11 if I disable the use of secondary
definition symbols for one-only support.
Have
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #8 from tprince at computer dot org 2008-03-03 16:20 ---
pr31341 has a patch attached to allow the test case to run on targets where
there is checking for conflicts with stdint.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
--- Comment #6 from tprince at computer dot org 2008-03-03 16:26 ---
gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were
applied.
--
tprince at computer dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-03 16:34 ---
No, we only confirm bugs once they have a reduced testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35057
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #12 from hubicka at gcc dot gnu dot org 2008-03-03 16:23
---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-03 16:37 ---
basic_endpoint()
: data_()
{
asio::detail::sockaddr_in4_type data
= reinterpret_castasio::detail::sockaddr_in4_type(data_);
data.sin_family = 2;
data.sin_port = 0;
data.sin_addr.s_addr
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-03 17:02 ---
(In reply to comment #2)
Oh, and both versions were built with mpfr 2.2.1, which configure told me was
buggy but acceptable (if I remember the wording correctly) - is this my
problem?
I think so. Can you try to
A simple C source fails with an ICE with 4.3.0 (the 20070907 and 20080228
snapshots) with optimizations (-O1/-O2/-Os -- I haven't narrowed it down to
which exact optimization though). This machine is x86-64 but the same assertion
occurs targeting both x86-64 (-m64) and x86 (-m32). Fedora Core 5
--- Comment #2 from lloyd at randombit dot net 2008-03-03 16:57 ---
Oh, and both versions were built with mpfr 2.2.1, which configure told me was
buggy but acceptable (if I remember the wording correctly) - is this my
problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
--- Comment #1 from lloyd at randombit dot net 2008-03-03 16:55 ---
Created an attachment (id=15255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15255action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35426
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-03 17:49 ---
nelem*sizeof(long)
Wraps so what do you expect? This is the correct behavior really.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from debian-gcc at lists dot debian dot org 2008-03-03
17:57 ---
an ecj update to 20080303 from the R3_3_maintenance branch doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410
I found that an result of pointer subtraction in a big array is negative when
it is expected to be positive.
% cat t.i
typedef int ptrdiff_t;
typedef unsigned int size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__));
extern void exit (int __status) __attribute__
--- Comment #13 from pcarlini at suse dot de 2008-03-03 19:04 ---
Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
machines I'm not seeing any progress :(
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2008-03-03 19:35 ---
Quoting your insn once more:
(insn 58 57 59 6 gnu/java/nio/natVMSelector.cc:82 (parallel [
(set (reg:DI 4 si [165])
(mult:DI (zero_extend:DI (reg:SI 0 ax))
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #1 from ubizjak at gmail dot com 2008-03-03 19:52 ---
You can put all arguments that use atoi() to this PR:
-mregparm=aaa, -mbranch-cost=foo, -mpreferred-stack-boundary=10^5, ...
Do we really need to fix this?
--
ubizjak at gmail dot com changed:
What
The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with -O:
int foo(__complex__ int z0, __complex__ int z1)
{
return z0 != 0 || z1 != 0;
}
bug.c: In function
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35429
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -ftrapv -O3:
void foo(int x[])
{
int i, j;
for (i = 0; i 2; i++)
for (j = 0; j 2; j++)
{
x[i] = x[i*j];
x[i] = x[i*j];
}
}
The following valid code snippet triggers an ICE since GCC 4.0.0 when compiled
with -W:
void foo(__complex__ int i)
{
i == 0u;
}
bug.c: In function 'foo':
bug.c:3: internal compiler error: tree check: expected integer_type or
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
The following valid code snippet triggers an ICE since GCC 4.1.0 when compiled
with -O2:
void bar();
void foo(int i)
{
__complex__ int k = 0;
if (i)
k = 1;
for (i = 0; i 1; ++i)
;
if (k)
bar();
}
bug.c: In
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35431
This is caused by the vectorizer.
Sent from my iPhone
On Mar 3, 2008, at 11:50, reichelt at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
The following valid code snippet triggers an ICE on mainline and 4.3
branch
when compiled with -ftrapv -O3
-- Pinski
--- Comment #1 from pinskia at gmail dot com 2008-03-03 20:14 ---
Subject: Re: New: [4.3/4.4 regression] ICE with -ftrapv
This is caused by the vectorizer.
Sent from my iPhone
On Mar 3, 2008, at 11:50, reichelt at gcc dot gnu dot org
[EMAIL PROTECTED]
wrote:
The following
The following valid code snippet triggers an ICE since GCC 4.1.0:
struct A
{
char c[0];
};
void foo(struct A a)
{
(a = a).c;
}
bug.c: In function 'foo':
bug.c:8: internal compiler error: Segmentation fault
Please submit a
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35432
The following (IMHO valid) code snippet triggers an ICE since GCC 4.1.0:
typedef int* X;
typedef int* Y;
X (*p)[][0];
Y (*q)[][0];
typeof(*(0 ? p : q)) x = { 0 };
bug.c:7: internal compiler error: Segmentation fault
Please
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-03 20:29
---
This is caused by the vectorizer.
Indeed. The ICE appears also with -ftrapv -O -ftree-vectorize.
(This still compiles fine on the 4.2 branch.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35433
The following invalid code snippet triggers an ICE since GCC 4.2.0:
===
typedef int i __attribute__((alias(j)));
===
bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1267
Please submit a full
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35434
The following (valid?) code snippet triggers an ICE since GCC 3.3:
==
typedef int X __attribute__((tls_model(initial-exec)));
==
bug.c:1: internal compiler error: tree check:
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35435
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35436
The following invalid code snippet triggers an ICE since GCC 4.0.0:
===
struct A
{
int i;
struct A a;
};
void foo()
{
struct A b = { 0 };
}
===
bug.c:4: error: field 'a' has incomplete type
bug.c: In function 'foo':
bug.c:9: internal
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35437
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with -fopenmp:
void foo();
#pragma omp threadprivate(foo)
bug.c:2: internal compiler error: tree check: expected var_decl, have
function_decl in
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with -fopenmp:
void x[1];
#pragma omp threadprivate(x)
bug.c:1: error: declaration of 'x' as array of voids
bug.c:2: internal compiler error: tree
--- Comment #19 from bugzilla-gcc at thewrittenword dot com 2008-03-03
21:12 ---
Proposed patch:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00162.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20366
The following invalid code snippet triggers an ICE since GCC 4.1.0:
struct A {};
void foo()
{
(struct A){}();
}
The compiler crashes trying to emit an error message, which results in a
completely broken diagnostic (e.g. file
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35440
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.0:
void foo(char **p, char **q)
{
(p - q)();
}
With GCC 4.0.x we got
bug.c: In function 'foo':
bug.c:3: error: called object '#'exact_div_expr'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.0.2:
==
typedef char A __attribute__((vector_size(8)));
typedef int B __attribute__((vector_size(8)));
void foo(A a)
{
((B)a)();
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35441
Target Milestone|--- |4.1.3
A broken diagnostic is issued for the following invalid code snippet
since GCC 4.1.0:
==
void foo()
{
({ int i; })();
}
==
#'bind_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35441
Target Milestone|--- |4.1.3
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
void foo(int n, int a[n], int 0);
void bar() {}
===
bug.c:1: error: expected ';', ',' or ')' before numeric constant
bug.c:2: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35444
The following invalid code snippet triggers an ICE since GCC 4.1.0:
===
int a[2][2] = { [0 ... 1] = { ; } };
===
bug.c:1: error: expected expression before ';' token
bug.c:1: internal compiler error: in finish_init,
The following invalid code snippet triggers an ICE since GCC 4.0.1:
===
extern int i;
extern int i;
int i[] = {};
===
bugI6.c:3: error: conflicting types for 'i'
bugI6.c:2: error: previous declaration of 'i' was here
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35446
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35445
The following invalid code snippet triggers an ICE since GCC 4.1.0:
==
void foo()
{
({ int i().; });
}
==
bug.c: In function 'i':
bug.c:3: error: expected declaration specifiers before '.' token
bug.c:3: error: expected declaration specifiers before '}'
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35447
The following invalid code snippet triggers an ICE on mainline and the
4.3 branch:
==
void foo()
{
0.2r == 0.2hr;
}
==
bug.c: In function 'foo':
bug.c:3: sorry, unimplemented: GCC cannot support operators with integer types
and fixed-point types that
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35448
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #7 from rwild at gcc dot gnu dot org 2008-03-03 22:35 ---
Subject: Bug 33131
Author: rwild
Date: Mon Mar 3 22:35:13 2008
New Revision: 132844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132844
Log:
2008-03-03 Peter O'Gorman [EMAIL PROTECTED]
PR
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-03-03 23:04
---
I think that -ftrapv should not be considered blocking for this purpose.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-03-03 23:18 ---
I see the test failing on i686-mingw32, but it's more complicated than just
failing for the given warning.
The warning is given, and pruned by core DejaGnu's prune_warnings. This means
that {
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:26
---
(In reply to comment #5)
Was it decided this is a platform specific library issue, not gfortran?
I think it's likely, but to be sure we need some more input. Dominique, could
you try to print out the values of
--- Comment #2 from akr at m17n dot org 2008-03-03 23:45 ---
(In reply to comment #1)
nelem*sizeof(long)
Wraps so what do you expect? This is the correct behavior really.
Oops. It wrapped.
But changing the type of nelem to size_t doesn't change the situation.
nelem *
--- Comment #14 from hubicka at ucw dot cz 2008-03-03 23:46 ---
Subject: Re: [4.4 Regression]: FAIL: abi_check
Honza, I'm sorry, can you please double-check the fix? On my x86_64-linux
machines I'm not seeing any progress :(
Hi,
this is what I get from our thester:
Differences:
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:46
---
Subject: Bug 33197
Author: fxcoudert
Date: Mon Mar 3 23:46:20 2008
New Revision: 132846
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132846
Log:
PR fortran/33197
gcc/fortran/
*
In doc/extend.texi we have:
int foo ()
@{
int x = 42;
int *y = x;
int result;
asm (magic stuff accessing an 'int' pointed to by '%1'
=d (r) : a (y), m (*y));
return result;
@}
two problems, r != result. Second problem, there should be a : before the
output constraint.
The
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-03-03 23:51
---
Tobias noted the following also need updating:
3999: /* Fortran 2008 draft allows BIND(C) for internal procedures. */
4000- if (gfc_current_state () == COMP_CONTAINS
4001-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-03 23:57 ---
ptrdiff_t is defined as a signed type so is the subtraction of two pointer
types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35427
--- Comment #15 from pcarlini at suse dot de 2008-03-04 00:09 ---
(In reply to comment #14)
Hi,
this is what I get from our thester:
Differences:
Tests that now work, but didn't before:
abi_check
so it ought to make differnece for i686-linux.
Note however, that the patch also
--- Comment #4 from akr at m17n dot org 2008-03-04 00:17 ---
The result can be representable by ptrdiff_t
because the result is number of longs.
The array is bit larger than 2**31 bytes.
So the result is bit larger than 2**29.
It is representable in signed.
--
#include iostream
struct test_a{ void load(){} };
struct test_b{ };
template template typename class Concept, typename Model
struct models
{
typedef char (yes)[2];
typedef char no;
template template typename class C, typename M, typename CM::type
P = 0
1 - 100 of 115 matches
Mail list logo
