[Bug rtl-optimization/65912] x_rtl.x_frame_offset not updated after frame related insn deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65912 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com --- On Apr 27, 2015, at 9:10 PM, jiwang at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Has anyone run into this issue on other architecture like MIPS, PPC? Yes on both.
[Bug target/65648] [5 Regression] Bad code due to IRA fails to recognize the clobber in parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com ---
On Wed, Apr 1, 2015 at 5:44 PM, terry.guo at arm dot com
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65648
Bug ID: 65648
Summary: [5 Regression] Bad code due to IRA fails to recognize
the clobber in parallel
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 35200
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35200action=edit
test case
When compile attached case with command:
arm-none-eabi-gcc -march=armv6-m -mthumb -Os x.c -S
The gcc generates bad code as below:
main:
push{r0, r1, r2, r4, r5, r6, r7, lr}
ldr r4, .L5
movsr5, #0
ldr r0, [r4, #8]
add r1, sp, #4
rsbsr2, r0, #0
adcsr2, r2, r0
subsr3, r2, r3 //r3 is used but not initialized
The instruction to initialize r3 is removed due to IRA failed to recognize the
clobber in reload pass. Before the reload pass, we have three instructions
like
below:
(insn 12 11 14 2 (parallel [
(set (reg:SI 128)
(eq:SI (reg:SI 110 [ D.4914 ])
(const_int 0 [0])))
(clobber (reg:SI 129))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(expr_list:REG_UNUSED (reg:SI 129)
(nil)))
(insn 20 19 22 2 (set (reg:SI 135)
(plus:SI (plus:SI (reg:SI 136)
(reg:SI 137))
(geu:SI (reg:SI 131 [ D.4914 ])
(reg:SI 134 [ c ] x.c:23 764 {thumb1_addsi3_addgeu}
(expr_list:REG_DEAD (reg:SI 137)
(expr_list:REG_DEAD (reg:SI 136)
(expr_list:REG_DEAD (reg:SI 134 [ c ])
(expr_list:REG_DEAD (reg:SI 131 [ D.4914 ])
(nil))
(insn 22 20 23 2 (set (reg:SI 138)
(minus:SI (reg:SI 128)
(reg:SI 135))) x.c:23 720 {thumb1_subsi3_insn}
(expr_list:REG_DEAD (reg:SI 135)
(expr_list:REG_DEAD (reg:SI 128)
(nil
After the reload pass, those instructions are wrongly turned into:
(insn 20 53 58 2 (set (reg:SI 3 r3 [135])
(plus:SI (plus:SI (reg:SI 3 r3 [137])
(reg:SI 2 r2 [136]))
(geu:SI (reg:SI 7 r7 [orig:131 D.4914 ] [131])
(reg:SI 6 r6 [153] x.c:23 764 {thumb1_addsi3_addgeu}
(nil))
(insn 58 20 55 2 (parallel [
(set (reg:SI 2 r2 [128])
(eq:SI (reg:SI 0 r0 [orig:110 D.4914 ] [110])
(const_int 0 [0])))
(clobber (reg:SI 3 r3 [129]))
]) x.c:23 760 {*cstoresi_eq0_thumb1_insn}
(nil))
(note 55 58 22 2 NOTE_INSN_DELETED)
(insn 22 55 23 2 (set (reg:SI 3 r3 [138])
(minus:SI (reg:SI 2 r2 [128])
(reg:SI 3 r3 [135]))) x.c:23 720 {thumb1_subsi3_insn}
(nil))
However the later pass can recognize the clobber in insn 58 and will remove
the
insn 20 because the r3 defined in insn 20 is clobbered by insn 58.
This is a bug in the arm's thumb1.md file, it uses match_operand when
it should really be using match_scratch.
Looks like most of the arm back-end has this bug in it.
See
https://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html#index-scratch-2870
and the corresponding match_scratch documentation.
That is this:
1515 (define_insn *cstoresi_eq0_thumb1_insn
1516 [(set (match_operand:SI 0 s_register_operand =l,l)
1517 (eq:SI (match_operand:SI 1 s_register_operand l,0)
1518(const_int 0)))
1519(clobber (match_operand:SI 2 s_register_operand =X,l))]
1520 TARGET_THUMB1
1521 @
1522rsbs\\t%0, %1, #0\;adcs\\t%0, %0, %1
1523rsbs\\t%2, %1, #0\;adcs\\t%0, %1, %2
1524 [(set_attr length 4)
1525(set_attr type multiple)]
1526 )
Really should be using (clobber (match_scratch:... ))
So it generates a scratch RTL right away and then the register
allocater knows that it is only used in that instruction.
Thanks,
Andrew
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #10 from pinskia at gmail dot com pinskia at gmail dot com --- On Mar 15, 2014, at 7:59 PM, wschmidt at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- The problem is actually introduced much earlier, during the cunrolli (complete unroll inner) pass. I'm attaching dumps from 055t.copyrename2 and 056t.cunrolli to show what happens. Prior to unrolling, we have a loop formed by blocks 47,19,20,...,46, with the original call to makeUnion at the end of block 45. The unroller decides that this loop will be executed exactly 3 times and unrolls it completely. (It's not clear to me on what basis this decision is made in the first place; it doesn't seem justified on the surface.) What is the type of bc? That access to bc in bb 46 looks like to be the cause. What is the original code look like, do we have an out of bounds access here or just a miscombining to create one? Thanks, Andrew In any case, the third copy of the loop comprises blocks 74 through 101, with the call to makeUnion duplicated at the end of block 100. The unroller then inserts a __builtin_unreachable at the end of block 101 for some reason. This survives until the rewrite into RTL, at which point it is converted to the barrier that causes the bad block reordering.
[Bug c++/58772] __attribute__((aligned(16))) and nested classes cause -ftree-vectorize to generate segfaulting code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772 --- Comment #6 from pinskia at gmail dot com pinskia at gmail dot com --- Sent from my iPad On Oct 21, 2013, at 2:35 AM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58772 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) The syntax would be ::posix_memalign (act, 16, sizeof (Actor)); Or #include mm_malloc.h ... act = _mm_malloc, sizeof (Actor), 16); which is supposed to be a bit more portable. (mm_malloc.h ships with GCC since 4.0, if I recall correctly.) Less portable as that only works on x86 while posix_memalign works on all posix targets.
[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com --- All of these functions overflow the loop induction variable so only -fwrapv will provide the behavior you want for all of the functions. The inconsistent behavior is due to the overflows happening for induction variables. If it was not an induction variable then -fno-strict-overflow would have worked..-fno-strict-overflow is only defined to work for non loop variables. Thanks, Andrew On Sep 17, 2013, at 6:28 PM, mednafen at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Bug ID: 58454 Summary: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mednafen at gmail dot com Created attachment 30844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844action=edit Testcase program. Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * : XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fno-tree-vrp -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fwrapv -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1 Thread model: posix gcc version 4.8.1 (GCC)
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #3 from pinskia at gmail dot com pinskia at gmail dot com --- I have a fix which I hope to share in the next few weeks. Sent from my iPad On Aug 30, 2013, at 3:31 AM, evstupac at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com --- I can't share CoreMark sources. However, you can get them at www.coremark.org when accept the license. The error caused by edge-count of new edges which is grater than max_count: (line 902) gcc_assert (max_count = edge-count); The new edge is generated in case of indirect inline: (line 1517) if (flag_indirect_inlining) new_indirect_edges.create (8); and does not participate in max_count calculation, but refers to it when adding to a heap: (lines 1724 and 1761) if (flag_indirect_inlining) add_new_edges_to_heap (edge_heap, new_indirect_edges); Updating max_count with new_edges counts resolves the ICE.
[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 2012-08-17 19:13:50 UTC --- This is a darwin only issue. On Aug 17, 2012 12:07 PM, tobi at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 Bug #: 54304 Summary: linking stage picks up system mpfr instead of in-tree version Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: t...@gcc.gnu.org This is an old bug, I found mention of it all over the internet, and also on the gcc mailing list http://gcc.gnu.org/ml/gcc-help/2011-04/msg00126.html . What happens is that with an in-tree gmp, mpfr, mpc (I used contrib/download_prerequisites) the linking stage picks up the system libraries instead of the in-tree versions. This causes a problem when the system libmpfr 3.0.0 and the in-tree version is = 3.0.0 and vice versa, because mpfr_get_z_exp was renamed to mpfr_get_z_2exp between the two (hidden behind a macro). The error I'm seeing with today's tree is: /Users/tobi/src/gcc/build/./prev-gcc/g++ -B/Users/tobi/src/gcc/build/./prev-gcc/ -B/usr/local/x86_64-apple-darwin11.4.0/bin/ -nostdinc++ -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs -B/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include/x86_64-apple-darwin11.4.0 -I/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/include -I/Users/tobi/src/gcc/libstdc++-v3/libsupc++ -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/src/.libs -L/Users/tobi/src/gcc/build/prev-x86_64-apple-darwin11.4.0/libstdc++-v3/libsupc++/.libs -g -O2 -mdynamic-no-pic -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-no_pie -o f951 \ fortran/arith.o fortran/array.o fortran/bbt.o fortran/check.o fortran/class.o fortran/constructor.o fortran/cpp.o fortran/data.o fortran/decl.o fortran/dump-parse-tree.o fortran/error.o fortran/expr.o fortran/interface.o fortran/intrinsic.o fortran/io.o fortran/iresolve.o fortran/match.o fortran/matchexp.o fortran/misc.o fortran/module.o fortran/openmp.o fortran/options.o fortran/parse.o fortran/primary.o fortran/resolve.o fortran/scanner.o fortran/simplify.o fortran/st.o fortran/symbol.o fortran/target-memory.o darwin-f.o fortran/convert.o fortran/dependency.o fortran/f95-lang.o fortran/trans.o fortran/trans-array.o fortran/trans-common.o fortran/trans-const.o fortran/trans-decl.o fortran/trans-expr.o fortran/trans-intrinsic.o fortran/trans-io.o fortran/trans-openmp.o fortran/trans-stmt.o fortran/trans-types.o fortran/frontend-passes.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl -L/opt/local/lib -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a attribs.o -L/Users/tobi/src/gcc/build/./gmp/.libs -L/Users/tobi/src/gcc/build/./mpfr/.libs -L/Users/tobi/src/gcc/build/./mpc/src/.libs -lmpc -lmpfr -lgmp -L../zlib -lz Undefined symbols for architecture x86_64: _mpfr_get_z_exp, referenced from: gfc_mpfr_to_mpz(__mpz_struct*, __mpfr_struct*, locus*) in arith.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make[3]: *** [f951] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 (I mentioned this in the aftermath to PR54292) Cheers
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #36 from pinskia at gmail dot com pinskia at gmail dot com 2012-04-02 17:35:59 UTC --- I know some of us use tee and that disables termainal detection code usually. Or output to a file and then use tail -f. So please don't do that. It would confuse lots of users. Sent from my Palm Pre on ATamp;T On Apr 2, 2012 4:17, manu at gcc dot gnu.org lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #31 from Manuel López-Ibáñez lt;manu at gcc dot gnu.orggt; 2012-04-02 08:16:52 UTC --- (In reply to comment #30) gt; (In reply to comment #26) gt; gt; The caret is not a solution to this problem, because what Gabriel wants is to gt; gt; not reconstruct expressions ONLY when the caret is shown, but he has said in gt; gt; the past that the caret should default to OFF to not change the current output gt; gt; for IDEs and other software parsing the output of gcc like emacs, so we are gt; gt; back to printing the monsters mentioned above by default. gt; gt; I think I've said before that caret should default to on when the output is a gt; terminal. gt; Well, that is reassuring. Then, will we still pretty-print expressions in diagnostics once we have the caret? Is there a GCC way to detect that the output is a terminal?
[Bug tree-optimization/52705] Loop optimization failure with -O2 versus -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705
--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com
2012-03-25 05:12:44 UTC ---
You are volating c/c++ aliasing rules. Use memcpy or -fno-strict-aliasing .
Sent from my Palm Pre on ATamp;T
On Mar 24, 2012 21:27, veiokej at gmail dot com
lt;gcc-bugzi...@gcc.gnu.orggt; wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52705
Bug #: 52705
Summary: Loop optimization failure with -O2 versus -O1
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: veio...@gmail.com
Created attachment 26976
--gt; http://gcc.gnu.org/bugzilla/attachment.cgi?id=26976
Intermediate of bug.c
When I compile with these different optimization levels, I get different
output. This isn't confusion over floats or uninitialized variables, as far as
I can tell. It appears to relate to casted memory accesses.
First of all, this relates to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49938, which _might_ solve the
problem (but I don't know, because I'm unable to upgrade from 4.6.1 under
MinGW). So please try the latest GCC before you try to debug this.
Here's the command line:
gcc -save-temps -O2 -obug.exe bug.c
This bug is very easy to reproduce. Here's the entire source of bug.c:
#include lt;stdint.hgt;
#include lt;stdio.hgt;
void
func(uint32_t a[8],uint32_t b[8]){
uint32_t i;
uint32_t c;
int64_t d;
for(i=0;ilt;=1;i++){
((uint64_t *)(b))[0]=((uint64_t *)(a))[0];
((uint64_t *)(b))[1]=((uint64_t *)(a))[0];
((uint64_t *)(b))[2]=((uint64_t *)(a))[0];
((uint64_t *)(b))[3]=((uint64_t *)(a))[0];
c=1;
d=b[0];
d-=c;
b[0]=d;
c=b[0];
d=b[1];
d-=clt;lt;1;
b[1]=d;
}
return;
}
int
main(int argc, char *argv[]){
uint32_t a[8]={1,0,0,0,0,0,0,0};
uint32_t b[8];
func(a,b);
printf(%08X%08X%08X%08X%08X%08X%08X%08X\n,b[0],b[1],b[2],b[3],b[4],b[5],b[6],b[7]);
return 0;
}
As you will see, you get different outputs depending on whether you use -O1 or
-O2.
The relation to Bug 49930 is this:
Look at the above code. If you change:
d=b[1];
d-=clt;lt;1;
b[1]=d;
to:
d=b[0];
d-=clt;lt;1;
b[0]=d;
Then you will see bug 49930.
Note that b[] appears to be only half-initialized because I only write to
subscripts 0 through 3. But that's not the case, because I've casted 8 32-bit
integers to 4 64-bit integers.
I notice that when I change the lines involving (uint64_t *) casts to normal
(uint32_t *) memory accesses, i.e. when I get rid of the casts, it seems to
work better (but didn't investigate at length). But I don't want to do that for
performance reasons. (bug.c is just an adaptation that's filtered from a real
function where performance matters.)
[Bug middle-end/51116] [4.7 Regression] configure: error: cannot compute suffix of object files: cannot compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51116
--- Comment #3 from pinskia at gmail dot com pinskia at gmail dot com
2011-11-13 04:32:06 UTC ---
According to another email mips is broken the same way.
Sent from my Palm Pre on ATamp;T
On Nov 12, 2011 20:18, danglin at gcc dot gnu.org
lt;gcc-bugzi...@gcc.gnu.orggt; wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51116
Bug #: 51116
Summary: [4.7 Regression] configure: error: cannot compute
suffix of object files: cannot compile
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa64-hp-hpux11.11
Target: hppa64-hp-hpux11.11
Build: hppa64-hp-hpux11.11
In stage1,
checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include -isystem
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include
checking for suffix of object files... configure: error: in
`/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
In config.log,
configure:3650: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B
/opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.7/hppa64-
hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/include
-i
system /opt/gnu64/gcc/gcc-4.7/hppa64-hp-hpux11.11/sys-include-c -g -O2
conf
test.c gt;amp;5
/var/tmp//ccjq1spX.s: Assembler messages:
/var/tmp//ccjq1spX.s:44: Error: can't resolve `.text.startup' {.text.startup
sec
tion} - `L$FB' {*UND* section}
/var/tmp//ccjq1spX.s:148: Error: can't resolve `.text.startup' {.text.startup
se
ction} - `L$FB' {*UND* section}
configure:3654: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| /* end confdefs.h. */
|
| int
| main ()
|
| ;
| return 0;
| }
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #3 from pinskia at gmail dot com pinskia at gmail dot com 2011-08-16 17:25:26 UTC --- Because darwin's as does not support it. It only supports with r0. Sent from my Palm Pre on ATamp;T On Aug 16, 2011 10:13, ebotcazou at gcc dot gnu.org lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 Eric Botcazou lt;ebotcazou at gcc dot gnu.orggt; changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-16 AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou lt;ebotcazou at gcc dot gnu.orggt; 2011-08-16 17:12:00 UTC --- gt; Well, look at the PR - it was an ICE with graphite and stack-check, so yes, gt; of course. gt; gt; stw 0,-12284(r1) gt; gt; looks like some missing operand print thing to dump fancy regnames (r0 instead gt; of 0). How come the assembler chokes on this? Looking into it...
[Bug rtl-optimization/49807] Missed byte (subreg) extraction when storing to volatile mem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49807 --- Comment #4 from pinskia at gmail dot com pinskia at gmail dot com 2011-07-21 20:39:08 UTC --- On Thu, Jul 21, 2011 at 1:34 PM, gjl at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: I don't know the exact rationale why volatile_ok is false in combine. It' obviously about volatile correctnet, but I don't see what would break here. It can, when dealing optimizations that reduce the size of load/stores of volatile memory. Thanks, Andrew Pinski
[Bug tree-optimization/49709] Bad code gen with -fipa-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49709 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 2011-07-12 00:58:13 UTC --- Hmmm. There was just a recent patch to the tail call area which was supposed to fix a testcase like this. Sent from my Palm Pre on ATamp;T On Jul 11, 2011 17:51, ian at airs dot com lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49709 Summary: Bad code gen with -fipa-sra Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: i...@airs.com Created attachment 24741 --gt; http://gcc.gnu.org/bugzilla/attachment.cgi?id=24741 Test case I have attached a C test case. When compiled for x86 with -m32 -O2, the test case aborts. When compiled with -m32, or with -m32 -O2 -fno-ipa-sra it runs to completion. I believe the bug is that ipa-sra leaves a call which refers to function parameters using MEM_REF expressions which refer to fields of the parameters. These are translated into MEM expressions which load the address of the parameter into a register and then use a MEM_REF to load an offset from that register. This MEM does not refer to the internal_arg_pointer, but to a register which was set based on the internal_arg_pointer. That means that mem_overlaps_already_clobbered_arg_p in calls.c does not recognize that the MEM refers to the argument area. That in turn means that gcc thinks that it can make a tail call, but when setting up the arguments for the call it clobbers arguments that it has yet to read. The fix may be to make mem_overlaps_already_clobbered_arg_p much smarter, or to disable tail calls when applying SRA to a function and passes parameters to it.
[Bug tree-optimization/47708] incorrect code on -O2 without -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47708 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 2011-02-12 06:36:09 UTC --- You are violating c/c++ aliasing rules. nbsp;The code is undefined. Sent from my Palm Pre on ATamp;T On Feb 11, 2011 22:27, zephyrtronium at gmail dot com lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47708 Summary: incorrect code on -O2 without -fno-tree-pre Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zephyrtron...@gmail.com Created attachment 23310 --gt; http://gcc.gnu.org/bugzilla/attachment.cgi?id=23310 minimal case gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.5.2/configure --enable-lto Thread model: posix gcc version 4.5.2 (GCC) Compiling the following minimal case on -O2 or -O3 and running results in incorrect output; with -O0, -O1, or -Os, it is correct. -O2 -fno-tree-pre results in correct output, but -O1 -ftree-pre is also correct. GCC 4.4.3 appears to work.
[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383 --- Comment #6 from pinskia at gmail dot com pinskia at gmail dot com 2011-01-21 11:43:45 UTC --- Sent from my Palm Pre on ATamp;T On Jan 20, 2011 21:34, hjl.tools at gmail dot com lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383 --- Comment #4 from H.J. Lu lt;hjl.tools at gmail dot comgt; 2011-01-21 05:33:53 UTC --- (In reply to comment #3) gt; The ivopts pass transforms gt; gt; gt; unsigned int D.2715; gt; unsigned int D.2716; gt; ... gt; D.2715_43 = (unsigned int) elems_3(D); gt; D.2716_42 = D.2715_43 + 4294967295; gt; n_49 = (int) D.2716_42; gt; gt; leads o the wrong result when Pmode != unsigned int. Adding gt; -fno-ivopts fixes the bug. gt; This is OK due to cast to int. But long unsigned int D.2757; long unsigned int D.2749; long unsigned int D.2750; unsigned int ivtmp.20; int D.2748; unsigned int ivtmp.17; ... D.2749_6 = (long unsigned int) prephitmp.8_18; D.2750_34 = ivtmp.17_28 - D.2749_6; MEM[symbol: heap, index: D.2750_34, step: 8, offset: 2296B] = n_11; Mem here should have been rejected. looks wrong since it assumes D.2750_34 can be negative. But D.2750_34 is unsigned. It won't work when ptr_mode == unsigned and Pmode is unsigned long long.
[Bug libobjc/47173] both objc_lookUpClass and objc_lookup_class are exported symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47173 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 2011-01-05 02:56:51 UTC --- I think one is the old abi and the other is the new one. Sent from my Palm Pre on ATamp;T On Jan 4, 2011 18:33, doko at ubuntu dot com lt;gcc-bugzi...@gcc.gnu.orggt; wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47173 Summary: both objc_lookUpClass and objc_lookup_class are exported symbols Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@ubuntu.com I assume that the first one should be removed?
[Bug c++/47108] enum won't use long long as underlying type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47108
--- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com
2010-12-29 13:18:40 UTC ---
enum { nbsp;a=1lt;lt;33 }blaf;nbsp;
That is still an int as 1 is of type int. Try 1lllt;lt;33.
[Bug testsuite/46425] [4.6 Regression] Revision 166570 caused many failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46425 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com 2010-11-11 04:41:09 UTC --- These failures have fixed already. The issue was in the testsuite. On Nov 10, 2010, at 8:13 PM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46425 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.11 04:13:10 Component|c |testsuite Target Milestone|--- |4.6.0 Ever Confirmed|0 |1
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #12 from pinskia at gmail dot com pinskia at gmail dot com 2010-10-26 15:56:20 UTC --- On Oct 26, 2010, at 7:30 AM, j...@jak-linux.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:30:24 UTC --- Created attachment 22162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162 Clang's assember This multiplication transformation is incorrect if the loop wraps (unsigned always wraps; never overflows). Gcc is correct in its speed. Though -O3 is faster but not because of multiplication but rather constant propatagtion. So this bug is invalid and some one should report a bug to llvm folks about this. Attaching the assembler output from clang, it should help understand which optimizations clang does (and improve gcc to do them as well).
[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance
--- Comment #3 from pinskia at gmail dot com 2010-09-03 19:02 ---
Subject: Re: New: Failure to bind auto variable to function template instance
I think there is a dup of this bug without auto. Not to mention it was
defect report against the standard.
On Sep 3, 2010, at 10:07 AM, jewillco at osl dot iu dot edu
gcc-bugzi...@gcc.gnu.org
wrote:
The following code:
template typename T void foo();
void f() {auto g = fooint;}
fails to compile in GCC 4.5.0's C++0x mode with the following error:
foo.cpp: In function âvoid f()â:
foo.cpp:2:20: error: âgâ has incomplete type
Trying different variants of this code, it appears that GCC believes
that
fooint is an ambiguous overloaded function, while there is only
one matching
function.
--
Summary: Failure to bind auto variable to function template
instance
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jewillco at osl dot iu dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45523
[Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
--- Comment #2 from pinskia at gmail dot com 2010-09-02 19:55 ---
Subject: Re: New: Does adding configure-options for specs-hardcoding make
sense?
You could use a small wrapper script that adds R option instead of a
specs file or adds the specs file to the command line.
On Sep 2, 2010, at 12:48 PM, nicolai dot stange at zmaw dot de
gcc-bugzi...@gcc.gnu.org
wrote:
Hi everybody,
I'm not involved in any gcc development nor am I familiar with gcc
and its
components and thus, the attached patch is just a place to start
from if you
agree with me that my request for adding more control over the specs
via
configure options makes sense.
My problem is this one:
At our site, we provide many versions of several compilers,
including the great
GCC, at non-standard locations. The problem is with the runtime
search paths
for the libgcc_s, ...: The runtime linker always finds the most
wrong one: The
one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if
it were
Linux or sth. other, it would also find the wrong libgcc_s, shipped
with the
distribution, or none at all).
Asking the kind guys in #gcc at freenode, they told me that I might
want to
supply a specs file. Hmm, I want to set site-wide specs for all users
transparently. Reading the sourcecode of gcc, I recognized that I
can put a
complete specs file to gcc_prefix/lib/gcc/target/version/specs.
(I didn't find any documentation about that feature, so maybe this
lack of docs
is another bug?).
But this solution has two drawbacks for me:
- I'm bootstrapping and the linking of the runtime libraries for the
target
would not be influenced by placing this specs-file _after_
installation. Ok, I
could go with LDFLAGS_FOR_TARGET, but this would make the whole
thing more
non-convenient (at least in my opionion).
- Creating that specs-file for every GCC-release makes automating
the GCC
deployment harder: At first I have to check if the default-specs are
still the
same, the I have to modify them to insert a runtime search path for
the new
installation location and then I have to put it at the right
location. It seems
that I have to exercise some bash/sed/diff/m4-tasks...
Another solution would be this:
Adding a --with-link-libgcc-specs option to the configure in the
gcc-subdirectory, I could configure gcc with
../gcc-4.5.1/configure
--with-link-libgcc-specs=\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/
gcc-4.5.1/lib/sparcv9}
...
(btw: -R is the -rpath-equivalent of the Sun Linker on Solaris)
If this user-supplied spec would be prepended/appended to the default
link_libgcc spec, all would be fine.
The attached patch is for link_libgcc spec only, but maybe altering
the other
specs by configure-options might be useful for other people under
other
circumstances, too?
Please note again, that the attached patch is just a quick hack, if
you agree
to add those options, one should have a closer look.
Best wishes
Nicolai
--
Summary: Does adding configure-options for specs-
hardcoding make
sense?
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolai dot stange at zmaw dot de
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #9 from pinskia at gmail dot com 2010-09-01 06:17 --- Subject: Re: Bad optimization in -O3 sometimes I am not talking about a library solution at all. I am talking about a solution inside the compiler. Gcc will optimize memcpy; how much for MIPS is a good question. Try it out and see. Oh if you are using scei's gcc you really should be reporting issues to them. On Aug 31, 2010, at 10:03 PM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 --- Unfortunately, a lib based solutions are difficult for me to implement. The reason is that the current PSP SDK uses newlib. I can probably change my personal toolchain with some work, but then it's a custom modification that needs to be replicated to every other ScummVM dev as well as our buildbot. Not impossible, but not work I'd like to get in to right now. In any case, it sounds like what you're saying is that memcpy has asm instructions in the right place to use lwl and lwr. I can also do that in my implementation. My request was more general, as in gcc needs some kind of custom keyword to tell it to allow unaligned pointers and to generate appropriate unaligned code, so we don't have to trick the compiler into doing it in a way that ruins optimization. Something like __unaligned__ uint32 *ptr32 = bytePtr; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug middle-end/45484] r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32
--- Comment #11 from pinskia at gmail dot com 2010-09-02 05:55 --- Subject: Re: r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32 On Sep 1, 2010, at 10:47 PM, ubizjak at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #10 from ubizjak at gmail dot com 2010-09-02 05:47 --- (In reply to comment #8) Since this doesn't backtrace in gdb, I recompiled dwarf2out.c with the patch... You should use bigger hammer. Try valgrind using following procedure: a) Create a preprocessed source ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc -Os -S -save-temps sprintf-chk.c b) fire up valgrind: valgrind ~/gcc-build/gcc/cc1 -Os -quiet sprintf-chk.i ==3664== Memcheck, a memory error detector ==3664== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==3664== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==3664== Command: /home/uros/gcc-build/gcc/cc1 -Os -quiet sprintf- chk.i ==3664== ==3664== Invalid read of size 8 ==3664==at 0xC71730: search_line_sse2 (lex.c:394) ==3664==by 0xC71919: _cpp_clean_line (lex.c:665) ==3664==by 0xC72317: _cpp_get_fresh_line (lex.c:1878) ==3664==by 0xC73AA1: _cpp_lex_direct (lex.c:1943) ==3664==by 0xC74896: _cpp_lex_token (lex.c:1817) ==3664==by 0xC76FC7: cpp_get_token (macro.c:1240) ==3664==by 0xC7727F: cpp_get_token_with_location (macro.c:1352) ==3664==by 0x51684C: c_lex_with_flags (c-lex.c:302) ==3664==by 0x4CFAA7: c_lex_one_token (c-parser.c:204) ==3664==by 0x4DC468: c_parser_compound_statement_nostart (c- parser.c:320) ==3664==by 0x4DEA18: c_parser_compound_statement (c-parser.c:3545) ==3664==by 0x4DBDC2: c_parser_declaration_or_fndef (c-parser.c: 1375) ==3664== Address 0x5331f50 is 5,808 bytes inside a block of size 5,815 alloc'd ==3664==at 0x4A05255: realloc (vg_replace_malloc.c:476) ==3664==by 0xC9ADAC: xrealloc (xmalloc.c:179) ==3664==by 0xC6659F: _cpp_convert_input (charset.c:1734) ==3664==by 0xC6EFA2: read_file (files.c:648) ==3664==by 0xC6F9CA: _cpp_stack_file (files.c:723) ==3664==by 0xC71190: cpp_read_main_file (init.c:570) ==3664==by 0x51B58A: c_common_post_options (c-opts.c:1124) ==3664==by 0x7DACA4: toplev_main (toplev.c:1826) ==3664==by 0x369861EC5C: (below main) (in /lib64/libc-2.12.so) ==3664== ==3664== Invalid read of size 8 ==3664==at 0xC71723: search_line_sse2 (lex.c:382) ==3664==by 0xC71919: _cpp_clean_line (lex.c:665) ==3664==by 0xC72317: _cpp_get_fresh_line (lex.c:1878) ==3664==by 0xC73AA1: _cpp_lex_direct (lex.c:1943) ==3664==by 0xC74896: _cpp_lex_token (lex.c:1817) ==3664==by 0xC76FC7: cpp_get_token (macro.c:1240) ==3664==by 0xC7727F: cpp_get_token_with_location (macro.c:1352) ==3664==by 0x51684C: c_lex_with_flags (c-lex.c:302) ==3664==by 0x4CFAA7: c_lex_one_token (c-parser.c:204) ==3664==by 0x4DC468: c_parser_compound_statement_nostart (c- parser.c:320) ==3664==by 0x4DEA18: c_parser_compound_statement (c-parser.c:3545) ==3664==by 0x4DBDC2: c_parser_declaration_or_fndef (c-parser.c: 1375) ==3664== Address 0x5331f50 is 5,808 bytes inside a block of size 5,815 alloc'd ==3664==at 0x4A05255: realloc (vg_replace_malloc.c:476) ==3664==by 0xC9ADAC: xrealloc (xmalloc.c:179) ==3664==by 0xC6659F: _cpp_convert_input (charset.c:1734) ==3664==by 0xC6EFA2: read_file (files.c:648) ==3664==by 0xC6F9CA: _cpp_stack_file (files.c:723) ==3664==by 0xC71190: cpp_read_main_file (init.c:570) ==3664==by 0x51B58A: c_common_post_options (c-opts.c:1124) ==3664==by 0x7DACA4: toplev_main (toplev.c:1826) ==3664==by 0x369861EC5C: (below main) (in /lib64/libc-2.12.so) ==3664== ==3680== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 6 from 6) Woo-hoo? Actually those can be safely ignored. The loads will not cross page boundaries and then the code does not depend on the extra parts if the buffer has correctly a null character at the end. So it is a non bug that valgrind picks up but does not know how to handle when processing strings with vector instructions. -- ubizjak at gmail dot com changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-02 05:47:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #5 from pinskia at gmail dot com 2010-08-31 19:09 --- Subject: Re: Bad optimization in -O3 sometimes On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS instructions without breaking strict aliasing rules...? Have you tried using memcpy? Thanks a bunch! -- yotambarnoy at gmail dot com changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug c++/45462] Bad optimization in -O3 sometimes
--- Comment #7 from pinskia at gmail dot com 2010-09-01 04:41 --- Subject: Re: Bad optimization in -O3 sometimes On Aug 31, 2010, at 9:32 PM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 04:32 --- I recently implemented a custom memcpy for ScummVM. I didn't notice the standard memcpy using lwl and lwr. In any case, how would memcpy do it any better? Unless you're referring to the new memcpy inlining in newer versions of gcc? I am referring to the standard builtin version of memcpy. It is not just in newer versions; it has been there since 3.0. What is new is the more optimized version for x86 with either a large constant or a non constant. Can you try memcpy? If that does not work, please file a bug and cc me, I will see what I can do. I am working with MIPS lately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462
[Bug tree-optimization/45340] __builtin_expect and -Os generates stupid code
--- Comment #8 from pinskia at gmail dot com 2010-08-25 12:43 --- Subject: Re: __builtin_expect and -Os generates stupid code On Aug 25, 2010, at 5:23 AM, socketpair at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #7 from socketpair at gmail dot com 2010-08-25 12:23 --- Well, I understand that problem is not in __builtin_expect. Should I open new, separate bug about block reordering and generating jmp to next line ? No because it is not jumping to the next line but across the next instruction which just happens to be an inline-asm which is blank. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45340
[Bug bootstrap/45376] no such instruction: `pcmpestri $0,(%rdi),%xmm0'
--- Comment #3 from pinskia at gmail dot com 2010-08-22 18:05 --- Subject: Re: New: no such instruction: `pcmpestri $0,(%rdi),%xmm0' What version of binutils is being used? Have you tried a newer version? On Aug 22, 2010, at 3:11 AM, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Updating today at revision 163455 gave : /home/mik/gcc46/src/libcpp/lex.c: Assembler messages: /home/mik/gcc46/src/libcpp/lex.c:448: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' /home/mik/gcc46/src/libcpp/lex.c:432: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' A revision from yesterday worked (2010-08-21), but I don't remember the revision number. Possible culprit according to the ChangeLog : revision 163446. -- Summary: no such instruction: `pcmpestri $0,(%rdi),%xmm0' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael at gcc dot gnu dot org GCC build triplet: x86_64-unknown-freebsd8.0 GCC host triplet: x86_64-unknown-freebsd8.0 GCC target triplet: x86_64-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug target/45258] linkage on -lm and -lpthread should be purged from darwin build
--- Comment #1 from pinskia at gmail dot com 2010-08-11 17:03 --- Subject: Re: New: linkage on -lm and -lpthread should be purged from darwin build What about removing those in the driver? This way it works correctly for other makefiles too? On Aug 11, 2010, at 9:30 AM, howarth at nitro dot med dot uc dot edu gcc-bugzi...@gcc.gnu.org wrote: Currently libjava is being improperly linked (PR java/41991) due to the presence of -lm and -lpthreads on the shared library linkages. This causes libSystem.dylib to be pushed to the front of the linkage and breaks the logic used by libgcc_ext. We should add and set defines for HAVE_LIBSYSTEM_PTHREADS and HAVE_LIBSYSTEM_LIBMATH to configure and use these for conditionals in the Makefile.am's where appropriate to avoid passing -lm and -lpthread on darwin. -- Summary: linkage on -lm and -lpthread should be purged from darwin build Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258
[Bug c++/45246] optimizer dereference
--- Comment #4 from pinskia at gmail dot com 2010-08-10 12:36 ---
Subject: Re: New: optimizer dereference
On Aug 10, 2010, at 1:00 AM, attardi at di dot unipi dot it
gcc-bugzi...@gcc.gnu.org
wrote:
Code produced using -O2 handles dereferencing incorrectly.
Here is a program that shows the bug:
#include iostream
#include vector
class Derived : public std::vectorchar *
{
public:
Derived() {}
};
void* foo(void* arg) {
void* baseptr = 0;
*(std::vectorchar* **)baseptr = (Derived *)arg;
return baseptr;
}
Have it do
jlong a = 0;
memcpy(a, arg, sizeof(void*));
That is the most portable way of putting a pointer value in jlong.
void* foo2(void* arg) {
void* baseptr = 0;
*(std::vectorchar* **)baseptr = *(Derived **)arg;
return baseptr;
}
int main()
{
Derived* d = new Derived();
void* upcast = foo(d);
void* upcast2 = foo2(d);
std::cerr d , upcast , upcast2 std::endl;
}
If you compile without -O2 the two values upcast and upcast2 are the
same, as they should be.
Using -O2 the results are different.
The bug occurrs with both:
g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1
This kind of code is generated by SWIG for Java, so I can't change
the source.
Curiously the bug disappears if you put a print statement before the
assignment to baseptr.
--
Summary: optimizer dereference
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: attardi at di dot unipi dot it
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45246
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45246
[Bug c++/45012] Invalid ambiguity on partial class specialization matching
--- Comment #2 from pinskia at gmail dot com 2010-07-21 02:53 ---
Subject: Re: New: Invalid ambiguity on partial class specialization matching
On Jul 20, 2010, at 7:43 PM, rodolfo at rodsoft dot org
gcc-bugzi...@gcc.gnu.org
wrote:
The following code doesn't compile unless variable RUNTIME is
defined as a
static const int instead of an enum:
This enum value has an anonymous type which is not valid in the
context of templates in C++03/98. It is valid in the current draft of C
++0x though. But I cannot remember if 4.5 implements that rule for -
std=gnu++0x (-std=c++0x).
#include type_traits
enum { RUNTIME = 0 };
// it compiles with the previous line commented out and the next
commented in
// static const int RUNTIME=0;
template class T, class U, class EN=void struct foo;
template templateint class V, int M
struct fooVM,VM, typename std::enable_ifM==RUNTIME ||
M==2::type {};
template templateint class V1, templateint class V2, int M
struct fooV1M,V2M, typename std::enable_ifM==RUNTIME ||
M==2::type {};
template int M struct bar {};
foobar2,bar2 x;
--
Summary: Invalid ambiguity on partial class specialization
matching
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodolfo at rodsoft dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45012
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45012
[Bug c/44947] Optimizer doesn't see setjmp()
--- Comment #3 from pinskia at gmail dot com 2010-07-15 09:19 ---
Subject: Re: Optimizer doesn't see setjmp()
On Jul 15, 2010, at 2:15 AM, cm1 at mumac dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #1 from cm1 at mumac dot de 2010-07-15 09:15 ---
Sorry, I edited the contents of the precompiler output to make it
more readable
and messed up the auto variable name. Please use this code:
#include stdlib.h
#include stdio.h
#include setjmp.h
#define EXC_TRY 1
#define EXC_CATCH 2
func()
{
const char *p = NULL;/*** auto variable
***/
IRRC you need volatile here as defined by the c standard.
{
jmp_buf exc_jmp_buf;
int exc_state;
if (setjmp(exc_jmp_buf) == 0) {/*** setjmp() ***/
exc_state = EXC_TRY;
} else {
exc_state = EXC_CATCH;
}
if (exc_state == EXC_TRY) {/*** TRY BLOCK ***/
p = some value;
}
if (exc_state == EXC_CATCH) { /*** CATCH BLOCK
***/
puts(p);
}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44947
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44947
[Bug libstdc++/44952] #include iostream.h imply global constructor.
--- Comment #1 from pinskia at gmail dot com 2010-07-15 16:02 --- Subject: Re: New: #include iostream.h imply global constructor. This is expected and iirc required by the c++ standard too. On Jul 15, 2010, at 8:51 AM, hubicka at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Noticed while reading http://comments.gmane.org/gmane.comp.web.chromium.devel/16789 evans:/abuild/jh/trunk-install/bin/:[0]# more g.C #include iostream evans:/abuild/jh/trunk-install/bin/:[0]# ./g++ -O2 g.C -S evans:/abuild/jh/trunk-install/bin/:[0]# more g.s .file g.C .text .p2align 4,,15 .type _GLOBAL__I_g.C, @function _GLOBAL__I_g.C: .LFB969: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movl$_ZStL8__ioinit, %edi call_ZNSt8ios_base4InitC1Ev movl$__dso_handle, %edx movl$_ZStL8__ioinit, %esi movl$_ZNSt8ios_base4InitD1Ev, %edi addq$8, %rsp .cfi_def_cfa_offset 8 jmp __cxa_atexit .cfi_endproc .LFE969: -- Summary: #include iostream.h imply global constructor. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952
[Bug middle-end/44890] Hitting gcc_assert in build2_stat with pr30388.c testsuite test case
--- Comment #1 from pinskia at gmail dot com 2010-07-09 14:48 --- Subject: Re: New: Hitting gcc_assert in build2_stat with pr30388.c testsuite test case Can you give the full backtrace? Where is the build2 being called from? On Jul 9, 2010, at 7:36 AM, bergner at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: The pr30388.c test case ICE's on trunk and powerpc64-linux with the following options: -Os -m64 Looking at a backtrace, we're hitting this assert in tree.c:build2_stat(): if (code == POINTER_PLUS_EXPR arg0 arg1 tt) gcc_assert (POINTER_TYPE_P (tt) POINTER_TYPE_P (TREE_TYPE (arg0)) INTEGRAL_TYPE_P (TREE_TYPE (arg1)) useless_type_conversion_p (sizetype, TREE_TYPE (arg1))); gdb shows this: (gdb) frame 1 #1 0x1066de84 in build2_stat (code=POINTER_PLUS_EXPR, tt=0x441, arg0=0x45112e8, arg1=0x43104b0) at /home/bergner/gcc/gcc-mainline-r161924/gcc/tree.c:3715 3715gcc_assert (POINTER_TYPE_P (tt) POINTER_TYPE_P (TREE_TYPE (arg0)) (gdb) call debug_tree(tt) integer_type 0x441 long unsigned int public unsigned sizetype DI size integer_cst 0x4310780 type integer_type 0x44100a8 bit_size_type constant 64 unit size integer_cst 0x43107a8 type integer_type 0x441 long unsigned int constant 8 align 64 symtab 0 alias set -1 canonical type 0x441 precision 64 min integer_cst 0x43107d0 0 max integer_cst 0x4310aa0 -1 (gdb) call debug_tree(arg0) ssa_name 0x45112e8 type integer_type 0x441 long unsigned int public unsigned sizetype DI size integer_cst 0x4310780 constant 64 unit size integer_cst 0x43107a8 constant 8 align 64 symtab 0 alias set -1 canonical type 0x441 precision 64 min integer_cst 0x43107d0 0 max integer_cst 0x4310aa0 -1 visited var var_decl 0x44f1fe0 D.2060def_stmt D.2060_43 = ivtmp.27_37 + D.2059_42; version 43 (gdb) call debug_tree(arg1) integer_cst 0x43104b0 type integer_type 0x441 long unsigned int constant 1 -- Summary: Hitting gcc_assert in build2_stat with pr30388.c testsuite test case Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bergner at gcc dot gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44890 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44890
[Bug c++/44840] bug in STL iterator class
--- Comment #1 from pinskia at gmail dot com 2010-07-06 14:40 ---
Subject: Re: New: bug in STL iterator class
On Jul 6, 2010, at 7:21 AM, andre dot bergner dot 0 at googlemail dot
com gcc-bugzi...@gcc.gnu.org wrote:
This is not a compiler bug, but a bug in the STL iterator class.
The less-than-operator does not work properly.
The following program can reproduce the bug.
# include iostream
# include vector
using namespace std;
main() {
vectorint v;
vectorint::iterator i = v.begin();
--i;
I think the behavior is undefined because now i is not inside the
vector at all. In fact I think doing --i on an iterator at the
begining is undefined.
cout ( i - v.begin() ) endl; // output: -1
cout ( i v.begin() ) endl; // output: 0 !!! SHOULD BE
1 !!!
cout ( i - v.begin() 0) endl; // output: 1 this one is
correct
}
--
Summary: bug in STL iterator class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot bergner dot 0 at googlemail dot com
GCC build triplet: -
GCC host triplet: -
GCC target triplet: -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44840
[Bug c/44842] gcc should not issue warnings for code that will never be executed
--- Comment #1 from pinskia at gmail dot com 2010-07-06 16:33 ---
Subject: Re: New: gcc should not issue warnings for code that will never be
executed
This is a dup of a much older bug which I cannot find right now.
On Jul 6, 2010, at 8:10 AM, vincent at vinc17 dot org
gcc-bugzi...@gcc.gnu.org
wrote:
GCC issues warnings like division by zero or right shift count =
width of
type even though the corresponding code will never be executed
(under a
condition that is always false); it shouldn't do this, at least by
default. For
instance:
int tst (void)
{
int x;
x = 0 ? 1 / 0 : 0;
return x;
if (0)
{
x = 1 / 0;
x = 1 128;
}
return x;
}
$ gcc-snapshot -std=c99 -O2 -c tst.c
tst.c: In function 'tst':
tst.c:8:13: warning: division by zero [-Wdiv-by-zero]
tst.c:9:7: warning: right shift count = width of type [enabled by
default]
One can see that GCC detects neither the first return x; nor the
always-false
condition, and issues spurious warnings for the lines:
x = 1 / 0;
x = 1 128;
On the other hand, GCC could successfully detect that the 1 / 0 in
x = 0 ? 1 / 0 : 0;
would never be executed.
Note: always-false conditions occur in practice for platform-
dependent code,
e.g. by doing a test on integer types.
--
Summary: gcc should not issue warnings for code that will
never
be executed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
[Bug target/44793] Code generated references undefined symbol
--- Comment #3 from pinskia at gmail dot com 2010-07-02 20:17 --- Subject: Re: New: Code generated references undefined symbol These functions are part of PowerPC abi. So they should be provided by either libgcc or the libc. On Jul 2, 2010, at 1:12 PM, joel at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: This was spotted on powerpc-rtems but likely impacts more targets. It is triggered by -Os. I will attach the preprocessed file. powerpc-rtems4.11-gcc (GCC) 4.5.0 20100414 (RTEMS gcc-4.5.0-10.fc12/newlib-1.18.0-10.fc12) $ powerpc-rtems4.11-gcc -mcpu=603e -Os -S j.c $ grep _rest j.s b _restgpr_31_x $ powerpc-rtems4.11-gcc -mcpu=603e -O0 -S j.c $ grep _rest j.s $ powerpc-rtems4.11-gcc -mcpu=603e -O1 -S j.c $ grep _rest j.s $ powerpc-rtems4.11-gcc -mcpu=603e -O2 -S j.c $ grep _rest j.s $ -- Summary: Code generated references undefined symbol Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC host triplet: powerpc-rtems4.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
[Bug c/44741] Complex division with NaN produces unexpected result
--- Comment #1 from pinskia at gmail dot com 2010-07-01 05:04 ---
Subject: Re: New: Complex division with NaN produces unexpected result
I think the issue is we don't implement imagainy types so 1 + nan I
turns into nan.
On Jun 30, 2010, at 9:51 PM, ian at airs dot com gcc-bugzi...@gcc.gnu.org
wrote:
Annex G of the ISO C99 standard says that a complex value with one
part being
infinity is considered an infinity, even if the other part is a
NaN. It's not
clearly stated, but presumably if neither part of the number is an
infinity,
but one part is a NaN, then the number is a NaN. And presumably if
a complex
NaN is involved in a math operation, the result should be a complex
NaN.
So, I would expect that dividing a complex NaN by a complex 0 would
give me a
complex NaN. However, when I run this program:
#include stdio.h
#include math.h
#include complex.h
__complex float
div (__complex float f1, __complex float f2)
{
return f1 / f2;
}
int
main ()
{
__complex float f;
f = div (NAN + NAN * I, 0);
printf (%g+%g*i\n, creal (f), cimag (f));
f = div (1.0 + NAN * I, 0);
printf (%g+%g*i\n, creal (f), cimag (f));
f = div (NAN + 1.0 * I, 0);
printf (%g+%g*i\n, creal (f), cimag (f));
}
with current mainline, it prints
nan+nan*i
nan+nan*i
nan+inf*i
That last answer seems incorrect according to the rules of Annex G.
It is an
infinity when it should be a NaN.
--
Summary: Complex division with NaN produces unexpected
result
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44741
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44741
[Bug c/44715] Break in increment expression of for statement inconsistent with g++
--- Comment #2 from pinskia at gmail dot com 2010-06-29 16:40 ---
Subject: Re: New: Break in increment expression of for statement
inconsistent with g++
What does a break with a statement expression do for each frontend? Is
it even valid to have a break there(without a statement expression)?
If it is valid, what does each standard say about the break there? If
they say the same thing then I say both frontends should behave the
same but if the c standard says a break should apply to the outer one
then we should follow that for statement expressions also.
On Jun 29, 2010, at 9:20 AM, doug dot gregor at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
The following program exhibits different behavior with gcc vs. g++:
dgregor$ cat t.c
#include stdio.h
int main()
{
int i;
for( i = 0; i 3; )
for( ; ; ({ i++; break; }) )
printf( %d\n, i );
}
With gcc, the break in the statement expression applies to the outer
for
loop, so we get just 0 as output:
dgregor$ gcc t.c ./a.out
0
with g++, the break in the statement expression applies to the inner
for
loop, so we get 0 1 and 2 as the output:
dgregor$ g++ t.c ./a.out
0
1
2
g++ seems to have the right behavior here, and in any case g++ can't
really be
changed now: Qt's foreach macro depends on having break bind to
the inner for
loop.
--
Summary: Break in increment expression of for statement
inconsistent with g++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
[Bug libstdc++/44663] missed GXX_EXPERIMENTAL guards in tr1/tuple?
--- Comment #4 from pinskia at gmail dot com 2010-06-25 14:18 --- Subject: Re: New: missed GXX_EXPERIMENTAL guards in tr1/tuple? On Jun 25, 2010, at 3:49 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org wrote: hi, the latest llvm/clang++ reports an error during parsing tr1/tuple included from tr1/functional: Both of these are c++0x only headers and really are only supported when compiling in c++0x mode. In file included from t00.cpp:1: In file included from /usr/include/c++/4.5.0/tr1/functional:39: /usr/include/c++/4.5.0/tr1/tuple:68:30: error: variadic templates are only allowed in C++0x templateint _Idx, typename... _Elements afaics there's no #ifdef __GXX_EXPERIMENTAL... guards but... http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01.html#manual.intro.status.standard.200x (...) In this implementation -std=gnu++0x or -std=c++0x flags must be used to enable language and library features. The pre-defined symbol __GXX_EXPERIMENTAL_CXX0X__ is used to check for the presence of the required flag. (...) -- Summary: missed GXX_EXPERIMENTAL guards in tr1/tuple? Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC host triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44663
[Bug fortran/44636] the -i4 option is not supported anymore in 4.4
--- Comment #1 from pinskia at gmail dot com 2010-06-22 16:34 --- Subject: Re: New: the -i4 option is not supported anymore in 4.4 They were replaced with -fdefualt-integer-4/8. On Jun 22, 2010, at 8:49 AM, doko at ubuntu dot com gcc-bugzi...@gcc.gnu.org wrote: [forwarded from http://bugs.debian.org/582085] gfortran-4.4 does not support anymore the -i4 option, while gfortran-4.3 does. This is necessary for me to compile gildas (see http://www.iram.fr/~gildas/dist/index.html). Is there any specific reason why support for this flag was dropped from 4.4 ? Looking at the code, f951 doesn't know anything about a -i4/-i8 option, however in 4.3 this option wasn't passed to f951, but in 4.4 and newer it is. I assmume this report can be closed as invalid, but I did want to document it, that gfortran isn't supposed to handle -i4/-i8 -- Summary: the -i4 option is not supported anymore in 4.4 Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44636 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44636
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #8 from pinskia at gmail dot com 2010-06-17 09:37 --- Subject: Re: switch/case optimization produces an invalid lookup table index I bet it could be reproduced on any target with -fshort-enums. On Jun 17, 2010, at 2:20 AM, eblot dot ml at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from eblot dot ml at gmail dot com 2010-06-17 09:20 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. The generated assembly has all four elements in the initialization of CSWTCH.2 and the intermediate tree dumps from the cross compiler are not really different from the ones from a native x86_64 compiler. I think this might be due to the ABI differences between the official ARM ABI (AAPCS) and the Linux variant, which is slightly different. I'd bet the way the enumerations are handled (variable size with AAPCS, fixed, integer-native size with ARM Linux) is the 'culprit' here. See http://www.codesourcery.com/sgpp/lite/arm/arm_gnu_linux_abi.pdf The enumeration used in this bug report is coded as a byte with AAPCS, whereas it should be coded as a 32-bit value with Linux ARM ABI. This might explain why you cannot reproduce the issue with a Linux-target cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44559] you can't use a typedef from a typename scope in a template
--- Comment #1 from pinskia at gmail dot com 2010-06-16 17:04 ---
Subject: Re: New: you can't use a typedef from a typename scope in a template
On Jun 16, 2010, at 9:57 AM, gcc at razorcam dot com
gcc-bugzi...@gcc.gnu.org
wrote:
You can't use a typedef from a typename scope in a template
This is obviously a major bug and it means you can't access the
typedefs of the
ISO standard library containers in order to use safe types to
manipulate those
containers, when typename is such a container.
Here is the output of the command g++ bug_report_typedef.cc
bug_report_typedef.cc: In function âvoid f(T)â:
bug_report_typedef.cc:3: error: expected â;â before âiâ
g++ -v follows the source code of bug_report_typedef.cc
template typename T
void f(T t){
T::type i;
You are missing the keyword typename. The standard requires this
keyword on dependent names because it could be either a variable or a
type. The standard assumes a variable name without the keyword.
}
g++ -v bug_report_typedef.cc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.4.4-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-
shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-
threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --
enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-
linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-3)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -quiet -v -D_GNU_SOURCE
bug_report_typedef.cc -quiet -dumpbase bug_report_typedef.cc -
mtune=generic
-auxbase bug_report_typedef -version -o /tmp/ccgt4Dk8.s
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR
version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-
heapsize=51739
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/../../../../x86_64-linux-gnu/
include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed
/usr/include
End of search list.
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR
version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-
heapsize=51739
Compiler executable checksum: a92c574e76687c18572fdbea97434cec
bug_report_typedef.cc: In function âvoid f(T)â:
bug_report_typedef.cc:3: error: expected â;â before âiâ
--
Summary: you can't use a typedef from a typename scope in a
template
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at razorcam dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44559
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44559
[Bug middle-end/44530] wrong code due to branch optimization
--- Comment #2 from pinskia at gmail dot com 2010-06-13 21:58 --- Subject: Re: New: wrong code due to branch optimization Sent from my iPhone On Jun 13, 2010, at 2:34 PM, Daniel dot Davies at xerox dot com gcc-bugzi...@gcc.gnu.org wrote: When compiled with -03, the attached file prints out an error message due to incorrectly comparing xCount + 32 0x8000. When compiled with the default optimization, it prints out the correct message. It sounds like the addition is overflowing and signed integer overflow is undefined. Use either -fwrapv or -fno-strict-overflow. $ gcc -v -save-temps -std=gnu99 -fno-strict-aliasing -funroll-loops -march=core2 -mfpmath=387 -ffloat-store -pedantic -Wall -W -Wstrict- prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wmissing-prototypes -fPIC gcc450CompareBug.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/gcc/ i386-pc-solaris2.10/4.5.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /tool/gcc/4.5.0/gcc-4.5.0/configure --prefix=/tool/gcc/4.5.0/i386-pc-solaris2.10 --with-gnu-as --with- gnu-ld --disable-shared --enable-lto --with-libelf=/usr/local --enable-gold Thread model: posix gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-fno-strict- aliasing' '-funroll-loops' '-march=core2' '-mfpmath=387' '-ffloat-store' '- pedantic' '-Wall' '-W' '-Wstrict-prototypes' '-Wpointer-arith' '-Wwrite-strings' '-Wcast-qual' '-Wmissing-prototypes' '-fPIC' /tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/gcc/i386-pc- solaris2.10/4.5.0/cc1 -E -quiet -v gcc450CompareBug.c -march=core2 -mfpmath=387 -std=gnu99 -pedantic -Wall -W -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast- qual -Wmissing-prototypes -fno-strict-aliasing -funroll-loops -ffloat- store -fPIC -fpch-preprocess -o gcc450CompareBug.i ignoring nonexistent directory /tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/../../../../i386-pc-solaris2.10/include #include ... search starts here: #include ... search starts here: /usr/local/include /tool/gcc/4.5.0/i386-pc-solaris2.10/include /tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/include /tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-fno-strict- aliasing' '-funroll-loops' '-march=core2' '-mfpmath=387' '-ffloat-store' '- pedantic' '-Wall' '-W' '-Wstrict-prototypes' '-Wpointer-arith' '-Wwrite-strings' '-Wcast-qual' '-Wmissing-prototypes' '-fPIC' /tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/gcc/i386-pc- solaris2.10/4.5.0/cc1 -fpreprocessed gcc450CompareBug.i -quiet -dumpbase gcc450CompareBug.c -march=core2 -mfpmath=387 -auxbase gcc450CompareBug -pedantic -Wall -W -Wstrict-prototypes -Wpointer-arith -Wwrite-strings -Wcast-qual -Wmissing-prototypes -std=gnu99 -version -fno-strict-aliasing - funroll-loops -ffloat-store -fPIC -o gcc450CompareBug.s GNU C (GCC) version 4.5.0 (i386-pc-solaris2.10) compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 GNU C (GCC) version 4.5.0 (i386-pc-solaris2.10) compiled by GNU C version 4.5.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min- heapsize=131072 Compiler executable checksum: cf0046f5352e75464cfcf0489db9539c COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu99' '-fno-strict- aliasing' '-funroll-loops' '-march=core2' '-mfpmath=387' '-ffloat-store' '- pedantic' '-Wall' '-W' '-Wstrict-prototypes' '-Wpointer-arith' '-Wwrite-strings' '-Wcast-qual' '-Wmissing-prototypes' '-fPIC' /tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/../../../../i386-pc-solaris2.10/bin/as -v -V -Qy -s -o gcc450CompareBug.o gcc450CompareBug.s GNU assembler version 2.20 (i386-pc-solaris2.10) using BFD version (GNU Binutils) 2.20 COMPILER_PATH=/tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/gcc/i386- pc-solaris2.10/4.5.0/:/tool/gcc/4.5.0/i386-pc-solaris2.10/libexec/ gcc/i386-pc-solaris2.10/4.5.0/:/tool/gcc/4.5.0/i386-pc-solaris2.10/ libexec/gcc/i386-pc-solaris2.10/:/tool/gcc/4.5.0/i386-pc-solaris2.10/ lib/gcc/i386-pc-solaris2.10/4.5.0/:/tool/gcc/4.5.0/i386-pc- solaris2.10/lib/gcc/i386-pc-solaris2.10/:/tool/gcc/4.5.0/i386-pc- solaris2.10/lib/gcc/i386-pc-solaris2.10/4.5.0/../../../../i386-pc- solaris2.10/bin/:/usr/ccs/bin/ LIBRARY_PATH=/tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/:/tool/gcc/4.5.0/i386-pc-solaris2.10/lib/gcc/i386- pc-solaris2.10/4.5.0/../../../../i386-pc-solaris2.10/lib/:/tool/gcc/ 4.5.0/i386-pc-solaris2.10/lib/gcc/i386-pc- solaris2.10/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #4 from pinskia at gmail dot com 2010-06-08 05:11 --- Subject: Re: __cxa_end_cleanup ends up in wrong section i.e. not in .text Well this code will only be compiled for arm-eabi which is an elf only target. Please submit your patch to gcc-patc...@. Sent from my iPhone On Jun 7, 2010, at 9:53 PM, raj dot khem at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from raj dot khem at gmail dot com 2010-06-08 04:53 --- (In reply to comment #2) Confirmed, it should do a .text and then a previous. I have closed a bug where an inline-asm was not doing this too (see PR 35895). another version I had was with pushsection and popsection but then I read that these directives are ELF specific I thought not to use them .previous is also stated ELF specific in GAS manual. if its ok I can redo it with pushsection/popsection -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug c++/44399] Problem with command line arguments in windows
--- Comment #5 from pinskia at gmail dot com 2010-06-03 13:48 ---
Subject: Re: New: Problem with command line arguments in windows
Sent from my iPhone
On Jun 3, 2010, at 5:15 AM, alexandrfedorov at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
I'm trying to write windows console application working with
directories, and i
discover that arguments processed not right. For example:
#include iostream
int main ( int argc, char *argv[], char *envp[] ) {
std::cout you have argc arguments;
}
resulting:
a.exe a a
you have 2 arguments
This is correct because the first argument is a.exe.
a.exe a a a
you have 3 arguments
a.exe a a\ a
you have 2 arguments
As i understand, backslash is escaping double quote and we have [a
a a]
argument instead of [a a\],[a].
It's very sad, because i must operate with directories or UNC paths
like:
\\serv\share\some dir with spaces\ where double quotes is required
and
backslash can be present.
Quoting long file paths with double quotes and backslashes in paths
is a common
thing in windows console programs.
--
Summary: Problem with command line arguments in windows
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexandrfedorov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44399
[Bug debug/44375] goto_locus lost at -O0 during cfg cleanup
--- Comment #3 from pinskia at gmail dot com 2010-06-02 13:33 --- Subject: Re: New: goto_locus lost at -O0 during cfg cleanup I think this is a dup of a much older bug. Sent from my iPhone On Jun 2, 2010, at 3:30 AM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: As mentioned in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00115.html for -O0 we sometimes, e.g. for return without value or for C++ NRV optimized return don't emit any insns with the location of the return stmt, which results in worse debug experience. -- Summary: goto_locus lost at -O0 during cfg cleanup Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44375
[Bug target/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra, __naked attribute is broken
--- Comment #12 from pinskia at gmail dot com 2010-05-29 13:30 --- Subject: Re: [4.5 Regression] arm linux kernel crahes when built with -fipa-sra, __naked attribute is broken The naked attribute should cause two things noinline and noclone. Sent from my iPhone On May 29, 2010, at 4:50 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-29 11:50 --- (it seems quite stupid to have naked functions with only an asm inside in the first place - you can equally well use plain assembly) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug rtl-optimization/44323] IRA/reload moves asm statement
--- Comment #1 from pinskia at gmail dot com 2010-05-29 15:39 ---
Subject: Re: New: IRA/reload moves asm statement
I don't think this is valid. You cannot depend on where the spill will
happen around a function call. It is spilling to save the volatile
register. With -O, we don't use volatile registers to keep variables
across functions. While at -O2 we do so it saves it right before the
function call.
Sent from my iPhone
On May 29, 2010, at 8:25 AM, hjl dot tools at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
On Linux/x86-64, IRA/reload moves asm statement by
adding movss at -O2:
[...@gnu-6 vzeroupper-1]$ cat foo.c
extern void bar2 (void);
float
foo (float y)
{
asm volatile (nop);
bar2 ();
return y;
}
[...@gnu-6 vzeroupper-1]$ gcc -S -O foo.c
[...@gnu-6 vzeroupper-1]$ cat foo.s
.file foo.c
.text
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movss %xmm0, 12(%rsp)
#APP
# 5 foo.c 1
nop
# 0 2
#NO_APP
callbar2
movss 12(%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident GCC: (GNU) 4.4.3 20100127 (Red Hat 4.4.3-4)
.section.note.GNU-stack,,@progbits
[...@gnu-6 vzeroupper-1]$ gcc -S -O2 foo.c
[...@gnu-6 vzeroupper-1]$ cat foo.s
.file foo.c
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
#APP
# 5 foo.c 1
nop
# 0 2
#NO_APP
movss %xmm0, (%rsp)
callbar2
movss (%rsp), %xmm0
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident GCC: (GNU) 4.4.3 20100127 (Red Hat 4.4.3-4)
.section.note.GNU-stack,,@progbits
[...@gnu-6 vzeroupper-1]$
--
Summary: IRA/reload moves asm statement
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44323
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44323
[Bug target/44222] [4.6 regression] Revision 159621 caused new x86 test failures
--- Comment #1 from pinskia at gmail dot com 2010-05-21 01:52 --- Subject: Re: New: [4.6 regression] Revision 159621 caused new x86 test failures This is the same problem as the other sse testcases. Sent from my iPhone On May 20, 2010, at 6:34 PM, hjl dot tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: On Linux/x86, revision 159621: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html caused FAIL: gcc.target/i386/3dnow-1.c (internal compiler error) FAIL: gcc.target/i386/3dnow-1.c (test for excess errors) FAIL: gcc.target/i386/3dnow-2.c (internal compiler error) FAIL: gcc.target/i386/3dnow-2.c (test for excess errors) FAIL: gcc.target/i386/3dnowA-1.c (internal compiler error) FAIL: gcc.target/i386/3dnowA-1.c (test for excess errors) FAIL: gcc.target/i386/3dnowA-2.c (internal compiler error) FAIL: gcc.target/i386/3dnowA-2.c (test for excess errors) FAIL: gcc.target/i386/pr42549.c (internal compiler error) FAIL: gcc.target/i386/pr42549.c (test for excess errors) -- Summary: [4.6 regression] Revision 159621 caused new x86 test failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44222 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44222
[Bug c++/44186] Wrong code generated with -O2 and above
--- Comment #1 from pinskia at gmail dot com 2010-05-18 03:50 ---
Subject: Re: New: Wrong code generated with -O2 and above
Sent from my iPhone
On May 17, 2010, at 8:37 PM, eyakubovich at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
This is a stripped down code from proposed Boost.Move library.
Asserts don't
fire with -O0 and -O1 but do with -O2 and -O3
#include assert.h
template class T
class rv : public T
{
rv();
~rv();
rv(rv const);
void operator=(rv const);
};
template class T
rvT move(T x)
{
return *static_castrvT* (x);
}
//A movable class
class movable
{
movable(movable );
movable operator=(movable);
public:
operator rvmovable()
{ return *reinterpret_cast rvmovable* (this); }
operator const rvmovable() const
{ return *reinterpret_castconst rvmovable* (this); }
private:
int value_;
public:
movable() : value_(1){}
//Move constructor and assignment
movable(rvmovable m)
{ value_ = m.value_; m.value_ = 0; }
movable operator=(rvmovable m)
{ value_ = m.value_; m.value_ = 0; return *this; }
bool moved() const //Observer
{ return value_ == 0; }
};
movable function(movable m)
{
return movable(move(m));
}
int main()
{
{
movable m;
movable m2(move(m));
The above code cause aliasing violations because you acess a movable
object via a rvmovable (from now on just refered to as rv for short)
one. So you have a type rv who's base type is movable. note both rv
and movable are non pods which I think removes the case for upcasting
and then accessing the first member.
assert(m.moved());
assert(!m2.moved());
}
{
movable m;
movable m3(function(movable(move(m;
assert(m.moved());
assert(!m3.moved());
}
{
movable m;
movable m4(function(move(m)));
assert(m.moved());
assert(!m4.moved());
}
return 0;
}
--
Summary: Wrong code generated with -O2 and above
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eyakubovich at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
[Bug middle-end/44134] Unneeded +0.0 for c = 0.0 ; c = c+ a*b
--- Comment #2 from pinskia at gmail dot com 2010-05-14 13:10 ---
Subject: Re: New: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Sent from my iPhone
On May 14, 2010, at 2:18 AM, tkoenig at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
This code leads to the adding of 0.0, which is a nop. Any
signalling should have been done previously.
It is not signalling that matters here but signed zero. 0.0 + -0.0 ==
0.0. So without the 0.0 +, you can get a negative zero.
i...@linux-fd1f:/tmp cat mult.f90
subroutine foo(a,b,c)
real, intent(in) :: a,b
real, intent(out) :: c
c = 0.0
c = c + a*b
end subroutine foo
i...@linux-fd1f:/tmp gfortran -O3 -fdump-tree-optimized -S mult.f90
i...@linux-fd1f:/tmp cat mult.f90.142t.optimized
;; Function foo (foo_)
foo (real(kind=4) restrict a, real(kind=4) restrict b, real
(kind=4)
restrict c)
{
real(kind=4) D.1542;
real(kind=4) D.1541;
real(kind=4) D.1540;
real(kind=4) D.1539;
bb 2:
D.1539_4 = *a_3(D);
D.1540_6 = *b_5(D);
D.1541_7 = D.1539_4 * D.1540_6;
D.1542_8 = D.1541_7 + 0.0;
*c_1(D) = D.1542_8;
return;
}
i...@linux-fd1f:/tmp cat mult.s
.file mult.f90
.text
.p2align 4,,15
.globl foo_
.type foo_, @function
foo_:
.LFB0:
movss (%rdi), %xmm0
mulss (%rsi), %xmm0
addss .LC0(%rip), %xmm0
movss %xmm0, (%rdx)
ret
.LFE0:
.size foo_, .-foo_
.section.rodata.cst4,aM,@progbits,4
.align 4
.LC0:
.long 0
.section.eh_frame,a,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0
.byte 0x1
.string zR
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x3
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.uleb128 0
.align 8
.LEFDE1:
.ident GCC: (GNU) 4.6.0 20100513 (experimental)
.section.note.GNU-stack,,@progbits
--
Summary: Unneeded +0.0 for c = 0.0 ; c = c+ a*b
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44134
[Bug c/43930] gcc handle short overflow failed
--- Comment #1 from pinskia at gmail dot com 2010-04-29 02:23 ---
Subject: Re: New: gcc handle short overflow failed
Sent from my iPhone
On Apr 28, 2010, at 6:58 PM, cnstar9988 at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
#include string.h
#include stdio.h
int main(int argc, char **argv)
{
short i = 1;
int n = (int)(i 16);
fprintf(stderr, %d\n, n);
return 0;
}
always 65536
it must to 0
No because short is promoted to int.
--
Summary: gcc handle short overflow failed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cnstar9988 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43930
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43930
[Bug c++/43881] warning attached to a function is emitted even though the function is not being called
--- Comment #2 from pinskia at gmail dot com 2010-04-24 23:12 ---
Subject: Re: New: warning attached to a function is emitted even though the
function is not being called
It is called directly because safe_close's value is replaced in the
indirect call. Since safe_close is static and not changed in the code
at all, it is marked as read only and the initialized value can be
used directly.
Sent from my iPhone
On Apr 24, 2010, at 3:49 PM, bruno at clisp dot org gcc-bugzi...@gcc.gnu.org
wrote:
The gcc documentation, section Declaring Attributes of Functions,
states
about the __attribute__ ((__warning__ (...))) of a function:
If this attribute is used on a function declaration and a call to
such a function is not eliminated through dead code elimination or
other optimizations, a warning which will include MESSAGE will be
diagnosed.
Here is a case where the warning is diagnosed although the program
contains
no direct call to the function:
=== main.cc ===
extern C int close(int);
static int (*safe_close) (int fd) = close;
extern __typeof__ (close) close __attribute__ ((__warning__ (The
symbol close
refers to the system function. Use safe_close instead.)));
int fd;
int main()
{
safe_close(fd);
}
===
$ g++ -S -O main.cc
main.cc: In function 'int main()':
main.cc:7:17: warning: call to 'close' declared with attribute
warning: The
symbol close refers to the system function. Use safe_close instead.
The warning is not justified, because its only use is as initializer
of the variable 'safe_close', and at that moment, the warning is not
yet
attached to it.
Notes:
- The warning occurs only with optimization, not with -O0.
- The warning occurs only if the variable 'safe_close' is 'static',
not
when it is changed to a global variable.
- The behaviour of GCC 4.3.4 and GCC 4.4.3 is the same as the one
of GCC
4.5.0.
--
Summary: warning attached to a function is emitted even
though
the function is not being called
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bruno at clisp dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881
[Bug middle-end/43861] -Os creates larger binaries than before in some cases (-falign-... options enabled)
--- Comment #1 from pinskia at gmail dot com 2010-04-22 23:51 --- Subject: Re: New: -Os creates larger binaries than before in some cases (-falign-... options enabled) Which target is this for? Sent from my iPhone On Apr 22, 2010, at 4:48 PM, rwahl at gmx dot de gcc-bugzi...@gcc.gnu.org wrote: Hi, I just noticed that some of my libraries are greater when compiled with gcc 4.4.3 instead of gcc 4.3.2. Diffing the output of gcc -- help=optimizers -Q -Os shows this in 4.3.2: -falign-jumps[disabled] -falign-labels [disabled] -falign-loops[enabled] and this for 4.4.3: -falign-functions [enabled] -falign-jumps [enabled] -falign-labels[enabled] -falign-loops [disabled] when explicitely disabling the alignment options then the code size shrinks. For libxml2 in my case from 704256 to 675584 bytes. The manual says: -Os disables the following optimization flags: -falign-functions -falign-jumps -falign-loops -falign-labels -freorder- blocks -freorder-blocks-and-partition -fprefetch-loop-arrays -ftree-vect-loop-version which is not true (even not for 4.3.2 since loop alignment was enabled). Some other opts like -freorder-blocks is enabled as well. So is this actually a bug or is the documentation outdated or even both? -- Summary: -Os creates larger binaries than before in some cases (- falign-... options enabled) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rwahl at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43861 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43861
[Bug bootstrap/43819] Bootstrapping GCC 4.5.0 fails with cannot compute suffix of object files: cannot compile
--- Comment #5 from pinskia at gmail dot com 2010-04-20 16:38 --- Subject: Re: Bootstrapping GCC 4.5.0 fails with cannot compute suffix of object files: cannot compile Sent from my iPhone On Apr 20, 2010, at 8:42 AM, florin at iucha dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from florin at iucha dot net 2010-04-20 15:42 --- The 'missing' library is in fact present: Yes it is present but that directory is not looked at during the runtime, use either LD_LIBRARY_PATH or edit /etc/ld.so.conf and run ldconf. $ ls -l /usr/local.296/lib/ total 4260 -rw-r--r--1 root root 1726470 Apr 20 15:00 libelf.a lrwxrwxrwx1 root root 16 Apr 20 15:00 libelf.so - libelf.so.0.8.12 lrwxrwxrwx1 root root 16 Apr 20 15:00 libelf.so.0 - libelf.so.0.8.12 -rwxr-xr-x1 root root 287786 Apr 20 15:00 libelf.so. 0.8.12 -rw-r--r--1 root root 774602 Apr 19 23:49 libgmp.a -rwxr-xr-x1 root root 921 Apr 19 23:49 libgmp.la lrwxrwxrwx1 root root 16 Apr 19 23:49 libgmp.so - libgmp.so.10.0.1 lrwxrwxrwx1 root root 16 Apr 19 23:49 libgmp.so.10 - libgmp.so.10.0.1 -rwxr-xr-x1 root root 417082 Apr 19 23:49 libgmp.so. 10.0.1 -rw-r--r--1 root root 135776 Apr 19 23:57 libmpc.a -rwxr-xr-x1 root root 1012 Apr 19 23:57 libmpc.la lrwxrwxrwx1 root root 15 Apr 19 23:57 libmpc.so - libmpc.so.2.0.0 lrwxrwxrwx1 root root 15 Apr 19 23:57 libmpc.so.2 - libmpc.so.2.0.0 -rwxr-xr-x1 root root82707 Apr 19 23:57 libmpc.so. 2.0.0 -rw-r--r--1 root root 545650 Apr 19 23:55 libmpfr.a -rwxr-xr-x1 root root 989 Apr 19 23:55 libmpfr.la lrwxrwxrwx1 root root 16 Apr 19 23:55 libmpfr.so - libmpfr.so.1.2.2 lrwxrwxrwx1 root root 16 Apr 19 23:55 libmpfr.so.1 - libmpfr.so.1.2.2 -rwxr-xr-x1 root root 317404 Apr 19 23:55 libmpfr.so. 1.2.2 drwxr-xr-x3 root root 4096 Apr 20 15:00 locale drwxr-xr-x2 root root 4096 Apr 20 15:00 pkgconfig $ ldd /usr/local.296/lib/libmpc.so.2 libmpfr.so.1 = /usr/local.296/lib/libmpfr.so.1 (0x40011000) libgmp.so.10 = /usr/local.296/lib/libgmp.so.10 (0x40055000) libc.so.6 = /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) -- florin at iucha dot net changed: What|Removed |Added --- --- -- CC||florin at iucha dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43819 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43819
[Bug c/43782] Erroneous expansion of __asm__() directive
--- Comment #6 from pinskia at gmail dot com 2010-04-19 15:07 --- Subject: Re: Erroneous expansion of __asm__() directive Sent from my iPhone On Apr 19, 2010, at 7:35 AM, Nelson H. F. Beebe be...@math.utah.edu wrote: That is wrong because with ATT style x86 asm, the src is first and the dest is second. That cannot be the case: you cannot change the operand order after three years of it working one way! It did not change. Just what happened was gcc is now inlining the function. Before it was not inlining the function which allowed the inline-asm's two operands to be the same (the argument to the function and the return value are done in the same register). Which means you were just getting lucky that it worked. In fact ATT asm has always been that way; while intel style asm is the opposite. Gcc outputs ATT by default, though you can change it via an option. --- --- --- -- - Nelson H. F. BeebeTel: +1 801 581 5254 - - University of UtahFAX: +1 801 581 4148 - - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu - - 155 S 1400 E RM 233 be...@acm.org be...@computer.org - - Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ - --- --- --- -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43782
[Bug other/43562] GCC ICE on optimize attribute
--- Comment #14 from pinskia at gmail dot com 2010-04-19 19:11 ---
Subject: Re: GCC ICE on optimize attribute
Sent from my iPhone
On Apr 19, 2010, at 12:02 AM, jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-19
07:02 ---
This change broke building wine on x86-64.
There was already a bug filed for this and a patch was committed today
or yesterday to the trunk to fix this ice.
Distilled testcase:
__attribute__ ((ms_abi)) fn2 (int, int);
struct S { int s; };
struct T { int t; struct S *u; };
void
foo (struct T *x, void *y)
{
int a, b, c, d;
fn1 (0, a, b, c, d);
x-u[x-t].s = fn2 (fn3 (), a);
fn1 (y, a, b, c, d);
}
__attribute__ ((ms_abi)) void
bar (int x)
{
}
void
baz (int x)
{
}
now ICEs at -O2 on x86_64-linux with:
wineice.i: In function 'foo':
wineice.i:12: internal compiler error: in insert_save, at caller-
save.c:1171
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Apparently setup_save_areas
saved_reg-slot
= assign_stack_local_1
(regno_save_mode[regno][1],
GET_MODE_SIZE (regno_save_mode[regno][1]), 0,
true);
creates a slot where regno_save_mode[regno][1] for regno 4 is
VOIDmode, and the
VOIDmode MEM which has MEM_ALIGN 0 then confuses everything.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
---
--
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43562
[Bug regression/43750] -march unconditionally added to COLLECT_GCC_OPTIONS
--- Comment #1 from pinskia at gmail dot com 2010-04-14 17:56 --- Subject: Re: New: -march unconditionally added to COLLECT_GCC_OPTIONS Sent from my iPhone On Apr 14, 2010, at 1:56 AM, jue at jue dot li gcc-bugzi...@gcc.gnu.org wrote: As of 4.5.0 -march is always added to COLLECT_GCC_OPTIONS if gcc is not called with that option. Well this was on purpose as before configuring for i686-linux-gnu was really for i386 arch. Now it is correctly i686. If you don't want __i686 defined, configure gcc for i586-linux-gnu instead which defaults to i586. $ echo '' | gcc -v -E - 21 | grep -E '^(COLLECT_GCC_OPTIONS|gcc)' gcc version 4.5.0 20100406 (prerelease) (CRUX) (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' '-march=pentiumpro' the same with gcc 4.4.3: $ echo '' | gcc -v -E - 21 | grep -E '^(gcc|COLLECT_GCC_OPTIONS)' gcc version 4.4.3 (CRUX) (GCC) COLLECT_GCC_OPTIONS='-v' '-E' '-mtune=generic' I run into that because I'm not able to compile glibc on i686 without explicit setting CC to something like gcc -march=i586. The reason is the well known _i686 problem, see [1] for a exact description of my error and [2] for a very old but recently reopen glibc bug. [1] http://www.eglibc.org/archives/patches/msg00073.html [2] http://sources.redhat.com/bugzilla/show_bug.cgi?id=411 -- Summary: -march unconditionally added to COLLECT_GCC_OPTIONS Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jue at jue dot li GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750
[Bug c/43691] Code segfault when compiled with -Os, -O2, or -O3
--- Comment #3 from pinskia at gmail dot com 2010-04-08 17:06 --- Subject: Re: Code segfault when compiled with -Os, -O2, or -O3 I don't think this is a bug in gcc. The inline-asm uses $16 but any of the output/temp registers could use that as you don't say the agrument is used as an input. Sent from my iPhone On Apr 8, 2010, at 9:50 AM, mattst88 at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from mattst88 at gmail dot com 2010-04-08 16:50 --- Created an attachment (id=20338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20338action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20338action=view) test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43691
[Bug other/43693] [gcc-plugin] c++ based plugins doesn't work.
--- Comment #1 from pinskia at gmail dot com 2010-04-08 17:25 ---
Subject: Re: New: [gcc-plugin] c++ based plugins doesn't work.
Iirc this is on purpose. You need to build gcc with the c++ compiler
if you want c++ plugins.
Sent from my iPhone
On Apr 8, 2010, at 10:12 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org
wrote:
during loading c++ based plugin we get undefined runtime symbols,
e.g.:
undefined symbol:
_Z28plugin_default_version_checkP18plugin_gcc_versionS0_
undefined symbol: _Z17register_callbackPKciPFvPvS1_ES1_
known workaround:
extern C { #include gcc-plugin.h }
--
Summary: [gcc-plugin] c++ based plugins doesn't work.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43693
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43693
[Bug lto/43659] -flto doesn't remember -fPIC
--- Comment #1 from pinskia at gmail dot com 2010-04-06 03:01 ---
Subject: Re: New: -flto doesn't remember -fPIC
This is done on purpose. The -fpic is needed on the link line too.
This is a bug in libtool.
Sent from my iPhone
On Apr 5, 2010, at 6:47 PM, debian-gcc at lists dot debian dot org
gcc-bugzi...@gcc.gnu.org
wrote:
[forwarded from http://bugs.debian.org/524176]
Matthias
gcc-4.5 with -flto doesn't work with -fPIC properly.
Simple testcase:
int entry(int a)
{
return bar(a)+1;
}
int bar(int a)
{
return a+4;
}
$ gcc-4.5 foo1.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo2.c -flto -fPIC -DPIC -c
$ gcc-4.5 foo1.o foo2.o -flto -shared
/usr/bin/ld: /tmp/ccmA7RCK.lto.o: relocation R_X86_64_PC32 against
symbol `bar'
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
This works however:
$ gcc-4.5 foo1.o foo2.o -flto -shared -fPIC
Now -fPIC is something libtool automatically adds, and I it doesn't
add it at
linktime (perhaps other build systems don't either).
Could gcc's -flto see that all .o files involved in the link are -
fPIC... and
make the resulting file -fPIC too?
Or at least it should see the -shared in the linker line, and
automatically use
-fPIC when -flto is used.
--
Summary: -flto doesn't remember -fPIC
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43659
[Bug c/43639] Missed optimization with complex long double
--- Comment #1 from pinskia at gmail dot com 2010-04-04 06:28 ---
Subject: Re: New: Missed optimization with complex long double
Sent from my iPhone
On Apr 3, 2010, at 11:21 PM, svfuerst at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
gcc 4.4 compiles the following:
_Complex long double foo(long double p1, long double p2)
{
return p1 + (__extension__ 1.0iF) * p2;
}
gcc-4.4 -O3 tgcc.c -c -o tgcc.o
into
0x +0: fldt 0x8(%rsp)
0x0004 +4: fldt 0x18(%rsp)
0x0008 +8: fxch %st(1)
0x000a +10:retq
This is ok, except for the useless fxch instruction. However, gcc
4.5 compiles
the same code into:
gcc-4.5 -O3 tgcc.c -c -o tgcc.o
0x +0: fldt 0x18(%rsp)
0x0004 +4: fld%st(0)
0x0006 +6: fmuls 0x0(%rip)# 0xc foo+12
0x000c +12:fldt 0x8(%rsp)
0x0010 +16:faddp %st,%st(1)
0x0012 +18:retq
which is quite a bit worse.
Except it is needed for handling -0.0 correctly.
--
Summary: Missed optimization with complex long double
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: svfuerst at gmail dot com
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43639
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43639
[Bug bootstrap/43615] [4.5 Regression] bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
--- Comment #2 from pinskia at gmail dot com 2010-04-01 08:50 --- Subject: Re: New: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Sent from my iPhone On Apr 1, 2010, at 12:03 AM, jv244 at cam dot ac dot uk gcc-bugzi...@gcc.gnu.org wrote: My usual routine to build gcc-trunk started failing yesterday (or the day before)? The configure has remained unchanged (notice --disable-multilib --disable-bootstrap): --disable-bootstrap is almost never a good idea for a native build. /data/vondele/gcc_bench/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_bench/gcc_trunk/build --enable-languages=c,c++,fortran --program-suffix=-trunk --disable- multilib --disable-bootstrap --with-gmp=/data/vondele/gcc_bench/libs/ --with-mpfr=/data/vondele/gcc_bench/libs/ --with-mpc=/data/vondele/gcc_bench/libs/ The error seems to be: -fvisibility=hidden -DHIDE_EXPORTS /data/vondele/gcc_bench/gcc_trunk/obj/./gcc/xgcc -B/data/vondele/gcc_bench/gcc_trunk/obj/./gcc/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ bin/ -B/data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ lib/ -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/ include -isystem /data/vondele/gcc_bench/gcc_trunk/build/x86_64-unknown-linux-gnu/sys- include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast- qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/ libgcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/. -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../include -I/data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldi3.o - MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/include/features.h:354:0, from /usr/include/stdio.h:28, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/tsystem.h:87, from /data/vondele/gcc_bench/gcc_trunk/gcc/libgcc/../gcc/libgcc2.c:29: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory compilation terminated. make[4]: *** [_muldi3.o] Error 1 make[4]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/32/ libgcc' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ libgcc' make[2]: *** [all-multi] Error 2 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj/x86_64-unknown-linux-gnu/ libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/data/vondele/gcc_bench/gcc_trunk/obj' make: *** [all] Error 2 -- Summary: bootstrap fails: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
[Bug objc/43535] ICE on objc.dg/objc-gc-4.m -fgnu-runtime
--- Comment #3 from pinskia at gmail dot com 2010-03-26 16:14 --- Subject: Re: ICE on objc.dg/objc-gc-4.m -fgnu-runtime I think there is an already filed bug about this option with the gnu runtime also. This option should not be supported or a nop there. Sent from my iPhone On Mar 26, 2010, at 5:16 AM, developer at sandoe-acoustics dot co dot uk gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from developer at sandoe-acoustics dot co dot uk 2010-03-26 12:16 --- I believe that this test was not previously carried out with -fgnu- runtime . So, technically I think it's a failed New test rather than a regression (but I will triple-check a little later). In any event, I don't suppose we want an ICE as a response to a command line error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43535 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43535
[Bug c++/43352] keyword 'and' defined when even in the absence of iso646
--- Comment #2 from pinskia at gmail dot com 2010-03-13 03:59 --- Subject: Re: New: keyword 'and' defined when even in the absence of iso646 Sent from my iPhone On Mar 12, 2010, at 7:54 PM, mdjones0978-gcc at yahoo dot com gcc-bugzi...@gcc.gnu.org wrote: = test.cpp == #include string std::string and( AND ); #ifdef and #undef and #endif #define and error msgs = test.cpp:5:8: error: and cannot be used as a macro name as it is an operator in C++ test.cpp:8:9: error: and cannot be used as a macro name as it is an operator in C++ test.cpp:3: error: expected unqualified-id before ââ token Several comments along this theme. http://stackoverflow.com/questions/2419805/when-did-and-become-an-operator-in-c http://en.wikipedia.org/wiki/Iso646.h C++ is not C. The C++ standard says these are keywords and not defines which is unlike the C standard. -- Summary: keyword 'and' defined when even in the absence of iso646 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mdjones0978-gcc at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43352 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43352
[Bug c++/43330] trivial types are not being statically initialized
--- Comment #1 from pinskia at gmail dot com 2010-03-11 11:41 ---
Subject: Re: New: trivial types are not being statically initialized
Sent from my iPhone
On Mar 11, 2010, at 3:24 AM, eric dot niebler at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
According to the C++0x status page
(http://gcc.gnu.org/gcc-4.5/cxx0x_status.html), Standard Layout
Types
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm)
have been
implemented in gcc-4.5. A quick test shows that trivial types are
not being
statically initialized, as the paper requires. The following struct
S is
trivial and the non-local constant s should be statically
initialized, IIUC:
struct S
{
S() {}
};
The above is not a trivial type though. It has a non trivial default
constructor. If you want a trivial constructor use either = default
or delete it all together.
S const s{};
However, when compiled with -O2 -std=c++0x -S using the latest 4.5
snapshot, I
see the following assembly:
.file main.cpp
.text
.p2align 4,,15
.def__GLOBAL__I_main.cpp; .scl3; .type
32; .endef
__GLOBAL__I_main.cpp:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
.section.ctors,w
.align 4
.long __GLOBAL__I_main.cpp
Unless I'm mistaken, the global s is still being dynamically
initialized.
Apologies in advance if I'm reading this wrong.
--
Summary: trivial types are not being statically initialized
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot niebler at gmail dot com
GCC build triplet: gcc-4.5-20100304
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43330
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43330
[Bug c++/43333] [4.5 Regression] __is_pod seems broken
--- Comment #3 from pinskia at gmail dot com 2010-03-11 17:01 ---
Subject: Re: New: __is_pod seems broken
Sent from my iPhone
On Mar 11, 2010, at 8:03 AM, matz at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org
wrote:
On r157245 (and former revisions) this testcase will abort:
# cat ispod.cc
struct strPOD
{
const char *const foo;
const char *const bar;
};
I don't think this is a pod as it requires a non trivial constructor.
extern C void abort (void);
int main ()
{
if (!__is_pod (strPOD))
abort ();
return 0;
}
This manifests itself in blocxx not compiling with gcc 4.5 (due to
its use
of tr1::is_pod implemented in terms of above). It still works
with a random
gcc 4.3 version.
--
Summary: __is_pod seems broken
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug driver/43334] Generate an XML dump of the parse tree
--- Comment #1 from pinskia at gmail dot com 2010-03-11 17:37 --- Subject: Re: New: Generate an XML dump of the parse tree Sent from my iPhone On Mar 11, 2010, at 8:26 AM, jrevans1 at earthlink dot net gcc-bugzi...@gcc.gnu.org wrote: Essentially I would like a feature similair to gccxml (www.gccxml.org) that is officially blessed and native to the compiler instead of some out-of- date hack. If a feature like this were to be officially supported, it would open the doors to many applications who might want to use the gcc to parse its files for them. Gcc now support plugins which in my mind a better way to support applications which want to use gcc to parse sources. It is a good idea, with minimal impact, it just requires a forked gcc to have its features. I don't think it will be that minimal as people will depend on the format being constant between versions which I doubt will happen. -- Summary: Generate an XML dump of the parse tree Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jrevans1 at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43334 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43334
[Bug bootstrap/43328] multilib bootstrap broken.
--- Comment #6 from pinskia at gmail dot com 2010-03-11 18:15 --- Subject: Re: multilib bootstrap broken. Sent from my iPhone On Mar 11, 2010, at 10:11 AM, pluto at agmk dot net gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from pluto at agmk dot net 2010-03-11 18:11 --- (In reply to comment #4) Did you 'rm -rf ~/src/gcc/trunk' and create that directory anew? no, what for? svn status reports no unversioned files in trunk directory. Svn status does not report .o files normally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
[Bug tree-optimization/43213] [4.5 Regression] Worse code generated with -O2
--- Comment #4 from pinskia at gmail dot com 2010-03-01 10:38 --- Subject: Re: [4.5 Regression] Worse code generated with -O2 Sent from my iPhone On Mar 1, 2010, at 2:29 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-01 10:29 --- Huh. Confirmed. Not that interesting because the aliasing sets are different and we made 4.5 work for c++ code dealing with dynamic types. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-03-01 10:29:21 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43213 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43213
[Bug rtl-optimization/43156] [4.5 Regression] SPU-elf ICEs on simple programs
--- Comment #2 from pinskia at gmail dot com 2010-03-01 15:45 --- Subject: Re: [4.5 Regression] SPU-elf ICEs on simple programs Sent from my iPhone On Mar 1, 2010, at 3:51 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-01 11:51 --- spu-elf is neither a primary nor a secondary platform. But, confirmed, as I originally reported this. My anaylis of this bug is that this bug is very generic and could cause issues on any target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-03-01 11:51:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43156 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43156
[Bug target/43225] Structure copies not vectorized
--- Comment #1 from pinskia at gmail dot com 2010-03-02 05:24 ---
Subject: Re: New: Structure copies not vectorized
Sent from my iPhone
On Mar 1, 2010, at 8:23 PM, astrange at ithinksw dot com
gcc-bugzi...@gcc.gnu.org
wrote:
Source:
#include emmintrin.h
struct a1 { char l[16];};
Are sure that struct has 128 bit alignment because I think it only has
8bit alignment.
struct a2 { __m128i l; };
void f1(struct a1 *a, struct a1 *b)
{
*a = *b;
}
void f2(struct a2 *a, struct a2 *b)
{
*a = *b;
}
/usr/local/gcc45/bin/gcc -O3 -fomit-frame-pointer -S copy_gcc.c
_f1:
movq(%rsi), %rax
movq%rax, (%rdi)
movq8(%rsi), %rax
movq%rax, 8(%rdi)
ret
_f2:
movdqa (%rsi), %xmm0
movdqa %xmm0, (%rdi)
ret
Both are appropriately aligned and should use movdqa. This might not
show up in
generic code, but I could have used it in an ffmpeg optimization.
--
Summary: Structure copies not vectorized
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC host triplet: x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43225
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43225
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #3 from pinskia at gmail dot com 2010-02-27 13:06 --- Subject: Re: New: Endianness and Optimization Sent from my iPhone On Feb 27, 2010, at 2:56 AM, kai dot extern at googlemail dot com gcc-bugzi...@gcc.gnu.org wrote: The attached code (which tries to generically load given-endianness values of varying width from memory) shows some interesting optimization quirks. It's especially pussling why optimization quality varies so greatly with width, and is actually worst for the native word width. You are violating c++ aliasing rules. You access a uint8_t via different types. For example: $ gcc -Wall -Wextra bad.cc -lstdc++ -O3 -### Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable- shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 -- enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc -- disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64- linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/cc1plus -quiet -D_GNU_SOURCE bad.cc -D_FORTIFY_SOURCE=2 -quiet -dumpbase bad.cc - mtune=generic -auxbase bad -O3 -Wall -Wextra -fstack-protector -o /tmp/ccnHgEb9.s COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' as -Qy -o /tmp/cceJWVC8.o /tmp/ccnHgEb9.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ 4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64- linux-gnu/ COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/collect2 --build-id --eh- frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux- gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib -L/lib/../ lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../.. -L/usr/lib/x86_64-linux-gnu /tmp/cceJWVC8.o -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crtn.o $ objdump -d a.out | c++filt | sed -n '/Test_/,/constructors/ p' out (See attachments for source and output.) -- Summary: Endianness and Optimization Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kai dot extern at googlemail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug c++/43149] Partial optimization
--- Comment #4 from pinskia at gmail dot com 2010-02-23 16:02 --- Subject: Re: Partial optimization Sent from my iPhone On Feb 23, 2010, at 7:53 AM, bangerth at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from bangerth at gmail dot com 2010-02-23 15:53 --- So the attribute would have to be attached to the namespace, I guess. Or just use the pragma instead :). We can keep the PR open, but my best guess is that this is going to be one of those PRs that stay open forever as there is so little demand for this kind of feature. Maybe you can explain what you need this for? W. -- bangerth at gmail dot com changed: What|Removed |Added --- --- -- Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149
[Bug c++/43149] Partial optimization
--- Comment #8 from pinskia at gmail dot com 2010-02-23 16:29 --- Subject: Re: Partial optimization Sent from my iPhone On Feb 23, 2010, at 8:16 AM, bschindler at inf dot ethz dot ch gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from bschindler at inf dot ethz dot ch 2010-02-23 16:16 --- Also, the following would not work #pragma GCC optimize(2) // I don't know whether I got that syntax right #include Eigen/Core #pragma pop_options blubb; Eigen/Core is a separate file so I'd expect the pragma to have no effect on it no? Or am I wrong here? You are wrong here the pragma works across header files. I just talked to some Eigen developers and they seemed to be very favorable to the idea of a namespace wide option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43149
[Bug c++/43126] at this point in file warnings are upside down
--- Comment #4 from pinskia at gmail dot com 2010-02-20 09:00 --- Subject: Re: at this point in file warnings are upside down Sent from my iPhone On Feb 19, 2010, at 10:51 PM, glenn at zewt dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from glenn at zewt dot org 2010-02-20 06:51 --- (4:16? I havn't seen that before. I hope gcc isn't going to start outputting character offsets by default; that's a lot of noise.) Yes gcc is now printing out column information. And no it is not a lot of noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43126
[Bug c/43128] c-c++-common/pr41779.c doesn't work
--- Comment #2 from pinskia at gmail dot com 2010-02-20 11:00 --- Subject: Re: c-c++-common/pr41779.c doesn't work Sent from my iPhone On Feb 20, 2010, at 2:40 AM, manu at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from manu at gcc dot gnu dot org 2010-02-20 10:40 --- What are the excess messages? The problem is simple c does nit have overloaded functions. I am testing the obvious patch which fixes this; renaming the functions. -- manu at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-20 10:40:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128
[Bug c++/43122] g++ does not allow overloading operators for sse types (__m128, __m128d)
--- Comment #1 from pinskia at gmail dot com 2010-02-19 16:05 ---
Subject: Re: New: g++ does not allow overloading operators for sse types
(__m128, __m128d)
Well there is already a builtin operator+ for vector types with the
generic vector support.
Sent from my iPhone
On Feb 19, 2010, at 7:50 AM, mr dot nuke dot me at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
When trying to overload operators for __m128 and __m128d types. For
example,
the following code:
#include xmmintrin.h
#include stddef.h
inline __m128 operator + (const __m128 A, const __m128 B)
{
return _mm_add_ps(A, B);
}
int main()
{
float a[4];
float b[4];
for(size_t i = 0; i 4; i++)
{
a[i] = 2 * i;
b[i] = 2 * i;
}
__m128 sseA, sseB;
sseA = _mm_loadu_ps(a);
sseB = _mm_loadu_ps(b);
__m128 sseSum = sseA + sseB;
return 0;
}
Generates
error: 'float __vector__ operator+(float __vector__, float
__vector__)' must
have an argument of class or enumerated type
Compiler options: -O3 -msse
Both ICL (windows and Linux) and MSVC accept this code and compile it
correctly.
--
Summary: g++ does not allow overloading operators for sse
types
(__m128, __m128d)
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mr dot nuke dot me at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43122
[Bug tree-optimization/43089] Optimizer ignores type in a conversion
--- Comment #6 from pinskia at gmail dot com 2010-02-16 17:51 --- Subject: Re: Optimizer ignores type in a conversion Sent from my iPhone On Feb 16, 2010, at 9:37 AM, 0xe2 dot 0x9a dot 0x9b at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com 2010-02-16 17:37 --- (In reply to comment #4) There is nothing to fix. Your program triggers undefined behavior. It can do anything, which can include something you'd expect, or something completely different and it can depend on compiler options, position of stars, etc. I understand what you are saying, but I do not agree with that. I my opinion, an *optimization* option should never result in any change of a program's behavior for this particular kind of undefined behaviors. I mean, there are basically two different kinds of undefined behaviors: 1. Where the compiler has to choose a *particular* implementation. Huh, this is the opposite effect of undefined behavior. In fact for signed interger overflow, gcc sometimes optimizes it as wrapping and others as clamping. In this case it is clamping. It is hard sometimes to optimize constiently undefined behavior because of inlining and other optimizations that can change the ir before the optimization of undefined behavior. 2. Where the compiler does not choose anything or cannot choose anything particular. (For example, what happens if accessing deallocated memory.) The conversion test-case is of the 1st kind. Not of the 2nd kind. GCC -O0 chooses to generate a particular sequence of instructions to implement the undefined behavior. GCC -O2 does not respect the choice made at -O0 (or vice versa). So, my question is: If it is possible for the problematic code to be implemented in all contexts by the same operation, and in this case it indeed is possible, why is GCC using two different operations? How do you justify that? -- 0xe2 dot 0x9a dot 0x9b at gmail dot com changed: What|Removed |Added --- --- -- Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #9 from pinskia at gmail dot com 2010-02-04 16:36 --- Subject: Re: Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none Sent from my iPhone On Feb 4, 2010, at 2:48 AM, rearnsha at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #8 from rearnsha at gcc dot gnu dot org 2010-02-04 10:48 --- Created an attachment (id=19803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19803action=view) Possible patch I've been testing the attached patch on ARM (well, thumb) where there's a similar issue. It's perhaps a bit more aggressive than it needs to be, but it should solve the problem generically rather than requiring each back- end to implement hacks for what is really a MI issue. Could someone test this on PPC? Well powerpc64 it is valid to move across the stack pointer if the stack is less than a specific size so this can cause regressions there. And will also cause a performance regressions on x86_64 also for the same reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
[Bug c++/42649] Optimizer breaks boost shared_ptr
--- Comment #7 from pinskia at gmail dot com 2010-01-07 17:18 --- Subject: Re: Optimizer breaks boost shared_ptr Sent from my iPhone On Jan 7, 2010, at 8:56 AM, rlogel at navtech dot aero gcc-bugzi...@gcc.gnu.org wrote: --- Comment #5 from rlogel at navtech dot aero 2010-01-07 16:56 --- I realize that 3.4.6 is very old, but we need to support RedHat Enterprise 4 builds which use gcc 3.4.6. Then report this bug to redhat since you have a support contract with them. Also you are using a redhat modified gcc so reporting to them first is the correct thing to do. We would rather not undertake upgrading to gcc 4.x because we have a large legacy code base, some of which uses writeable strings. -- rlogel at navtech dot aero changed: What|Removed |Added --- --- -- Severity|normal |critical Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42649 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42649
[Bug target/42553] wrong code with -O1
--- Comment #1 from pinskia at gmail dot com 2009-12-30 13:14 ---
Subject: Re: New: wrong code with -O1
Sent from my iPhone
On Dec 30, 2009, at 7:56 AM, debian-gcc at lists dot debian dot org
gcc-bugzi...@gcc.gnu.org
wrote:
current trunk/branches on x86_64-linux-gnu. return values with
different
compilers and different optimizations:
-O0 -O1 -O2 -O3
gcc-4.1 0222
gcc-4.3 0222
gcc-4.4 2000
gcc-4.5 0100
Matthias
#include stdbool.h
#include stdio.h
static bool atomic_test_and_reset_bit(unsigned long *v,unsigned long
bit) {
bool res;
__asm__ __volatile__( btr %2,%1\n
adc $0,%0\n
:=r(res), =m(*v)
:r(bit), r(0)) ;
return res ? 1 : 0;
This inline-asm looks wrong. Because it says *v is always overriden.
So if that function is inlined, flags down below does not have to be
set before it.
}
int main(void)
{
unsigned long flags = 0;
int j;
j = atomic_test_and_reset_bit(flags, 2);
printf(%d\n, j);
return 0;
}
--
Summary: wrong code with -O1
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42553
[Bug c/42199] A problem with -maltivec
--- Comment #1 from pinskia at gmail dot com 2009-11-27 19:12 --- Subject: Re: New: A problem with -maltivec Can you attach the preprocessed source for the configure test that is failing? It looks like the context sensitive keywords is causing the header to fail to compile. Sent from my iPhone On Nov 27, 2009, at 11:00 AM, galtgendo at o2 dot pl gcc-bugzi...@gcc.gnu.org wrote: You'll probably mark this bug as invalid, as it's not my bug and being on x86, I really can't provide any info. http://bugs.gentoo.org/show_bug.cgi?id=293899 http://bugs.freedesktop.org/show_bug.cgi?id=25103 As you may see there, a trivial autoconf test was failing with -maltivec, but even before upstream made a change to do that test with g++, instead of gcc, it was working on x86. That's why I suspect it may be a compiler problem, that poppler upstream simply masked. -- Summary: A problem with -maltivec Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: galtgendo at o2 dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42199 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42199
[Bug debug/42065] DWARF .debug_macinfo contains unused macros
--- Comment #1 from pinskia at gmail dot com 2009-11-16 14:31 ---
Subject: Re: New: DWARF .debug_macinfo contains unused macros
Sent from my iPhone
On Nov 16, 2009, at 6:12 AM, jan dot kratochvil at redhat dot com
gcc-bugzi...@gcc.gnu.org
wrote:
-g3 currently produces huge objects as it contains many unused macros.
-g2 produces no macros debug info so GDB cannot provide its expansion.
That is by design and the reason why -g is -g2 by default
There is no way to store just the used macros.
(debuginfo compression driven by Roland McGrath may eliminate them but
still...)
While even a macro never used by a program can be helpful in most
cases IMO it
is enough to provide the macro definitions touched by the code being
debugged.
-feliminate-unused-debug-symbols -feliminate-unused-debug-types have
no effect.
---
---
---
--
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
---
---
---
--
Getting:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 1 macro : NOT used
DW_MACINFO_define - lineno : 2 macro : USED(x) x
or:
gcc -g2 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
nothing printed
Expected output:
gcc -g3 -o unusedmacro unusedmacro.c -Wall; readelf -wm unusedmacro
DW_MACINFO_define - lineno : 2 macro : USED(x) x
--
Summary: DWARF .debug_macinfo contains unused macros
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065
[Bug bootstrap/41996] lto-elf.c fails to compile on IRIX 6.5
--- Comment #3 from pinskia at gmail dot com 2009-11-14 22:44 --- Subject: Re: lto-elf.c fails to compile on IRIX 6.5 Sent from my iPhone On Nov 14, 2009, at 2:35 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-14 22:35 --- I guess the easiest is to avoid the special formats and simply use %ld and long unconditionally. How about using atoll and adding that to libitry? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #5 from pinskia at gmail dot com 2009-11-08 19:57 --- Subject: Re: Code optimized for AMD Geode is slower than generic Sent from my iPhone On Nov 8, 2009, at 11:52 AM, rootkit85 at yahoo dot it gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from rootkit85 at yahoo dot it 2009-11-08 19:52 --- # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.060 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow Since it has cmov this is not a real geode :). bogomips: 996.12 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: # CFLAGS='-march=native' ./dry.c Dhrystones per Second: 715308 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c/41990] Incorrect stack setup on x86_64
--- Comment #2 from pinskia at gmail dot com 2009-11-08 20:29 --- Subject: Re: New: Incorrect stack setup on x86_64 The x86_64 abi includes a red zone. So I doubt this a bug in gcc unless netbsd's abi does not match what gcc does. Sent from my iPhone On Nov 8, 2009, at 12:25 PM, cube at cubidou dot net gcc-bugzi...@gcc.gnu.org wrote: Provided a somewhat specific set of local variables, and as long as the code of the function doesn't make any other function calls, gcc will decrease %rsp but an incorrect and too small value. This leads to local variables being corrupted when the execution is interrupted; this happens notably in the kernel where interrupts use the stack of the thread they interrupted. The file that I will hopefully be able to attach to that report demonstrates the issue, if you look at the assembler output. With the function call commented out, gcc sets up the stack that way: movq%rsp, %rbp subq$152, %rsp and later access one of the local variables with: movl$0, -272(%rbp,%rax,4) When the function call is uncommented, the subq instruction here will correctly substract 272 to %rsp. I've compiled a 4.4.2 for the sole purpose of doing this bug report; NetBSD comes with 4.1.3 and that's where the bug was initially spotted. -- Summary: Incorrect stack setup on x86_64 Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cube at cubidou dot net GCC build triplet: x86_64-unknown-netbsd4.99.60 GCC host triplet: x86_64-unknown-netbsd4.99.60 GCC target triplet: x86_64-unknown-netbsd4.99.60 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41990
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #7 from pinskia at gmail dot com 2009-11-04 13:57 --- Subject: Re: -fdump-tree-all for lto does not work as expected Sent from my iPhone On Nov 4, 2009, at 1:32 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenther at suse dot de 2009-11-04 09:32 --- Subject: Re: -fdump-tree-all for lto does not work as expected On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-03 20:02 --- My /tmp is small so this causes it to be filled up quickly. Is there a simple work around? No. Actually thinking about it, setting TMPDIR env is a workaround :) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug lto/41598] bootstrap *using* lto fails
--- Comment #11 from pinskia at gmail dot com 2009-10-11 17:48 --- Subject: Re: bootstrap *using* lto fails On Sun, Oct 11, 2009 at 8:13 AM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: is this valid cross translation-unit if T is used across units? Yes this is valid for C. In C, types are across TUs are not based on names. This is why the code for -combine was complex with respect of type equality. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41598
[Bug tree-optimization/40844] O2 optimizes out assignment to bitfield
--- Comment #1 from pinskia at gmail dot com 2009-07-24 05:54 ---
Subject: Re: New: O2 optimizes out assignment to bitfield
Sent from my iPhone
On Jul 23, 2009, at 10:22 PM, jim at bodwin dot us gcc-bugzi...@gcc.gnu.org
wrote:
Incorrect code is produced for the following source with the O2
option. In
particular, the assignment to the bitfield field2 is optimized out
of the code
entirely and regImage is left all zero. Correct code is produced
with the O1
option and (at least) with gcc version 4.3.2.
Source Code
typedef struct hwreg {
short field1 : 4;
short field2 : 2;
short field3 : 10;
} hwreg_t;
void foo(volatile short *hwPtr, short f2) {
hwreg_t regImage; // Place to build reg image bit-by-bit
*(short *) regImage = 0;
regImage.field2 = f2;
*hwPtr = *((short *) regImage);
}
I think you are violating c/c++ aliasing rules here.
Object dump
/tmp/foo.o: file format elf32-littlearm
Disassembly of section .text:
foo:
0: e3a03000mov r3, #0 ; 0x0
4: e24dd004sub sp, sp, #4 ; 0x4
8: e1c030b0strhr3, [r0]
c: e28dd004add sp, sp, #4 ; 0x4
10: e12fff1ebx lr
gcc -v output
Configured with: ../gcc-4.4.1/configure --target=arm-elf --disable-
__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/
arm-elf :
(reconfigured) ../gcc-4.4.1/configure --target=arm-elf --disable-
__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/
arm-elf
Thread model: single
gcc version 4.4.1 (GCC)
--
Summary: O2 optimizes out assignment to bitfield
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at bodwin dot us
GCC build triplet: i486-pc-linux-gnu
GCC host triplet: i486-pc-linux-gnu
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40844
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40844
[Bug rtl-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong
--- Comment #1 from pinskia at gmail dot com 2009-07-08 08:13 ---
Subject: Re: New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, bastian dot schick at sciopta dot com
gcc-bugzi...@gcc.gnu.org
wrote:
If the following code is compiled with -Os for ARM or ColdFire, the
exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of
volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because
the
PowerPC version does not show the problem.
Also: Using a different start-address for tbl, does not show the
problem.
It looks more like a wrapping issue. 4*64 = 256. So we go from -256u
to 0 which causes wrapping of the pointer which is undefined and
therefor I think gcc is doing the correct thing (If got my numbers
correct).
The problem has been reported also for 4.4.0.
typedef volatile unsigned long __vu32;
void bs()
{
int i;
__vu32 *tbl = (__vu32 *)0xff00;
for(i = 0; i 64; ++i){
//- tbl[i] = (__vu32)10;
*tbl++ = (__vu32)10;
}
}
Cmd-line: arm-none-eabi-gcc -S -Os t.c
Output:
.cpu arm7tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file t.c
.text
.align 2
.global bs
.type bs, %function
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mvn r2, #255
.L2:
mov r3, #10
str r3, [r2], #4
b .L2
.size bs, .-bs
.ident GCC: (Sourcery G++ Lite 2008q3-39) 4.3.2
--
Summary: Optimizer handles loops with volatiles and post-
incr.
wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bastian dot schick at sciopta dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-mingw32
GCC target triplet: i686-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #3 from pinskia at gmail dot com 2009-07-07 03:44 ---
Subject: Re: New: dereferencing type-punned pointer warnings cannot be
disabled
Sent from my iPhone
On Jul 6, 2009, at 6:12 PM, mikulas at artax dot karlin dot mff dot
cuni dot cz gcc-bugzi...@gcc.gnu.org wrote:
Gcc became recently (4.4) very bad regarding false positive type-
punned
warnings. In previous versions, the warnings could be suppressed by
casting to
(void *), in 3.x and 4.1 it worked perfectly, in 4.3 it still worked
somehow
(except in -Wstrict-aliasing=3 mode), in 4.4 there are cases where
it doesn't
work at all.
I don't want to completely disable the warnings with -Wno-strict-
aliasing (this
could leave bugs unnotified), but I need a method to disable them on
case-by-case basis once I verified that the code in question is
correct.
Simple example, compile with -O2 -Wall:
extern int c;
int a(void)
{
return *(short *)(void *)c;
}
This is a very bad example of a false positive as you are acessing an
int as a short; that is undefined. I will look at your code later on,
my laptop for home is currently broken.
In 4.4 the warning can't be disabled at all! The (void *) cast
doesn't suppress
the warning and none of three options to -Wstrict-aliasing helps. In
4.3 the
cast to (void *) suppressed the warning in -Wstrict-aliasing 1,2
modes (and
didn't suppress it in the default mode 3), in 4.4 the warning can't be
suppressed at all.
Gcc developers tried to made these warnings more intelligent with
less false
positives, but unfortunatelly they completely broke the method to
disable them
in the specific case. For me, false positives are not a major
problem --- when
I get a false positive, I just read the code, check it and if I
conclude that
it's OK, I disable the warning with (void *).
But if there's no way to disable false positives, it makes the
warnings
completely useless.
--
Summary: dereferencing type-punned pointer warnings cannot
be
disabled
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #4 from pinskia at gmail dot com 2009-07-07 03:48 --- Subject: Re: dereferencing type-punned pointer warnings cannot be disabled Sent from my iPhone On Jul 6, 2009, at 6:34 PM, mikulas at artax dot karlin dot mff dot cuni dot cz gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 01:34 --- Created an attachment (id=18146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces type- punned warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug regression/40665] dereferencing type-punned pointer warnings cannot be disabled
--- Comment #5 from pinskia at gmail dot com 2009-07-07 03:50 --- Subject: Re: dereferencing type-punned pointer warnings cannot be disabled Thus code is undefined you have an acess of a char array as a struct. Yes you are only taking the address of an element but it is still considered an acess by the standards. Sent from my iPhone On Jul 6, 2009, at 6:34 PM, mikulas at artax dot karlin dot mff dot cuni dot cz gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-07 01:34 --- Created an attachment (id=18146) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18146action=view) a bug in -Wstrict-aliasing=3 This is an example of a flaw in -Wstrict-aliasing=3 (this mode is very bad, produces many false positives on my project and I'm wondering why is it default?) Gcc man page says that -Wstrict-aliasing=3 produces less false positives than -Wstrict-aliasing=2. This is counterexample, it produces type- punned warning in -Wstrict-aliasing=3 mode and doesn't warn in -Wstrict-aliasing=2. I added (void *) casts everywhere, but they don't quash the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40665
[Bug c/40645] Bus error caused by ldd/std instructions in struct copy.
--- Comment #1 from pinskia at gmail dot com 2009-07-04 01:38 ---
Subject: Re: New: Bus error caused by ldd/std instructions in struct copy.
This code is undefined because of alignment requirments differences
for the structs and the union.
Sent from my iPhone
On Jul 3, 2009, at 6:33 PM, dentongosnell at yahoo dot com
gcc-bugzi...@gcc.gnu.org
wrote:
$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1
'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-
shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/
include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-
gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
To trigger the bug :-
$ gcc align_bug.c
$ ./a.out
Bus error
$
Here is align_bug.c :-
-
#include stdio.h
struct b_one {
int i;
double d;
};
struct b_two {
int i1;
int i2;
};
union myblock {
struct b_one one;
struct b_two two;
};
void myfunc(union myblock *dp1, union myblock *dp2)
{
dp2-two = dp1-two;
}
int main()
{
int w;
struct b_two a = {1,2};
struct b_two b;
myfunc((union myblock *)a, (union myblock *)b);
printf(%d %d\n, b.i1, b.i2);
return 0;
}
--
The problem seems to happen in myfunc when the compiled code tries
to copy the 8-byte structure dp2-two to dp1-two, using a ldd/std
instruction pair. The problem seems to be that dp1 and dp2 (ie a and
b in main) aren't strictly enough aligned for that. If you take out
the redundant int w in main then a and b happen to be aligned okay
and the bus error doesn't happen.
I think the compiler is assuming union myblock has the same
alignment as struct b_one, which is more strictly aligned than
struct b_two because of its double member.
I realise that casting a to (union myblock*) in main may technically
invoke undefined behaviour... but I think the cast is reasonable given
that union myblock contains the type of a.
One other thing, there is a flag -mno-faster-structs which this page
suggests would prevent this sort of ldd/std use
(http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). Unfortunately
this flag doesn't seem to make any difference to this case.
--
Summary: Bus error caused by ldd/std instructions in
struct copy.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dentongosnell at yahoo dot com
GCC build triplet: sparc-linux-gnu
GCC host triplet: sparc-linux-gnu
GCC target triplet: sparc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40645
[Bug target/15623] nop insertion does not look see restrict pointers
--- Comment #7 from pinskia at gmail dot com 2009-06-25 19:33 --- Subject: Re: nop insertion does not look see restrict pointers Sent from my iPhone On Jun 25, 2009, at 12:30 PM, rguenth at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-25 19:30 --- which makes this bug ... ??? dependent on a bug you're going to file? Most likely closing as won't fix as this is not important for any newer ppcs. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --- --- -- Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15623
[Bug target/40473] -mno-sched-prolog breaks function parameter debug location lists
--- Comment #2 from pinskia at gmail dot com 2009-06-17 13:12 --- Subject: Re: -mno-sched-prolog breaks function parameter debug location lists This option should just be removed. Sent from my iPhone On Jun 17, 2009, at 2:21 AM, amodra at bigpond dot net dot au gcc-bugzi...@gcc.gnu.org wrote: --- Comment #1 from amodra at bigpond dot net dot au 2009-06-17 09:21 --- See http://sourceware.org/bugzilla/show_bug.cgi?id=10231 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40473
[Bug c/40366] Array + XOR swap fails
--- Comment #1 from pinskia at gmail dot com 2009-06-07 07:23 ---
Subject: Re: New: Array + XOR swap fails
Both of these are undefined. Look up about sequence point rules.
Sent from my iPhone
On Jun 7, 2009, at 12:15 AM, ashutosh dot sharma dot 0204 at gmail
dot com gcc-bugzi...@gcc.gnu.org wrote:
Compiler Version:
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Copyright (C) 2007 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.
Sample code:
#include stdio.h
int main() {
int a[2];
a[0]=10;
a[1]=20;
printf(a[0] = %d a[1] = %d\n, a[0], a[1]);
a[0]^=a[1]^=a[0]^=a[1];
printf(a[0] = %d a[1] = %d\n, a[0], a[1]);
return 0;
}
gcc test.c -o test -O2
a[0] = 10 a[1] = 20
a[0] = 20 a[1] = 10
gcc test.c -o test -O0
a[0] = 10 a[1] = 20
a[0] = 0 a[1] = 10
Bug: When compiled with -O0 swap fails.
Swap only fails in case of array. Following code works fine with -O0:
#include stdio.h
int main() {
int a, b;
a=10;
b=20;
printf(a = %d b = %d\n, a, b);
a^=b^=a^=b;
printf(a = %d b = %d\n, a, b);
return 0;
}
--
Summary: Array + XOR swap fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ashutosh dot sharma dot 0204 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40366
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #1 from pinskia at gmail dot com 2009-04-29 23:13 --- Subject: Re: New: [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used Looks like this failson non elf hosts (well darwin supports dlopen so I don't understand why it fails on darwin). Sent from my iPhone On Apr 29, 2009, at 10:19 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: Yet another bootstrap error on i686-apple-darwin9: ... /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev- gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -c -g -O2 -fomit-frame- pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format- attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength- strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/. -I../../gcc-4.5-work/gcc/../include - I./../intl -I../../gcc-4.5-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.5-work/gcc/../libdecnumber -I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/ include -I/sw/include -DCLOOG_PPL_BACKEND ../../gcc-4.5-work/gcc/pointer- set.c -o pointer-set.o cc1: warnings being treated as errors ./plugin-version.h:11: error: 'gcc_version' defined but not used make[3]: *** [plugin.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 -- Summary: [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug libgcj/39747] [4.4/4.5 Regression] libjavamath is linking against libgmp
--- Comment #4 from pinskia at gmail dot com 2009-04-27 07:16 --- Subject: Re: [4.4/4.5 Regression] libjavamath is linking against libgmp Sent from my iPhone On Apr 26, 2009, at 11:54 PM, jakub at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from jakub at gcc dot gnu dot org 2009-04-27 06:54 --- This doesn't look like a GCC bug, but user error. It is a gcc bug as this dependency is not documented this way. At least I could not find the documention for this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
