[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-17 08:30:05 UTC --- Since I can't reproduce the failure, please help me debug this (basically, print all local variables around the assertion and the proc maps) or suggest me how to reproduce. I've got access to a ppc machine with 3.3.8 Linux, but it uses 44 bit address space and basic asan functionality seems to work (I am working with LLVM trunk, not with GCC version, but that should not matter)
[Bug fortran/56015] New: Option -ffast-math reveals i*(a+bi) - -b-bi, a complex multiplication bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 Bug #: 56015 Summary: Option -ffast-math reveals i*(a+bi) - -b-bi, a complex multiplication bug Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: t_nis...@yahoo.co.jp With gfortran, optimization option -O3 -ffast-math, more precisely -O3 -funsafe-math-optimizations -ffinite-math-only reveals a complex multiplication bug of i*(a+bi) = Good: -b+ai Bug: -b-bi Source: ! multiplyi.f -*-f90-*- !! program multiplyi implicit none complex*16 p(10) p(:) = (0.1d0, 0.2d0) p(:) = (0.0d0, 1.0d0) * p(:) write(6,'(2f5.1)') p(1) end program multiplyi Compilation and execution: $ gfortran --version GNU Fortran (GCC) 4.7.2 $ gfortran -ffree-form -O3 -o nofast-math multiplyi.f ./nofast-math -0.2 0.1 $ gfortran -ffree-form -O3 -ffast-math -o fast-math multiplyi.f ./fast-math -0.2 -0.2 Details: * I could reproduce this bug with gcc-4.4.6, 4.6.3, and 4.7.2. * I could reproduce it on Intel Core i5 and Xeon5650 (64bit) and VIA C7-M (32bit). * To reproduce this bug, the variable p(10) should not be an array in 4.6.3, but it should be an array in 4.7.2. Tank you for your constant efforts on gfortran, Takeshi
[Bug c++/56014] [C++1y] ICE using return type deduction for member functions with -g enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56014 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 Summary|[C++1y] Return type |[C++1y] ICE using return |deduction for member|type deduction for member |functions does not work |functions with -g enabled |when -g is enabled | Ever Confirmed|0 |1
[Bug middle-end/56015] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 Component|fortran |middle-end Summary|Option -ffast-math reveals |expand expands p[9] = |i*(a+bi) - -b-bi, a|COMPLEX_EXPR |complex multiplication bug |-IMAGPART_EXPR p[9], ||REALPART_EXPR p[9]; ||incorrectly. Ever Confirmed|0 |1 Known to fail|4.4.6, 4.6.3, 4.7.2 |4.3.5, 4.4.5, 4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-17 08:52:25 UTC --- Actually it is not the multiplication that goes wrong. In fact the code looks correct before expand. Turning off TER (-fno-tree-ter) will work around this expand issue though.
[Bug libstdc++/56016] New: mutlithreading problem with iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016
Bug #: 56016
Summary: mutlithreading problem with iostream
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b...@justexpired.e4ward.com
Created attachment 29188
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29188
sample program
I wrote a program that uses 2 threads (pthreads), one to read from stdin, the
other to write to stdout. The goal is that even if stdout is blocked by a pipe,
reading from stdin should not be blocked, instead, data should be accumulated
in the program's heap and eventually copied to stdout. The program works fine
if reading and writing are done with unistd (read/write) or cstdlib
(fread/fwrite) routines, but not with iostream (cin.read/cout.write).
I'm using stock Linux Mint 13, which comes with gcc 4.6.3.
The program is attached, I compiled it with:
$ g++ -g -o drain drain.cpp -lpthread
To reproduce the bug, follow these steps:
1. Create an input file:
$ dd if=/dev/zero bs=1024 count=256 zeros
2. Create 2 named pipes:
$ mkfifo pipe-1
$ mkfifo pipe-2
3. Start a source and a sink:
$ cat zeros pipe-1
$ { sleep 300; cat result; } pipe-2
4. Finally, connect them with our program:
$ ./drain 2 pipe-1 pipe-2
Expected behaviour: job 1 (cat into pipe-1) should finish right away, with all
input transferred to the buffers of ./drain. The output thread of ./drain
should be blocked, waiting for somebody to read data from pipe-2. To cause the
entire pipeline to complete, kill the sleep process with e.g.
$ killall sleep
This causes the cat in the sink to pull data from pipe-2.
The expected behaviour occurs when using ./drain 0 (unistd routines) or ./drain
1 (cstdlib routines), but not with ./drain 2 (iostream routines)
Observed behaviour: (most of the time...) job 1 doesn't complete. Instead, the
input thread of ./drain blocks at some point, without completing the stdin
reading. When the sleep process is killed, the entire pipeline completes. The
problem is the blocking, though. Perhaps the blocked cout.write() holds some
mutex, preventing cin.read() from completing. But I'm speculating here.
Note: the named pipes have a certain capacity, in my case about 65536. This
means the output thread of ./drain will be able to write a few blocks even
before the sleep process ends and cat reads from pipe-2. For the same reason,
the cat into pipe-1 might complete even if the input thread of ./drain blocks
(which is the bad behaviour), as long as the difference can be held by pipe-1.
The numbers make the bug reproducible on my system, but if the pipes have
larger capacity, the size of the input should be increased.
[Bug libstdc++/56016] mutlithreading problem with iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-17 09:16:20 UTC --- You might need std::ios_base::sync_with_stdio(false);
[Bug go/56017] New: libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 Bug #: 56017 Summary: libgo testsuite does not support cross testing Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: sch...@linux-m68k.org ../../../libgo/testsuite/gotest: line 470: ./a.out: cannot execute binary file FAIL: bufio make[4]: *** [bufio/check] Error 1
Re: [Bug middle-end/42371] dead code not eliminated during folding with whole-program
Still a problem in latest 4.7, google/4.7, and trunk (4.8). So 4.6 was working but 4.7 isn't?
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 --- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2013-01-17 10:27:10 UTC --- Still a problem in latest 4.7, google/4.7, and trunk (4.8). So 4.6 was working but 4.7 isn't?
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Known to work||4.1.2 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 Summary|expand expands p[9] = |[4.6/4.7/4.8 Regression] |COMPLEX_EXPR|expand expands p[9] = |-IMAGPART_EXPR p[9], |COMPLEX_EXPR |REALPART_EXPR p[9]; |-IMAGPART_EXPR p[9], |incorrectly.|REALPART_EXPR p[9]; ||incorrectly. --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:30:11 UTC --- Works correctly with 4.1.2, where we had CR.108 = REALPART_EXPR p[0]; REALPART_EXPR p[0] = -IMAGPART_EXPR p[0]; IMAGPART_EXPR p[0] = CR.108; in the *.optimized dump. Thus a regression.
[Bug go/56017] libgo testsuite does not support cross testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56017 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 10:30:27 UTC --- Confirmed.
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:31:08 UTC --- Created attachment 29189 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29189 gcc48-pr56015.patch Untested fix.
[Bug inline-asm/55934] [4.8 Regression] LRA inline asm error recovery
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:45:20 UTC --- I don't care much about the error wording, I've put into dg-error just what gcc was reporting before (and after it emitted ICE).
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 10:48:40 UTC --- Hmm, I wonder if it isn't better to disable TER for these cases. We might run into similar issues with other loads (BIT_FIELD_REF and vectors for example).
[Bug c/56018] New: Access to member of unnamed union variable in structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56018
Bug #: 56018
Summary: Access to member of unnamed union variable in
structure
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stephan...@gmail.com
Created attachment 29190
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29190
ngx_event preprocessed file, where __sigaction_handler automaticaly added
When accessing from structure to unnamed union variable, it's union variable
name automatically added to preprocessed code, without check if it was added in
source.
In nginx(1.3.7, ngx_event.c) there code like:
struct sigaction sa;
sa.sa_handler = ngx_timer_signal_handler;
From preprocessor file I got, that sigaction has next difinition:
# 25 /usr/include/bits/sigaction.h 3 4
struct sigaction
{
union
{
__sighandler_t sa_handler;
void (*sa_sigaction) (int, siginfo_t *, void *);
}
__sigaction_handler;
__sigset_t sa_mask;
int sa_flags;
void (*sa_restorer) (void);
};
So when I find the lines above I saw that while accessing the union variable
member, it's name was added(ngx_event.i:13893):
sa.__sigaction_handler.sa_handler = ngx_timer_signal_handler;
When I changed source code to:
sa.__sigaction_handler.sa_handler = ngx_timer_signal_handler;
the preprocessor file of it became:
sa.__sigaction_handler.__sigaction_handler.sa_handler =
ngx_timer_signal_handler;
and I got an error:
gcc -c -pipe -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g -I
src/core -I src/event -I src/event/modules -I src/os/unix -I objs \
-o objs/src/event/ngx_event.o \
src/event/ngx_event.c
gcc-4.4: warning: -pipe ignored because -save-temps specified
src/event/ngx_event.c: In function ‘ngx_event_process_init’:
src/event/ngx_event.c:644: error: ‘union anonymous’ has no member named
‘__sigaction_handler’
make[1]: *** [objs/src/event/ngx_event.o] Error 1
make[1]: Leaving directory `/root/newM/nginx-1.3.7'
make: *** [build] Error 2
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #172 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 10:53:29 UTC --- (In reply to comment #171) Created attachment 29182 [details] Patch to compress line info This patch removes column information from LTO (so we lose carret diagnostics in warnings/errors output at LTO time that seems resonable thing to do) and avoid entering duplicate locators into the linemap. The patch reduces linemap usage from 23% to 5% of GGC memory saving 1-2GB on Mozilla. (also reducing LTO file size). Patch looks incomplete? What does dropping columns only do to memory use? Please disable flag_diagnostics_show_caret unconditionally in lto1 if you do that.
[Bug fortran/55983] [4.7/4.8 Regression] ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 --- Comment #9 from janus at gcc dot gnu.org 2013-01-17 10:55:55 UTC --- Author: janus Date: Thu Jan 17 10:55:50 2013 New Revision: 195261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195261 Log: 2013-01-17 Janus Weil ja...@gcc.gnu.org PR fortran/55983 * class.c (find_typebound_proc_uop): Check for f2k_derived instead of asserting it. 2013-01-17 Janus Weil ja...@gcc.gnu.org PR fortran/55983 * gfortran.dg/class_55.f90: New. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/class_55.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/class.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug fortran/55983] [4.7/4.8 Regression] ICE in find_typebound_proc_uop, at fortran/class.c:2711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55983 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from janus at gcc dot gnu.org 2013-01-17 10:58:42 UTC --- Fixed on trunk and 4.7. Closing.
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 10:59:08 UTC --- Seems the elf_platform () returned strings need some adjustment to match the RS6000_CPU names. Grepping Linux kernel, elf_platform can return e.g. pa6t power3 power4 power5 power5+ power6 power6x power7 power7+ power8 powerpc ppc403 ppc405 ppc440 ppc440gp ppc470 ppc5554 ppc601 ppc603 ppc604 ppc7400 ppc7450 ppc750 ppc823 ppc8540 ppc8548 ppc970 ppca2 ppc-cell-be ppce500mc ppce5500 ppce6500 so, supposedly initialy ppc prefix, if any, should be dropped, ppc-cell-be should be replaced by cell and most likely the string checked against the asm_names[].cpu strings. There are other minor differences, e.g. kernel has ppc440 and ppc440gp, while gcc 440fp and 440 (do they match in this order, or differently?).
[Bug c/56018] Access to member of unnamed union variable in structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56018
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||INVALID
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
11:14:13 UTC ---
This has nothing to do with gcc, the header file has:
union
{
/* Used if SA_SIGINFO is not set. */
__sighandler_t sa_handler;
/* Used if SA_SIGINFO is set. */
void (*sa_sigaction) (int, siginfo_t *, void *);
}
__sigaction_handler;
# define sa_handler __sigaction_handler.sa_handler
# define sa_sigaction __sigaction_handler.sa_sigaction
And, using __sigaction_handler.sa_handler in your source file is wrong,
__sigaction_handler is reserved for the implementation (and so is sa_handler in
POSIX if you include signal.h header).
[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264 --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-17 11:43:18 UTC --- Author: jamborm Date: Thu Jan 17 11:43:14 2013 New Revision: 195262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195262 Log: 2013-01-17 Martin Jambor mjam...@suse.cz PR tree-optimizations/55264 * ipa-inline-transform.c (can_remove_node_now_p_1): Never return true for virtual methods. * ipa.c (symtab_remove_unreachable_nodes): Never return true for virtual methods before inlining is over. * cgraph.h (cgraph_only_called_directly_or_aliased_p): Return false for virtual functions. * cgraphclones.c (cgraph_create_virtual_clone): Mark clones as non-virtual. testsuite/ * g++.dg/ipa/pr55264.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr55264.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/cgraphclones.c trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56015] [4.6/4.7/4.8 Regression] expand expands p[9] = COMPLEX_EXPR -IMAGPART_EXPR p[9], REALPART_EXPR p[9]; incorrectly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56015 --- Comment #5 from Takeshi Nishimatsu t_nissie at yahoo dot co.jp 2013-01-17 11:58:24 UTC --- (In reply to comment #3) Created attachment 29189 [details] gcc48-pr56015.patch Untested fix. Thank you for your fix. I add one more test multiplying -i. program pr56015 implicit none complex*16 m(10),p(10) m(:) = (0.3d0, 0.4d0) m(:) = (0.0d0,-1.0d0) * m(:) call bar (m) p(:) = (0.1d0, 0.2d0) p(:) = (0.0d0, 1.0d0) * p(:) call foo (p) contains subroutine bar (m) complex*16 m(10) if (any (m .ne. ( 0.4d0,-0.3d0))) call abort end subroutine subroutine foo (p) complex*16 p(10) if (any (p .ne. (-0.2d0, 0.1d0))) call abort end subroutine end program pr56015
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #173 from Jan Hubicka hubicka at ucw dot cz 2013-01-17 12:30:30 UTC --- Patch looks incomplete? What does dropping columns only do to memory use? I will check. I remember that prior columns there was also some savings for the cache. Just saving 20% out of 23% is cooler than saving 20% out of 5% of memory. Note that we are still over 8GB for Mozilla LTO after latest Mozilla checkout. Please disable flag_diagnostics_show_caret unconditionally in lto1 if you do that. Yeah, I wanted, but I am not sure where in lto.c is proper place to do so?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #174 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 12:42:06 UTC --- lto_post_options ?
[Bug libstdc++/56019] New: max_align_t should be in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019
Bug #: 56019
Summary: max_align_t should be in std namespace
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org
According to 3.11.2 in the C++11 standard max_align_t should be inside the std
namespace (i.e. the text talks about use of alignof(std::max_align_t)). GCC
only provides ::max_align_t, though:
% cat main.cpp
#include
cstddef
int main()
{
return alignof(std::max_align_t);
}
% /opt/gcc-4.7.2/bin/g++ -Wall -std=c++11 -o test main.cpp
main.cpp: In function ‘int main()’:
main.cpp:4:20: error: ‘max_align_t’ is not a member of ‘std’
main.cpp:4:20: note: suggested alternative:
In file included from
/home/.opt/gcc-4.7.2/bin/../lib/gcc/x86_64-suse-linux-gnu/4.7.2/../../../../include/c++/4.7.2/cstddef:44:0,
from main.cpp:1:
/home/.opt/gcc-4.7.2/bin/../lib/gcc/x86_64-suse-linux-gnu/4.7.2/include/stddef.h:426:3:
note: ‘max_align_t’
% /opt/gcc-4.8-snapshot/bin/g++ -Wall -std=c++11 -o test main.cpp
main.cpp: In function ‘int main()’:
main.cpp:4:20: error: ‘max_align_t’ is not a member of ‘std’
return alignof(std::max_align_t);
^
main.cpp:4:20: note: suggested alternative:
In file included from
/home/.opt/gcc-4.8-snapshot/include/c++/4.8.0/cstddef:44:0,
from main.cpp:1:
/home/.opt/gcc-4.8-snapshot/lib/gcc/x86_64-suse-linux-gnu/4.8.0/include/stddef.h:425:3:
note: ‘max_align_t’
} max_align_t;
^
[Bug c/56020] New: FE_INVALID flag not set on comparison with NAN (unordered)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56020
Bug #: 56020
Summary: FE_INVALID flag not set on comparison with NAN
(unordered)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincent-...@vinc17.net
GCC doesn't set the FE_INVALID flag on comparison with NAN (=, =, , ), e.g.
with:
#include stdio.h
#include math.h
#include fenv.h
#pragma STDC FENV_ACCESS ON
int main (void)
{
double d = NAN;
int err;
feclearexcept (FE_INVALID);
d = 0.0;
err = ! fetestexcept(FE_INVALID);
if (err)
printf (The FE_INVALID flag is not set\n);
return err;
}
$ gcc-snapshot --version
gcc (Debian 20130113-1) 4.8.0 20130113 (experimental) [trunk revision 195136]
[...]
$ gcc-snapshot -std=c99 -Wall nancmp.c -o nancmp -lm
nancmp.c:5:0: warning: ignoring #pragma STDC FENV_ACCESS [-Wunknown-pragmas]
#pragma STDC FENV_ACCESS ON
^
nancmp.c: In function 'main':
nancmp.c:13:3: warning: statement with no effect [-Wunused-value]
d = 0.0;
^
$ ./nancmp
The FE_INVALID flag is not set
The statement with no effect warning would also be incorrect once this bug is
fixed.
[Bug c/56020] FE_INVALID flag not set on comparison with NAN (unordered)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56020 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 13:21:26 UTC --- The comparison is dead. FENV_ACCESS is not implemented (side-effects on FENV are not preserved). Use if (d = 0.0) __asm(); GCC uses ucomisd for the comparison, even with -fsignalling-nans.
[Bug tree-optimization/42108] [4.6/4.7/4.8 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #55 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-17 14:20:06 UTC --- (In reply to comment #54) Re-confirmed on trunk. The initial GFortran IL is still ... awkward. Apart from the issue of using a canonicalized IV at all we have This part has been fixed by the patch http://gcc.gnu.org/ml/fortran/2013-01/msg00136.html (partially undoing PR42131), Commit: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195260
[Bug tree-optimization/42108] [4.6/4.7/4.8 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #56 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 14:30:10 UTC --- 4.3 vs. trunk I get 9.5s vs. 12.3s for -O3. With 4.7 and 4.6 I get the same result (on Intel CPUs). Thus basically re-confirmed after the recent patches.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #175 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-17 14:40:04 UTC --- Created attachment 29191 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29191 alternative patch without the compression. This is alternative patch just skipping columns but not doing the compression. It seems that compression is actually quite effective. Non-compressing w/o column info is 1073872920 bytes, compression + no column is 268566544 bytes compression + column is 1073872920 bytes Perhaps I messed up the caching with column info? It strikes wrong that the numbers are precisely the same. But perhaps it is just reallocation strategy. I will also generate fresh numbers for unpatched GCC.
[Bug tree-optimization/42108] [4.6/4.7/4.8 Regression] 50% performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108 --- Comment #57 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17 14:42:11 UTC --- A proper fix these days (with tuples) is to add new tree codes that carry the knowledge that countm1.6_40 = _38 / _39; may not trap. The frontend already knows this (step == _39 == 0 has undefined behavior according to the language). This is work in a similar area as no-undefined-overflow or the proposed changes to make FP rounding modes explicit.
[Bug libstdc++/56019] max_align_t should be in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56019 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-17 14:52:45 UTC --- cstddef just hasn't been updated since max_align_t was added to stddef.h
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #176 from Richard Biener rguenth at gcc dot gnu.org 2013-01-17
14:54:22 UTC ---
(In reply to comment #175)
Created attachment 29191 [details]
alternative patch without the compression.
This is alternative patch just skipping columns but not doing the compression.
It seems that compression is actually quite effective.
Non-compressing w/o column info is 1073872920 bytes,
compression + no column is 268566544 bytes
compression + column is 1073872920 bytes
Perhaps I messed up the caching with column info? It strikes wrong that the
numbers are precisely the same. But perhaps it is just reallocation strategy.
I
will also generate fresh numbers for unpatched GCC.
+linemap_line_start (line_table, data_in-current_line, 0);
- return linemap_position_for_column (line_table, data_in-current_col);
+ return linemap_position_for_column (line_table, 0);
linemap_line_start will aready return a location for column 0.
So I'd say we want
if (file_change)
{
...
}
return linemap_line_start (line_table, data_in-current_line, 0);
instead. Which hopefully does nothing if nothing changed.
I don't know how you implement caching - you didn't attach a patch to do so.
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-01-17 15:06:50 UTC --- I agree. Today I needed to duplicate std::lock_guard because of this problem
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #177 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-17 15:13:53 UTC --- Created attachment 29192 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29192 caching Aha, now I see why you ask for complete patch. I obviously messed up the code. This is how I do caching (in version that still has columns in it). I removed the final incarnation of the patch, but it should be easy to re-do.
[Bug target/56021] New: HAVE_STBLIB_H and HAVE_LIMITS_H not defined. Can't build gcc 3.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56021 Bug #: 56021 Summary: HAVE_STBLIB_H and HAVE_LIMITS_H not defined. Can't build gcc 3.2.1 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: bryro...@cisco.com I am using CentOS 4.8 and gcc3.4.6 to build a gcc 3.2.1 cross compiler for mipsisa32-elf (using binutils 2.13.1). After configuring I get the following error when issuing make -w all install 21 | tee make.out on the command line. gcc -c -DHAVE_CONFIG_H -O2 -ffunction-sections -I. -I/home/bryrober/BRCM/gcc-3.2.1/libiberty/../include -W -Wall -Wtraditional -pedantic /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:46: error: conflicting types for 'malloc' /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:46: error: conflicting types for 'malloc' /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c: In function `code_for_qualifier': /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:623: warning: implicit declaration of function `abort' /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c: In function `ada_demangle': /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:1003: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:1056: warning: dereferencing type-punned pointer will break strict-aliasing rules /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c: In function `squangle_mop_up': /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:1149: warning: implicit declaration of function `free' /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c: In function `demangle_qualified': /home/bryrober/BRCM/gcc-3.2.1/libiberty/cplus-dem.c:3282: warning: implicit declaration of function `atoi' If I fix this error I get a error in fib heap.c complaining about LONG_MIN undeclared which is defined in limits.h. Here is my configuration output /home/bryrober/BRCM/gcc-3.2.1/configure --target=mipsisa32-elf --prefix=/home/bryrober/BRCM/gnutools --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --with-newlib --with-gxx-include-dir=/home/bryrober/BRCM/gnutools/mipsisa32-elf/sys-include --host=i686-unknown-linux-gnu --with-headers=/usr/include -v 21 | tee configure.out
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||nickc at gcc dot gnu.org,
||ramana at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17
15:55:26 UTC ---
The issue isn't latent, can be still reproduced with:
/* PR target/49069 */
/* { dg-do compile } */
/* { dg-options -Os -fno-tree-forwprop -Wno-div-by-zero } */
int a;
const unsigned long long b[1] = { 1ULL };
extern void bar (int);
void
foo (void)
{
for (a = 0; a == 1; a = 2)
;
bar (b[0] == (a == 0 ? a : a / 0));
}
Which also shows that the middle-end usually optimizes that well (cf. #c4), but
the arm backend relying on that always happening is just a very bad assumption.
[Bug middle-end/56022] New: [4.8 regression] ICE (segfault) at convert_memory_address_addr_space (explow.c:334)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56022
Bug #: 56022
Summary: [4.8 regression] ICE (segfault) at
convert_memory_address_addr_space (explow.c:334)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kr...@kde.org
% cat ice.cpp
typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
__attribute__((target(no-avx))) static bool currentImplementationSupported()
{}
__m256 foo0(__m256 a) {}
% /opt/gcc-4.8-snapshot/bin/g++ -mavx -c ice.cpp
ice.cpp: In function ‘__m256 foo0(__m256)’:
ice.cpp:3:24: internal compiler error: Segmentation fault
__m256 foo0(__m256 a) {}
^
0xab4dcf crash_signal
../.././gcc/toplev.c:332
0x875c4a convert_memory_address_addr_space(machine_mode, rtx_def*, unsigned
char)
../.././gcc/explow.c:334
0x914476 expand_function_end()
../.././gcc/function.c:5166
0x7ca8d7 construct_exit_block
../.././gcc/cfgexpand.c:4219
0x7ca8d7 gimple_expand_cfg
../.././gcc/cfgexpand.c:4627
% /opt/gcc-4.8-snapshot/bin/g++ --version
g++ (GCC) 4.8.0 20130113 (experimental)
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:08:15 UTC --- Created attachment 29193 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29193 gcc48-pr49069-1.patch One possible fix.
[Bug target/49069] [4.6/4.7/4.8 Regression] ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:10:45 UTC --- Created attachment 29194 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29194 gcc48-pr49069-2.patch Another possible fix. Or Steven's fix (+ testcase) if it works. It will be optimized by RTL optimizers anyway. Just asserting that an unlikely, but possible thing, won't happen, is wrong. Can we get this fixed for 4.8?
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-17 16:19:19 UTC --- Yep, I'm fixing it. I went to add a test for locks that wouldn't rely on thread support and found I'd already added one ages ago: http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/testsuite/30_threads/lock_guard/cons/1.cc?revision=185390content-type=text%2Fplainview=co That just needs the dejagnu target selectors removed so it always runs.
[Bug target/56021] HAVE_STBLIB_H and HAVE_LIMITS_H not defined. Can't build gcc 3.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56021 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-17 16:22:58 UTC --- 3.4.1 AND 3.4.6 are no longer supported. Since it is the host libiberty that is failing, you should look into config.log from the libiberty directory to see why they are not being defined. It might be configure for that version is just broken with newer glibc/gcc's and there is not much to be done here from our side except close this bug as won't fix.
[Bug target/56021] HAVE_STBLIB_H and HAVE_LIMITS_H not defined. Can't build gcc 3.2.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56021 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-17 16:24:08 UTC --- Noone's going to change anything in the GCC 3.2.1 sources now, so I expect this will be closed as WONTFIX. And this can't be severity=blocker because it's obviously not going to block the 3.2.2 release :)
[Bug target/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #11 from uros at gcc dot gnu.org 2013-01-17 16:25:04 UTC --- Author: uros Date: Thu Jan 17 16:24:54 2013 New Revision: 195273 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195273 Log: PR target/55981 * config/i386/sync.md (atomic_storemode): Always generate SWImode store through atomic_storemode_1. (atomic_storemode_1): Macroize insn using SWI mode iterator. testsuite/ChangeLog: PR target/55981 * gcc.target/pr55981.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr55981.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sync.md trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/51083] TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51083 --- Comment #21 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-17 16:27:35 UTC --- Author: hubicka Date: Thu Jan 17 16:27:23 2013 New Revision: 195274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195274 Log: PR tree-optimizatoin/51083 * gcc.c-torture/compile/pr51083.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug target/27855] [4.5/4.7/4.8 regression] reassociation causes the RA to be confused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855 --- Comment #46 from Uros Bizjak ubizjak at gmail dot com 2013-01-17 16:36:30 UTC --- (In reply to comment #45) Is there any improvement if you use -fschedule-insns1 -fsched-pressure? Yes, please see the table bellow: ALGORITHM NB REPSTIME MFLOPS = = = == == -DREPS=1 -msse3 -O2 -ffast-math atlasmm 60 1 0.899 4806.07 -msse3 -O2 -ffast-math -fschedule-insns -fsched-pressure atlasmm 60 1 0.697 6198.93 -DREPS=1 -msse3 -O2 -ffast-math -fno-tree-reassoc atlasmm 60 1 0.672 6429.56 -DREPS=1 -msse3 -O2 -ffast-math -fno-tree-reassoc -fschedule-insns -fsched-pressure atlasmm 60 1 0.683 6326.00 -DREPS=1 -msse3 -O2 -ffast-math -ftree-vectorize atlasmm 60 1 0.898 4811.42 -DREPS=1 -msse3 -O2 -ffast-math -ftree-vectorize -fno-tree-reassoc atlasmm 60 1 0.919 4701.47 -DREPS=1 -msse3 -O2 -ffast-math -ftree-vectorize -fno-tree-reassoc -fschedule-insns -fsched-pressure atlasmm 60 1 0.911 4742.77
[Bug rtl-optimization/55273] [4.8 Regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:36:53 UTC --- Author: jakub Date: Thu Jan 17 16:36:43 2013 New Revision: 195275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195275 Log: PR tree-optimizatoin/55273 * gcc.c-torture/compile/pr55273.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr55273.c - copied unchanged from r195274, trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Removed: trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55273] [4.8 Regression] ICE in iv_number_of_iterations, at loop-iv.c:2819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55273 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:38:28 UTC --- Author: hubicka Date: Thu Jan 17 16:27:23 2013 New Revision: 195274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195274 Log: PR tree-optimizatoin/51083 * gcc.c-torture/compile/pr51083.c: New testcase. * loop-iv.c (iv_number_of_iterations): Consider zero iteration case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr51083.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:40:48 UTC --- (In reply to comment #7) There are already R_386_SIZE32 38 word32 Z + A R_X86_64_SIZE32 32 word32 Z + A R_X86_64_SIZE64 33 word64 Z + A Their support has been checked into glibc and binutils. Can address sanitizer use them?
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-17 16:43:46 UTC --- (In reply to comment #8) Their support has been checked into glibc and binutils. Can address sanitizer use them? What about all the other targets that asan now supports?
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:48:53 UTC --- (In reply to comment #9) (In reply to comment #8) Their support has been checked into glibc and binutils. Can address sanitizer use them? What about all the other targets that asan now supports? Those targets won't support common symbols until they implement size relocation.
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 16:49:58 UTC --- Ugh, no, that is way too premature. This really shouldn't be a dynamic relocation. And asan shouldn't be registering the same (common or in the end non-common) var multiple times from different shared libraries or binaries. For this we should have a way to refer using non-dynamic relocation to the common symbol (like R_*_32 or R_*_64, but resolved to the local copy of the symbol, not global one; or can we have .hidden aliases to common symbols?), and this size relocation should be also resolved at link time.
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2013-01-17 16:57:29 UTC --- Size relocation means that all instances of # __beg: .quadcommon_data # __size: .quadcommon_data@size # __size_with_redzone: .quadcommon_data@size + 40 resolve to the same address and size at link-time or run-time. Can we take advantage of it?
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #178 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-17 17:11:13 UTC --- The global cache with arbitrary large size reduces usage down to 0.3% (16908304) bytes. So it seems that sharing across files is quite an important part of the game. I will try to fiddle with the cache size to see how big cache is actually needed. Unpatches mainline needs 1073872920 bytes, that is the same as with dropping columns and/or my initial local caching implementation. This is apparently because of the exponential resizing of the table (i.e. we simply do not save enough to see a difference). Honza
[Bug libstdc++/56016] mutlithreading problem with iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016 --- Comment #2 from JxP bugs at justexpired dot e4ward.com 2013-01-17 17:24:52 UTC --- Created attachment 29195 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29195 sample program not mixing iostream with stdio I confirm that using ios_base::sync_with_stdio(false) makes the original program run correctly (use argument 3 for that). However, I would expect that after commenting out all fprintf(stderr) lines, the program should work correctly even without that extra command (still use argument 2 for that), because then it doesn't explicitly use any stdio routines. But it doesn't. To see it fail now that we don't trace steps on stderr, follow the steps in the original post, use argument 2, then at the end type jobs to see the first cat still running. Why would the user be expected to ask iostream not to sync with stdio, if stdio isn't used?!
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org
|gnu.org |
--- Comment #10 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17
17:35:44 UTC ---
This looks like a problem totally unrelated to libitm and friends. The ICE
happens because dyld_stub___cxa_allocate_exception() is returning 0, which then
gets dereferenced. For that matter, it happens on a plain C++ program
compiling and linking the way dejagnu is setting things up:
Yanory-Hernandezs-MacBook:testsuite aldyh$ cat a.C
static void f1(){
throw 1;
}
int main()
{
try {
f1();
} catch (...) {
}
}
Yanory-Hernandezs-MacBook:testsuite aldyh$ /Users/aldyh/bld/1/gcc/xgcc
-B/Users/aldyh/bld/1/gcc/ a.C
-B/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm
-I/mnt/gcc/libitm/testsuite/.. -shared-libgcc -fmessage-length=0 -fgnu-tm
-nostdinc++
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libstdc++-v3/include
-I/mnt/gcc/libstdc++-v3/libsupc++ -I/mnt/gcc/libstdc++-v3/include/backward
-I/mnt/gcc/libstdc++-v3/testsuite/util
-L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/.libs
-L/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/./libitm/../libstdc++-v3/src/.libs
-shared-libgcc -lstdc++ -lm -g -o ./a.out
Yanory-Hernandezs-MacBook:testsuite aldyh$ ./a.out
Segmentation fault
(gdb) b f1
Breakpoint 1 at 0x10890: file a.C, line 2.
(gdb) disp/i $pc
(gdb) r
Starting program:
/Users/aldyh/bld/1/x86_64-apple-darwin10.8.0/libitm/testsuite/a.out
Reading symbols for shared libraries . done
Breakpoint 1, 0x00010890 in f1 () at a.C:2
2throw 1;
1: x/i $pc 0x10890 f1+4:mov$0x4,%edi
(gdb) si
0x000108952throw 1;
1: x/i $pc 0x10895 f1+9:callq 0x109ae
dyld_stub___cxa_allocate_exception
(gdb)
0x000109ae in dyld_stub___cxa_allocate_exception ()
1: x/i $pc 0x109ae dyld_stub___cxa_allocate_exception:jmpq
*0x68c(%rip)# 0x11040
(gdb)
0x000108e0 in __cxa_allocate_exception ()
1: x/i $pc 0x108e0 __cxa_allocate_exception:xor%eax,%eax
(gdb)
0x000108e2 in __cxa_allocate_exception ()
1: x/i $pc 0x108e2 __cxa_allocate_exception+2:retq
(gdb)
0x0001089a in f1 () at a.C:2
2throw 1;
1: x/i $pc 0x1089a f1+14:movl $0x1,(%rax)
(gdb)
Investigating whether this __cxa_allocation_exception() is coming from
trunk/libstdc++-v3 or from the system libstdc++...
[Bug libstdc++/56016] mutlithreading problem with iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016 --- Comment #3 from JxP bugs at justexpired dot e4ward.com 2013-01-17 17:45:24 UTC --- Created attachment 29196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29196 sample program using iostream onlywith stdio
[Bug sanitizer/55739] asan doesn't work on common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55739 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 17:48:18 UTC --- No idea why you keep mentioning .quadcommon_data .quadcommon_data@size .quadcommon_data@size + 40 That is nothing even close to what asan needs. Asan for what is normally emitted e.g. as: .comm common_data,15,4 needs to emit .comm common_data,64,32 instead, and then a hidden alias to common_data (currently not allowed by as) or some new relocations which will result in the address of the common_data copy in current executable resp. shared library, followed by 15 (the size of the real common_data), followed by common_data@size (which will be either 15 or 64, depending on how large is common_data actually allocated). This still relies on the the linker always choosing the highest alignment from all the alignments of the same var (because libasan relies that all such variables are at least 32 bytes aligned), and if merging of common vars in whatever order always results in highest size being picked, then we even don't need any of this @size stuff at all. The problem is that if you link say a shared library or executable where you have some -fsanitize=address compiled common vars and then some non-sanitized object with the var initialized (i.e. non-common), then the non-common var wins, but a) doesn't get appropriately aligned (so, impossible to be passed to asan register function), and b) not appropriately sized. Consider: 1.c: asm (.globl foo; .comm foo,4,4;); 2.c: asm (.globl foo; .comm foo,64,32;); 3.c: asm (.globl foo; .comm foo,4,4;); 4.c: int foo = 6; (1.c and 3.c emulate -fno-sanitize=address common var, 4.c non-sanitized non-common var, 2.c sanitized common var). Now, gcc -shared -fpic -o test.so 1.c 2.c 3.c seems to DTRT, foo is 32-byte aligned and 64-bytes long, so we could register it as foo's hidden alias, 4, 64. But if you gcc -shared -fpic -o test.so 1.c 2.c 3.c 4.c you get: /usr/bin/ld: Warning: alignment 4 of symbol `foo' in /tmp/ccoadfJM.o is smaller than 32 in /tmp/cc8Dhbe7.o /usr/bin/ld: Warning: size of symbol `foo' changed from 64 in /tmp/cc8Dhbe7.o to 4 in /tmp/ccoadfJM.o No @size stuff helps with this.
[Bug libstdc++/56016] mutlithreading problem with iostream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56016 --- Comment #4 from JxP bugs at justexpired dot e4ward.com 2013-01-17 17:51:53 UTC --- Comment on attachment 29196 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29196 sample program using iostream only This last one doesn't even include cstdio or unistd.h. Still, ios_base::sync_with_stdio makes the difference between working correctly or not.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||echristo at gcc dot ||gnu.org, stanshebs at ||earthlink dot net --- Comment #11 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17 18:24:40 UTC --- Do any of the Darwin maintainers (or anyone else) know how to proceed from here? For some reason, while running the testsuite for libitm (as shown in comment#10), the stub for __cxa_allocate_exception is just a return 0. Even a simple C++ program doing a throw, calls this invalid stub. Is dejagnu building executables incorrectly in libitm? Or is there something else going on?
[Bug libffi/56000] FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56000 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-17 18:27:47 UTC --- Should be fixed now.
[Bug middle-end/42371] dead code not eliminated during folding with whole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371 --- Comment #13 from Matt Hargett matt at use dot net 2013-01-17 18:28:18 UTC --- No. 4.6 doesn't devirt (at -O2 or -O3) and therefore the DCE isn't relevant. At both -O2 and -O3, with and without -fwhole-program, both with and without adjustin declarations one()/two() to one(void)/two(void): 4.7 and google/4.7 both devirt correctly but the DCE on the function bodies doesn't happen. 4.8 also devirts correctly, but the DCE on the function bodies doesn't happen.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-17
18:43:45 UTC ---
BTW, the reason this works when forcing the instrumented path as Torvald
suggested (comment #7) is because when f1() is instrumented, the call to
__cxa_allocate_exception is also instrumented and we actually call:
dyld_stub__ITM_cxa_allocate_exception() - _ITM_cxa_allocate_exception, which
is defined in libitm/eh_cpp.cc:
void *
_ITM_cxa_allocate_exception (size_t size)
{
void *r = __cxa_allocate_exception (size);
gtm_thr()-cxa_unthrown = r;
return r;
}
Assembly single stepping through the above shows that the call to
__cxa_allocate_exception (through dyld_stub___cxa_allocate_exception) has a
correct stub, not this return 0 nonsense I describe in comment #10.
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-17 19:20:27 UTC --- Author: mpolacek Date: Thu Jan 17 19:19:37 2013 New Revision: 195280 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195280 Log: Fix PR55833. Added: trunk/gcc/testsuite/gcc.dg/pr55833.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/loop-unswitch.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-17 19:22:11 UTC --- Fixed.
[Bug rtl-optimization/55833] [4.6 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED | Known to fail|4.8.0 | --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-17 19:44:10 UTC --- Considering backporting to 4.6.
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 --- Comment #3 from npl at chello dot at 2013-01-17 20:43:35 UTC --- great, response looks already more promising than my other gcc patches/requests. Any chance this will find its way into 4.7.3?
[Bug sanitizer/55679] new asan tests from r194458 fail on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55679 --- Comment #19 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-01-17 21:29:01 UTC --- Author: mrs Date: Thu Jan 17 21:28:56 2013 New Revision: 195281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195281 Log: PR sanitizer/55679 * g++.dg/asan/interception-test-1.C: Skip on darwin. * lib/target-supports.exp (check_effective_target_swapcontext): Use check_no_compiler_messages to test support in ucontext.h. (check_effective_target_setrlimit): Return 0 for Darwin's non-posix compliant RLIMIT_AS. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/asan/interception-test-1.C trunk/gcc/testsuite/lib/target-supports.exp
[Bug rtl-optimization/56023] New: [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023
Bug #: 56023
Summary: [4.6 Regression]: [alpha] -fcompare-debug failure due
to sched1 pass
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Host: x86_64-linux-gnu
Target: alpha-linux-gnu
Following compare-debug failure breaks bootstrap on alpha-linux-gnu on 4.6:
--cut here--
void
foo (char *c)
{
unsigned int x = 0;
unsigned int i;
for (i = 0; c[i]; i++)
{
if (i = 5 x != 1)
break;
else if (c[i] == ' ')
x = i;
else if (c[i] == '/' c[i + 1] != ' ' i)
x = i + 1;
}
}
--cut here--
The compare-debug failure can be reproduced on a cross to alpha-linux-gnu:
~/gcc-build-alpha/gcc/xgcc -B ~/gcc-build-alpha/gcc -O2 -fcompare-debug -S t.c
xgcc: error: t.c: -fcompare-debug failure
~/gcc-build-alpha/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/home/uros/gcc-build-alpha/gcc/xgcc
Target: alpha-linux-gnu
Configured with: ../gcc-svn/branches/gcc-4_6-branch/configure
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.6.4 20130117 (prerelease) [gcc-4_6-branch revision 195276] (GCC)
The resulting assembly differs in:
--with g--
$L8:
$LM8:
cmpeq $5,1,$5 # 30*setcc_internal[length = 4]
cmpult $8,$2,$2 # 35*setcc_internal[length = 4]
cmpeq $5,0,$5 # 31*setcc_internal[length = 4]
(*)addl $3,1,$3 # 43*addsi_se/1[length = 4]
and $5,$2,$2 # 39anddi3/1[length = 4]
cpys $f31,$f31,$f31 # 171fnop[length = 4]
(**)addl $4,1,$4 # 41*addsi_se/1[length = 4]
bne $2,$L1 # 44*bcc_normal[length = 4]
$L9:
--/with g--
--without g--
$L8:
cmpeq $5,1,$5 # 26*setcc_internal[length = 4]
cmpult $8,$2,$2 # 31*setcc_internal[length = 4]
cmpeq $5,0,$5 # 27*setcc_internal[length = 4]
(**)addl $4,1,$4 # 37*addsi_se/1[length = 4]
and $5,$2,$2 # 35anddi3/1[length = 4]
cpys $f31,$f31,$f31 # 143fnop[length = 4]
(*)addl $3,1,$3 # 39*addsi_se/1[length = 4]
bne $2,$L1 # 40*bcc_normal[length = 4]
$L9:
--/without g--
Insns (*) and (**) switched places when compiled w/ or w/o -g.
The problem is in sched1 pass, where the first difference occurs, and adding
-fno-schedule-insns to compile flags avoids the failure.
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2013-01-17 22:08:50 UTC --- Created attachment 29197 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29197 Preprocessed source of the file that miscompares during bootstrap This is the preprocessed source of the file that miscompares during bootstrap. ~/gcc-build-alpha/gcc/xgcc -B ~/gcc-build-alpha/gcc -O2 -fcompare-debug -S opts.i xgcc: error: opts.i: -fcompare-debug failure
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=451680 Target Milestone|--- |4.6.4
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 Eric Christopher echristo at gmail dot com changed: What|Removed |Added CC||echristo at gmail dot com --- Comment #13 from Eric Christopher echristo at gmail dot com 2013-01-17 22:17:16 UTC --- You can use DYLD_PRINT_BINDINGS to find out which __cxa_allocate_exception call is being used, it'll also give you the addresses so you can make sure that the right one is being called as you step through.
[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56010 Peter Bergner bergner at vnet dot ibm.com changed: What|Removed |Added CC||bergner at vnet dot ibm.com --- Comment #2 from Peter Bergner bergner at vnet dot ibm.com 2013-01-17 22:27:34 UTC --- Jakub Jelinek wrote: There are other minor differences, e.g. kernel has ppc440 and ppc440gp, while gcc 440fp and 440 (do they match in this order, or differently?). Ick, If you look at kernel/cputable.c, it seems some of the ppc440 cpus have the PPC_FEATURE_HAS_FPU feature bit set, while some don't, so we can't really rely on the AT_PLATFORM value alone for the ppc440 cpus, we'll also have to look at the HWCAP to see whether we should use 440 or 440fp.
[Bug c++/55742] [4.8 regression] __attribute__ in class function declaration cause prototype does not match errors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #30 from davidxl xinliangli at gmail dot com 2013-01-17 22:45:22 UTC --- (In reply to comment #26) On Wed, Jan 16, 2013 at 5:02 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16 16:02:35 UTC --- The actual merging of target attribute isn't that important, what would be more important is that other attributes are merged together in that case and the decls treated as the same thing. Anyway, with target(any) attribute, what would happen for void foo () __attribute__((target (avx))); void foo () __attribute__((target (any))); IMHO the re-declaration with a different target attribute should be an error. This can be a clean way to handle declarations. The definition should have either 'default' attribute or a matching target attribute. A proper forward declaration for a function with MV applied shouldn't have any target attribute. What does this sentence mean? David
[Bug target/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 --- Comment #12 from uros at gcc dot gnu.org 2013-01-17 22:51:07 UTC --- Author: uros Date: Thu Jan 17 22:51:00 2013 New Revision: 195283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195283 Log: Backport from mainline 2012-01-17 Uros Bizjak ubiz...@gmail.com PR target/55981 * config/i386/sync.md (atomic_storemode): Generate SWImode store through atomic_storemode_1. (atomic_storemode_1): Macroize insn using SWI mode iterator. testsuite/ChangeLog: Backport from mainline 2012-01-17 Uros Bizjak ubiz...@gmail.com PR target/55981 * gcc.target/pr55981.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.target/pr55981.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/i386/sync.md branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-01/msg00870.htm ||l Resolution||FIXED --- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2013-01-17 22:53:58 UTC --- Fixed.
[Bug rtl-optimization/56023] [4.6 Regression]: [alpha] -fcompare-debug failure due to sched1 pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56023 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-17 CC||aoliva at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2013-01-17 23:00:38 UTC --- Confirm bug and add CC.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-01-17 23:20:26 UTC --- Created attachment 29198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29198 standalone test case Here's a standalone test case, extracted from gmp's t-get_d.c. It's largish (444 lines) but most of that are support functions needed for the program logic but otherwise unrelated to the wrong-code issue. The wrong-code occurs in check_random() as a side-effect of the inlining of my_ldexp().
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2013-01-17 23:23:47
UTC ---
There are two off-by-one:
diff --git a/libsanitizer/asan/asan_poisoning.cc
b/libsanitizer/asan/asan_poisoning.cc
index a00baff..bbbaf0a 100644
--- a/libsanitizer/asan/asan_poisoning.cc
+++ b/libsanitizer/asan/asan_poisoning.cc
@@ -23,7 +23,7 @@ void PoisonShadow(uptr addr, uptr size, u8 value) {
CHECK(AddrIsAlignedByGranularity(addr));
CHECK(AddrIsAlignedByGranularity(addr + size));
uptr shadow_beg = MemToShadow(addr);
- uptr shadow_end = MemToShadow(addr + size);
+ uptr shadow_end = MemToShadow(addr + size - 1) + 1;
CHECK(REAL(memset) != 0);
REAL(memset)((void*)shadow_beg, value, shadow_end - shadow_beg);
}
diff --git a/libsanitizer/asan/asan_thread.cc
b/libsanitizer/asan/asan_thread.cc
index cc2e777..02f49dd 100644
--- a/libsanitizer/asan/asan_thread.cc
+++ b/libsanitizer/asan/asan_thread.cc
@@ -72,7 +72,7 @@ void AsanThread::Destroy() {
void AsanThread::Init() {
SetThreadStackTopAndBottom();
CHECK(AddrIsInMem(stack_bottom_));
- CHECK(AddrIsInMem(stack_top_));
+ CHECK(AddrIsInMem(stack_top_ - 1));
ClearShadowForThreadStack();
if (flags()-verbosity = 1) {
int local = 0;
[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2013-01-17 23:52:39
UTC ---
Created attachment 29199
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29199
make check-gcc RUNTESTFLAGS='--target_board=unix/-m64 asan.exp'
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 46bb0b4..23c8c7f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27609,7 +27609,7 @@ rs6000_final_prescan_insn (rtx insn, rtx *operand
ATTRIBUTE_UNUSED,
static unsigned HOST_WIDE_INT
rs6000_asan_shadow_offset (void)
{
- return (unsigned HOST_WIDE_INT) 1 (TARGET_64BIT ? 41 : 29);
+ return (unsigned HOST_WIDE_INT) 1 (TARGET_64BIT ? 43 : 29);
}
#endif
diff --git a/libsanitizer/asan/asan_mapping.h
b/libsanitizer/asan/asan_mapping.h
index 54e21b7..6c22709 100644
--- a/libsanitizer/asan/asan_mapping.h
+++ b/libsanitizer/asan/asan_mapping.h
@@ -32,7 +32,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE uptr
__asan_mapping_offset;
# define SHADOW_OFFSET (1 29)
# else
# if defined(__powerpc64__)
-#define SHADOW_OFFSET (1ULL 41)
+#define SHADOW_OFFSET (1ULL 43)
# else
#define SHADOW_OFFSET (1ULL 44)
# endif
@@ -46,7 +46,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE uptr
__asan_mapping_offset;
#if SANITIZER_WORDSIZE == 64
# if defined(__powerpc64__)
- static const uptr kHighMemEnd = 0x0fffUL;
+ static const uptr kHighMemEnd = 0x3fffUL;
# else
static const uptr kHighMemEnd = 0x7fffUL;
# endif
[Bug rtl-optimization/21182] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #6 from Denis Vlasenko vda.linux at googlemail dot com 2013-01-18 00:48:23 UTC --- Created attachment 29200 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29200 Updated testcase, build heper, and results of testing with different gcc versions Tarball contains: serpent.c: the original testcase, only with #ifdef NAIL_REGS instead of #if 0 which allows test compiles w/o editing it. Basically, gcc -DNAIL_REGS serpent.c will try to force gcc to use only registers instead of stack. gencode.sh: builds serpent.c with -O2 and -O3, with and without -DNAIL_REGS. The object file names contain gcc version and used options. Then they are objdump'ed and output saved. Tweakable with setting $PREFIX and/or $CC. No -fomit-frame-pointer used: the testcase can be compiled so that stack is not used even without that option. Disassembly: serpent-O2-3.4.3.asm serpent-O2-4.2.1.asm serpent-O2-4.6.3.asm serpent-O2-DNAIL_REGS-3.4.3.asm serpent-O2-DNAIL_REGS-4.2.1.asm serpent-O2-DNAIL_REGS-4.6.3.asm serpent-O3-3.4.3.asm serpent-O3-4.2.1.asm serpent-O3-4.6.3.asm serpent-O3-DNAIL_REGS-3.4.3.asm serpent-O3-DNAIL_REGS-4.2.1.asm serpent-O3-DNAIL_REGS-4.6.3.asm Object files: textdata bss dec hex filename 3260 0 03260 cbc serpent-O2-DNAIL_REGS-3.4.3.o 3260 0 03260 cbc serpent-O3-DNAIL_REGS-3.4.3.o 3292 0 03292 cdc serpent-O3-3.4.3.o 3536 0 03536 dd0 serpent-O2-4.6.3.o 3536 0 03536 dd0 serpent-O3-4.6.3.o 3845 0 03845 f05 serpent-O2-DNAIL_REGS-4.6.3.o 3845 0 03845 f05 serpent-O3-DNAIL_REGS-4.6.3.o 3877 0 03877 f25 serpent-O2-4.2.1.o 3877 0 03877 f25 serpent-O3-4.2.1.o 4302 0 0430210ce serpent-O2-3.4.3.o 4641 0 046411221 serpent-O2-DNAIL_REGS-4.2.1.o 4641 0 046411221 serpent-O3-DNAIL_REGS-4.2.1.o Take a look inside serpent-O2-DNAIL_REGS-3.4.3.asm file. This is what I want to get without asm hacks: the smallest code, uses no stack. gcc-3.4.3 -O3 comes close: it does spill a few words to stack (search for (%ebp)), but is generally good code (close to ideal?). All other attempts fare worse: gcc-3.4.3 -O2: code is significantly worse than -O3. gcc-4.2.1 -O2/-O3: code is better than gcc-3.4.3 -O2, worse than gcc-4.6.3 gcc-4.6.3 -O2/-O3: six instances of spills to stack . Code is still not as good as gcc-3.4.3 -O3. (-DNAIL_REGS only confuses it more, unlike 3.4.3). Stack usage summary: $ grep 'sub.*,%esp' *.asm | grep -v DNAIL_REGS serpent-O2-3.4.3.asm: 6: 81 ec 00 01 00 00 sub$0x100,%esp serpent-O2-4.2.1.asm: 6: 83 ec 78sub$0x78,%esp serpent-O2-4.6.3.asm: 4: 83 ec 04sub$0x4,%esp serpent-O3-4.2.1.asm: 6: 83 ec 78sub$0x78,%esp serpent-O3-4.6.3.asm: 4: 83 ec 04sub$0x4,%esp (serpent-O3-3.4.3.asm is not listed, but it allocates and uses one word on stack by push insn). Modules with best (= minimal) stack usage: $ grep -F -e '(%esp)' -e '(%ebp)' serpent-O2-DNAIL_REGS-3.4.3.asm 6: 8b 75 08mov0x8(%ebp),%esi 9: 8b 7d 10mov0x10(%ebp),%edi ca9: 8b 75 0cmov0xc(%ebp),%esi $ grep -F -e '(%esp)' -e '(%ebp)' serpent-O3-3.4.3.asm 7: 8b 7d 08mov0x8(%ebp),%edi a: 8b 4d 10mov0x10(%ebp),%ecx 18c: 89 7d f0mov%edi,-0x10(%ebp) 1dd: 8b 45 f0mov-0x10(%ebp),%eax 23b: 8b 75 f0mov-0x10(%ebp),%esi 299: 8b 7d f0mov-0x10(%ebp),%edi 432: 8b 55 f0mov-0x10(%ebp),%edx 4a0: 8b 4d f0mov-0x10(%ebp),%ecx 50e: 8b 7d f0mov-0x10(%ebp),%edi 84f: 8b 45 f0mov-0x10(%ebp),%eax 8b9: 8b 75 f0mov-0x10(%ebp),%esi 923: 8b 7d f0mov-0x10(%ebp),%edi cb6: 8b 55 0cmov0xc(%ebp),%edx $ grep -F -e '(%esp)' -e '(%ebp)' serpent-O3-4.6.3.asm 7: 8b 4c 24 20 mov0x20(%esp),%ecx b: 8b 44 24 18 mov0x18(%esp),%eax 22e: 89 0c 24mov%ecx,(%esp) 239: 23 3c 24and(%esp),%edi 588: 89 0c 24mov%ecx,(%esp) 58f: 23 3c 24and(%esp),%edi 8f4: 89 0c 24mov%ecx,(%esp) 8fd: 23 3c 24and(%esp),%edi c60: 89 0c 24mov%ecx,(%esp) c6b: 23 3c 24and(%esp),%edi d37: 89 14 24mov%edx,(%esp) d5a: 8b 44 24 1c mov0x1c(%esp),%eax
[Bug rtl-optimization/21182] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 Denis Vlasenko vda.linux at googlemail dot com changed: What|Removed |Added CC||vda.linux at googlemail dot ||com --- Comment #7 from Denis Vlasenko vda.linux at googlemail dot com 2013-01-18 00:51:01 UTC --- gcc-4.6.3 got better a bit, still not as good as gcc-4.6.3 -O3. I meant: gcc-4.6.3 got better a bit, still not as good as gcc-3.4.3 -O3 used to be.
[Bug rtl-optimization/21182] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #8 from Denis Vlasenko vda.linux at googlemail dot com 2013-01-18 00:55:37 UTC --- Grrr, another mistake. Correcting again: Conclusion: gcc-3.4.3 -O3 was close to ideal. ^ gcc-4.2.1 is worse. gcc-4.6.3 got better a bit, still not as good as gcc-3.4.3 -O3 used to be. ^
[Bug rtl-optimization/21182] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-18 00:57:00 UTC --- It would be interesting to try the trunk which has a newer register allocator than even 4.6.x/4.7.x.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #6 from Jeffrey A. Law law at redhat dot com 2013-01-18 04:28:01 UTC --- Thanks. The fact that -fno-rename-registers does not affect the result indicates this is a separate code generation issue than the one I'm working on. The reduced testcase should help considerably. Thanks, Jeff
[Bug lto/54933] 'builtin symbol' referenced in section ... defined in discarded section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54933
Joey Ye joey.ye at arm dot com changed:
What|Removed |Added
CC||joey.ye at arm dot com
--- Comment #1 from Joey Ye joey.ye at arm dot com 2013-01-18 06:33:20 UTC ---
This issue especially impacts retarget, where library functions are
retargeted to user implementations. Retarget is a common practice in
bare-metal development but runs into defined in discarded section with LTO
enabled.
Here is the retarget case:
# gcc version 4.8.0 20130115 (experimental) [trunk revision 195189] (GCC)
# GNU ld (GNU Binutils) 2.23.51.20130111
$ cat main.c
int main()
{
return puts(Hello);
}
// it works if following line is enabled
// __attribute__ ((used))
int _write(int c)
{
/* Do something */
return c;
}
$ cat lib-a.c
int puts(const char * str)
{
return _write(*str);
}
$ gcc -flto -c -o lib-a.o lib-a.c
$ ar rv liba.a lib-a.o
r - lib-a.o
$ gcc main.c liba.a -flto --entry=main -nostdlib -o l
`_write' referenced in section `.text' of liba.a(lib-a.o): defined in discarded
section `.text' of /tmp/ccwUUKiA.o (symbol from plugin)
collect2: error: ld returned 1 exit status
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 --- Comment #13 from Jeffrey A. Law law at gcc dot gnu.org 2013-01-18 07:54:52 UTC --- Author: law Date: Fri Jan 18 07:54:47 2013 New Revision: 195288 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195288 Log: PR rtl-optimization/52573 * regrename.c (build_def_use): Ignore REG_DEAD notes if there is a REG_UNUSED for the same register. * gcc.dg/pr52573.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr52573.c Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/52573] [4.6/4.7/4.8 regression] regrename creates overlapping register allocations for output operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52573 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.6.4 |4.8.0 --- Comment #14 from Jeffrey A. Law law at redhat dot com 2013-01-18 07:56:10 UTC --- Fixed on trunk
