[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-05-04 06:17:47 UTC --- (In reply to comment #2) Created attachment 24174 [details] assembly file for libgcc/../gcc/config/soft-fp/extenddftf2.c Can you please add -dp to compile flags? Which assembler do you use?
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2011-05-04 07:04:50 UTC --- Created attachment 24176 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24176 Band-aid patch for broken assemblers You have broken assembler, see Intel instruction set reference, MOVD/MOVQ insn. I will provide the patch that detects this problem in the assembler, but please report this to eventually fix the assembler issue.
[Bug target/48863] New: A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863
Summary: A Bug When Assembler Instructions with C Expression
Operands in arm-elf-gcc 4.5
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shangyun...@gmail.com
Created attachment 24175
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24175
test case for this bug
Assembler instructions with C expression operands, gcc(arm-elf-gcc) compiler
may produce the wrong instrctions sequence with option -O2.There is a case only
for test below.
In the case, the second instruction (mov r0, r1) destroyed r0 without saving,
but r0 kept the value of variable fd and the variable should be passed to swi
0. I think it's a serious bug, gcc compiler does not consider that unsigned
high = length / 23 may produce a function call.
case start
static __inline__ int __syscall_test(int fd, unsigned pad, unsigned long high,
unsigned low)
{
unsigned int __sys_result;
{
register int _a1 __asm__ (r0) = fd;
register int _a2 __asm__ (r1) = pad;
register int _a3 __asm__ (r2) = high;
register int _a4 __asm__ (r3) = low;
__asm__ __volatile__ (swi 0
: =r(_a1)
: 0(_a1),r(_a3), r(_a4));
__sys_result = _a1;
}
return __sys_result;
}
int f_test(int fd, long long length)
{
unsigned low = length 0x;
unsigned high = length / 23;
return __syscall_test(fd, 0, high, low);
}
-- compile result --
.file case.c
.global __divdi3
.text
.align 2
.global f_test
.type f_test, %function
f_test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfd sp!, {r4, lr}
mov r0, r1
mov r4, r1
mov r3, #0
mov r1, r2
mov r2, #23
bl __divdi3
mov r3, r4
mov r2, r0
@ 10 case.c 1
swi 0
@ 0 2
ldmfd sp!, {r4, pc}
.size f_test, .-f_test
.ident GCC: (GNU) 4.5.2
end ===
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 07:42:55 UTC --- Does it fix (at least some of) the x32 issues as well? If some (e.g. ICEs) are left, please post backtraces and other relevant details.
[Bug fortran/48858] Incorrect error for same binding label on two generic interface specifics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-04 08:23:41 UTC --- (In reply to comment #0) This code should compile. There is only one entity with the binding lablel Cfun. In the words in the standard, only one entity of the program with this binding label. The names cfunc2 and cfunc1 are both local identifiers. (Sections 16.2 and 16.3). This construction is specifically allowed in the standard to allow users to call a C function with multiple interfaces, similar to what is illustrated here. I think I have to re-read that standard; I once got the impression that it wasn't allowed to have two different interfaces pointing to the same entity. (In reply to comment #1) [BIND(C) with OPTIONAL arguments] The Intel and PGI compilers already support this (no compile errors, correct output). Having a correct output is probably not surprising as most Fortran compilers already handle OPTIONAL internally by passing a NULL pointer. Thus, also for gfortran it would only a few lines (allowing it unless -std=f95/f2003/f2008 is specified - and rejecting with BIND(C) the combination of OPTIONAL with VALUE). I was thinking of introducing an flag -std=f2008tr, which will allow F2008 with the two TR, which are being drafted: TR 29113 and the coarray TR. It's on my agenda (cf. PR 48820 and http://gcc.gnu.org/wiki/TR29113Status), but as it is a post-F2008 item, I thought I wait for the PDTR or FDTR and concentrate until then on, e.g., coarrays.
[Bug c++/48834] [4.7 Regression] -fno-exceptions causes wrong code generation on C++ code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48834 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 08:16:56 UTC --- Fixed.
[Bug tree-optimization/48837] [4.4/4.5/4.6/4.6 Regression] Wrong optimization of recursive function calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837 --- Comment #8 from Zdenek Dvorak rakdver at gcc dot gnu.org 2011-05-04 08:33:51 UTC --- Created attachment 24177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24177 Fix for the issue Indeed, once the accumulator transformation is performed, the other tail calls in the function are moved to non-tail positions.
[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-05-04 08:48:23 UTC --- I see this on armv5tel-linux-gnueabi too, with the glibc-ports-2.10.1 definition of the syscall wrapper macros. It seems to be caused by / being expanded to a libcall by the backend. If I move the / 23 expression to a helper function and make that noinline, then the division does occur well before the swi registers are set up. Without the noinline a call to __aeabi_uldivmod occurs just before the swi, clobbering some of its parameters.
[Bug fortran/48864] New: -Ofast should imply -fno-protect-parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864 Summary: -Ofast should imply -fno-protect-parens Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org -Ofast implies -O3 -ffast-math and possibly some more performance options; it should also imply -fno-protect-parens For -Ofast, cf. http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html For -fno-protect-parens, cf. http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html That -Ofast implies -fno-protect-parens should also be documented for -Ofast. An example how drastic the performance depends on -fno-protect-parens is the following program; it additionally requires -funroll-loops: http://openmp.org/forum/viewtopic.php?f=3t=1134#p4565 gfortran timings can be found at http://openmp.org/forum/viewtopic.php?f=3t=1134start=11 http://openmp.org/forum/viewtopic.php?f=3t=1134start=11#p4673
[Bug debug/48866] New: gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866 Summary: gcc hangs when -g is set Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: sieb...@aicas.com Created attachment 24178 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24178 Minimum C example I could produce. The original code was generated C code. gcc hangs when compiling the attached C source code (on Linux/x86) as follows gcc -O2 -c test.c -o test.o -g [hangs forever...] ^C The problem disappears without -g or when using -O0. gcc -O2 -c test.c -o test.o gcc -O0 -c test.c -o test.o -g
[Bug c++/48749] [4.6/4.7 Regression] internal compiler error: tree check: expected field_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|4.7.0 |4.6.1 Summary|[4.7 Regression] internal |[4.6/4.7 Regression] |compiler error: tree check: |internal compiler error: |expected field_decl |tree check: expected ||field_decl --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 08:54:07 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=171461 The patch has been backported to 4.6 branch as well and if built with --enable-checking=yes, it ICEs there the same way. In: 5880case COMPONENT_REF: 5881 /* If this component is really a base class reference, then the field 5882 itself isn't definitive. */ 5883 if (DECL_FIELD_IS_BASE (TREE_OPERAND (instance, 1))) 5884return RECUR (TREE_OPERAND (instance, 0)); 5885 return RECUR (TREE_OPERAND (instance, 1)); instance is a COMPONENT_REF with type Pos, TREE_OPERAND (instance, 0) is INDIRECT_REF - *coords and TREE_OPERAND (instance, 1) is not FIELD_DECL, but IDENTIFIER_NODE pos.
[Bug preprocessor/48865] New: It would be useful to have a way to check the value of a #define at preprocessing time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865 Summary: It would be useful to have a way to check the value of a #define at preprocessing time Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@arklinux.org When debugging compile failures in huge projects that heavily (ab)use preprocessor macros, it would be useful to have a way to output the value of a preprocessor token, e.g. something like #define XYZ 42 // buried deep inside some header #warning XYZ is ##XYZ should say XYZ is 42 or, better yet: XYZ is 42 (defined in something.h:123, included from somethingelse.h:456, included from stillsomethingelse.h:789)
[Bug middle-end/48597] x86-64 unwind register save location misses half-register write?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 09:14:07 UTC --- Author: jakub Date: Wed May 4 09:14:00 2011 New Revision: 173357 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173357 Log: Backport from mainline 2011-04-28 Jakub Jelinek ja...@redhat.com PR middle-end/48597 * final.c (final_scan_insn): Call dwarf2out_frame_debug even for inline asm. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/final.c
[Bug target/48774] [4.6/4.7 Regression] gcc-4.6.0 optimization regression on x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48774
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
09:21:15 UTC ---
Author: jakub
Date: Wed May 4 09:21:09 2011
New Revision: 173359
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173359
Log:
Backported from mainline
2011-05-03 Uros Bizjak ubiz...@gmail.com
Jakub Jelinek ja...@redhat.com
PR target/48774
* config/i386/i386.c (ix86_match_ccmode): For CC{A,C,O,S}mode
only succeed if req_mode is the same as set_mode.
* gcc.dg/pr48774.c: New test.
Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr48774.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/i386/i386.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug testsuite/48809] [4.4 Regression] switch statement optimization error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48809 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 09:19:10 UTC --- Author: jakub Date: Wed May 4 09:19:07 2011 New Revision: 173358 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173358 Log: Backport from mainline 2011-04-30 Jakub Jelinek ja...@redhat.com PR tree-optimization/48809 * tree-switch-conversion.c (build_arrays): Compute tidx in unsigned type. (gen_inbound_check): Don't compute index_expr - range_min in utype again, instead reuse SSA_NAME initialized in build_arrays. Remove two useless gsi_for_stmt calls. * gcc.c-torture/execute/pr48809.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr48809.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-switch-conversion.c
[Bug preprocessor/48865] It would be useful to have a way to check the value of a #define at preprocessing time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 09:29:48 UTC --- gcc -E -dD doesn't help?
[Bug c++/48867] New: Using the compilation flag -mfpmath=sse breaks Snes9x build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48867
Summary: Using the compilation flag -mfpmath=sse breaks Snes9x
build.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j.russell.mo...@gmail.com
Created attachment 24179
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24179
Compilation output.
Adding -mfpmath=sse to the compilation flags when building Snes9x generates the
following messages when compiling filters/hq2x.cpp:
{standard input}: Assembler messages:
{standard input}:59302: Warning: end of file not at end of a line; newline
inserted
{standard input}:60006: Error: no such instruction: `m'
{standard input}:60006: Error: open CFI at the end of file; missing
.cfi_endproc directive
g++: internal compiler error: Killed (program cc1plus)
The system I was using is a 64-bit Archlinux.
Compilation flags: -march=core2 -mfpmath=sse -O3 -pipe -fomit-frame-pointer
(although the configure script added some more)
gcc-v: Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6-20110429/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--disable-multilib --disable-libstdcxx-pch --enable-checking=release
Thread model: posix
gcc version 4.6.0 20110429 (prerelease) (GCC)
Compilation output: http://pastebin.com/TjqtN8sS
I've left the preprocessed files (the one that triggers the bug should be
hq2x.ii) along with the sources I used here:
http://dl.dropbox.com/u/2431380/snes9x-1.53-src.tar.xz
They're in the unix directory, that's where the makefile is too.
[Bug testsuite/48809] [4.4 Regression] switch statement optimization error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48809 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 09:33:21 UTC --- Fixed.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-04 10:00:02 UTC --- is this really fixed? with gcc version 4.6.1 20110422 (prerelease) (GCC) the reduced test do compile but I still get g++ -c produceICE.ii -std=c++0x -Wall -mavx In file included from /data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/plugins/EtaPtMinGsfElectronFullCloneSelector.cc:16:0: /data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/interface/GsfElectronSelector.h: In member function 'void helper::GsfElectronCollectionStoreManager::cloneAndStore(const I, const I, edm::Event)': /data/CMSSW_4_2_0_pre6/src/CommonTools/RecoAlgos/interface/GsfElectronSelector.h:54:36: internal compiler error: Segmentation fault Please submit a full bug report,
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #6 from uros at gcc dot gnu.org 2011-05-04 10:05:23 UTC ---
Author: uros
Date: Wed May 4 10:05:20 2011
New Revision: 173361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173361
Log:
PR target/48860
* config/i386/i386.md (*movdi_internal_rex64) Use %vmovd
for reg-xmm moves.
* config/i386/sse.md (*vec_concatv2di_rex64_sse4_1): Ditto.
(vec_concatv2di_rex64_sse): Ditto.
(*sse2_storeq_rex64): Do not emit %v prefix for mov{q} mnemonic.
(*vec_extractv2di_1_rex64): Ditto.
Revert:
2011-05-02 Uros Bizjak ubiz...@gmail.com
* config/i386/mmx.md (*movmode_internal_rex64): Use %vmovq for
reg-xmm moves.
(*movv2sf_internal_rex64): Use %vmovq for reg-xmm moves.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/mmx.md
trunk/gcc/config/i386/sse.md
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 10:13:37 UTC --- I can confirm that the original testcase still ICEs, both mainline and branch.
[Bug debug/48866] gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.04 10:22:37 Ever Confirmed|0 |1 Known to fail||4.6.1, 4.7.0 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 10:22:37 UTC --- Confirmed mainline and 4_6-branch.
[Bug c++/48574] [4.6/4.7 Regression] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 10:54:48 UTC --- Indeed, unlike the reduced testcase, for the original one it triggers during fold_non_dependent_expr_sfinae which means that processing_template_decl is 0 and thus type_dependent_expression_p check Dodji added returns false immediately. Related to PR48749, where processing_template_decl is 1, but type_dependent_expression_p is still false, because the COMPONENT_REF has non-dependent type, yet its operands are dependent (it was created using build_min_non_dep).
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-04 11:04:28 UTC --- (In reply to comment #7) 0 is a valid null pointer constant in C. If you want to use NULL as a sentinel you must always cast it. I'm sure that is something nobody does. Thus 0 is an extremely stupid NULL pointer definition.
[Bug bootstrap/48842] [4.7 regression] ICE in evaluate_conditions_for_edge at ipa-inline-analysis.c:537 on Tru64 Unix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48842 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-04 11:13:24 UTC --- --- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2011-05-02 11:54:47 UTC --- I've fixed identical falure happening on HP and AIX. Does it still reproduce for you? Mainline bootstraps again as of 20110502. Thanks. Rainer
[Bug preprocessor/48865] It would be useful to have a way to check the value of a #define at preprocessing time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865 --- Comment #2 from bero at arklinux dot org 2011-05-04 11:16:01 UTC --- It does - if you know how to read it. It's easy to tell a student who has never used a compiler outside of an IDE how to add a #warning -- teaching him how to read the output of -E -dD is quite a bit harder and might trigger the old Linux is hard, give me my Vi$ual $tudio myth. Even for someone who does know how to read -E -dD, I think sometimes the easy way could be quicker sometimes (especially locating the relevant place in pieces of code that are so full of macros that the output doesn't bear much resemblance to the original).
[Bug bootstrap/48842] [4.7 regression] ICE in evaluate_conditions_for_edge at ipa-inline-analysis.c:537 on Tru64 Unix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48842 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-05-04 11:14:19 UTC --- Fixed.
[Bug fortran/48864] -Ofast should imply -fno-protect-parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.04 11:33:11 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-04 11:33:11 UTC --- Confirmed.
[Bug c++/48856] Crash when compiling certain source code with C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-04 11:08:30 UTC --- Works for me with 4.6.0 and on the tip of the branch on x86_64 with -m32.
[Bug debug/48866] gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-04 11:32:01 UTC --- it's var-tracking
[Bug debug/48866] gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
12:07:42 UTC ---
cselib actually. Shorter testcase:
struct S { struct S *d[2]; };
struct S *
foo (struct S *x)
{
struct S *y, *z;
y =
x-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1];
z =
y-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1]-d[1];
return z;
}
[Bug c++/38634] ICE with wrong number of template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38634 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords|error-recovery, |diagnostic |ice-checking, | |ice-on-invalid-code | --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 12:02:42 UTC --- Thanks Jason. Let's recategorize it a bit, then.
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851 --- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-05-04 12:02:44 UTC --- Also defining NULL as 0 creates problems when passing it to varargs functions on LP64 platforms, not just for sentinels. As Andreas says, it's a valid null pointer constant, but a terribly stupid choice for NULL.
[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 Lionel GUEZ ebay.20.tedlap at spamgourmet dot com changed: What|Removed |Added CC||ebay.20.tedlap at ||spamgourmet dot com --- Comment #47 from Lionel GUEZ ebay.20.tedlap at spamgourmet dot com 2011-05-04 12:15:16 UTC --- (In reply to comment #46) I have started on the second phase of this effort which is to get rid of the floating point issue on -m32 machines. Hello. I have noticed a bug which seems related to the one you are describing. According to the Fortran 95 standard, printing the number 0.96 with the format 1pg7.1 should give the same result than with format f3.0. Thus, the result should be 1., but Gfortran produces the surprising result 0. Is it the same bug? Sincerely, Lionel GUEZ
[Bug preprocessor/48865] It would be useful to have a way to check the value of a #define at preprocessing time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 12:11:04 UTC --- Teach them to how to pipe the output of gcc -E -dD to grep, it'll do them good in the long run.
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 12:33:38 UTC --- (In reply to comment #0) The workaround, of course, is to define the empty default constructor in ConstMember. Or simply add an empty new-initializer, which works when you can't change the definition of ConstMember
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.04 12:32:05 CC||fabien.chene at gmail dot ||com Summary|Regression: incorrect |[4.6/4.7 Regression] |uninitialized const|incorrect uninitialized |member error on new|const member error on new |without new-initializer |without new-initializer Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 12:32:05 UTC --- Fabien, could you take a look? I think Andrew's right that this was caused by the patch for PR 25811
[Bug c++/39055] [4.3/4.4/4.5/4.6/4.7 regression] ICE with questionable default parameter of a member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2011-05-04 12:38:03 UTC --- It was discussed on the reflector in messages 15450-3 and 80, but seems never to have made it into the issues list...
[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 #49 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-04 12:48:28 UTC --- (In reply to comment #47) (In reply to comment #46) I have started on the second phase of this effort which is to get rid of the floating point issue on -m32 machines. Hello. I have noticed a bug which seems related to the one you are describing. According to the Fortran 95 standard, printing the number 0.96 with the format 1pg7.1 should give the same result than with format f3.0. Thus, the result should be 1., but Gfortran produces the surprising result 0. Is it the same bug? Sincerely, Lionel GUEZ Can you please provide a short example program, and what version of GFortran you are using? I cannot reproduce the described bug with GFortran 4.4.5 nor with 4.7-20110430. Your expected result is correctly produced by the program: print (1pg7.1), 0.96 end = 1.
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 12:52:02 UTC --- The assembler is from... Xcode 4.0.2 Build version 4A2002a but the assembler from... Xcode 3.2.6 Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0 BuildVersion: 10M2518 also shows the same error.
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 12:49:27 UTC --- Created attachment 24180 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24180 assembly file for libgcc/../gcc/config/soft-fp/extenddftf2.c with -dp
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 12:58:41 UTC --- Opened radr://9381460 with extenddftf2.s generated with -dp as the testcase.
[Bug debug/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826 --- Comment #1 from Ryan Mansfield rmansfield at qnx dot com 2011-05-04 13:01:31 UTC --- The change that introduced this ICE is rev171033. http://gcc.gnu.org/viewcvs?view=revisionrevision=171033
[Bug c++/48869] New: OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Summary: OpenMP task construct fails to instantiate copy
constructor(same as Bug 36523)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bbe...@gmail.com
The same bug like in gcc 4.4.0 Bug 36523.
The following test case fails with a linker error. It compiles okay with the
pragma omp task line removed.
$ cat task.cpp
templatetypename T
struct A
{
A() { }
A(const A) { }
void foo() { }
};
int main()
{
Aint a;
#pragma omp task
a.foo();
return 0;
}
$ g++ -fopenmp -Wall task.cpp
/tmp/cc5epalM.o: In function `main.omp_cpyfn.1':
task.cpp:(.text+0x73): undefined reference to `Aint::A(Aint const)'
collect2: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
...
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
[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 #48 from jvdelisle at frontier dot com 2011-05-04 12:30:59 UTC --- On 05/04/2011 05:15 AM, ebay.20.tedlap at spamgourmet dot com wrote: --- Comment #47 from Lionel GUEZebay.20.tedlap at spamgourmet dot com 2011-05-04 12:15:16 UTC --- (In reply to comment #46) --- snip --- Hello. I have noticed a bug which seems related to the one you are describing. According to the Fortran 95 standard, printing the number 0.96 with the format 1pg7.1 should give the same result than with format f3.0. Thus, the result should be 1., but Gfortran produces the surprising result 0. Is it the same bug? It is PR48787 and a patch has been submitted for approval. It is fixed on my development trunk.
[Bug c++/48869] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.04 13:06:58 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 13:06:58 UTC --- Confirmed mainline and 4_6-branch.
[Bug target/48868] New: There are no -mtls-dialect=gnu2 run-time tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868 Summary: There are no -mtls-dialect=gnu2 run-time tests Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: aol...@gcc.gnu.org We have no ideas if there are any -mtls-dialect=gnu2 regressions since there are no -mtls-dialect=gnu2 run-time tests. We should add -mtls-dialect=gnu2 run-time testcases in gcc.
[Bug c++/39055] [4.3/4.4/4.5/4.6/4.7 regression] ICE with questionable default parameter of a member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 13:04:59 UTC --- Thanks. I'm looking at the messages and indeed, it seems that GCC and EDG are actually correct, but we want a formal DR Resolution in order to close this, right? I don't know exactly how things are managed in Core: should somebody ask (Mike?) to open an issue?
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 13:10:23 UTC --- Could this be similar to the required change from... http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html to adapt to the darwin assembler's usage of movq?
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2011-05-04 13:25:28 UTC --- (In reply to comment #10) Could this be similar to the required change from... http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html to adapt to the darwin assembler's usage of movq? Yes... Unfortunately, the commit didn't explain, why inconsistent use of movd vs. movq.
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-05-04 13:33:57 UTC --- I still got FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/stackalign/alloca-1.c -O2 -flto (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto -flto-partition=none (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-3.c -O2 -flto (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O1 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O1 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O3 -g (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto -flto-partition=none (internal compiler error) FAIL: gcc.dg/torture/stackalign/nested-4.c -O2 -flto -flto-partition=none (test for excess errors)
[Bug c++/48859] [4.6/4.7 Regression] incorrect uninitialized const member error on new without new-initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859 fabien at gcc dot gnu.org changed: What|Removed |Added CC||fabien at gcc dot gnu.org AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | --- Comment #4 from fabien at gcc dot gnu.org 2011-05-04 13:52:27 UTC --- (In reply to comment #2) Fabien, could you take a look? I think Andrew's right that this was caused by the patch for PR 25811 Sure.
[Bug c++/47723] internal compiler: Segmentation fault - gcc 4.5.2 Arch Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723
--- Comment #14 from Jason Merrill jason at gcc dot gnu.org 2011-05-04
13:42:19 UTC ---
(In reply to comment #10)
struct S { };
S* p = new S::S();
EDG 4.0-4.3 all reject this as well.
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
14:06:56 UTC ---
Can you track down on which mem_loc_descriptor call these new
DW_OP_GNU_*_type/DW_OP_GNU_{convert,reinterpret}
locs have been added, and for that post a backtrace and debug_rtx on the
outermost mem_loc_descriptor call argument?
[Bug c++/48870] New: operator== overload of vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48870
Summary: operator== overload of vector types
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: john.sal...@deshaw.com
I'd like to overload operator== for vector (e.g., SSE __m128i) types. It seems
that __m128i is neither of class nor enumerated types, which makes it
unsuitable for operator-overload. Can this be fixed?
salm...@drdlogin0039.en.desres$ cat m128.cpp
#include x86intrin.h
bool operator==(__m128i a, __m128i b){
__m128i x = _mm_xor_si128(a, b);
return _mm_testz_si128(x, x);
}
salm...@drdlogin0039.en.desres$ dw -m gcc/4.6.0-23A/bin g++ -msse4.2 m128.cpp
m128.cpp:3:37: error: 'bool operator==(__m128i, __m128i)' must have an argument
of class or enumerated type
salm...@drdlogin0039.en.desres$
[Bug debug/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826 Ryan Mansfield rmansfield at qnx dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Ryan Mansfield rmansfield at qnx dot com 2011-05-04 14:06:56 UTC --- After rev171033 debugging is completely broken for this mips configuration. i.e. everything build I compile with -g ICEs this way.
[Bug c++/48871] New: gcc doesn't accept null pointer value as a template non-type argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48871
Summary: gcc doesn't accept null pointer value as a template
non-type argument
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boost...@gmail.com
According to 14.3.2 [temp.arg.nontype],
a constant expression that evaluates to a null pointer or null member pointer
value can be a template argument.
Thus, following code is well-formed.
But gcc issues errors.
template void * ptr
struct X { } ;
int main()
{
X 0 x1 ; // error: could not convert template argument '0' to 'void*'
X nullptr x2 ; // error: could not convert template argument 'nullptr'
to 'void*'
}
[Bug debug/48866] gcc hangs when -g is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 14:21:28 UTC --- The problem is the MEMs nested in other MEM addresses, cselib isn't prepared to handle it efficiently. So, either we should break very deep MEM nests using extra DEBUG_INSNs and debug temporaries (not sure how easy it would be to break them during expand_debug_expr, so perhaps either when expand_debug_expr finishes, or perhaps during vt_initialize before an insn is passed to cselib_process_insn), or cselib would need to have some cache on MEMs it already looked up during current toplevel cselib_lookup or cselib_subst_to_values calls - for small number of MEMs perhaps a linear cache that cselib_lookup_mem could iterate over, holding MEM rtx / corresponding cselib_val * pairs, for bigger amounts perhaps pointer_map. Without such a cache, 14 nested MEMs result in certainly more than 4 billion cselib_lookup searches within one cselib_process_insn.
[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818 --- Comment #2 from Melanie Cappelaere melaniec at enfocus dot com 2011-05-04 14:19:01 UTC --- Created attachment 24181 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24181 Example with custom allocator Thank you for the workaround. Little side note: this bug also applies to stl containers using a custom allocator that happens to have the same name and occurs in both the application and the library. Allocation is done using the library's allocator, but deallocation is done using the application's. (The workaround also works in this case.)
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 14:13:04 UTC --- This looks similar to this bug... http://www.mail-archive.com/mpir-devel@googlegroups.com/msg04286.html where is claimed these are bugs in the older gas on darwin.
[Bug c++/48871] gcc doesn't accept null pointer value as a template non-type argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48871 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 14:37:05 UTC --- I think this is a dup of PR 10541
[Bug debug/48826] ICE in dwarf2out_var_location, at dwarf2out.c:22013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 14:10:20 UTC --- Most probably the backend is reordering insns after var-tracking, it shouldn't be doing that. ARM/SH/S390 backends all have fixed similar bugs very quickly after this patch went in.
[Bug target/48860] r173265 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2011-05-04 15:11:49 UTC --- Bootstrap fixed again on x86_64-apple-darwin10 at r173376.
[Bug target/48868] There are no -mtls-dialect=gnu2 run-time tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-04 15:31:21 UTC --- Can't you run the testsuite with -mtls-dialect=gnu2 to see if there are any failures?
[Bug c++/48872] New: [C++0x][noexcept] Placement-new problem with non-empty arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
Summary: [C++0x][noexcept] Placement-new problem with non-empty
arguments
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110430 (experimental) in C++0x mode rejects the following program:
//--
#include new
struct U {};
templateclass T
T create();
const bool b = noexcept(::new (((void*) 0)) U(createU()));
static_assert(b, Ouch); // #
int main() {}
//--
At the line marked with # the static_assert fires. The same problem occurs, if
the initializer of U is e.g. createU() or createconst U(), but a program
with an empty initializer like
const bool b = noexcept(::new (((void*) 0)) U());
is accepted. In either case no operation which potentially throws an exception
is called, therefore the program should be accepted.
[Bug c++/48869] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
15:31:38 UTC ---
Broken by:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=149750
i.e. gimplification unit-a-time. The problem is we won't know until
gimplification whether some non-POD vars will be firstprivate or not, and when
gimplification has been postponed so late, instantiate_pending_templates won't
be called any longer.
Unfortunately, I think duplicating most of the OpenMP related code from
gimplify.c to find out implicitly firstprivate vars in task constructs earlier
would be very hard and huge amount of code duplication, on the other side if we
wanted to instantiate the missing templates late, we'd have to basically repeat
the whole do { ... } while (reconsider); loop from
cp_write_global_declarations from within some langhook (I don't think we can do
that while in the middle of gimplifying something).
Richard/Richard/Jason, any ideas?
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2011-05-04 15:37:43
UTC ---
(In reply to comment #9)
Can you track down on which mem_loc_descriptor call these new
DW_OP_GNU_*_type/DW_OP_GNU_{convert,reinterpret}
locs have been added, and for that post a backtrace and debug_rtx on the
outermost mem_loc_descriptor call argument?
Breakpoint 6, mem_loc_descriptor (rtl=0x70dde4c0, mode=DImode,
mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:13952
13952 mem_loc_result = new_loc_descr (DW_OP_GNU_regval_type,
(gdb) call debug_rtx (rtl)
(reg/f:DI 6 bp)
(gdb) bt
#0 mem_loc_descriptor (rtl=0x70dde4c0, mode=DImode, mem_mode=DImode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:13952
#1 0x00b3b26c in mem_loc_descriptor (rtl=0x70d47f90, mode=DImode,
mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14196
#2 0x00b1bed6 in dwarf2out_frame_debug_cfa_expression (
set=0x70d47fc0, label=0x4a8edc0 do not output)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:2088
#3 0x00b1d605 in dwarf2out_frame_debug (insn=0x70d45a20,
after_p=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:2870
#4 0x00c9a5f8 in final_scan_insn (insn=0x70d45a20,
file=0x4c05540, optimize_p=2, nopeepholes=0, seen=0x7fffddac)
at /export/gnu/import/git/gcc-x32/gcc/final.c:2775
#5 0x00c98a73 in final (first=0x70ce95c0, file=0x4c05540,
optimize_p=2) at /export/gnu/import/git/gcc-x32/gcc/final.c:1795
#6 0x00c9cf40 in rest_of_handle_final ()
at /export/gnu/import/git/gcc-x32/gcc/final.c:4246
#7 0x0133ac0e in execute_one_pass (pass=0x4a80980)
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1556
#8 0x0133adfd in execute_pass_list (pass=0x4a80980)
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1611
#9 0x0133ae1e in execute_pass_list (pass=0x4a81360)
---Type return to continue, or q return to quit---
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1612
#10 0x0133ae1e in execute_pass_list (pass=0x4a81300)
at /export/gnu/import/git/gcc-x32/gcc/passes.c:1612
#11 0x01b15ff1 in tree_rest_of_compilation (fndecl=0x70ce7200)
at /export/gnu/import/git/gcc-x32/gcc/tree-optimize.c:423
#12 0x0280711e in cgraph_expand_function (node=0x70ceb250)
at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1579
#13 0x028072dd in cgraph_expand_all_functions ()
at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1638
#14 0x0280796a in cgraph_optimize ()
at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1901
#15 0x02804dde in cgraph_finalize_compilation_unit ()
at /export/gnu/import/git/gcc-x32/gcc/cgraphunit.c:1099
#16 0x004f38c6 in c_write_global_declarations ()
at /export/gnu/import/git/gcc-x32/gcc/c-decl.c:9883
#17 0x01782785 in compile_file ()
at /export/gnu/import/git/gcc-x32/gcc/toplev.c:591
#18 0x0178496b in do_compile ()
at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1913
#19 0x01784ab8 in toplev_main (argc=20, argv=0x7fffe248)
at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1976
#20 0x00734eaa in main (argc=20, argv=0x7fffe248)
at /export/gnu/import/git/gcc-x32/gcc/main.c:36
(gdb) f 1
#1 0x00b3b26c in mem_loc_descriptor (rtl=0x70d47f90, mode=DImode,
mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14196
14196 mem_loc_result = mem_loc_descriptor (XEXP (rtl, 0), mode,
mem_mode,
(gdb) call debug_rtx (rtl)
(plus:DI (reg/f:DI 6 bp)
(const_int -24 [0xffe8]))
(gdb) f 2
#2 0x00b1bed6 in dwarf2out_frame_debug_cfa_expression (
set=0x70d47fc0, label=0x4a8edc0 do not output)
at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:2088
2088= mem_loc_descriptor (XEXP (dest, 0), get_address_mode (dest),
(gdb)
[Bug c++/48873] New: [C++0x][noexcept] Placement-new problem with deleted destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48873
Summary: [C++0x][noexcept] Placement-new problem with deleted
destructors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110430 (experimental) in C++0x mode rejects the following program:
//--
#include new
struct D {
~D() = delete;
};
templateclass T
T create();
const bool b = noexcept(::new (((void*) 0)) D(createD())); // #
int main() {}
//--
At the line marked with # we get:
error: use of deleted function 'D::~D()'
The same error occurs with example arguments like createD() or createconst
D(), but the program becomes accepted (as expected), if the initializer list
of D is empty, i.e. if we use the noexcept expression:
noexcept(::new (((void*) 0)) D())
instead to initialize b.
The program should be accepted in either case, because no effective destructor
call is going on here (no temporary is produced).
[Bug target/48868] There are no -mtls-dialect=gnu2 run-time tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-05-04 15:42:11 UTC --- (In reply to comment #1) Can't you run the testsuite with -mtls-dialect=gnu2 to see if there are any failures? 90% of gcc testsuites don't use TLS. Run the whole testsuite with -mtls-dialect=gnu2 may be OK for one-time test. But it isn't appropriate as the regular gcc test.
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.6 Target Milestone|--- |4.5.4 Summary|OpenMP task construct fails |[4.5/4.6/4.7 Regression] |to instantiate copy |OpenMP task construct fails |constructor(same as Bug |to instantiate copy |36523) |constructor(same as Bug ||36523) Known to fail||4.5.3, 4.6.0, 4.7.0
[Bug c/48874] New: Sign of zeros sometimes lost in literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
Summary: Sign of zeros sometimes lost in literals
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
Consider
#include stdio.h
#include complex.h
int main()
{
double _Complex a = 0.0 + I*0.0;
double _Complex b = 0.0 - I*0.0;
double _Complex c = -0.0 + I*0.0;
double _Complex d = -0.0 - I*0.0;
printf(a= (%g,%g)\n, creal(a), cimag(a));
printf(b= (%g,%g)\n, creal(b), cimag(b));
printf(c= (%g,%g)\n, creal(c), cimag(c));
printf(d= (%g,%g)\n, creal(d), cimag(d));
}
This program, compiled with gcc zero1.c -O2 -pedantic -Wall -std=c99 (or
-std=gnu99) prints
a= (0,0)
b= (0,-0)
c= (0,0)
d= (-0,-0)
That is, the sign of the real part of c is lost. Add -fdump-tree-original to
the compile flags shows the dump as
;; Function main (null)
;; enabled by -tree-original
{
complex double a = __complex__ (0.0, 0.0);
complex double b = __complex__ (0.0, -0.0);
complex double c = __complex__ (0.0, 0.0);
complex double d = __complex__ (-0.0, -0.0);
complex double a = __complex__ (0.0, 0.0);
complex double b = __complex__ (0.0, -0.0);
complex double c = __complex__ (0.0, 0.0);
complex double d = __complex__ (-0.0, -0.0);
printf ((const char * restrict) a= (%g,%g)\n, REALPART_EXPR a,
IMAGPART_EXPR a);
printf ((const char * restrict) b= (%g,%g)\n, REALPART_EXPR b,
IMAGPART_EXPR b);
printf ((const char * restrict) c= (%g,%g)\n, REALPART_EXPR c,
IMAGPART_EXPR c);
printf ((const char * restrict) d= (%g,%g)\n, REALPART_EXPR d,
IMAGPART_EXPR d);
}
return 0;
so it seems the negative sign of the real part of c is lost already in the
frontend.
Version of the compiler:
gcc version 4.7.0 20110504 (experimental) (GCC)
Target: x86_64-unknown-linux-gnu
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de
2011-05-04 15:46:47 UTC ---
On Wed, 4 May 2011, jakub at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
15:31:38 UTC ---
Broken by:
http://gcc.gnu.org/viewcvs?root=gccview=revrev=149750
i.e. gimplification unit-a-time. The problem is we won't know until
gimplification whether some non-POD vars will be firstprivate or not, and when
gimplification has been postponed so late, instantiate_pending_templates won't
be called any longer.
Unfortunately, I think duplicating most of the OpenMP related code from
gimplify.c to find out implicitly firstprivate vars in task constructs earlier
would be very hard and huge amount of code duplication, on the other side if
we
wanted to instantiate the missing templates late, we'd have to basically
repeat
the whole do { ... } while (reconsider); loop from
cp_write_global_declarations from within some langhook (I don't think we can
do
that while in the middle of gimplifying something).
Richard/Richard/Jason, any ideas?
Can we just always instantiate the templates (always assuming they will be
firstprivate) or are we strictly bound to only instantiate when we
know they will be used? Thus, how does the OMP spec interact with C++
template instantiation rules?
I don't like the idea of instantiating templates when we started
gimplification ... can we move related analysis to the frontend
somewhere so we know whether things are firstprivate or not there?
Richard.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org 2011-05-04 16:09:19 UTC --- Hi, I discussed some of the issues today with Martin. For the array descriptor testcase, we really want ipa-cp to be propagate the constant array bounds instead of making Inliner to blindly inline enough in all cases. For that we need 1) Make ipa-prop to work on aggregates. For aggregates passed by value we can have jump functions that define known constants at known offsets 2) Make ipa-inline-analysis to produce predicates on constantness of aggregate fields in the same format 3) Array descriptors are passed by reference, rather than by value. This need further work, since need to be sure that the value passed does not change by aliasing. IPA-SRA would help here if it was really SRA and we had -fwhole-program, but that is weak. We would need IPA-PTA to solve this in general. Perhaps frontend could help us here since the descriptors are probably constant after they are initialized, or is there way to change existing descriptor? 4) Make ipa-inline-analysis to understand that determining loop bounds is very cool to do. I also looked into the dumps of fatigue. One obvious problem is that we overestimate stack sizes by about factor of 10. This seems to be mostly due to I/O routines structures that gets packed later. We used to take results of stack frame packing, but Steven reverted this behaviour and now we estimate stack sizes by simply summing up the size of local arrays. I wonder, perhaps we want to revert to original way at least when optimizing and when generating summary for late inliner (early inliner probably does not care and Steven's main concern was that this is computed 3 times, twice for early inliner and once for real inliner). Honza
[Bug rtl-optimization/48773] Dataflow and REG_DEAD notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 --- Comment #6 from Matthew Fortune mfortune at gmail dot com 2011-05-04 16:19:32 UTC --- (In reply to comment #5) This is a known issue introduced by the DF merge. I think that the current state of affairs is that the passes consuming REG_DEAD/REG_UNUSED notes have to invoke df_note_add_problem on entry. Can anyone speculate as to which passes consume REG_DEAD notes or is it a case of trawling the source? invoking df_note_add_problem in the final pass should resolve the bug I have seen but I expect there are more.
[Bug c/48874] Sign of zeros sometimes lost in literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com 2011-05-04 16:17:12 UTC ---
On Wed, 4 May 2011, jb at gcc dot gnu.org wrote:
#include stdio.h
#include complex.h
int main()
{
double _Complex a = 0.0 + I*0.0;
double _Complex b = 0.0 - I*0.0;
double _Complex c = -0.0 + I*0.0;
double _Complex d = -0.0 - I*0.0;
printf(a= (%g,%g)\n, creal(a), cimag(a));
printf(b= (%g,%g)\n, creal(b), cimag(b));
printf(c= (%g,%g)\n, creal(c), cimag(c));
printf(d= (%g,%g)\n, creal(d), cimag(d));
}
This program, compiled with gcc zero1.c -O2 -pedantic -Wall -std=c99 (or
-std=gnu99) prints
a= (0,0)
b= (0,-0)
c= (0,0)
d= (-0,-0)
That is, the sign of the real part of c is lost. Add -fdump-tree-original to
the compile flags shows the dump as
That output appears correct to me. Each initializer is a real+complex
addition, and the sum of -0.0 and +0.0 is +0.0 except when rounding
towards negative infinity.
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 16:25:46 UTC --- Not sure if it would be ok to request instantiation of say copy ctor when we are unsure if the var will be firstprivate or not. The copy ctor can be marked as =delete, or perhaps say the instantiation of the copy ctor could result in static assertion failures or could use some =delete method...
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #21 from Marc Glisse marc.glisse at normalesup dot org 2011-05-04 16:27:28 UTC --- Created attachment 24182 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24182 first iteration in patch format Inserted in ratio, with some cleanup of dead code, rewrite of ratio_less. The static_assertions should help notice problems (in particular the __big_div ones should be good). I haven't tested much, but it seems to pass the current testsuite. Additional tests (no time to format or check them now) are available: * at the end of the overkill attachment * in comment #13 and comment #17
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04
16:37:40 UTC ---
Say:
templatetypename T
struct B
{
B () {}
B (const B) = delete;
~B () {}
};
templatetypename T
struct A
{
A () {}
A (const A) { BT b; BT c = b; }
void foo () {}
~A() {}
};
int
main()
{
Aint a;
#pragma omp task shared(a)
a.foo ();
#pragma omp task default(shared)
a.foo ();
#pragma omp parallel shared(a)
#pragma omp task
a.foo ();
#if 0
#pragma omp task
a.foo ();
#pragma omp parallel private (a)
#pragma omp task
a.foo ();
#endif
return 0;
}
With #if 0 all the a's are shared, even though it isn't immediately obvious in
all cases that it is that way without going through all the gimplify.c rules.
With #if 1 instead of #if 0 those two last tasks have implicit firstprivate(a)
and thus need to instantiate the copy ctor.
[Bug rtl-optimization/48773] Dataflow and REG_DEAD notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-04 16:38:54 UTC --- Can anyone speculate as to which passes consume REG_DEAD notes or is it a case of trawling the source? invoking df_note_add_problem in the final pass should resolve the bug I have seen but I expect there are more. The latter. That would be a little surprising at this point.
[Bug rtl-optimization/48773] Dataflow and REG_DEAD notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 --- Comment #8 from froydnj at codesourcery dot com froydnj at codesourcery dot com 2011-05-04 16:47:52 UTC --- On Wed, May 04, 2011 at 04:25:19PM +, mfortune at gmail dot com wrote: Can anyone speculate as to which passes consume REG_DEAD notes or is it a case of trawling the source? invoking df_note_add_problem in the final pass should resolve the bug I have seen but I expect there are more. Grepping for REG_DEAD shows up a number of places.
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #18 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-04 16:49:17 UTC --- Ne patch submitted to list for approval. http://gcc.gnu.org/ml/fortran/2011-05/msg00022.html
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.04 16:57:29 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 16:57:29 UTC --- Thanks a lot Marc. Let me work on this, add all the testcases we have around, regression test again.
[Bug preprocessor/48865] It would be useful to have a way to check the value of a #define at preprocessing time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 17:10:49 UTC --- Or, as I've just done, learn how to do it in your favourite editor. For mine (vim) it's [i to display the value and [^i to jump to the definition, which seems at least as good as the IDE you mention, and much quicker than changing the code and compiling it.
[Bug fortran/48864] -Ofast should imply -fno-protect-parens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-04 17:10:20 UTC --- Author: burnus Date: Wed May 4 17:10:15 2011 New Revision: 173385 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173385 Log: gcc/ 2011-05-04 Tobias Burnus bur...@net-b.de PR fortran/48864 * doc/invoke.texi (Ofast): Document that it enables Fortran's -fno-protect-parens. gcc/fortran 2011-05-04 Tobias Burnus bur...@net-b.de PR fortran/48864 * invoke.texi (fno-protect-parens): Document that -Ofast implies -fno-protect-parens. * options.c (gfc_init_options, gfc_post_options): Make -Ofast imply -fno-protect-parens. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/options.c
[Bug c/48874] Sign of zeros sometimes lost in literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-04 17:03:56 UTC --- Ah, I see. while sizeof(I) == 8, due to the addition it gets expanded to (0.0, 1.0), and then, as you say, the negative zero is lost. So to generate the literal constant (-0, 0) one needs double _Complex c2 = -(0.0 - I*0.0); Thank you both for the explanation.
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #24170|0 |1 is obsolete|| --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 17:13:37 UTC --- Created attachment 24183 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24183 gcc47-pr48853.patch Is this better?
[Bug c/48874] Sign of zeros sometimes lost in literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
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-05-04 17:00:31 UTC ---
(In reply to comment #0)
Consider
#include stdio.h
#include complex.h
int main()
{
double _Complex a = 0.0 + I*0.0;
double _Complex b = 0.0 - I*0.0;
double _Complex c = -0.0 + I*0.0;
double _Complex d = -0.0 - I*0.0;
printf(a= (%g,%g)\n, creal(a), cimag(a));
printf(b= (%g,%g)\n, creal(b), cimag(b));
printf(c= (%g,%g)\n, creal(c), cimag(c));
printf(d= (%g,%g)\n, creal(d), cimag(d));
}
This program, compiled with gcc zero1.c -O2 -pedantic -Wall -std=c99 (or
-std=gnu99) prints
a= (0,0)
b= (0,-0)
c= (0,0)
d= (-0,-0)
That is, the sign of the real part of c is lost. Add -fdump-tree-original to
the compile flags shows the dump as
To some of us this, this is a well-known problem/issue/feature of gcc.
In the expression, -0.0 + I * 0.0, the I is treated as 0 + i 1 where
i = sqrt(-1). So, you get -0.0 + (0 + i 1) * 0.0 = -0.0 + 0.0 + i 0.0,
which yields 0.0 + i 0.0.
There were/are fun issues with NaN and +-Inf. Joseph fixed some/all
of those problems. For details, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-04 17:30:31 UTC --- (In reply to comment #12) Perhaps frontend could help us here since the descriptors are probably constant after they are initialized, or is there way to change existing descriptor? Only if the dummy/formal argument is a pointer or an allocatable. Regarding ipa-cp, wasn't there a problem with fn spec (cf. PR 45579)? And many Fortran procedures have this attribute. This seems to be mostly due to I/O routines structures that gets packed later. We really need to start reusing them ... (Cf. PR 48419, PR 34705, and http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01762.html )
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2011-05-04 17:24:24 UTC --- (In reply to comment #11) Created attachment 24183 [details] gcc47-pr48853.patch Is this better? No, it doesn't handle DW_OP_GNU_const_type: (gdb) f 0 #0 mem_loc_descriptor (rtl=0x70de42f0, mode=DImode, mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED) at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14350 14350 mem_loc_result = new_loc_descr (DW_OP_GNU_const_type, 0, (gdb) bt #0 mem_loc_descriptor (rtl=0x70de42f0, mode=DImode, mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED) at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14350 #1 0x00b3b39d in mem_loc_descriptor (rtl=0x70d47f90, mode=DImode, mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED) at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14212 #2 0x00b1bed6 in dwarf2out_frame_debug_cfa_expression ( set=0x70d47fc0, label=0x4a8ee40 do not output) at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:2088 #3 0x00b1d605 in dwarf2out_frame_debug (insn=0x70d45a20, after_p=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:2870 #4 0x00c9a66c in final_scan_insn (insn=0x70d45a20, file=0x4c05540, optimize_p=2, nopeepholes=0, seen=0x7fffddac) at /export/gnu/import/git/gcc-x32/gcc/final.c:2775 #5 0x00c98ae7 in final (first=0x70ce95c0, file=0x4c05540, optimize_p=2) at /export/gnu/import/git/gcc-x32/gcc/final.c:1795 #6 0x00c9cfb4 in rest_of_handle_final () at /export/gnu/import/git/gcc-x32/gcc/final.c:4246 #7 0x0133ac82 in execute_one_pass (pass=0x4a80a00) at /export/gnu/import/git/gcc-x32/gcc/passes.c:1556 #8 0x0133ae71 in execute_pass_list (pass=0x4a80a00) at /export/gnu/import/git/gcc-x32/gcc/passes.c:1611 #9 0x0133ae92 in execute_pass_list (pass=0x4a813e0) ---Type return to continue, or q return to quit---q at /export/gnu/impoQuit (gdb) f 1 #1 0x00b3b39d in mem_loc_descriptor (rtl=0x70d47f90, mode=DImode, mem_mode=DImode, initialized=VAR_INIT_STATUS_INITIALIZED) at /export/gnu/import/git/gcc-x32/gcc/dwarf2out.c:14212 14212 dw_loc_descr_ref mem_loc_result2 (gdb) call debug_rtx (rtl) (plus:DI (reg/f:DI 6 bp) (const_int -24 [0xffe8])) (gdb) We need to check all those new DW_OP_GNU_ ops.
[Bug c++/40315] template instantiation fails when using const typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-04 17:38:37 UTC --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1001 is NAD so I think we can close this bug as INVALID
[Bug c++/48872] [C++0x][noexcept] Placement-new problem with non-empty arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-05-04 17:38:16 UTC ---
(In reply to comment #0)
sigh an error happended when I tryied to transform my original example (using
std::declval) to a form with a minimum of library support. So let me provide
this fixed example and please ignore the first example:
gcc 4.7.0 20110430 (experimental) in C++0x mode rejects the following program:
//---
#include new
templateclass T
T create() noexcept;
struct U {
~U() noexcept(false);
};
constexpr bool b = noexcept(::new ((void*) 0) U(createU()));
static_assert(b, Ouch); // #
int main() {}
//---
The compiler rejects the line marked with # because of an assertion failure.
This happens in all cases where an U is placement-constructed with arguments as
with createU() or with createconst U(). The example is accpted when only
value-initialized, like this:
constexpr bool b = noexcept(::new ((void*) 0) U());
This example demonstrates that the compiler seems to create a temporary in the
affected cases, so this is just another aspect of #48873.
[Bug c++/48872] [C++0x][noexcept] Placement-new problem with non-empty arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04
17:53:25 UTC ---
As I side remark, I'm not sure to understand why your testcases often include
an 'int main { }' line, I don't think are about link-time problems, no? If you
compile only what's the main for?
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-05-04 17:46:33 UTC --- I think it would be fine to mark_used the copy ctor in cases where it might or might not be used.
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 Charles Wilson gcc.20.cwilson at spamgourmet dot com changed: What|Removed |Added CC||gcc.20.cwilson at ||spamgourmet dot com --- Comment #11 from Charles Wilson gcc.20.cwilson at spamgourmet dot com 2011-05-04 17:48:14 UTC --- FWIW, using mingw.org's gcc-4.5.2 release, the test passes: $ g++ -fopenmp omp_test.c -o omp_test -lpthread $ ./omp_test.exe OMP : All looks good Relevant installation data: gcc-core-4.5.2-1-mingw32-bin gcc-c++-4.5.2-1-mingw32-bin libgcc-4.5.2-1-mingw32-dll-1 libstdc++-4.5.2-1-mingw32-dll-6 libgomp-4.5.2-1-mingw32-dll-1 mingwrt-3.18-mingw32-dll mingwrt-3.18-mingw32-dev w32api-3.17-2-mingw32-dev pthreads-w32-2.8.0-3-mingw32-dev libpthread-2.8.0-3-mingw32-dll-2 I believe this is because TLS support was added to the mingw(32) runtime in late Jan 2010, thanks to Kai's work: http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3550 (Although a full compiler suite, and mingw runtime, with TLS support was not officially released until March 2010)
[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-04 17:56:19 UTC --- Nit (for the future): library patches are diffed from where the library ChangeLog is.
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #24183|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-04 17:51:37 UTC --- Created attachment 24184 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24184 gcc47-pr48853.patch So like this? CONST_DOUBLEs really shouldn't appear in the addresses...
[Bug c++/48872] [C++0x][noexcept] Placement-new problem with non-empty arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-05-04 17:59:21 UTC ---
(In reply to comment #2)
As I side remark, I'm not sure to understand why your testcases often include
an 'int main { }' line, I don't think are about link-time problems, no? If you
compile only what's the main for?
I will try to reduce that in the future for bug reports. I'm still in standard
mode when doing this to ensure that the program is well-formed and
well-defined. Partial programs seem ok here, if I understand you correctly.
[Bug debug/48853] [4.7 Regression] Wrong DWARF codegen when Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853 --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2011-05-04 18:10:24 UTC --- (In reply to comment #13) Created attachment 24184 [details] gcc47-pr48853.patch So like this? CONST_DOUBLEs really shouldn't appear in the addresses... It looks much better. I am retesting everything now. Thanks.
[Bug c++/48749] [4.6/4.7 Regression] internal compiler error: tree check: expected field_decl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/40315] template instantiation fails when using const typename
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2011-05-04 18:14:36 UTC --- Agreed.
