--- Comment #4 from steven at gcc dot gnu dot org 2009-03-10 06:48 ---
The load to the general register should also be moved by bt-load, then.
The bt-load pass is "designed" for SH only, in its current state, but I think
extending it to move a small group of insns instead of just one sh
--- Comment #14 from steven at gcc dot gnu dot org 2009-03-10 06:32 ---
ISTR Richi has scripts to automatically identify file+function that is
miscompiled...?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:27 ---
(In reply to comment #3)
> (In reply to comment #1)
MIRO: Mudflap Improved with Referent Objects - Works on OpenSolaris also.
http://gcc.gnu.org/wiki/MIRO
Results for gcc version 4.4.0 20080520 (experimental) [miro revisi
--- Comment #4 from rob1weld at aol dot com 2009-03-10 04:22 ---
(In reply to comment #3)
> Dismal Testsuite results are here:
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02284.html
> Rob
Great results are here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02375.html
--
--- Comment #13 from hjl dot tools at gmail dot com 2009-03-10 03:52
---
(In reply to comment #12)
> Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
> loc_descriptor_from_tree_1
>
> > --- Comment #11 from hjl dot tools at gmail dot com 2009-03-08 17:40
> > ---
>
>
--- Comment #3 from contact at multimedia dot cx 2009-03-10 03:01 ---
Confirmed fixed with revision 144720. Thanks.
--
contact at multimedia dot cx changed:
What|Removed |Added
---
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2009-03-10
01:47 ---
Subject: Re: [4.4 Regression] ICE at dwarf2out.c:10353 in
loc_descriptor_from_tree_1
> --- Comment #11 from hjl dot tools at gmail dot com 2009-03-08 17:40
> ---
> It seems that stage2 cc1plus
--- Comment #3 from casmyu at gmail dot com 2009-03-10 01:23 ---
Hi:
I have changed the code as you said, but it is more error now.
1 #include
2
3 int main()
4 {
5 char src[30] = {"This is a test message.\n"};
6 char dst[30];
7 int len = 25;
8
9 __asm_
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-03-09 23:22 ---
This works on the trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #3 from maksverver at geocities dot com 2009-03-09 23:21
---
Created an attachment (id=17433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17433&action=view)
The broken tree code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #2 from maksverver at geocities dot com 2009-03-09 23:21
---
Created an attachment (id=17432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17432&action=view)
The working tree code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
--- Comment #1 from maksverver at geocities dot com 2009-03-09 23:19
---
Created an attachment (id=17431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17431&action=view)
The test case that fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39417
Attached is a small program that computes some values and puts them in a
std::vector. The values are stored in the `init' variable, but when
optimizations are enabled, the data actually added to the vector is garbage.
I've done a little testing and the problem exists when compiling with -O and
-O2
--- Comment #1 from burnus at gcc dot gnu dot org 2009-03-09 22:00 ---
> procedure() :: p
> integer :: p
I think it is valid; ifort 11beta also accepts it. (NAG 5.1 doesn't.)
Looking at "12.3.2.3 Procedure declaration statement" one sees that
"PROCEDURE()" is has the same effect as the
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-09 21:28 ---
It is hard for the library to know if we are doing an insert or doing an
extract as there is only one type of operator[] really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39416
--- Comment #2 from glyn at adgie dot f9 dot co dot uk 2009-03-09 21:25
---
Thanks Paolo, I suspected that this was not a bug in libstdc++, but
standard-compliant behaviour.
It just seems so unexpected, when compared to other languages that have maps,
e.g. tables in Lua. It is also une
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 21:12 ---
Yeah, before r128631 (PR debug/33316) it ICEd in modified_type_die, after it in
gen_tagged_type_instantiation_die.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 20:53
---
There is nothing wrong here, the bahavior is fully specified in the Standard,
23.3.1.2 as:
Returns: (*((insert(make_pair(x, T(.first)).second.
Note, our inline documentation comments are also very clear
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-09 20:52 ---
This is introduced by revision 117493:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00158.html
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00239.html
--
hjl dot tools at gmail dot com changed:
What|
#include
#include
#include
// Demonstrate unexpected behaviour of std::map::operator[] when used in a read
// context, e.g. on the right hand side of an assignment.
//
// The intended application is a shell environment table, where accessing a
// non-existent variable should yield an empty stri
--- Comment #10 from jmichae3 at yahoo dot com 2009-03-09 20:12 ---
I didn't read that in the documentation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39404
This is silently accepted:
struct T { };
struct T_impl: public T { };
T_impl *g(T *tp) { return static_cast(tp); }
The result type of the static_cast is pointer-to-const and should not
convert to a pointer-to-non-const. This seems to be specific to when
it is used as a downcast. Replacing
--- Comment #5 from jakub at gcc dot gnu dot org 2009-03-09 19:35 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-09 19:34 ---
Subject: Bug 39371
Author: jakub
Date: Mon Mar 9 19:34:10 2009
New Revision: 144732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144732
Log:
PR c++/39371
* semantics.c (finish_switch_cond):
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
The following code is invalid, but currently accepted by gfortran:
procedure(iabs) :: p
integer :: p
end
It is also accepted when the two statements are reversed in order.
It's not completely obvious to me whether this variant is invalid, too:
procedure() :: p
integer :: p
It is rejected by g95
--- Comment #3 from paolo dot carlini at oracle dot com 2009-03-09 18:17
---
Volunteers for a better Summary?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16
---
*** Bug 39407 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pinskia at gcc dot gnu dot org 2009-03-09 18:16
---
*** This bug has been marked as a duplicate of 10200 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from jwakely dot gcc at gmail dot com 2009-03-09 18:13
---
aha, on PR 11814 you mention PR 20308 which is the same.
Thanks, Andrew!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 18:10
---
The below, not using any header neither C++0x mode (very likely can be further
reduced), doesn't compile with mainline and 4_3-branch, does with EDG-based
compilers in strict mode:
template
class __static_as
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 17:48
---
let's try to simplify the issue as much as possible... are defaulted / deleted
functions really necessary to trigger the bug? Thus, is c++0x mode really
necessary?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-03-09 17:42
---
This is related to PR 11814 or is the same bug. I thought there was an exact
duplicate of this parsing issue but I cannot find it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
ot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: GCC-4.4.0 (20090309), Cygwin, Windows XP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39413
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39412
struct S { int i; };
void
bar (const void *x, unsigned long y)
{
const union { struct S a[y / sizeof (struct S)]; } *u = x;
}
void
foo (const void *x, unsigned long y)
{
bar (x, y);
}
ICEs at -O[23s] -g with
internal compiler error: in gen_tagged_type_instantiation_die, at
dwarf2out.c:14850
--- Comment #12 from paolo dot carlini at oracle dot com 2009-03-09 16:24
---
Seriously, thanks Jonathan for the reduced C++ snippet. Really, this way of
seeing the issue makes much more sense to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #11 from paolo dot carlini at oracle dot com 2009-03-09 16:19
---
Better... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-03-09 16:08
---
reduced:
template struct x;
template struct y { int x; };
template
bool operator<(const y& l, const y& r) { return l.x < r.x; }
It doesn't happen except in a template context, so it seems that l.x< is parse
Hi Team,
I have 'GNAT BUG DETECTED' error message when I try to compile my project. I am
providing the more simple example of source code which will help to reproduce
the problem.
Please, advise
+===GNAT BUG DETECTED==+
| 4.3.2 (i386-portbld-fr
--- Comment #9 from pinskia at gmail dot com 2009-03-09 15:59 ---
Subject: Re: Parse error in when user declares template-name c
Sent from my iPhone
On Mar 9, 2009, at 8:40 AM, "rguenth at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #7 from rguenth at gcc dot gnu dot org
Sent from my iPhone
On Mar 9, 2009, at 8:40 AM, "rguenth at gcc dot gnu dot org" > wrote:
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09
15:40 ---
I think this is more likely a C++ frontend issue. At least I cannot
believe
this behavior is mandated by the std
--- Comment #8 from hjl dot tools at gmail dot com 2009-03-09 15:58 ---
Icc 11 has no problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #2 from pinskia at gmail dot com 2009-03-09 15:57 ---
Subject: Re: Excessive optimization issue
Sent from my iPhone
On Mar 9, 2009, at 8:36 AM, "rguenth at gcc dot gnu dot org"
wrote:
>
>
> --- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09
> 15:36 --
Sent from my iPhone
On Mar 9, 2009, at 8:36 AM, "rguenth at gcc dot gnu dot org" > wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09
15:36 ---
You need to specify that the registers are clobbered by the asm.
The only
way to do that is to use output constrai
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-03-09 15:40 ---
I think this is more likely a C++ frontend issue. At least I cannot believe
this behavior is mandated by the std ;)
Jason?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-03-09 15:37 ---
This flag isn't supposed to be used with libstdc++.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-09 15:36 ---
You need to specify that the registers are clobbered by the asm. The only
way to do that is to use output constraints ("+D", "+c", etc.) on proper
temporaries.
int lent = len;
char *dstt = dst;
char *srct = s
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-03-09 15:20
---
(In reply to comment #5)
> Well, the as-if rule allows (x.c < ((y.c)) too of course.
bah - it would allow it if I could type the right number of closing
parentheses!
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-03-09 15:19
---
Well, the as-if rule allows (x.c < ((y.c)) too of course.
I could be wrong and the compiler should parse it ok, I haven't thought about
it very hard.
The same problem occurs here, although it's only in a
--- Comment #4 from paolo dot carlini at oracle dot com 2009-03-09 15:08
---
Before considering touching the library, I want evidence that at least another
widespread implementation has that operator< somehow different than the obvious
way. Besides, the issue affects too, of course, an
--- Comment #5 from r dot emrich at de dot tecosim dot com 2009-03-09
15:07 ---
(In reply to comment #4)
> Sorry, pex_run & co aren't the reason for this issue. By further debugging I
> found that for bigger functions using alloca with variable sizes wrong code is
> generated for optimi
--- Comment #1 from amit at mobiletornado dot com 2009-03-09 14:38 ---
Created an attachment (id=17430)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17430&action=view)
the preprocessed file (gzipped)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39409
$ uname -a
system type: AIX aix52a 1 6 000921F2D700
$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs -
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-03-09 14:25
---
(In reply to comment #2)
> FWIW, if I use v3 together with the Intel C++ compiler, it builds...
>
That's interesting, Comeau's online compiler gives a very similar error to gcc
4.3.2
--
http://gcc.gnu.org/b
--- Comment #10 from jakub at gcc dot gnu dot org 2009-03-09 14:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from paolo dot carlini at oracle dot com 2009-03-09 14:02
---
FWIW, if I use v3 together with the Intel C++ compiler, it builds...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #9 from jakub at gcc dot gnu dot org 2009-03-09 14:01 ---
Subject: Bug 39394
Author: jakub
Date: Mon Mar 9 14:01:29 2009
New Revision: 144727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144727
Log:
PR tree-optimization/39394
* gimplify.c (gimplify
--- Comment #1 from paolo dot carlini at oracle dot com 2009-03-09 14:00
---
disgusting ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39407
--- Comment #6 from matz at gcc dot gnu dot org 2009-03-09 13:25 ---
It's also PRE that produces such patterns, so moving predcom behind
vectorization alone won't help this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 13:16 ---
This is likely dup of PR39360, please retry with a newer snapshot.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
It was just brought to my attention that this fails to compile:
template void c();
#include
In file included from
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../include/c++/4.3.2/stack:67,
from mark.cc:2:
/sbcimp/run/pd/gcc/32-bit/4.3.2/lib/gcc/i68
--- Comment #1 from dcb314 at hotmail dot com 2009-03-09 11:53 ---
Created an attachment (id=17429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17429&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39406
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-09 11:52 ---
Created an attachment (id=17428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17428&action=view)
gcc44-pr39394.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
I just tried to compile the Suse Linux package sparse sparse-0.4.1.git1-1.56
with the GNU C compiler version 4.4 snapshot 20090306
and the compiler said
sparse.c: In function 'check_context':
sparse.c:546: internal compiler error: in referenced_var_lookup, at
tree-dfa.c:563
Please submit a full bu
--- Comment #8 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09
11:34 ---
Thanks Jerry.
PS
CHARACTER(80) :: str
no longer required in test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
--- Comment #7 from davidgkinniburgh at yahoo dot co dot uk 2009-03-09
11:33 ---
Thanks Jerry.
PS
CHARACTER(80) :: str
no longer needed in test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39402
--- Comment #7 from jakub at gcc dot gnu dot org 2009-03-09 11:28 ---
Oops, sorry. I guess the problem is that this VL type isn't gimplified.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-09 11:09 ---
Confirmed. Simplified testcase:
extern inline void *
asmfn (void *dest, const void *src, unsigned long n)
{
asm volatile (""
: "=m" (*(struct { char x[n]; } *) dest)
: "r" (n), "r" (dest), "r" (src),
"m" (*(struct
--- Comment #5 from falk at debian dot org 2009-03-09 10:59 ---
Here's a test case:
void *p;
extern inline void *f1(int n) {
asm volatile("" : "=m"(*(struct { char x[n]; }*) p));
}
int x;
extern inline void f2() {
x ? f1(1) : f1(2);
}
inline void f3() { f2(); }
void f4() { f3(
Can't see why this shouldn't work with std::shared_ptr; changing the type of
m_foo to std::shared_ptr, i.e. leaving out the redundant template
argument, changes nothing; only when making foo a class instead of a class
template, and removing all template arguments, does it compile.
co...@weasel:/tm
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-09 10:31 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00463.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from cneil at yahoo dot com 2009-03-09 10:14 ---
OK, maybe I should slept before I submitted this.
1. The glibc-2.9 snapshot is from 20081201. I am not capable of time travel.
2. I successfully compiled this same glibc-2.9 snapshot with the gcc-4.4
snapshot from 20090
--- Comment #3 from cneil at yahoo dot com 2009-03-09 10:00 ---
Created an attachment (id=17427)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17427&action=view)
preprocessed argp-help.c
If any additional information is needed, I'll do my best to provide it.
--
http://gcc.gnu
--- Comment #2 from cneil at yahoo dot com 2009-03-09 09:58 ---
I think I'm hitting the same bug as the reporter.
i686-pc-linux-gnu-gcc argp-help.c -c -std=gnu99 -fgnu89-inline -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -fno-strict-aliasing -ggdb
-march=i686 -pipe -Wstrict
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-09 08:22 ---
This isn't related to just bool, e.g.:
void
foo (unsigned char b)
{
switch ((unsigned int) b)
{
case 1:
case 257:
break;
}
}
also results in
pr39371-2.C:7: warning: large integer implicitly trun
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-03-09
07:52 ---
>From gcc.info:
*Warning:* the `-fpack-struct' switch causes GCC to generate code
that is not binary compatible with code generated without that
switch. Additionally, it makes the code s
--- Comment #13 from dannysmith at users dot sourceforge dot net
2009-03-09 07:46 ---
(In reply to comment #12)
> Was this broken in 4.3 compilers? Is it a 4.4 regression?
>
This is not a new bug in the compiler (the same multiple definition will occur
with 3.4.5) , but an old 'featu
79 matches
Mail list logo
