OS version: Red Hat Enterprise Linux AS release 4 (Nahant Update 5)
gcc version: g++ (GCC) 4.1.2
gcc command: gcc -c xx.cpp
Source file:
--
#include
#include
class test
{
public:
test() { }
int** operator&() { return (int**)0; }
--- Comment #1 from evgeny at mainsoft dot com 2009-11-19 08:10 ---
Created an attachment (id=19044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19044&action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42105
--- Comment #2 from evgeny at mainsoft dot com 2009-11-19 08:12 ---
The source code published in bug description compiled successfully with gcc
(g++) 3.4.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42105
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 08:30 ---
This is by design for C++03 but for C++0x (really C++1x) it is not.
*** This bug has been marked as a duplicate of 41792 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-19 08:30 ---
*** Bug 42105 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-19 09:38
---
It is basic, yes, a point worth making with people insisting that we do have a
serious bug, thus reopening the PR at will, without trusting the competence of
the maintainers and wasting some of our time.
--
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2009-11-19 10:09
---
g...@breakpoint.cc,
Would you please submit your patch to gcc-patc...@gcc.gnu.org. Only the
linux.h version of FUNCTION_PROFILER causes problems, you can leave the m68k.h
version as is.
Thanks.
--
http://g
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-19 10:45 ---
Confirmed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #23 from dominiq at lps dot ens dot fr 2009-11-19 10:56 ---
Further reduced test case:
void
check_add_float (void)
{
_Complex float a1, a2, b2, c2;
a1 = 0.0f;
a2 = a1;
b2 = a1;
c2 = a2 + b2;
}
int
main (void)
{
check_add_float ();
}
[ibook-dhum] f90/bug% gcc4
--- Comment #24 from dominiq at lps dot ens dot fr 2009-11-19 10:58 ---
Created an attachment (id=19045)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19045&action=view)
assembly generated with gcc45 complex-sign-add_red_2.c -O1 -g
-fno-guess-branch-probability -S
ibook-dhum] f90/
--- Comment #25 from dominiq at lps dot ens dot fr 2009-11-19 10:59 ---
Created an attachment (id=19046)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19046&action=view)
assembly generated by gcc45 complex-sign-add_red_2.c -O1 -g -S
[ibook-dhum] f90/bug% as complex-sign-add_red_2_
--- Comment #26 from dominiq at lps dot ens dot fr 2009-11-19 11:00 ---
Created an attachment (id=19047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19047&action=view)
diff between complex-sign-add_red_2_nop.s and complex-sign-add_red_2_yes.s
--
http://gcc.gnu.org/bugzilla/s
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-19
11:25 ---
Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not
declared in this scope
> --- Comment #7 from alanpae at ilkda dot com 2009-11-18 19:39 ---
> changing to --disable-threa
--- Comment #9 from jakub at gcc dot gnu dot org 2009-11-19 11:54 ---
The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED
macro on __gthread_mutex_destroy argument. It is perfectly fine on
__gthread_key_delete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-19 11:57 ---
Let's have a look at the dump for the test case in comment #2.
The call to 'func' is translated to:
real(kind=4) D.1568;
struct array1_real(kind=4) parm.7;
static real(kind=4) A.6[2] = {1.000149
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:00 ---
Taking address of var causes missing may be uninitialized.
*** This bug has been marked as a duplicate of 19430 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from manu at gcc dot gnu dot org 2009-11-19 12:00 ---
*** Bug 42079 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:13 ---
If the loop does nothing, the whole loop is removed before warning about
anything. If you find a testcase where the loop does something useful, and
there is still no warning, please open a new bug report. Thanks.
--
--- Comment #7 from manu at gcc dot gnu dot org 2009-11-19 12:19 ---
This is still unconfirmed until someone looks at the dumps and check that the
variables are indeed initialized in all paths that can be sensibly detected by
GCC.
BTW, when you release code, your compiler flags should n
--- Comment #3 from manu at gcc dot gnu dot org 2009-11-19 12:22 ---
The best we can do is to add this testcase to GCC 4.5 and close this as FIXED
in mainline. These kind of fixes are typically not easy to backport.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:26
---
Created an attachment (id=19048)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19048&action=view)
Reduced testcase
To be gnatchop-ed and cross-compiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #2 from manu at gcc dot gnu dot org 2009-11-19 12:28 ---
I think this is a duplicate of either bug 2972 or bug 19808 or one of the SRA
testcases.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-19 12:31
---
> This is most likely due to one of Jan's recent commits.
Right, r154121 changed
gcc_assert ((!DECL_WEAK (vnode->decl) || DECL_COMMON (vnode->decl))
|| TREE_PUBLIC (vnode->decl) || DECL_E
--- Comment #17 from yipiha2008 at gmail dot com 2009-11-19 13:18 ---
I tried removing the whole movsi section from the machine definition file
(iwmmxt.md) but if I do that GCC refuses to compile. Reading the GCC internals
documentation it appears that the movsi section is mandatory.
Do
--- Comment #5 from pault at gcc dot gnu dot org 2009-11-19 13:25 ---
Martien,
Thank you very much for this report.
I have assigned it to myself and have a non-regtested fix:
As remarked by Janus, the problem is with the array argument. The code
produced for the proc_pointer call is
--- Comment #18 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:47 ---
(define_insn "*iwmmxt_movsi_insn"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z
,rk,?z
Simplistic build works, then fails to find cc1plus on its own
when using g++
SunOS cairo 5.10 Generic_13-08 sun4u sparc SUNW,Sun-Fire-280R
~:cairo> ../gcc-4.3.4/configure --prefix=/cairo/tmp/jblaine \
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \
--disable-shared --w
--- Comment #19 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 13:57 ---
Created an attachment (id=19049)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19049&action=view)
patch to fix reported ICE
[not official, I really do not know whether this is the cor
--- Comment #20 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:09 ---
This patch creates now
---
(insn 460 148 153 20 ../sysdeps/unix/sysv/linux/libc_fatal.c:106 (set (reg:SI
43 wcgr0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -1
--- Comment #21 from enrico dot scholz at informatik dot tu-chemnitz dot de
2009-11-19 14:39 ---
forget comment #20.
WLDRW wcgr0, [fp, #-1324]
would be an invalid instruction. Offset is 10 bit only so that the RTL is
invalid for the iwmmxt processor.
--
http://gcc.gnu.org/bugz
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-19 14:40
---
Btw I can reproduce the bootstrap comparison fail with Ada when removing the
bogus flag_gtoggle check. Fixing the problem with canonicalize_cond_expr_cond
isn't the whole story appearantly - fixing it doesn't fix
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11
---
> For not doing the boolean_type_node fixing we'd need to not pre-load the
> streamer chache with (selected) builtin type nodes but instead stream them
> with every unit and function and pass them through the mer
Declare two variables as unsigned char.
use scanf with %d to read two values and store in the variables
when executing,
the first variable have 0 instead of scanned number;
the second variable have the scanned number;
--
Summary: Scaning unsigned char variable as integer using scanf
--- Comment #1 from suren dot r at live dot in 2009-11-19 15:29 ---
Created an attachment (id=19050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19050&action=view)
Source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #3 from espindola at gcc dot gnu dot org 2009-11-19 15:30
---
Subject: Bug 42096
Author: espindola
Date: Thu Nov 19 15:30:04 2009
New Revision: 154330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154330
Log:
2009-11-19 Rafael Avila de Espindola
PR boot
--- Comment #2 from suren dot r at live dot in 2009-11-19 15:30 ---
Created an attachment (id=19051)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19051&action=view)
.i file generated
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 15:31 ---
Compiling with -W -Wall, we get the following warnings:
t.c: In function âmainâ:
t.c:9: warning: format â%dâ expects type âint *â, but argument 2 has
type âunsigned char *â
t.c:11: warning: format â
--- Comment #4 from suren dot r at live dot in 2009-11-19 15:31 ---
Created an attachment (id=19052)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19052&action=view)
.o file created
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #10 from singler at gcc dot gnu dot org 2009-11-19 15:32
---
The new patch is functional. However, for simple cases like setting integers,
I have no speedup (yet).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #11 from singler at gcc dot gnu dot org 2009-11-19 15:33
---
Created an attachment (id=19053)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19053&action=view)
Functional patch for parallel fill and fill_n.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #12 from singler at gcc dot gnu dot org 2009-11-19 15:35
---
Remove old email address.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenther at suse dot de 2009-11-19 15:36 ---
Subject: Re: flag_gtoggle in free_lang_data hides -fcompare-debug
errors
On Thu, 19 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:
> --- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-11-19 15:11
> --
--- Comment #13 from wuerzner at gmail dot com 2009-11-19 15:47 ---
If you have no speedup, do you recognize any loss of speed due to the
parallelization overhead (for small examples)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #4 from espindola at gcc dot gnu dot org 2009-11-19 15:57
---
Closing this bug as bootstrap should now work. The gold plugin still needs some
portability improvements.
--
espindola at gcc dot gnu dot org changed:
What|Removed |Added
--
With the attached sample code I get a substantial performance drop from 4.3.1
to either 4.4.1 or 4.5.0, same compiler option, same machine. To reproduce,
feed a size to the program (in the case below, 4) and time the executable.
[sfili...@donald fgp_fmm_20091112]$ gfortran -v
Using built-in
--- Comment #1 from sfilippone at uniroma2 dot it 2009-11-19 16:01 ---
Created an attachment (id=19054)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19054&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #7 from tromey at gcc dot gnu dot org 2009-11-19 16:30 ---
Created an attachment (id=19055)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19055&action=view)
modified patch
I've slightly updated the patch to handle non-public entities
as well.
--
http://gcc.gnu.org
--- Comment #8 from tromey at gcc dot gnu dot org 2009-11-19 16:45 ---
Created an attachment (id=19056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19056&action=view)
patch for readelf
This patch modifies the binutils readelf utility to
dump the new section.
--
http://gcc.g
--- Comment #22 from yipiha2008 at gmail dot com 2009-11-19 16:47 ---
I tried applying this patch:
(define_insn "*iwmmxt_movsi_insn"
- [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+ [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,rk
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-19 16:49 ---
-ftree-vectorizer-verbose=2 tells you:
eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 =
((D.1683_72));
eval.f90:32: note: not vectorized: relevant stmt not supported: D.1684_58 =
((D.1683
--- Comment #8 from paolo at gcc dot gnu dot org 2009-11-19 16:55 ---
Subject: Bug 41622
Author: paolo
Date: Thu Nov 19 16:55:25 2009
New Revision: 154335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154335
Log:
2009-11-19 Paolo Carlini
PR libstdc++/41622
*
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-19 16:59 ---
Subject: Bug 561
Author: jason
Date: Thu Nov 19 16:59:05 2009
New Revision: 154336
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154336
Log:
PR c++/561
* decl.c (static_fn_type): Split out...
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-19 17:03
---
Fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from sfilippone at uniroma2 dot it 2009-11-19 17:17 ---
(In reply to comment #2)
> -ftree-vectorizer-verbose=2 tells you:
>
> eval.f90:35: note: not vectorized: relevant stmt not supported: D.1684_73 =
> ((D.1683_72));
>
> eval.f90:32: note: not vectorized: relevant stmt
--- Comment #4 from rguenther at suse dot de 2009-11-19 17:30 ---
Subject: Re: [4.4/4.5 Regression] Vectorizer
cannot deal with PAREN_EXPR gracefully, 50% performance regression
On Thu, 19 Nov 2009, sfilippone at uniroma2 dot it wrote:
> --- Comment #3 from sfilippone at uniroma2
--- Comment #5 from suren dot r at live dot in 2009-11-19 18:05 ---
Mr. Andrew,
I dont understand the term 'undefined code'. Are you saying this is not a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42107
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-11-19 18:07 ---
(In reply to comment #5)
> Mr. Andrew,
> I dont understand the term 'undefined code'. Are you saying this is not a bug?
This is not a bug in GCC but the code you wrote. scanf's %d takes a pointer to
an int variable
Random Linux Kernel functions have 16 byte stack alignment at the start of the
function. This stack alignment happens before the
push %ebp
mov %esp, %ebp
sequence and breaks the kernel function graph tracer which needs to manipulate
the return address. When the alignment happens then still 4
--- Comment #1 from tglx at linutronix dot de 2009-11-19 18:27 ---
Created an attachment (id=19057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19057&action=view)
source code (kernel/time/timer_stat.c)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
--- Comment #2 from tglx at linutronix dot de 2009-11-19 18:28 ---
Created an attachment (id=19058)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19058&action=view)
intermediate file timer_stats.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
--- Comment #3 from tglx at linutronix dot de 2009-11-19 18:30 ---
Created an attachment (id=19059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19059&action=view)
compiler command line
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-19 18:34 ---
Is this really a bug since you have:
struct entry {
...
} __attribute__((__aligned__((1 << (4);
...
void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
void *timerf, char *comm,
--- Comment #7 from ludovic at ludovic-brenta dot org 2009-11-19 18:50
---
Created an attachment (id=19060)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19060&action=view)
Disassembly of prj-part.adb, with sources (objdump -S)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #13 from aoliva at gcc dot gnu dot org 2009-11-19 18:54 ---
> one could randomize the delta we add to next_decl_uid
Yeah, that would be an interesting test. In fact, we had something along these
lines before, when we used (randomized) pointers rather than uids, and we
faile
--- Comment #2 from bradhomer at gbis dot com 2009-11-19 19:11 ---
Subject: Re: Reference operator (&) error from included file.
Take a look at "The C Programming Language" by Kernighan and Ritchie,
chapter 5.
On 18 Nov 2009 20:11:51 -, "pinskia at gcc dot gnu dot org"
wrote:
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 19:12 ---
>Take a look at "The C Programming Language" by Kernighan and Ritchie,
chapter 5.
But this is not a reference operator at this point. It is for a reference
type. Reference types are different from the reference op
--- Comment #5 from tglx at linutronix dot de 2009-11-19 19:27 ---
(In reply to comment #4)
> Is this really a bug since you have:
> struct entry {
> ...
> } __attribute__((__aligned__((1 << (4);
>
> ...
>
> void timer_stats_update_stats(void *timer, pid_t pid, void *startf,
>
--- Comment #5 from sfilippone at uniroma2 dot it 2009-11-19 19:42 ---
(In reply to comment #4)
> Subject: Re: [4.4/4.5 Regression] Vectorizer
> cannot deal with PAREN_EXPR gracefully, 50% performance regression
>
>
> Heh, with -fwhole-program GCC optimizes the test away and I get 0.
--- Comment #6 from toon at moene dot org 2009-11-19 19:53 ---
Richard Guenther wrote:
> Well, within eval there's nothing really obvious to me. The
> innermost loop is exactly the same:
But it is a very inefficient way of vectorizing, because the inner loop's body
is either executed
--- Comment #7 from brunorex at gmail dot com 2009-11-19 20:08 ---
I don't get the error anymore with gcc 4.5.0 20091112.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
The following valid code snippet triggers an ICE on trunk
when compiled with "-O2":
===
bool foo();
struct A
{
A* fooA() { if (foo()) foo(); return this; }
virtual void barA(char);
};
template struct B
{
A *p, *q;
void fooB(char c
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-19 21:09 ---
(In reply to comment #5)
> The fix is to make use of the fact a proc_pointer component call is already
> detected and can be used to suppress the internal_pack. Thusly:
>
> Index: gcc/fortran/trans-expr.c
> =
--- Comment #2 from spop at gcc dot gnu dot org 2009-11-19 21:12 ---
Fixed in the Graphite branch. The changes of the branch will be pushed into
trunk soon.
I will commit the reduced testcase to the Graphite testsuite.
Sebastian
--
spop at gcc dot gnu dot org changed:
W
x
gcc version 4.5.0 20091119 (experimental) [trunk revision 154326] (GCC)
And now I always get the abort too:
[deuterium:~] andreast% gcj -C hello.java
gcj: Internal error: Abort trap (program ecj1)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
CrashReporter
I seeing failures in gcc.dg/cleanup-13.c on x86_64-unknown-linux-gnu and
i686-unknown-linux-gnu with gcc-4.4.3 svn. E.g.:
FAIL: gcc.dg/cleanup-13.c (test for excess errors)
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01708.html
gcc.dg/cleanup-13.c: Assembler messages:
gcc.dg/cleanup-13.c:30
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-19 21:59 ---
(In reply to comment #6)
> Index: gcc/fortran/trans-expr.c
> ===
> --- gcc/fortran/trans-expr.c(revision 154327)
> +++ gcc/fortran/trans-expr.c(wo
--- Comment #8 from spop at gcc dot gnu dot org 2009-11-19 22:14 ---
Subject: Re: [4.4/4.5 Regression] -fprefetch-loop-arrays:
ICE: in initialize_matrix_A, at tree-data-ref.c:1887
Hi,
Here is a fix for this one, on top of the graphite branch.
I will commit this fix to the gra
The attached code produces an error at runtime, however it seems fine
to me. Notice that there is no error accessing the function with the
specific name "g", while there is an error when using the generic name
"gen_g".
gfortran --version
GNU Fortran (GCC) 4.5.0 20091105 (experimental)
gfortran ./
--- Comment #3 from spop at gcc dot gnu dot org 2009-11-19 22:33 ---
Subject: Bug 42050
Author: spop
Date: Thu Nov 19 22:32:44 2009
New Revision: 154347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154347
Log:
Testcase for PR42050.
2009-11-18 Sebastian Pop
PR midd
--- Comment #9 from spop at gcc dot gnu dot org 2009-11-19 22:33 ---
Subject: Bug 40281
Author: spop
Date: Thu Nov 19 22:32:50 2009
New Revision: 154348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154348
Log:
Fix PR40281.
2009-11-18 Sebastian Pop
PR middle-end/40
--- Comment #7 from anlauf at gmx dot de 2009-11-19 22:33 ---
I tried the code on a x86 Core2 system (32 bit mode).
gfortran 4.3, 4.5:
22.74user 0.03system 0:22.82elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
Intels ifort 11.1 is only ~ 5% faster, but:
SunStudio 12.1: (sunf95 -fast
--- Comment #27 from howarth at nitro dot med dot uc dot edu 2009-11-19
23:27 ---
We have an update on radar 7397601 from Nick Kledzik...
7397601 is a bug in dsymutils. It was not handling the case when the
dwarf debug info contained an AT_location with form DW_FORM_block1 with
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-19 23:55 ---
If you remove
allocate(loc_ar(1))
deallocate(loc_ar)
in function f(), the code compiles and runs in either case.
--
kargl at gcc dot gnu dot org changed:
What|Removed |
--- Comment #28 from howarth at nitro dot med dot uc dot edu 2009-11-20
00:13 ---
Why do we have
case dw_val_class_const_double:
switch (HOST_BITS_PER_WIDE_INT)
{
case 8:
return DW_FORM_data2;
case 16:
return DW_FORM_data4;
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2009-11-20 00:20 ---
Subject: Re: overloaded function with allocatable result problem
If the code is compiled with -fdump-tree-original one
immediately see the cause of the runtime error. Eliminating
the common code
Unfortunately, but 8603 seems to cause internal compiler errors on select files
when using -O3. -O{s,0,1,2} are unaffected.
I'm attaching pp.i (preprocessed pp.c from libperl), and flist.i (preprocessed
flist.c from rsync) as test cases.
gcc-4.3.4 does not exhibit this failure, but when patched f
--- Comment #1 from mattst88 at gmail dot com 2009-11-20 00:44 ---
Created an attachment (id=19061)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19061&action=view)
Test Case 1 - pp.i - preprocessed pp.c from libperl
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
--- Comment #2 from mattst88 at gmail dot com 2009-11-20 00:45 ---
Created an attachment (id=19062)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19062&action=view)
Test Case 2 - flist.i - preprocessed flist.c from rsync
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
--- Comment #6 from tglx at linutronix dot de 2009-11-20 00:52 ---
I changed the summary to match the real problem.
Further info:
While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some
Test gcc.dg/c99-stdint-1.c checks for range of__PTRDIFF_TYPE__ and fails for
avr target.
test_misc_limits (void)
{
CHECK_SIGNED_LIMITS_2(__PTRDIFF_TYPE__, PTRDIFF_MIN, PTRDIFF_MAX, -65535L,
65535L);
On AVR pointers and integers are 16bit.
INTPTR_MIN =-32768
INTPTR_MAX = 32767
UINTPTR_MAX = 6
--- Comment #1 from joseph at codesourcery dot com 2009-11-20 01:13 ---
Subject: Re: New: c99-stdint test fails for ptrdiff test
On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote:
> __PTRDIFF_MAX__ is set by gcc at 32767 and so stdint.h gives PTRDIFF_MAX 32767
> and PT
There is an issue with non-placement deallocation:
In file included from
../../../../../../../src/ppl-0.10.2/src/Row.defs.hh:504:0,
from
../../../../../../../src/ppl-0.10.2/src/Linear_Row.defs.hh:28,
from
../../../../../../../src/ppl-0.10.2/src/Constraint.defs.hh:
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-11-20 01:47
---
Created an attachment (id=19063)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19063&action=view)
preprocessed source, still quite large
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42115
--- Comment #7 from suren dot r at live dot in 2009-11-20 02:02 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Mr. Andrew,
> > I dont understand the term 'undefined code'. Are you saying this is not a
> > bug?
>
> This is not a bug in GCC but the code you wrote. scanf's %
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-11-20 02:07
---
I found c99 limit now which explains it.
I was tempted to make PTRDIFF_TYPE signed 32 bits to solve c99 compliance -
however that completely useless as we cannot declare array exceeding > 32767
bytes anyw
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-20 02:31 ---
Fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|---
--- Comment #3 from joseph at codesourcery dot com 2009-11-20 02:36 ---
Subject: Re: c99-stdint test fails for ptrdiff test
On Fri, 20 Nov 2009, hutchinsonandy at gcc dot gnu dot org wrote:
> So should I skip ptrdiff limit test based on pointers being <32 bits? Perhaps
> ints < 32 bit
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-20 02:37 ---
.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-20 03:05 ---
I just had another email exchange about this, but can't find it right now.
Anyway, 5.3.4 [expr.new]:
A declaration of a placement deallocation function matches the declaration of a
placement allocation function if it
1 - 100 of 113 matches
Mail list logo
