[Bug target/48708] New: Invalid V2DI vector set insn generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708
Summary: Invalid V2DI vector set insn generated
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Following testcase, derived from PR48678:
#include emmintrin.h
typedef long long T __attribute__((may_alias));
struct S { __m128i d; };
__m128i
foo (long long *x, struct S *y, __m128i *z)
{
struct S s = *y;
((T *) s.d)[0] = *x;
return _mm_cmpeq_epi16 (s.d, *z);
}
ICEs with invalid insn pattern (-O2 -msse2):
t.c: In function ‘foo’:
t.c:12:1: error: unrecognizable insn:
(insn 10 9 11 3 (set (reg/v:V2DI 66 [ s ])
(vec_concat:V2DI (reg:DI 71)
(vec_select:DI (reg/v:V2DI 66 [ s ])
(parallel [
(const_int 1 [0x1])
] t.c:10 -1
(nil))
t.c:12:1: internal compiler error: in extract_insn, at recog.c:2109
The problem is in i386.c, ix86_expand_vector_set (around line 31485), where
V2DImode goes through the same code path as V2DFmode, synthesizing
unrecognisable vec_concat/vec_select insn in invalid mode.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #39 from Tobias Burnus burnus at gcc dot gnu.org 2011-04-21 08:29:45 UTC --- Author: burnus Date: Thu Apr 21 08:29:41 2011 New Revision: 172812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172812 Log: 2011-04-21 Tobias Burnus bur...@net-b.de PR fortran/18918 * array.c (gfc_match_array_spec): Fix maximal rank(+corank) check. 2011-04-21 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #18 from rguenther at suse dot de rguenther at suse dot de
2011-04-21 08:36:14 UTC ---
On Thu, 21 Apr 2011, eraman at google dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #17 from Easwaran Raman eraman at google dot com 2011-04-21
00:20:51 UTC ---
On Sun, Apr 17, 2011 at 3:45 AM, rguenther at suse dot de
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #16 from rguenther at suse dot de rguenther at suse dot de
2011-04-17 10:44:02 UTC ---
On Fri, 15 Apr 2011, eraman at google dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #15 from Easwaran Raman eraman at google dot com 2011-04-15
22:22:15 UTC ---
(In reply to comment #14)
On Fri, 15 Apr 2011, eraman at google dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Easwaran Raman eraman at google dot com changed:
What |Removed |Added
CC| |eraman at google dot
com
--- Comment #13 from Easwaran Raman eraman at google dot com
2011-04-15 19:18:25 UTC ---
Richard, did you mean to write
static bool
can_escape (tree expr)
{
tree base;
if (!expr)
return true;
base = get_base_address (expr);
if (DECL_P (base)
(!may_be_aliased (base)
!pt_solution_includes (cfun-gimple_df-escaped, base)))
return false;
return true;
}
Only case when we know it doesn't escape is if bas is a DECL_P and is
not in
cfun-gimple_df-escaped and not aliased, right? Actually, I'm
wondering if it
is sufficient to test just
DECL_P (base) !pt_solution_includes (cfun-gimple_df-escaped,
base).
No, because if the escaped solution for example includes ANYTHING then
the test will return true. That !may-aliased variables are not
contained in ANYTHING isn't known w/o context.
Richard.
Correct me if I am wrong. If I understand you right, just using DECL_P
(base)
!pt_solution_includes is conservative since pt_solution_includes may
return
true if the escaped solution contains ANYTHING. To make it less
conservative,
you're suggesting
if (DECL_P (base)
(!may_be_aliased (base)
|| !pt_solution_includes (cfun-gimple_df-escaped, base)))
return false;
I tried that and most Fortran tests are failing. One of the tests
(default_format_1.f90) has the following RTL sequence:
(insn 30 29 32 4 (set (mem/s/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0])) [2
dt_parm.0.common.flags+0 S4 A64])
(const_int 16512 [0x4080])) default_format_1.inc:56 64
{*movsi_internal}
(nil))
(insn 32 30 33 4 (set (reg:DI 5 di)
(reg/f:DI 106)) default_format_1.inc:56 62 {*movdi_internal_rex64}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0]))
(nil)))
(call_insn 33 32 36 4 (call (mem:QI (symbol_ref:DI (_gfortran_st_write)
[flags 0x41] function_decl 0x7f301ed12e00 _gfortran_st_write) [0
_gfortran_st_write S1 A8])
(const_int 0 [0])) default_format_1.inc:56 618 {*call_0}
(expr_list:REG_DEAD (reg:DI 5 di)
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(nil)))
For the DECL dt_parm, pt_solution_includes (cfun-gimple_df-escaped,
base)
returns false, even though its location is passed as a parameter to
_gfortran_st_write.
I did test with
if (DECL_P (base)
(!may_be_aliased (base)
!pt_solution_includes (cfun-gimple_df-escaped, base)))
which has no regressions. Is that what you suggest?
No, the version with || should be ok. The dt_parm argument does
not escape at the _gfortran_st_write call site because this
intrinsic function has a .wW fnspec attribute which specifies
the arguments do not escape. What you indeed need to do in
addition to the escaped solution query is walk over all function
arguments and see if there is one that aliases 'base'. That
may not be easily possible on RTL though. On the tree level
we have a separate points-to set for such call clobbers/uses
but we do not preserve it for RTL.
Is it ok to make calls whose arg(s) have EAF_NOESCAPE kill all
locations off the frame in addition to killing all locations that
potentially escape (using the || case you suggested)? Will it be
better or worse than just checking !may_be_aliased (base) alone?
It's probably easiest and safest to just check !may_be_aliased for now.
Richard.
[Bug target/48708] Invalid V2DI vector set insn generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.04.21 08:47:48
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-04-21 08:47:48
UTC ---
Patch in testing:
Index: i386.c
===
--- i386.c(revision 172811)
+++ i386.c(working copy)
@@ -31483,10 +31483,19 @@ ix86_expand_vector_set (bool mmx_ok, rtx
break;
case V2DImode:
- use_vec_merge = TARGET_SSE4_1;
+ use_vec_merge = TARGET_SSE4_1 TARGET_64BIT;
if (use_vec_merge)
break;
+ tmp = gen_reg_rtx (GET_MODE_INNER (mode));
+ ix86_expand_vector_extract (false, tmp, target, 1 - elt);
+ if (elt == 0)
+tmp = gen_rtx_VEC_CONCAT (mode, tmp, val);
+ else
+tmp = gen_rtx_VEC_CONCAT (mode, val, tmp);
+ emit_insn (gen_rtx_SET (VOIDmode, target, tmp));
+ return;
+
case V2DFmode:
{
rtx op0, op1;
[Bug target/48708] Invalid V2DI vector set insn generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Target Milestone|--- |4.6.2
[Bug tree-optimization/48571] [4.5/4.6/4.7 Regression] Missed data-dependence for (bogus?) reconstructed array-refs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48571 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c/48685] [4.5/4.6/4.7 regression] ICE in gimplify_expr, at gimplify.c:7034
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48685 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/48604] [4.5/4.6/4.7 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48604 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug lto/48683] [4.7 Regression] 252.eon in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48683 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-21 09:37:36 UTC --- The function _ZN10xalanc_1_818XalanDOMStringPoolC2Emmm is the one causing PR 48585 (caused by an earlier commit of mine). So these might actually be two different bugs (is is a segfault in the LTRANS stage, I suppose) ...or it is a better manifestation of the same bug, it is hard to tell. I guess I should update my source anyway.
[Bug target/46329] ICE on ARM for __attribute__ ((vector_size (8 * sizeof(int)))) operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-04-21 09:39:06 UTC --- Author: rsandifo Date: Thu Apr 21 09:39:03 2011 New Revision: 172815 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172815 Log: gcc/ PR target/46329 * config/arm/arm.c (arm_legitimate_constant_p_1): Return false for all Neon struct constants. gcc/testsuite/ 2011-04-04 Richard Earnshaw rearn...@arm.com Richard Sandiford richard.sandif...@linaro.org PR target/46329 * gcc.target/arm/pr46329.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr46329.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug debug/48459] [4.7 Regression] avr: Assertion failure with -gdwarf-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2011-04-20 CC||gjl at gcc dot gnu.org Known to fail||4.7.0 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-04-21 10:02:49 UTC --- Increased the importance from P3 to P3 because this makes avr-gcc+dwarf-2 completely unusable. Configuring as --target=avr --with-dwarf2 fails to build cross compiler.
[Bug target/35073] illegal opcode movw for mcu avr3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35073 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||gjl at gcc dot gnu.org Known to work||4.7.0 Resolution||FIXED Known to fail|| --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-04-21 10:29:55 UTC --- Closed as resolved+fixed. avr-gcc builds fine as of 4.7.0 snapshot from 2011-04-16. Both avr-binutils 2.20 and 2.21 work.
[Bug rtl-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 10:48:34 UTC --- Created attachment 24066 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24066 patch Patch I am testing.
[Bug target/48628] ICE in reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48628 --- Comment #4 from belagod at gcc dot gnu.org 2011-04-21 10:53:26 UTC --- Sorry for the delay: this is my gcc -v: arm-eabi-gcc COLLECT_LTO_WRAPPER=.../trunk/2011-04-20/install-a9softfpneon/bin/../libexec/gcc/arm-eabi/4.7.0/lto-wrapper Target: arm-eabi Configured with: .../trunk/source/gcc-fsf/configure --target=arm-eabi --enable-checking=release --disable-gdbtk --disable-werror --disable-tui --disable-rda --disable-sid --disable-utils --disable-lto --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon --prefix=.../trunk/2011-04-20/install-a9softfpneon --with-mpfr=.../tools/linux_x86_64 --with-mpc=.../tools/linux_x86_64 --with-gmp=.../tools/linux_x86_64 --disable-lto --disable-werror --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib Thread model: single gcc version 4.7.0 20110420 (experimental) (GCC)
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 11:05:09 UTC --- Before the patch: movq%rsp, %rdx leaq-16(%rsp), %rcx movl$0, %eax .L5: addl%eax, %eax addl12(%rdx), %eax subq$4, %rdx cmpq%rcx, %rdx jne .L5 after the patch: movl$0, %edx movl$0, %eax .L5: addl%eax, %eax addl12(%rsp,%rdx), %eax subq$4, %rdx cmpq$-16, %rdx jne .L5 not 100% clear which to prefer. Alternatively alias-analysis can be dumbed down, never exploiting knowledge of a constant offset added to a pointer before dereferencing it (thus, ignoring the constant offset operand in MEM_REFs and TARGET_MEM_REFs). FYI, the disambiguation that triggers is /* If only one reference is based on a variable, they cannot alias if the pointer access is beyond the extent of the variable access. (the pointer base cannot validly point to an offset less than zero of the variable). They also cannot alias if the pointer may not point to the decl. */ if ((TREE_CODE (base1) != TARGET_MEM_REF || (!TMR_INDEX (base1) !TMR_INDEX2 (base1))) !ranges_overlap_p (MAX (0, offset1p), -1, offset2p, max_size2)) return false; thus, for the pointer base cannod validly point to an offset less than zero say that this only holds for ptr + constant offset, not ptr in isolation.
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-04-21 11:07:03 UTC --- Hmm, I am not sure I follow here. So the bug seems to be that 1) ipa-cp produces a clone 2) somehow after WPA we inline the original function, not the clone right? How this can lead to more direct calls? Is the call represented as call to clone in the callgraph? If not, I guess ipa-cp produced clone but kept original copy around and we are inlining real cal to original copy. This can happen. If callgraph has call to clone properly represented, but somehow we end up inlining original, I would expect the original to have monotonously fewer direct calls, so we should have the call destination we discovered during inlining around... Only case i can think this might legally happen is inlining producing direct call via devirtualization from folding. In this case cgraph don't see the posibility and we need to add the cgraph node (we already checked that the destination is not static function in other unit) Honza
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #15 from Andreas Tobler andreast at gcc dot gnu.org 2011-04-21 11:34:32 UTC --- This was my fault. I have in mind that my breakage happened between 4.2 and 4.3. (And you write that 4.2.4 is ok, right?) Unfortunately we can not update/downgrade to this revision number with the 4.3 checkout. What you can do is checkout trunk and go back to r122895. This was the revision which worked for me on my target. With r122896 I get similar faults as you. The procedure is as follows: svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc-src-dir (you name the directory) cd gcc-src-dir svn up -r 122895 To see what happened in each svn commit you can browse the link below. It is just a random timestamp. You have to look for the revision number by 'hand'. http://gcc.gnu.org/ml/gcc-cvs/2007-03/
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #6 from Zdenek Dvorak rakdver at gcc dot gnu.org 2011-04-21 11:49:36 UTC --- I think we rely on the assumption that pointer arithmetics satisfies the restrictions of C standard (i.e., that the pointer is within a single memory object) on more places than just this one. So, if the code produced by ivopts is indeed for (p = a; p != a - 3; --p) *(p + 3) = ... this could potentially cause other problems other than with alias analysis. But, I would expect the code from ivopts to be rather for (p = a; ...; p = (pointer) ((unsigned) p - 1) *((pointer) ((unsigned) p + 3)) = ... Which should be a valid code. Is that the case? If so, fixing alias analysis would be the proper solution.
[Bug target/48708] Invalid V2DI vector set insn generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708 --- Comment #2 from uros at gcc dot gnu.org 2011-04-21 11:55:50 UTC --- Author: uros Date: Thu Apr 21 11:55:45 2011 New Revision: 172821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172821 Log: PR target/48708 * config/i386/i386.c (ix86_expand_vector_set) V2DImode: Generate vec_extract and vec_concat for non-SSE4_1 targets. testsuite/ChangeLog: PR target/48708 * gcc.target/i386/pr48708.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr48708.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug debug/48703] segfault in canonicalize_for_substitution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48703 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.21 12:19:17 Blocks||48207 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 12:19:17 UTC --- I have a patch.
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 12:32:04 UTC --- IVOPTs generates ivtmp.25_24 = (long unsigned int) array; array.26_26 = (long unsigned int) array; D.2769_27 = array.26_26 + 0x0fff0; bb 3: # ans_21 = PHI ans_16(4), 0(2) # ivtmp.25_20 = PHI ivtmp.25_19(4), ivtmp.25_24(2) D.2741_10 = ans_21 * 2; D.2767_25 = (void *) ivtmp.25_20; D.2737_15 = MEM[(int *)D.2767_25 + 12B]; ans_16 = D.2741_10 + D.2737_15; ivtmp.25_19 = ivtmp.25_20 - 4; if (ivtmp.25_19 != D.2769_27) goto bb 4; else goto bb 5; bb 4: goto bb 3; thus, the addition of the constant offset does not happen in a separate unsigned long computation but is (of course) folded into the (TARGET_)MEM_REF. What now exposes this kind of bugs is that we 1) prefer to generate MEM_REFs instead of equivalent TARGET_MEM_REFs, 2) do not completely give up on TARGET_MEM_REFs in alias analysis. I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as opaque, only looking at the final pointer that is dereferenced, not at the pieces of the address computation. We'd retain the case where two such derefrences differ only in a constant offset. I don't think that any pass interprets the address computation that is implicit in a memory refrence in any way at the moment.
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 12:39:10 UTC --- (In reply to comment #7) IVOPTs generates ivtmp.25_24 = (long unsigned int) array; array.26_26 = (long unsigned int) array; D.2769_27 = array.26_26 + 0x0fff0; bb 3: # ans_21 = PHI ans_16(4), 0(2) # ivtmp.25_20 = PHI ivtmp.25_19(4), ivtmp.25_24(2) D.2741_10 = ans_21 * 2; D.2767_25 = (void *) ivtmp.25_20; Actually D.2767_25 is already the problem as it can point before array. D.2737_15 = MEM[(int *)D.2767_25 + 12B]; Here we assume that the memory reference happens only to array[3] or beyond, as D.2767_25 is assumed to at least point to array[0] but never to array[-1]. Other passes could derive similar info for D.2767_25 given that points-to analysis computes it points somewhere into array.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #40 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-21 12:44:54 UTC --- Reply to comment #37 Using volatile does not fix the behavior for the if condition. I have tried several volatile permutations on it as well. Using volatile rather than the asm volatile on the temp case does resolve that one and the attached case Test program for optimization (ie declaring temp as volatile) So, we are stuck at comment #37 at the moment. This has prompted me to think Why are we doing this in floating point to begin with? The Fortran Standard model assumes perfect floating representation. The r and rexp_d could be represented in exact ascii decimal form and these tests done after we generate the DTOA string representation of m. This would require refactoring our code, but it could be done I think and the tests would then be a byte scan which in most cases would exit after a few loop iterations. I suppose this would be a bit slower. Regardless, it is an idea I toss out for comment.
[Bug libgcj/48709] New: java/net/natVMInetAddress.cc:42:52: error: declaration of C function 'int gethostname(char*, int)' conflicts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48709 Summary: java/net/natVMInetAddress.cc:42:52: error: declaration of C function 'int gethostname(char*, int)' conflicts Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de Building cross x86_64-unknown-linux-gnu to i686-pc-cygwin: libtool: compile: /SCRATCH/tmp.uPE4kUseBu/gcc-4.5.3/gcc-4.5.3/./gcc/xgcc -shared-libgcc -B/SCRATCH/tmp.uPE4kUseBu/gcc-4.5.3/gcc-4.5.3/./gcc -nostdinc++ -L/SCRATCH/tmp.uPE4kUseBu/gcc-4.5.3/gcc-4.5.3/i686-pc-cygwin/libstdc++-v3/src -L/SCRATCH/tmp.uPE4kUseBu/gcc-4.5.3/gcc-4.5.3/i686-pc-cygwin/libstdc++-v3/src/.libs -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/bin/ -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/lib/ -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/include -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava -I./include -I./gcj -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava -Iinclude -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/include -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/classpath/include -Iclasspath/include -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/classpath/native/fdlibm -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/.././libjava/../gcc -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/../zlib -I/opt/devel/gnu/src/gcc-cygwin/gcc-4.5.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3\ -DTOOLEXECLIBDIR=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/lib\ -DJAVA_HOME=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3\ -DBOOT_CLASS_PATH=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/share/java/libgcj-4.5.3.jar\ -DJAVA_EXT_DIRS=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/lib/gcj-4.5.3-11\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\ -DLIBGCJ_DEFAULT_DATABASE=\/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/lib/gcj-4.5.3-11/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.5.3-11/classmap.db\ -g -O2 -MT java/net/natVMInetAddress.lo -MD -MP -MF java/net/.deps/natVMInetAddress.Tpo -c java/net/natVMInetAddress.cc -DDLL_EXPORT -DPIC -o java/net/.libs/natVMInetAddress.o java/net/natVMInetAddress.cc:42:52: error: declaration of C function ‘int gethostname(char*, int)’ conflicts with /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.5.3/i686-pc-cygwin/include/sys/unistd.h:232:6: error: previous declaration ‘int gethostname(char*, size_t)’ here It seems somehow related to PR45872. java/net/natVMInetAddressPosix.cc has: #ifndef HAVE_GETHOSTNAME_DECL extern C int gethostname (char *name, int namelen); #endif But HAVE_GETHOSTNAME_DECL isn't defined. A grep in the libjava build tree gives: include/config.h:/* #undef HAVE_GETHOSTNAME_DECL */ java/net/natVMInetAddress.cc:#ifndef HAVE_GETHOSTNAME_DECL I don't know if it's cause by the fact that cygwin has it's unistd.h in the include/sys directory, not in include.
[Bug tree-optimization/48613] [4.6/4.7 Regression] ICE: vector VEC(ipa_node_params_t,base) index domain error with -O0 -flto -findirect-inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48613 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.21 12:51:31 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-21 12:51:31 UTC --- -findirect-inlining with -O0 makes no sense, we should clear flag_indirect_inlining when -O0 or guard all flag_indirect_inlining uses with optimize (currently it is done that way only in one place, which is the reason why this ICEs).
[Bug fortran/48588] [4.6/4.7 Regression] ICE (segfault) in gfc_get_nodesc_array_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #9 from rakdver at kam dot mff.cuni.cz rakdver at kam dot mff.cuni.cz 2011-04-21 12:56:20 UTC --- ivtmp.25_24 = (long unsigned int) array; array.26_26 = (long unsigned int) array; D.2769_27 = array.26_26 + 0x0fff0; bb 3: # ans_21 = PHI ans_16(4), 0(2) # ivtmp.25_20 = PHI ivtmp.25_19(4), ivtmp.25_24(2) D.2741_10 = ans_21 * 2; D.2767_25 = (void *) ivtmp.25_20; D.2737_15 = MEM[(int *)D.2767_25 + 12B]; ans_16 = D.2741_10 + D.2737_15; ivtmp.25_19 = ivtmp.25_20 - 4; if (ivtmp.25_19 != D.2769_27) goto bb 4; else goto bb 5; bb 4: goto bb 3; So the computation of the induction variable is performed in (long unsigned int), which should be safe. I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as opaque, only looking at the final pointer that is dereferenced, not at the pieces of the address computation. We'd retain the case where two such derefrences differ only in a constant offset. I don't think that any pass interprets the address computation that is implicit in a memory refrence in any way at the moment. We definitely should decide on and document the precise semantics of (TARGET_)MEM_REFs. One possibility is to give no guarantees on the computations (i.e., treat them as opaque); this is easy for ivopts, but possibly removes some useful information (at least for MEM_REFs, I would not do that). On the other hand, if we decide to enforce the restrictions as for the pointer arithmetics, we should also say e.g. in what way are the parts of the address computation in TARGET_MEM_REFs associated, as that may make a difference.
[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-04-21 12:57:16 UTC --- Fixed now.
[Bug ada/48710] New: raised STORAGE_ERROR : stack overflow (or erroneous memory access) in g-catiio.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48710 Summary: raised STORAGE_ERROR : stack overflow (or erroneous memory access) in g-catiio.adb Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de Building cross x86_64-unknown-linux-gnu to i686-pc-cygwin: /SCRATCH/tmp.jYKMdkdWc2/gcc-4.7.0/gcc-4.7.0/./gcc/xgcc -B/SCRATCH/tmp.jYKMdkdWc2/gcc-4.7.0/gcc-4.7.0/./gcc/ -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.7.0/i686-pc-cygwin/bin/ -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.7.0/i686-pc-cygwin/lib/ -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.7.0/i686-pc-cygwin/include -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/CYGWIN_NT-5.1/i686-pc-cygwin/cygwin-1.7.9-1/gcc-4.7.0/i686-pc-cygwin/sys-include -c -g -O2 -W -Wall -gnatpg g-catiio.adb -o g-catiio.o raised STORAGE_ERROR : stack overflow (or erroneous memory access)
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de
2011-04-21 13:05:54 UTC ---
On Thu, 21 Apr 2011, rakdver at kam dot mff.cuni.cz wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #9 from rakdver at kam dot mff.cuni.cz rakdver at kam dot
mff.cuni.cz 2011-04-21 12:56:20 UTC ---
ivtmp.25_24 = (long unsigned int) array;
array.26_26 = (long unsigned int) array;
D.2769_27 = array.26_26 + 0x0fff0;
bb 3:
# ans_21 = PHI ans_16(4), 0(2)
# ivtmp.25_20 = PHI ivtmp.25_19(4), ivtmp.25_24(2)
D.2741_10 = ans_21 * 2;
D.2767_25 = (void *) ivtmp.25_20;
D.2737_15 = MEM[(int *)D.2767_25 + 12B];
ans_16 = D.2741_10 + D.2737_15;
ivtmp.25_19 = ivtmp.25_20 - 4;
if (ivtmp.25_19 != D.2769_27)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
So the computation of the induction variable is performed in (long unsigned
int),
which should be safe.
I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as opaque,
only looking at the final pointer that is dereferenced, not at the
pieces of the address computation. We'd retain the case where two
such derefrences differ only in a constant offset.
I don't think that any pass interprets the address computation that is
implicit in a memory refrence in any way at the moment.
We definitely should decide on and document the precise semantics of
(TARGET_)MEM_REFs.
One possibility is to give no guarantees on the computations (i.e., treat them
as opaque);
this is easy for ivopts, but possibly removes some useful information (at
least
for MEM_REFs,
I would not do that). On the other hand, if we decide to enforce the
restrictions as for
the pointer arithmetics, we should also say e.g. in what way are the parts of
the address
computation in TARGET_MEM_REFs associated, as that may make a difference.
What we lose when we treat them as opaque is disambiguating the load of i
in
int i;
int foo (int *p) { i = 0; *(p + 4) = 1; return i; }
where *(p + 4) is MEM[p, 16] where we see that p + 16 != i for any
valid (in the C sense) pointer p.
That would indeed be not so nice.
Richard.
[Bug ada/48711] New: value not in range of type Interfaces.C.unsigned in g-socthi.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48711 Summary: value not in range of type Interfaces.C.unsigned in g-socthi.adb Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de Building cross x86_64-unknown-linux-gnu to i686-pc-mingw32: /SCRATCH/tmp.yK829Id1E6/gcc-4.6.1/gcc-4.6.1/./gcc/xgcc -B/SCRATCH/tmp.yK829Id1E6/gcc-4.6.1/gcc-4.6.1/./gcc/ -L/SCRATCH/tmp.yK829Id1E6/gcc-4.6.1/gcc-4.6.1/i686-pc-mingw32/winsup/mingw -L/SCRATCH/tmp.yK829Id1E6/gcc-4.6.1/gcc-4.6.1/i686-pc-mingw32/winsup/w32api/lib -isystem /opt/devel/gnu/src/gcc-mingw/gcc-4.6.1/winsup/mingw/include -isystem /opt/devel/gnu/src/gcc-mingw/gcc-4.6.1/winsup/w32api/include -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/MINGW32_NT-5.1/i686-pc-mingw32/mingwrt-3.18-mingw32/gcc-4.6.1/i686-pc-mingw32/bin/ -B/opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/MINGW32_NT-5.1/i686-pc-mingw32/mingwrt-3.18-mingw32/gcc-4.6.1/i686-pc-mingw32/lib/ -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/MINGW32_NT-5.1/i686-pc-mingw32/mingwrt-3.18-mingw32/gcc-4.6.1/i686-pc-mingw32/include -isystem /opt/devel/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_11.3/cross/MINGW32_NT-5.1/i686-pc-mingw32/mingwrt-3.18-mingw32/gcc-4.6.1/i686-pc-mingw32/sys-include -c -g -O2 -W -Wall -gnatpg g-socthi.adb -o g-socthi.o g-socthi.adb:280:45: value not in range of type Interfaces.C.unsigned g-socthi.adb:280:45: static expression fails Constraint_Check
[Bug middle-end/48712] New: [4.5 Regression] ICE in dfs_enumerate_from, at cfganal.c:1207, with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48712 Summary: [4.5 Regression] ICE in dfs_enumerate_from, at cfganal.c:1207, with -O3 Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Running /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/dg-torture.exp ... FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer (internal compiler err or) FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer (test for excess error s) FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer -funroll-loops (intern al compiler error) FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer -funroll-loops (test f or excess errors) FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer -funroll-all-loops -fin line-functions (internal compiler error) FAIL: g++.dg/torture/pr42883.C -O3 -fomit-frame-pointer -funroll-all-loops -fin line-functions (test for excess errors) FAIL: g++.dg/torture/pr42883.C -O3 -g (internal compiler error) FAIL: g++.dg/torture/pr42883.C -O3 -g (test for excess errors) Executing on host: /mnt/gnu/gcc/objdir-test/gcc/testsuite/g++/../../g++ -B/mnt/g nu/gcc/objdir-test/gcc/testsuite/g++/../../ /mnt/gnu/gcc/gcc/gcc/testsuite/g++.d g/torture/pr42883.C -nostdinc++ -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib stdc++-v3/include/hppa2.0w-hp-hpux11.11 -I/mnt/gnu/gcc/objdir/hppa2.0w-hp-hpux11 .11/libstdc++-v3/include -I/mnt/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/mnt/gnu/gc c/gcc/libstdc++-v3/include/backward -I/mnt/gnu/gcc/gcc/libstdc++-v3/testsuite/ut il -fmessage-length=0 -O3 -fomit-frame-pointer-S -o pr42883.s(timeout = 300) /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr42883.C: In function 'void MakeI nternalMesh()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr42883.C:63:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr42883.C: In function 'void MakeI nternalMesh()': /mnt/gnu/gcc/gcc/gcc/testsuite/g++.dg/torture/pr42883.C:63:1: internal compiler error: in dfs_enumerate_from, at cfganal.c:1207 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/nowhere --with-gmp=/opt/gnu/gcc/gcc-4.6 --enable-threads=posix --enable-debug=no --disable-nls --disable-lto --without-cloog --without-ppl --enable-checking=release --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.5.3 20110420 (prerelease) [gcc-4_5-branch revision 172791] (GCC)
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-21 13:16:26 UTC --- (In reply to comment #10) Hmm, I am not sure I follow here. So the bug seems to be that 1) ipa-cp produces a clone 2) somehow after WPA we inline the original function, not the clone right? How this can lead to more direct calls? I don't think there are any new calls, just look at the dumps of release_ssa and then in inline-transform, the calls match. It seems to me that we loose all edges of this node and then try to re-create them during inline-transform which fails if one of the callees is in a different partition. Why we loose all the edges (both callers and calles) is still a mystery to me. I'll debug this again after updating svn to todays revision.
[Bug lto/48492] [4.7 Regression] LTO bootstrap failure in copy_constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-04-21 13:18:57 UTC --- I still need http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01461.html to do a LTO bootstrap with Ada enabled.
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
--- Comment #11 from rakdver at kam dot mff.cuni.cz rakdver at kam dot
mff.cuni.cz 2011-04-21 13:34:29 UTC ---
I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as
opaque,
only looking at the final pointer that is dereferenced, not at the
pieces of the address computation. We'd retain the case where two
such derefrences differ only in a constant offset.
I don't think that any pass interprets the address computation that is
implicit in a memory refrence in any way at the moment.
We definitely should decide on and document the precise semantics of
(TARGET_)MEM_REFs.
One possibility is to give no guarantees on the computations (i.e., treat
them
as opaque);
this is easy for ivopts, but possibly removes some useful information (at
least
for MEM_REFs,
I would not do that). On the other hand, if we decide to enforce the
restrictions as for
the pointer arithmetics, we should also say e.g. in what way are the parts
of
the address
computation in TARGET_MEM_REFs associated, as that may make a difference.
What we lose when we treat them as opaque is disambiguating the load of i
in
int i;
int foo (int *p) { i = 0; *(p + 4) = 1; return i; }
where *(p + 4) is MEM[p, 16] where we see that p + 16 != i for any
valid (in the C sense) pointer p.
That would indeed be not so nice.
what about always interpreting the computations in the type of the base of
MEM_REF
(allowing non-pointers as the base)? So both of the following forms would be
valid:
1)
int *p;
MEM[p + 16]
which is equivalent to *(p POINTER_PLUS 16)
2)
int *p;
unsigned v = (unsigned) p;
MEM[v + 16]
equivalent to *(int *) (v + 16)
The form 1) would be default, and contains the information needed by alias
analysis.
The form 2) would only be generated by optimizations that are unable to decide
whether
the pointer arithmetics form is valid (ivopts), and would be treated as
opaque by
alias analysis.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #63 from Vadim Zeitlin vz-gcc at zeitlins dot org 2011-04-21 14:04:37 UTC --- (In reply to comment #61) (In reply to comment #59) I review the patch, and found that we can add -fno-keep-inline-dllexport to the compiler option, and then, the compiler and linker stage works well. But the wxWidgets release mono dll's size is so large.(about 17M) In newer versions of GCC there is also a lot more debug info and Dwarf-2 exception table data that didn't used to be there. FWIW wxWidgets hardly uses exceptions (it has only two try/catch blocks that basically rethrow an exception thrown by user code but the library doesn't throw any exceptions itself). It does/can be configured to use the standard containers which do use exceptions however.
[Bug debug/23551] dwarf records for inlines appear incomplete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551 Matthew Fortune mfortune at gmail dot com changed: What|Removed |Added CC||mfortune at gmail dot com --- Comment #19 from Matthew Fortune mfortune at gmail dot com 2011-04-21 14:07:35 UTC --- I have one further case that may be worth adding to this ticket which relates to the order of formal paramters emitted for an inlined subroutine in debug info. GCC currently emits formal parameter DIEs for an inlined subroutine in reverse order to the function's parameters. The DWARF spec is slightly unclear in this area but does indicate that formal parameters must appear in the same order as listed in the function prototype in both abstract and concrete instances. One potential fix would be to change setup_one_parameter in tree-inline.c to append each new VAR_DECL to the vars list instead of prepend them. There may however be a more elegant approach by modifying the dwarf engine to detect and re-order VAR_DECLs that relate to formal paramters and emit them in the correct order. If this would be best as a separate ticket then I will open one.
[Bug middle-end/48712] [4.5 Regression] ICE in dfs_enumerate_from, at cfganal.c:1207, with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48712 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.21 14:31:57 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.3 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:31:57 UTC --- Seems like PR48000 now hits us on the branch (bah, we should do better with setting depends/blocks on bugs ...). I'll backport that rev. 170740
[Bug debug/48703] segfault in canonicalize_for_substitution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48703 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:35:56 UTC --- Fixed.
[Bug ada/48710] raised STORAGE_ERROR : stack overflow (or erroneous memory access) in g-catiio.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48710 --- Comment #1 from Rainer Emrich rai...@emrich-ebersheim.de 2011-04-21 14:36:12 UTC --- This is rev. 172660
[Bug debug/48703] segfault in canonicalize_for_substitution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48703 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:35:46 UTC --- Author: rguenth Date: Thu Apr 21 14:35:43 2011 New Revision: 172830 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172830 Log: 2011-04-21 Richard Guenther rguent...@suse.de PR lto/48703 * tree.c (free_lang_data_in_decl): Do not zero TREE_TYPE of DECL_NAME. * g++.dg/lto/pr48207-2_0.C: New testcase. * g++.dg/lto/pr48207-3_0.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lto/pr48207-2_0.C trunk/gcc/testsuite/g++.dg/lto/pr48207-3_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug tree-optimization/46787] Does not vectorize loop with load from scalar variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46787 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.04.21 14:39:11 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:39:11 UTC --- Mine.
[Bug rtl-optimization/48695] [4.6 Regression] Runtime with an array of std::vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48695 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:40:57 UTC --- Author: rguenth Date: Thu Apr 21 14:40:53 2011 New Revision: 172831 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172831 Log: 2011-04-21 Richard Guenther rguent...@suse.de PR middle-end/48695 * tree-ssa-alias.c (aliasing_component_refs_p): Compute base objects and types here. Adjust for their offset before comparing. * g++.dg/torture/pr48695.C: New testcase. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/torture/pr48695.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-alias.c
[Bug rtl-optimization/48695] [4.6 Regression] Runtime with an array of std::vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48695 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail||4.6.0 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 14:40:36 UTC --- Fixed.
[Bug translation/48638] gcc/plugin.c: inacessible - inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48638 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.04.21 15:02:51 Blocks||40883 Ever Confirmed|0 |1
[Bug translation/48640] gcc: tree-cfg.c: 2992: operand in in TARGET_MEM_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48640 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-04-21 15:05:14 UTC --- Fixed by: r172670 | meyering | 2011-04-18 20:42:30 + (Mon, 18 Apr 2011) | 1 line fix doubled-word typos in comments and strings: e.g., s/in in/in/
[Bug c/44384] builtin_object_size_ treatment of multidimensional arrays is unexpected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384 --- Comment #4 from Mark Eklund meklund at cisco dot com 2011-04-21 15:17:37 UTC --- Although subobject isn't well defined in the documentation, the below comments from tree-object-size.c revision r171388 lines 63-68 would indicate that subobject is the innermost array. /* * * object_sizes[0] is upper bound for number of bytes till the end of * the object. * object_sizes[1] is upper bound for number of bytes till the end of * the subobject (innermost array or field with address taken). * object_sizes[2] is lower bound for number of bytes till the end of * the object and object_sizes[3] lower bound for subobject. */
[Bug fortran/48713] New: Error: invalid instruction suffix for push
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48713 Summary: Error: invalid instruction suffix for push Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ian.chiv...@chiversandbryan.co.uk I get the above error when trying to compile the following fortran module. module timing_module implicit none integer , dimension(8) , private :: dt real , private :: h,m,s,ms,tt real , private :: last_tt contains subroutine start_timing() implicit none call date_and_time(values=dt) print 100 , dt(1:3),dt(5:8) 100 format( 1x,i4,'/',i2,'/',i2,1x,i2,':',i2,':',i2,1x,i3) h = real(dt(5)) m = real(dt(6)) s = real(dt(7)) ms = real(dt(8)) last_tt = 60*(60*h+m) + s + ms/1000.0 end subroutine start_timing subroutine print_date_and_time implicit none call date_and_time(values=dt) print 100 , dt(1:3),dt(5:8) 100 format( 1x,i4,'/',i2,'/',i2,1x,i2,':',i2,':',i2,1x,i3) end subroutine print_date_and_time subroutine print_hms implicit none call date_and_time(values=dt) print 100 , dt(5:8) 100 format( 1x,i2,':',i2,':',i2,1x,i3) end subroutine print_hms subroutine print_ms implicit none call date_and_time(values=dt) h = real(dt(5)) m = real(dt(6)) s = real(dt(7)) ms = real(dt(8)) tt = 60*(60*h+m) + s + ms/1000.0 print 100 , tt 100 format( 1x,f14.3) end subroutine print_ms subroutine print_time_difference implicit none call date_and_time(values=dt) h = real(dt(5)) m = real(dt(6)) s = real(dt(7)) ms = real(dt(8)) tt = 60*(60*h+m) + s + ms/1000.0 print 100 , (tt-last_tt) 100 format( 1x,f14.3) last_tt=tt end subroutine print_time_difference real function time_difference() implicit none tt = 0.0 call date_and_time(values=dt) h = real(dt(5)) m = real(dt(6)) s = real(dt(7)) ms = real(dt(8)) tt = 60*(60*h+m) + s + ms/1000.0 time_difference=tt-last_tt end function time_difference end module timing_module Here is the output from gfortran -v d:\document\fortran\newbook\examples\ch28\gfortrangfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/program files (x86)/gfortran/bin/../libexec/gcc/i586-pc-m ingw32/4.6.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --enable-shared --disa ble-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.6.0 20110214 (experimental) [trunk revision 170140] (GCC) d:\document\fortran\newbook\examples\ch28\gfortran This system is running Windows Vista Home Premium, 64 bit, sp2.
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #16 from diggskevin38 at gmail dot com 2011-04-21 15:30:29 UTC --- If someone wants to post svn commands to see the difference between the m68k.md file between 122895 122896 ... that would be cool (ya know ... so I don't have to beat my head against svn docs ...)
[Bug debug/42288] please emit empty .debug_aranges section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW CC||mark at gcc dot gnu.org --- Comment #7 from Mark Wielaard mark at gcc dot gnu.org 2011-04-21 15:33:09 UTC --- We discussed this a bit on the elfutils list WRT the dwarflint checks we have. And the consensus seems to be that it is more convenient to actually have an .aranges entry for each CU. https://fedorahosted.org/pipermail/elfutils-devel/2011-April/002024.html Could the patch be resurrected?
[Bug c/48685] [4.5/4.6/4.7 regression] ICE in gimplify_expr, at gimplify.c:7034
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48685 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-21 15:36:26 UTC --- The C front end should not depend on fold creating NON_LVALUE_EXPRs anywhere, but I don't know if C++ has such dependencies. Where does the NON_LVALUE_EXPR come from? In any case, I don't think NON_LVALUE_EXPR should be used for type conversions; a NON_LVALUE_EXPR with void type should only ever be used if the contained expression has void type (with the same qualifiers), and under those conditions STRIP_TYPE_NOPS should remove it. c_fully_fold_internal needs to preserve the type of the expression, so can't just remove a NON_LVALUE_EXPR that changes the type without adding some other conversion to the new type - but as noted above, if a NON_LVALUE_EXPR is changing the type I think the creation of that NON_LVALUE_EXPR is what's wrong.
[Bug rtl-optimization/48696] Horrible bitfield code generation on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-21 15:43:27 UTC --- On Wed, 20 Apr 2011, rguenth at gcc dot gnu.org wrote: If gcc has forgotten the underlying type, and only looks at the bitfield size and offset, gcc will likely never do a good job at it unless gcc gets _really_ smart and looks at all the accesses around it and decides I need to do these as 'int' just because (ie in the example, the unsigned base type is as important as is the bits 0..5 range information). Unfortunately the underlying type isn't easily available (at least I didn't yet find it ...). But I suppose we have to guess anyway considering targets that don't handle unaligned accesses well or packed bitfields. Thus, an idea was to use aligned word-size loads/stores and only at the start/end of a structure fall back to smaller accesses (for strict align targets). I still hope to eventually find that underlying type info somewhere ... The underlying type is used for -fstrict-volatile-bitfields, so it must be available in the cases needed for that option.
[Bug fortran/48713] Error: invalid instruction suffix for push
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48713 --- Comment #1 from Ian Chivers ian.chivers at chiversandbryan dot co.uk 2011-04-21 15:44:07 UTC --- I have just downloaded and installed the latest development version on this system and still get the same message. d:\document\fortran\newbook\examples\ch28\gfortrangfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/program files (x86)/gfortran/bin/../libexec/gcc/i586-pc-m ingw32/4.7.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --enable-shared --disa ble-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.7.0 20110419 (experimental) [trunk revision 170140] (GCC) hope this helps.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #11 from ralphengels at gmail dot com ralphengels at gmail dot com 2011-04-21 15:45:13 UTC --- ok it seems to be related to sysroots i tried compiling without --with-sysroot and cpp.exe works then. question would then be if its an error on my part ? i use sysinternals junction to create the /mingw32/mingw directory for sysroot as a reparse point but i tried just copying the relevant lib and include dirs instead and its still the same error so im not sure.
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #17 from Andreas Tobler andreast at gcc dot gnu.org 2011-04-21 15:46:44 UTC --- svn diff -r 122895:122896 m68k.md
[Bug rtl-optimization/48696] Horrible bitfield code generation on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de 2011-04-21 15:48:10 UTC --- On Thu, 21 Apr 2011, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-21 15:43:27 UTC --- On Wed, 20 Apr 2011, rguenth at gcc dot gnu.org wrote: If gcc has forgotten the underlying type, and only looks at the bitfield size and offset, gcc will likely never do a good job at it unless gcc gets _really_ smart and looks at all the accesses around it and decides I need to do these as 'int' just because (ie in the example, the unsigned base type is as important as is the bits 0..5 range information). Unfortunately the underlying type isn't easily available (at least I didn't yet find it ...). But I suppose we have to guess anyway considering targets that don't handle unaligned accesses well or packed bitfields. Thus, an idea was to use aligned word-size loads/stores and only at the start/end of a structure fall back to smaller accesses (for strict align targets). I still hope to eventually find that underlying type info somewhere ... The underlying type is used for -fstrict-volatile-bitfields, so it must be available in the cases needed for that option. It relies on the mode, thus the start of the bitfield is at bitpos % mode-size and its size is mode-size if it is aligned. I'm not sure -fstrict-volatile-bitfields works for the unaligned/packed case.
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2011-04-21 15:50:08 UTC --- (In reply to comment #16) If someone wants to post svn commands to see the difference between the m68k.md file between 122895 122896 ... that would be cool (ya know ... so I don't have to beat my head against svn docs ...) svn help (e.g. svn help diff) is usually all you need, rather than the full docs
[Bug bootstrap/48000] [4.6 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48000 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 15:51:48 UTC --- Author: rguenth Date: Thu Apr 21 15:51:39 2011 New Revision: 172833 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172833 Log: 2011-04-21 Richard Guenther rguent...@suse.de PR middle-end/48712 Backport from 4.6 branch 2011-03-07 Zdenek Dvorak o...@ucw.cz PR bootstrap/48000 * cfgloopmanip.c (fix_bb_placements): Return immediately if FROM is BASE_LOOP's header. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cfgloopmanip.c
[Bug middle-end/48712] [4.5 Regression] ICE in dfs_enumerate_from, at cfganal.c:1207, with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48712 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 15:51:48 UTC --- Author: rguenth Date: Thu Apr 21 15:51:39 2011 New Revision: 172833 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172833 Log: 2011-04-21 Richard Guenther rguent...@suse.de PR middle-end/48712 Backport from 4.6 branch 2011-03-07 Zdenek Dvorak o...@ucw.cz PR bootstrap/48000 * cfgloopmanip.c (fix_bb_placements): Return immediately if FROM is BASE_LOOP's header. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/cfgloopmanip.c
[Bug middle-end/48712] [4.5 Regression] ICE in dfs_enumerate_from, at cfganal.c:1207, with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48712 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-04-21 15:52:24 UTC --- Should be fixed now.
[Bug c++/48707] [4.6/4.7 Regression] [c++0x] ICE initializing static const int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48707 --- Comment #1 from Roman Kononov roman at binarylife dot net 2011-04-21 15:57:12 UTC --- It is caused by -r170488.
[Bug preprocessor/48677] cpp.exe broken ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677 --- Comment #12 from ralphengels at gmail dot com ralphengels at gmail dot com 2011-04-21 16:18:17 UTC --- ok it works ! but damn this is strange i had to encase the path to the sysroot directory in quotes and use the windows path instead of the posix path variant. ../src/gcc-4.6.0/configure \ --build=i686-w64-mingw32 --enable-libgomp \ --enable-cloog-backend=isl --enable-languages=c,c++,lto,fortran,objc,obj-c++ \ --enable-lto --enable-checking=release \ --disable-werror --disable-werror-allways \ --disable-win32-registry --enable-version-specific-runtime-libs \ --enable-fully-dynamic-string --prefix=/mingw32 \ --with-gnu-ld --with-gnu-as \ --with-sysroot=c:/codeblocks/mingw32 --disable-multilib \ CFLAGS=-mtune=generic \ BOOT_CFLAGS=-mtune=generic \ CFLAGS_FOR_TARGET=-mtune=generic \ CXXFLAGS=-mthreads -mtune=generic \ BOOT_CXXFLAGS=-mthreads -mtune=generic \ CXXFLAGS_FOR_TARGET=-mthreads -mtune=generic \ LFLAGS=-flto -fwhopr=2 -s \ BOOT_LFLAGS=-flto -fwhopr=2 -s \ LFLAGS_FOR_TARGET=-flto -fwhopr=2 -s make -j8 make DESTDIR=/e/gcc32 install
[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702 --- Comment #12 from davidxl xinliangli at gmail dot com 2011-04-21 16:22:03 UTC --- (In reply to comment #3) I have a patch that makes it fail on trunk as well. IVOPTs generates for (p = a; p != a - 3; --p) *(p + 3) = ... and alias analysis doesn't like this invalid pointer. I wonder why ivopt does not select the iv candidate whose base is a+3.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #41 from Thomas Henlich thenlich at users dot sourceforge.net 2011-04-21 16:36:14 UTC --- Actually it may be even simpler than that: We already know how many significant digits (d) we want in the output string, and at what digit to round. So we can write the digits of the significand into a buffer (with Ew.d editing). All that would remain is to decide whether to print the exponent or not (according to a simple integer comparison), otherwise shift the decimal point to the right place (simple string operation). E.g. 0.0995 with RU,G0.2 dtoa - .10, exponent=0 output - .10 12345000 with RD,G0.4: dtoa - .1234, exponent=8 output - .1234E+08 because exponent d 12345678.95 with RD,G0.9: dtoa - .123456789, exponent=8 output - 123456789. because exponent d
[Bug fortran/48713] Error: invalid instruction suffix for push
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48713 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-04-21 16:56:14 UTC --- (In reply to comment #0) Target: i586-pc-mingw32 This system is running Windows Vista Home Premium, 64 bit, sp2. I think you may have the wrong version of gfortran. You are running a 64-bit OS but trying to use a 32-bit version of the software. I don't do Windows, but I suspect you want the MinGW for Win64 from the gfortran wiki
[Bug middle-end/48585] [4.7 Regression] 483.xalancbmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585
--- Comment #12 from Martin Jambor jamborm at gcc dot gnu.org 2011-04-21
18:02:54 UTC ---
OK, I've been wrong on many accounts above but at least I know what is
going on now. The segfault happens while materializing cones, not
while inlining. And we're materializing a clone that is itself
unreachable, it's there only to facilitate materialization of its own
inline clones. Those have no edges so we did not find any. Moreover,
creating edges for it is entirely unnecessary too (nd can lead to
ICEs, as we now know.
By the way, in this particular case we could not find a node for the
decl because it was a same_body alias but since all clones that will
survive will redirect the call according the edge anyway, it can in
theory happen even without them. Nevertheless, the fact that
same_alias nodes apparently get lost with LTO, the first condition in
cgraph_redirect_edge_call_stmt_to_callee will not have any effect and
the calls will be redirected to the real decl from the same body
alias.
Anyway, my (untested) roposed fix is most probably this:
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 172817)
+++ gcc/tree-inline.c (working copy)
@@ -1725,6 +1725,7 @@ copy_bb (copy_body_data *id, basic_block
if ((!edge
|| (edge-indirect_inlining_edge
id-transform_call_graph_edges ==
CB_CGE_MOVE_CLONES))
+ id-dst_node-reachable
(fn = gimple_call_fndecl (stmt)) != NULL)
{
struct cgraph_node *dest = cgraph_get_node (fn);
[Bug tree-optimization/48714] New: gcc -O hangs gobbling memory, while gcc -O -fno-tree-fre finishes quickly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48714
Summary: gcc -O hangs gobbling memory, while gcc -O
-fno-tree-fre finishes quickly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24067
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24067
Output of ajo-gcc -v -w -O -ftree-fre -c test105974-reduced.c
This reproduces for me with svn revision 172796 (2011-04-20), but it doesn't
reproduce with gcc-4.4. I'm on Ubuntu 10.10, x86-64. Attached gcc-v.txt.
cat test105974.c EOF
extern volatile int g_4[1][4]; extern int g_7; void modify(int *);
void func_2() {
int l_46 = 4;
if (g_7) {
modify(l_46);
} else {
int i;
for (i = 0; i != 5; i += 1) {
volatile int *vp = g_4[0][l_46]; *vp = 0;
}
}
}
EOF
gcc -w -O -c test105974.c
[hangs]
gcc -w -O -fno-tree-fre -c test105974.c
[passes]
This test case is reduced from the output of Csmith
(http://embed.cs.utah.edu/csmith/), using the following command line:
csmith --bitfields --packed-struct -s 105974 test105974.c
gcc -w -I../csmith-2.0.0/runtime -O -c test105974.c
As I said, it reproduces for me only with a home-built bleeding-edge GCC, and
I'm still pretty unfamiliar with the GCC build process, so don't bite too hard
if this turns out to be user error on my end. ;)
[Bug rtl-optimization/48715] New: CASE_VALUES_THRESHOLD should be settable with --param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48715 Summary: CASE_VALUES_THRESHOLD should be settable with --param Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization AssignedTo: meiss...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Created attachment 24068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24068 Patch to use --param to set CASE_VALUES_THRESHOLD In looking at some improvements to the powerpc, we wanted to change the default for when a table jump is generated vs. a series of if statements. Now, we could just add a powerpc specific TARGET_CASE_VALUES_THRESHOLD, but I tend to think that these should be settable on all/most ports with --param. At present, there are only two ports (avr and mn10300) that define their own TARGET_CASE_VALUES_THRESHOLD hook. My first patch does not remove the target hook and modify the avr/mn10300 ports to use maybe_set_param_value, but that can be done if desired. The patch adds two --param values, one for when the port is using the casesi insn, and the other when it uses the more primitive tablejump insn.
[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602 --- Comment #42 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-21 19:09:24 UTC --- Yes, I agree. My intuition was telling me our approach was wrong. I will try to come up with a patch in the next few days. No rush please with Easter coming up.
[Bug fortran/48713] Error: invalid instruction suffix for push
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48713 --- Comment #3 from Ian Chivers ian.chivers at chiversandbryan dot co.uk 2011-04-21 19:11:29 UTC --- It was not clear to me which one I should have downloaded and installed. I'm trying to finish a book for springer and need most of the development stuff, including oop openmp mpi coarray so assumed that 4.7.x was the one to download. i've got a 32 bit windows system so i'll try 4.7.x on that and let you know. we try developing the examples for the book on several systems and keeping track of them all and the various compilers is a real headache. hopefully this is just a 32/64 bit windows problem from your point of view. cheers ian
[Bug fortran/48405] Handle expressions in DO loops for front-end optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48405 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-04-21 19:23:36 UTC --- Author: tkoenig Date: Thu Apr 21 19:23:34 2011 New Revision: 172838 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172838 Log: 2011-04-21 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/48405 * frontend_passes (cfe_register_funcs): Remove workaround for DO loops. (gfc_code_walker): Make sure the pointer to the current statement doen't change when other statements are inserted. 2011-04-21 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/48405 * gfortran.dg/function_optimize_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/function_optimize_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug c/48716] New: gcc OpenMP static variable declared in scope inside construct is predetermined shared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48716
Summary: gcc OpenMP static variable declared in scope inside
construct is predetermined shared
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@cray.com
A static variable is declared inside a task construct having a
default(none) clause. The OpenMP API says that this variable is
predetermined shared. Currently the GNU gcc compiler wants this
variable to appear in a SHARED clause.
The OpenMP API version 3.0 (May 2008) on p. 78 lines 10 20 states:
The following variables have predetermined data-sharing attributes:
. . .
* Static variables which are declared in a scope inside the construct
are shared.
On p. 87 lines 22-25 the following appears:
The default(none) clause requires that each variable that is referenced
in the construct, and that does not have a predetermined data-sharing
attribute, must have its data-sharing attribute explicitly determined by
being listed in a data-sharing attribute clause.
In Section 2.7 task Construct on p. 59, line 17, we see that the
default(none) clause may appear on the #pragma omp task construct.
Test case:
$ cat ISU3305.c
// derived from OpenMP test omp3c/c03_2_9_3_1_3k.c
// REFERENCES : OpenMP 3.0, p. 59, line 17
// OpenMP 3.0, p. 78, line 20
// OpenMP 3.0, p. 87, lines 22-25
int main(void) {
#pragma omp task default(none)
{
static int shared_var;
shared_var = 1;
}
return 0;
}
$ gcc --version
gcc (GCC) 4.6.0 20110325 (Cray Inc.)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -c -fopenmp ISU3305.c
ISU3305.c: In function 'main':
ISU3305.c:9:20: error: 'shared_var' not specified in enclosing parallel
ISU3305.c:6:13: error: enclosing task
$
Expected results from Intel and PGI compilers:
$ pgcc -c -mp ISU3305.c
$ icc -c -openmp ISU3305.c
$
[Bug target/48708] Invalid V2DI vector set insn generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708 --- Comment #3 from uros at gcc dot gnu.org 2011-04-21 20:23:58 UTC --- Author: uros Date: Thu Apr 21 20:23:55 2011 New Revision: 172843 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172843 Log: PR target/48708 * config/i386/i386.c (ix86_expand_vector_set) V2DImode: Generate vec_extract and vec_concat for non-SSE4_1 targets. testsuite/ChangeLog: PR target/48708 * gcc.target/i386/pr48708.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr48708.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/i386.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/48714] gcc -O hangs gobbling memory, while gcc -O -fno-tree-fre finishes quickly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48714
Arthur O'Dwyer arthur.j.odwyer at gmail dot com changed:
What|Removed |Added
Known to work||4.4.5, 4.5.1
Version|unknown |4.7.0
--- Comment #1 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com
2011-04-21 21:34:41 UTC ---
Here's another test case with exactly the same symptom. Again, it works with
gcc-4.4 but fails with my bleeding-edge gcc. The braces around the inner loop
are significant. Notice that the offending assignment to gp is actually dead
code.
cat test106865.c EOF
extern volatile int g_89[5][9];
extern int g, *gp;
void func_64() {
int i;
for (i = 0; i 1; ) {
for (g = 0; g 1; ) {
return;
}
gp = g_89[g][0];
}
}
EOF
gcc -w -O1 -c test106865.c
[hangs]
gcc -w -O1 -fno-tree-pre -c test106865.c
[passes]
[Bug c/48717] New: likely integer wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48717
Summary: likely integer wrong code bug
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
[regehr@gamow tmp012]$ current-gcc -O1 small.c -o small
[regehr@gamow tmp012]$ ./small
65535
[regehr@gamow tmp012]$ current-gcc -O2 small.c -o small
[regehr@gamow tmp012]$ ./small
-1
[regehr@gamow tmp012]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r172845-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r172845-install
--program-prefix=r172845- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110421 (experimental) (GCC)
[regehr@gamow tmp012]$ cat small.c
unsigned short safe_52 (unsigned short ui1, unsigned short ui2)
{
return ui1 + ui2;
}
extern int printf (const char *, ...);
int g_7 = 1;
int g_8;
void func_1 (void)
{
g_7 = safe_52 (~g_8, g_8);
}
int main (void)
{
func_1 ();
printf (%d\n, g_7);
return 0;
}
[Bug fortran/48718] New: gfortran crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48718 Summary: gfortran crash Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sl...@blue.cft.edu.pl Created attachment 24069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24069 crash.f90 (source file that crashes the compiler) $ gfortran -c crash.f90 crash.f90: In function ‘fpmd2upf’: crash.f90:894:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The source comes from the Quantum Espresso version 4.3 (I have concatenated the used modules into one file in an apropriate order). $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc/4.6.0/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../gcc-4.6.0/configure --prefix=/opt/gcc/4.6.0 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --with-cpu=generic --build=x86_64-redhat-linux --enable-bootstrap Thread model: posix gcc version 4.6.0 (GCC) $ uname -a Linux sl2klast.ifpan.edu.pl 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux (CentOS 5.5 x86_64)
[Bug fortran/48719] New: quad precision intrinsics are missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48719 Summary: quad precision intrinsics are missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sl...@blue.cft.edu.pl e.g. qcmplx
[Bug fortran/48720] New: quad precision literals do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48720 Summary: quad precision literals do not work Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sl...@blue.cft.edu.pl real*16 x x = 1.1q0 write(*,*) x end prints 1.1002384185791015625000 I am not quite sure, but shouldn't this be a quad precision literal?
[Bug fortran/48720] quad precision literals do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48720 --- Comment #1 from Cezary Sliwa sliwa at blue dot cft.edu.pl 2011-04-21 22:33:36 UTC --- Sorry, I almost forgot: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc/4.6.0/libexec/gcc/x86_64-redhat-linux/4.6.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../gcc-4.6.0/configure --prefix=/opt/gcc/4.6.0 --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --with-cpu=generic --build=x86_64-redhat-linux --enable-bootstrap Thread model: posix gcc version 4.6.0 (GCC) $ uname -a Linux sl2klast.ifpan.edu.pl 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux (CentOS 5.5 x86_64)
[Bug tree-optimization/48694] [4.7 Regression] possible memory hog bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48694 Arthur O'Dwyer arthur.j.odwyer at gmail dot com changed: What|Removed |Added CC||arthur.j.odwyer at gmail ||dot com --- Comment #5 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com 2011-04-21 22:38:48 UTC --- I just filed bug 48714, which is probably a duplicate of this, with a couple of small test cases. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48714
[Bug fortran/48718] gfortran crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48718 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-04-21 22:55:33 UTC --- On x86_64-apple-darwin10 I get the segmentation fault with 4.6 r169227 and 170921, but not with trunk r172845 nor with 4.5.2.
[Bug rtl-optimization/48721] New: [4.6/4.7 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48721 Summary: [4.6/4.7 Regression] ICE: verify_flow_info failed: missing barrier after block 6 with -foptimize-sibling-calls -fsched2-use-superblocks Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 24070 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24070 reduced testcase Compiler output: $ gcc -O -foptimize-sibling-calls -fsched2-use-superblocks -fschedule-insns2 -mtune=core2 testcase.c testcase.c: In function 'internal_state_transition': testcase.c:73:1: error: missing barrier after block 6 testcase.c:73:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r172826 - crash 4.6 r172337 - crash 4.5 r172337 - crash
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #19 from diggskevin38 at gmail dot com 2011-04-22 00:07:00 UTC --- !@$#%^%^ I tried to do a build with svn release and it failed for me. Same problem. xgcc says it is 4.3.0. What did I do wrong???
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #20 from diggskevin38 at gmail dot com 2011-04-22 00:28:55 UTC --- (In reply to comment #19) !@$#%^%^ I tried to do a build with svn release and it failed for me. Same problem. xgcc says it is 4.3.0. What did I do wrong??? -r122895 is the omitted version ...
[Bug target/48690] gcc-4.3.5 fails for target m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690 --- Comment #21 from diggskevin38 at gmail dot com 2011-04-22 00:30:24 UTC --- (In reply to comment #20) (In reply to comment #19) !@$#%^%^ I tried to do a build with svn release and it failed for me. Same problem. xgcc says it is 4.3.0. What did I do wrong??? -r122895 is the omitted version ... This is the build command: CFLAGS=-O2 -fomit-frame-pointer CXXFLAGS=-O2 -fomit-frame-pointer LIBCFLAGS=-O2 -m68040 -fomit-frame-pointer LIBCXXFLAGS=-O2 -m68040 -fomit-frame-pointer time nice -16 make|tee ../gcc-svn-r122895-O2-c,c++-m68k.out Is there something wrong here!?!???
[Bug middle-end/48722] New: ICE in df_refs_verify() with -mno-push-args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48722
Summary: ICE in df_refs_verify() with -mno-push-args
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24071
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24071
Output of ajo-gcc -v -w -m32 -Os -mno-push-args test512888621-reduced.c -c
This reproduces for me with svn revision 172796 (2011-04-20), but it doesn't
reproduce with gcc-4.4. I'm on Ubuntu 10.10, x86-64. Attached gcc-v.txt.
cat test512888621-reduced.c EOF
extern long long ll;
extern int i;
void func_43(int, long long);
int func_35()
{
func_43(ll 0x85, i);
return 0;
}
EOF
gcc -w -m32 -Os -mno-push-args test512888621-reduced.c -c
test512888621-reduced.c: In function ‘func_35’:
test512888621-reduced.c:8:1: internal compiler error: in df_refs_verify, at
df-scan.c:4267
This test case is reduced from the output of Csmith
(http://embed.cs.utah.edu/csmith/), using the following command line:
csmith --bitfields --packed-struct -s 512888621 test512888621.c
[Bug fortran/48720] quad precision literals do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48720 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-04-22 02:21:43 UTC --- Try this: real(16) :: x x = 1.1q0_16 write(*,*) x end I think we are not handling the 'q' as any more than an exponent marker. 'e' works just as well. I would suggest updating your syntax a bit to something like this: integer, parameter :: wp = 16 real(wp) :: x x = 1.1e0_wp ! or just x = 1.1_wp write(*,*) x end Of course I am getting a little off topic. I don't think 'q' is standard conforming. (maybe I am wrong)
[Bug fortran/48719] quad precision intrinsics are missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48719 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from kargl at gcc dot gnu.org 2011-04-22 04:03:47 UTC --- Use the generic cmplx.
[Bug fortran/48720] quad precision literals do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48720 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org 2011-04-22 04:07:23 UTC --- (In reply to comment #2) Try this: real(16) :: x x = 1.1q0_16 write(*,*) x end I think we are not handling the 'q' as any more than an exponent marker. 'e' works just as well. Oh my, is gfortran accepting 1.1q0. Let's stop that right now! Use 1.1e0_16.
