[Bug target/27125] optimize array bit shift
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 05:59 --- This is a dup of bug 23813 and many others. This is the standard subreg problem. *** This bug has been marked as a duplicate of 23813 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27125
[Bug rtl-optimization/23813] redundant register assignments not eliminated
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 05:59 --- *** Bug 27125 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ajrobb at bigfoot dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23813
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 06:08 --- I think to fix this one, we need a real pass to remove the promotions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 06:11 --- I am going to try to get this done for 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 06:12 --- I am going to fix up my patch for 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-20 01:00:10 |2006-08-21 06:12:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
[Bug tree-optimization/14442] missed sib if conversion optimization on the tree level (PHI-OPT misses that !(a == 0) is just a != 0)
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-21 06:14 --- I am going try to get this fixed for 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-01-21 02:49:55 |2006-08-21 06:14:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14442
[Bug middle-end/25566] Variable length types and inlining
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 06:15 --- I think the comment can just go away since we are lowering the VL variables before inlining so we get alloca now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally
--- Comment #15 from bonzini at gnu dot org 2006-08-21 06:20 --- Created an attachment (id=12108) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12108action=view) patch that does not touch the middle-end patch that does not touch the common parts of the compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/24647] two copies of a constant in two different registers
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 06:22 --- (In reply to comment #1) on x86-64 I get: That is what I get on x86 also now: f: movli.1523, %eax pushl %ebp movl%esp, %ebp testl %eax, %eax jne .L2 movl$2, i.1523 movb$2, %al .L2: popl%ebp ret But just change == 0 to != 0 and you get the problem still. Also this is a code size issue for -Os as movl with a constant takes up too much space. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||16996 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24647
[Bug c++/27935] gcc fails to compile code with operator delete(void*,size_t)
--- Comment #10 from quanah at stanford dot edu 2006-08-21 06:28 --- MySQL compiles fine with gcc3.3 and gcc3.4, so this is definately a problem in 4.0.3 itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
[Bug c/27675] Compiler crash building PHP component
--- Comment #4 from drnj at redherring dot co dot uk 2006-08-21 09:28 --- Subject: Re: Compiler crash building PHP component Swap space problem in NSLU2 linux based system - not a compiler bug. Appologies for not feeding that back sooner On 21 Aug 2006 05:31:59 -, pinskia at gcc dot gnu dot org gcc- [EMAIL PROTECTED] wrote : --- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 05:31 --- No feedback in 3 months. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added - --- Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27675 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27675
[Bug c++/28787] New: Internal compiler error (ICE) when trying to initialize function in template
The following code snippet crashes GCC 4.1.1 and 4.2.0 20060820 (experimental):
--
templatetypename T
void f(T r)
{
T a = r;
}
void g()
{
f(g);
}
--
Saving the code in a file a.cc and executing c++ -c a.cc produces:
--
a.cc: In function 'void f(T) [with T = void ()()]':
a.cc:9: instantiated from here
a.cc:4: internal compiler error: in digest_init, at cp/typeck2.c:709
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
The above output is produced by GCC 4.1.1. With the mentioned GCC CVS snapshot
the linenumber where the ICE is reported changes to cp/typeck2.c:718.
This bug might be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27807.
GCC 3.4.6 does not ICE, and rejects the code with a diagnostic, which is
correct behaviour as far as I know.
--
Summary: Internal compiler error (ICE) when trying to initialize
function in template
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vlukas at gmx dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
[Bug c++/28787] Internal compiler error (ICE) when trying to initialize function in template
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-21 10:48 --- Indeed a dup of that PR. *** This bug has been marked as a duplicate of 27807 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-invalid-code Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
[Bug c++/27807] [4.1/4.2 regression] ICE on invalid initializer
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-21 10:48 --- *** Bug 28787 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vlukas at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27807
[Bug c++/28787] Internal compiler error (ICE) when trying to initialize function in template
--- Comment #2 from vlukas at gmx dot de 2006-08-21 11:01 --- Indeed a dup of that PR. *** This bug has been marked as a duplicate of 27807 *** I do not mean to sound impertinent, but with GCC 4.2.0 20060820 (experimental), I can not reproduce bug 27807. However the code I submitted still crashes this same version. Doesn't that mean the the fix for 27807 does not at the same time fix this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-08-21 11:26 --- OK, right, I don't have time to fix this. I've looked at the rounding code, and carry propagation, and I think we'd need a new special case to handle that, but couldn't find a way to do it that doesn't break other cases. Jerry, Thomas, could you look into this? I find it has a pretty high annoyance factor, we're outputing wrong numbers. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at verizon dot net Severity|normal |major Last reconfirmed|2006-07-12 15:21:52 |2006-08-21 11:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug fortran/28788] New: [gfortran: 4.1, 4.2 regression] ICE on valid code
Current gfortran (trunk and head of 4.1 branch) segfaults when compiling the following code: module Precision integer, parameter :: dl = KIND(1.d0) end module Precision module ModelParams use precision type CAMBparams real(dl)::omegab,h0,tcmb,yhe end type type (CAMBparams) :: CP contains subroutine CAMBParams_Set(P) type(CAMBparams), intent(in) :: P end subroutine CAMBParams_Set end module ModelParams module TimeSteps use precision use ModelParams end module TimeSteps module ThermoData use TimeSteps contains subroutine inithermo(taumin,taumax) use precision use ModelParams real(dl) taumin,taumax call InitRECFAST(CP%omegab,CP%h0,CP%tcmb,CP%yhe) end subroutine inithermo end module ThermoData [EMAIL PROTECTED]:~/tmp gfortran -v -c modules.F90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --disable-multilib --with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran --enable-checking=release Thread model: posix gcc version 4.2.0 20060821 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN -quiet -v modules.F90 -mtune=generic -o /tmp/ccNsJVqs.f95 ignoring nonexistent directory /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /home/martin/software/ugcc/include /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include /usr/include End of search list. /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 /tmp/ccNsJVqs.f95 -ffree-form -quiet -dumpbase modules.F90 -mtune=generic -auxbase modules -version -fpreprocessed -I /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/cciJjRCJ.s GNU F95 version 4.2.0 20060821 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060821 (experimental). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005 In file modules.F90:33 use ModelParams 1 modules.F90:16: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. This problem was not present a few days ago, and it is quite elusive. Even adding or removing a few !innocent lines can change the error message, e.g. to something like In file modules.F90:43 use ModelParams 1 Error: The derived type 'p' at (1) is of type '', which has not been defined. which makes no sense. -- Summary: [gfortran: 4.1, 4.2 regression] ICE on valid code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de 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=28788
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #21 from martin at mpa-garching dot mpg dot de 2006-08-21 11:58 --- (In reply to comment #20) Fixed on trunk and 4.1 Thanks! The incorrect warnings have gone away. However, if I provoke correct warnings now, the line numbers in the warning messages are really confused, e.g. for the following code: module test contains subroutine dmc_fill_cache (handle1) integer, intent(inout) :: handle1 integer foo end subroutine subroutine dmc_check_consistency (handle2) integer, intent(inout) :: handle2 integer bar call assert_read(handle2) end subroutine end module test [EMAIL PROTECTED]:~/tmp gfortran -c fits_io.F90 -Wunused fits_io.F90: In function dmc_check_consistency: fits_io.F90:4: warning: unused variable bar fits_io.F90: In function dmc_fill_cache: fits_io.F90:14: warning: unused variable handle1 fits_io.F90:14: warning: unused variable foo Should I open a new PR for this? -- martin at mpa-garching dot mpg dot de changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug c++/28787] Internal compiler error (ICE) when trying to initialize function in template
--- Comment #3 from vlukas at gmx dot de 2006-08-21 12:04 ---
A variation of the code crashes GCC 4.2.0 20060820 (experimental) with a
different ICE:
--
templatetypename
void f()
{
typedef void (t)();
t a = x;
}
void g()
{
fint();
}
--
This produces the following output:
--
b.cc: In function 'void f()':
b.cc:5: error: function 'void a()' is initialized like a variable
b.cc:5: error: 'x' was not declared in this scope
b.cc:5: internal compiler error: tree check: expected var_decl, have
function_decl in cp_finish_decl, at cp/decl.c:5089
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
This latter snippet does not crash GCC 3.4.6 or 4.1.1. Should this rather get
its own report?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
[Bug target/28789] New: [4.1 regression] sha512sum miscompiled
$ sha512sum /dev/null 587d521d772a30110a26eda2a81cc763008c8c3d95f5b68abd6a7a66790e0c5a19aec0be2bbabd67680fa6f37ca7ab72b41280e74eeb5f417554c12d3ffeb031 - -- Summary: [4.1 regression] sha512sum miscompiled Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: s390-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
[Bug target/28789] [4.1 regression] sha512sum miscompiled
--- Comment #1 from schwab at suse dot de 2006-08-21 12:33 --- Created an attachment (id=12109) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12109action=view) Testcase $ gcc -O2 sha512.c ; ./a.out ; echo $? 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
[Bug middle-end/25261] [gomp] Nested function calls in #pragma omp parallel blocks
--- Comment #2 from jakub at gcc dot gnu dot org 2006-08-21 12:35 --- It is not that hard to try the testcase. It is still broken. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-21 12:35:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25261
[Bug middle-end/28790] New: ICE in initialize_inlined_parameters
! { dg-do compile }
! { dg-options -O2 -fopenmp }
program nestomp
integer :: j
j = 8
call bar
contains
subroutine foo (i)
integer :: i
!$omp atomic
j = j + 1
end subroutine
subroutine bar
integer :: i
i = 6
!$omp parallel
call foo(i)
!$omp end parallel
end subroutine
end
Guess this is related to 25261, tree-nested.c really needs work for OpenMP.
--
Summary: ICE in initialize_inlined_parameters
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
BugsThisDependsOn: 25261
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28790
[Bug middle-end/24947] -Os should maximize inlining --param values.
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-08-21 12:44 --- Just to note that for simple accestors (optimizing to single move), the compiler should be smart enough to figure out that inlining always reduce code size and inlining those will never hit any of the parameters mentioned. So increasing the parameters is just symptomatic fix and the metric computing profitability of inlining shall be tweaked instead. If max-inline-isnsn-single is hit, compiler really believe that the function body is rather large and inlining cause code growth. GCC at the moment is not terribly smart about discovering the simple wrappers and hopefully will somewhat improve with IPA branch. However if there are really simple testcases where compiler is mistaken, I would be interested to see them. (preferably as small self contained testcases ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24947
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #45 from hubicka at ucw dot cz 2006-08-21 12:56 --- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space Hi, -O2 times: Execution times (seconds) life analysis : 18.08 ( 3%) usr 0.04 ( 1%) sys 19.42 ( 3%) wall 1120 kB ( 0%) ggc integration : 5.97 ( 1%) usr 0.07 ( 2%) sys 6.13 ( 1%) wall 33701 kB ( 8%) ggc tree PRE : 233.01 (43%) usr 0.46 (13%) sys 241.22 (37%) wall 19480 kB ( 5%) ggc tree SSA to normal: 51.26 ( 9%) usr 0.07 ( 2%) sys 52.62 ( 8%) wall 22 kB ( 0%) ggc expand: 2.62 ( 0%) usr 0.07 ( 2%) sys 9.45 ( 1%) wall 24095 kB ( 6%) ggc PRE : 20.39 ( 4%) usr 0.05 ( 1%) sys 21.70 ( 3%) wall 200 kB ( 0%) ggc regmove : 97.32 (18%) usr 0.17 ( 5%) sys 107.36 (16%) wall 2 kB ( 0%) ggc local alloc : 6.28 ( 1%) usr 0.00 ( 0%) sys 6.29 ( 1%) wall 1480 kB ( 0%) ggc global alloc : 13.12 ( 2%) usr 0.71 (21%) sys 62.79 (10%) wall 13764 kB ( 3%) ggc reload CSE regs : 16.16 ( 3%) usr 0.02 ( 1%) sys 19.21 ( 3%) wall 4783 kB ( 1%) ggc scheduling 2 : 60.85 (11%) usr 0.57 (17%) sys 67.94 (10%) wall 206199 kB (51%) ggc TOTAL : 547.14 3.41 651.49 404467 kB Danny has fix for PRE scheduled for 4.2. Regmove hits again the same predicate function sincle we now produce big basic blocks. This can be fixed rather easilly rather by limiting walk in that predicate or assiging INSN consetuctive indexes. Scheduling has problem moving around linked lists of dependencies and fixing it seems to need to go away from log links and thus it is 4.2 issue too. One detail that just came to mind... All memory consumed in scheduling are log links. Producing 206MB of them for 24MB function is rather dense. Can't we prune them out somewhat perhaps by accounting transitivity (at least in special cases)? The instructions are all really mostly independent, but we apparently lose track of the fact somewhere and producing almost complette tournament apparently. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #22 from paulthomas2 at wanadoo dot fr 2006-08-21 13:31 --- Subject: Re: spurious warnings with -W -Wunused martin, Should I open a new PR for this? I have a half memory that there is already a PR for this. Could you check first before submitting a new one, please? Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug bootstrap/28695] Problem compiling Gcc 4.1.1 on a 64 bit linux redhat kernel
--- Comment #3 from ian dot cowan at atkinsglobal dot com 2006-08-21 13:34 --- I also have the same problem with gmake bootstrap, with my opteron based RHEL systems (kernels 2.4.21-20.ELsmp and 2.6.9-11.ELsmp). -- ian dot cowan at atkinsglobal dot com changed: What|Removed |Added CC||ian dot cowan at ||atkinsglobal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28695
[Bug fortran/25818] Problem with handling optional and entry master arguments
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-21 13:35 ---
Jakub and co.,
Does the below do it for you? Instead of passing null, I propose to pass the
address of a longlong containing zero. This then leaves the normal passing of
NULL to possibly represent a missing optional argument. It regtests OK.
I am proposing to pass a reference to a zero for unused arguments so that the
hidden, residual use of them in the master_entry does not cause an ICE.
Otherwise, it doesn't matter how the unused arguments are represented.
Paul
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 116268)
--- gcc/fortran/trans-decl.c(working copy)
*** build_entry_thunks (gfc_namespace * ns)
*** 1561,1566
--- 1561,1568
tree args;
tree string_args;
tree tmp;
+ tree zero;
+ bool zero_flag;
locus old_loc;
/* This should always be a toplevel function. */
*** build_entry_thunks (gfc_namespace * ns)
*** 1580,1585
--- 1582,1590
gfc_start_block (body);
+ zero_flag = false;
+ zero = NULL_TREE;
+
/* Pass extra parameter identifying this entry point. */
tmp = build_int_cst (gfc_array_index_type, el-id);
args = tree_cons (NULL_TREE, tmp, NULL_TREE);
*** build_entry_thunks (gfc_namespace * ns)
*** 1616,1621
--- 1621,1627
if (thunk_formal)
{
/* Pass the argument. */
+ /* TODO - missing optional arguments. */
DECL_ARTIFICIAL (thunk_formal-sym-backend_decl) = 1;
args = tree_cons (NULL_TREE, thunk_formal-sym-backend_decl,
args);
*** build_entry_thunks (gfc_namespace * ns)
*** 1627,1634
}
else
{
! /* Pass NULL for a missing argument. */
! args = tree_cons (NULL_TREE, null_pointer_node, args);
if (formal-sym-ts.type == BT_CHARACTER)
{
tmp = build_int_cst (gfc_charlen_type_node, 0);
--- 1633,1651
}
else
{
! /* Pass the address of a long zero for any argument that
!is not used in this thunk. */
! if (!zero_flag)
! {
! tmp = build_int_cst (intQI_type_node, 0);
! zero = gfc_create_var (intQI_type_node, NULL);
! gfc_add_modify_expr (body, zero, tmp);
! zero = fold_convert (pvoid_type_node,
! build_fold_addr_expr (zero));
! zero_flag = true;
! }
! args = tree_cons (NULL_TREE, zero, args);
!
if (formal-sym-ts.type == BT_CHARACTER)
{
tmp = build_int_cst (gfc_charlen_type_node, 0);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25818
[Bug target/28789] [4.1 regression] sha512sum miscompiled
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 14:14 --- This is most likely a dup of bug 28146 which was not mentioned was a regression and two the patch is inside reload which makes it harder to backport and make sure all the rest of the targets stay working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
[Bug target/28789] [4.1 regression] sha512sum miscompiled
--- Comment #3 from schwab at suse dot de 2006-08-21 14:27 --- *** This bug has been marked as a duplicate of 28146 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
[Bug target/28146] -O2 produces invalid code on s390-linux-gnu: gcc-4.1.2 20060608
--- Comment #9 from schwab at suse dot de 2006-08-21 14:27 --- *** Bug 28789 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||schwab at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
[Bug target/28791] New: sh64-elf -mdiv= options bitrot
The -mdiv=inv:minlat option no longer rearranges the computations;
It appears the combiner pattern falls foul of the combine_validate_cost
check. The assumed cost of the three constituent instructions is 4 each,
while the cost of the combined instruction is assumed to be 16.
sh_rtx_costs needs to be adjusted to make sure that the combination
happens; preferrably give the constituent insns a realistic cost.
-mdiv=inv:call performs the transformation, but the transformed instruction
is not recognized, causing an ICE.
testcase (add -O2 to options):
int
f (int a, int b)
{
return a/b;
}
--
Summary: sh64-elf -mdiv= options bitrot
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, missed-optimization
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
GCC target triplet: sh64-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28791
[Bug c/28792] New: Incorrect i386 code for inlined function with -O2 -mtune=generic
gcc 4.1.1 generates incorrect 386 code with -O2 or -O3 flag for an inlined function if the -mtune cpu-type is one of: generic, i586, i686, pentium2, pentium3, pentium-m. The generated code seems to be correct for the following cpu-types: i386, i486, pentium4 prescott. The problem is also present in gcc version 3.4.4 (cygming special). -- Summary: Incorrect i386 code for inlined function with -O2 - mtune=generic Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chiabaut at nortel dot com GCC host triplet: i386-redhat-linux GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
[Bug c/28792] Incorrect i386 code for inlined function with -O2 -mtune=generic
--- Comment #1 from chiabaut at nortel dot com 2006-08-21 15:16 --- Created an attachment (id=12110) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12110action=view) C source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
[Bug c/28792] Incorrect i386 code for inlined function with -O2 -mtune=generic
--- Comment #2 from chiabaut at nortel dot com 2006-08-21 15:20 --- gcc -v -save-temps -g -Wall -O2 -mtune=generic bug.c Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -E -quiet -v bug.c -mtune=generic -Wall -fworking-directory -O2 -fpch-preprocess -o bug.i ignoring nonexistent directory /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../i386-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/lib/gcc/i386-redhat-linux/4.1.1/include /usr/include End of search list. /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -fpreprocessed bug.i -quiet -dumpbase bug.c -mtune=generic -auxbase bug -g -O2 -Wall -version -o bug.s GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1) (i386-redhat-linux) compiled by GNU C version 4.1.1 20060525 (Red Hat 4.1.1-1). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 7a31534f101210f86e6343d2c0c239f8 as -V -Qy -o bug.o bug.s GNU assembler version 2.16.91.0.6 (i386-redhat-linux) using BFD version 2.16.91.0.6 20060212 /usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crt1.o /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o /usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o -L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1/../../.. bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
[Bug c/21920] alias violating
--- Comment #105 from pinskia at gcc dot gnu dot org 2006-08-21 15:23 --- *** Bug 28792 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||chiabaut at nortel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug target/28792] Incorrect i386 code for inlined function with -O2 -mtune=generic
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 15:23 --- The code violates C aliasing rules: struct pseudoheader ph; csum = my_chksum_tcp((u_int16_t *)ph, (u_int16_t *)pkt, len); . static unsigned short my_chksum_tcp( unsigned short *h, unsigned short * d, int dlen ) cksum = h[0]; *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
[Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-21 16:34 --- A regression hunt on powerpc-linux using the testcase from comment #3 identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=91097 r91097 | kazu | 2004-11-23 17:45:50 + (Tue, 23 Nov 2004) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #23 from martin at mpa-garching dot mpg dot de 2006-08-21 16:59 --- (In reply to comment #22) I have a half memory that there is already a PR for this. Could you check first before submitting a new one, please? If you are referring to PR21918, I think the current behaviour is worse than that, because the locations given are clearly wrong (i.e. in the wrong functions). I didn't find another PR that looks similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug c++/28793] New: Error while deducting template arg
Compiler: gcc 4.0.2 (bug can exist in higher versions)
OS: Red Hat Linux Adv. Server
Code, that generate error:
//=
#include iostream
template typename F
void MainFunction (F f)
{
}
template typename Type
void TestFunc (Type t)
{
}
template typename T1, typename T2
void TestFunc (T1 t1, T2 t2)
{
}
int main ()
{
MainFunction(TestFuncint);
return 1;
}
//=
gcc output:
Incremental build of configuration Debug for project test
make -k all
Building file: ../main.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -omain.o ../main.cpp
../main.cpp: In function int main():
../main.cpp:21: error: no matching function for call to MainFunction(unknown
type)
make: *** [main.o] Error 1
make: Target `all' not remade because of errors.
Build complete for project test
Error is that giving code is correct. Comeau and VS 7.1 compile it without any
problem.
--
Summary: Error while deducting template arg
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: suzev dot kirill at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
--- Comment #46 from hubicka at ucw dot cz 2006-08-21 17:11 --- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space Hi, for completeness the -O3 -fno-tree-pre -fno-tree-fre results (tree-pre/fre needs something little over 2GB of ram to converge) Execution times (seconds) garbage collection: 1.11 ( 1%) usr 0.07 ( 2%) sys 8.57 ( 5%) wall 0 kB ( 0%) ggc life analysis : 5.47 ( 4%) usr 0.12 ( 3%) sys 5.63 ( 3%) wall 2701 kB ( 1%) ggc life info update : 2.05 ( 2%) usr 0.00 ( 0%) sys 2.10 ( 1%) wall 643 kB ( 0%) ggc integration : 8.36 ( 7%) usr 0.18 ( 5%) sys 8.61 ( 5%) wall 79611 kB (27%) ggc tree CFG cleanup : 3.69 ( 3%) usr 0.00 ( 0%) sys 3.77 ( 2%) wall 20 kB ( 0%) ggc tree alias analysis : 2.64 ( 2%) usr 0.25 ( 6%) sys 3.01 ( 2%) wall 0 kB ( 0%) ggc tree SSA rewrite : 2.17 ( 2%) usr 0.02 ( 1%) sys 2.22 ( 1%) wall 21589 kB ( 7%) ggc tree SSA incremental : 4.04 ( 3%) usr 0.01 ( 0%) sys 4.10 ( 2%) wall 1061 kB ( 0%) ggc tree operand scan : 1.54 ( 1%) usr 0.54 (14%) sys 1.95 ( 1%) wall 18382 kB ( 6%) ggc dominator optimization: 2.49 ( 2%) usr 0.06 ( 2%) sys 2.61 ( 1%) wall 11262 kB ( 4%) ggc tree SRA : 3.04 ( 2%) usr 0.08 ( 2%) sys 3.12 ( 2%) wall 25600 kB ( 9%) ggc tree SSA to normal: 38.17 (31%) usr 0.09 ( 2%) sys 38.56 (21%) wall 11214 kB ( 4%) ggc dominance computation : 2.40 ( 2%) usr 0.05 ( 1%) sys 2.52 ( 1%) wall 0 kB ( 0%) ggc expand: 4.22 ( 3%) usr 0.20 ( 5%) sys 11.38 ( 6%) wall 35690 kB (12%) ggc global alloc : 13.43 (11%) usr 1.28 (32%) sys 54.13 (29%) wall 5873 kB ( 2%) ggc flow 2: 0.37 ( 0%) usr 0.01 ( 0%) sys 0.78 ( 0%) wall 5092 kB ( 2%) ggc TOTAL : 123.25 3.98 183.52 291674 kB Note that the testcase is very different at -O3, because min/max functions are inlined breaking gigantic basic blocks into number of small BBs, so many of bottlenecks visible at -O2 go away. I duno what happens in global alloc, tree SSA to normal is the live_on_entry/live_on_exit dicussed. We also have problems with very deep recursion levels as dominator tree is deep. I am thinking about implementing iterators for walking in dom order as the current fully blown domtree walker is bit uneasy in some cases. With FRE/PRE enabled also GGC runs out of stack frame size, because some of temporary values in annotations leaks and instruct GGC to recurse insanely. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
[Bug c++/28793] Error while deducting template arg
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
[Bug c++/28793] Error while deducting template arg
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-21 17:13 --- *** This bug has been marked as a duplicate of 5458 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 17:13 --- *** Bug 28793 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||suzev dot kirill at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug c++/26269] [4.0/4.1/4.2 regression] Declaring a variable too late yields bogus error message
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-21 17:27 --- Subject: Bug 26269 Author: lmillward Date: Mon Aug 21 17:27:48 2006 New Revision: 116301 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116301 Log: PR c++/26269 * decl.c (duplicate_decls): Return early if either newdecl or olddecl is error_mark_node. * g++.dg/other/error14.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/error14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26269
[Bug c++/26269] [4.0/4.1 regression] Declaring a variable too late yields bogus error message
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-08-21 17:28 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression]|[4.0/4.1 regression] |Declaring a variable too|Declaring a variable too |late yields bogus error |late yields bogus error |message |message http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26269
[Bug c++/28505] [4.0/4.1/4.2 regression] ICE with invalid constructors
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-21 17:34 --- Subject: Bug 28505 Author: lmillward Date: Mon Aug 21 17:34:44 2006 New Revision: 116302 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116302 Log: PR c++/28505 * decl.c (grokdeclarator): Return early after issuing diagnostic about an incomplete type. * g++.dg/parse/ctor7.C: New test. * g++.dg/parse/ctor8.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/ctor7.C trunk/gcc/testsuite/g++.dg/parse/ctor8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
[Bug c++/28505] [4.0/4.1 regression] ICE with invalid constructors
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-21 17:36 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with invalid constructors |with invalid constructors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
[Bug bootstrap/24631] SIGBUS during bootstrap
--- Comment #5 from rwcrocombe at raytheon dot com 2006-08-21 17:39 --- Hrm: I considered the problem moot since I was able to get gcc working. Machine is unavailable for further testing at this point, and thankfully my contact with SGI has basically ended. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24631
[Bug c++/28741] [4.2 regression] ICE with static member in invalid template class
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-21 17:41 --- Subject: Bug 28741 Author: lmillward Date: Mon Aug 21 17:41:18 2006 New Revision: 116303 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116303 Log: PR c++/28741 * tree.c (decl_anon_ns_mem_p): Robustify. * decl2.c (determine_visibility): Likewise. * g++.dg/template/void7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/void7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28741
[Bug c++/28741] [4.2 regression] ICE with static member in invalid template class
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-21 17:42 --- Fixed on mainline. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28741
[Bug target/27537] XMM alignment fault when compiling for i386 with -Os
--- Comment #10 from hjl at lucon dot org 2006-08-21 17:42 --- I have a mixed feeling toward this. On one hand, gcc does assume 16byte stack aligment. On the other hand, the original ia32 psABI only calls for 4 byte stack aliment. Requiring 16 byte aligment will make sure the outputs from gcc will be compatible with each other. But it means that the outputs from gcc aren't 100% compatible with the outputs from other compilers, which only enforce 4byte stack aligment following the original ia32 psABI. I guess that it may not be feasible to enforce 4byte stack aligment in gcc without code degradation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
[Bug c++/28787] Internal compiler error (ICE) when trying to initialize function in template
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-21 18:29 --- (In reply to comment #3) A variation of the code crashes GCC 4.2.0 20060820 (experimental) with a different ICE: That is most likely PR 27961. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
[Bug c/28768] [4.0/4.1/4.2 Regression] Preprocessor doesn't parse tokens correctly?
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-21 18:29 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=revrev=66019 r66019 | neil | 2003-04-23 22:44:06 + (Wed, 23 Apr 2003) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28768
[Bug fortran/18111] spurious warnings with -W -Wunused
--- Comment #24 from paulthomas2 at wanadoo dot fr 2006-08-21 20:13 --- Subject: Re: spurious warnings with -W -Wunused martin, --- Comment #23 from martin at mpa-garching dot mpg dot de 2006-08-21 16:59 --- (In reply to comment #22) I have a half memory that there is already a PR for this. Could you check first before submitting a new one, please? If you are referring to PR21918, I think the current behaviour is worse than that, because the locations given are clearly wrong (i.e. in the wrong functions). I didn't find another PR that looks similar. Yes, that's the one. I think that the cause must be the same, even if the symptoms are more severe. File a PR and link it to PR21918, please(since I will almost certainly have to deal with it, I am asking that as a housekeeping favour!). Best regards Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18111
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation with statement expressions and constructors (and ?: )
--- Comment #6 from jason at gcc dot gnu dot org 2006-08-21 20:55 --- Subject: Bug 27115 Author: jason Date: Mon Aug 21 20:54:57 2006 New Revision: 116311 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116311 Log: PR c++/27115 * gimplify.c (voidify_wrapper_expr): Handle STATEMENT_LIST as a wrapper. Loop to handle nested wrappers. (gimplify_bind_expr): Remove temp parameter. (gimplify_modify_expr_rhs): Handle CLEANUP_POINT_EXPR, BIND_EXPR and STATEMENT_LIST on the rhs. (gimplify_statement_list): Voidify the STATEMENT_LIST. (gimplify_expr): Pass pre_p to gimplify_statement_list. (gimplify_target_expr): Remove special BIND_EXPR handling. * cp/semantics.c (finish_stmt_expr_expr): Don't try to voidify here, just leave the expression as it is. (finish_stmt_expr): If the statement-expression has class type, wrap it in a TARGET_EXPR. * cp/cp-gimplify.c (cp_gimplify_init_expr): Don't bother with CLEANUP_POINT_EXPR. * cp/except.c (build_throw): Give the CLEANUP_POINT_EXPR void type. Added: trunk/gcc/testsuite/g++.dg/abi/forced-sticky.C trunk/gcc/testsuite/g++.dg/abi/forced.C trunk/gcc/testsuite/g++.dg/ext/stmtexpr8.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/except.c trunk/gcc/cp/semantics.c trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-21 21:20 --- A regression hunt on powerpc-linux identified this patch, which is a merge of the pch-branch: http://gcc.gnu.org/viewcvs?view=revrev=61136 r61136 | geoffk | 2003-01-10 02:22:34 + (Fri, 10 Jan 2003) If it would be worthwhile I can do a search on that branch. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||geoffk at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot
--- Comment #8 from jason at redhat dot com 2006-08-21 22:04 ---
Subject: Re: [4.2 regression] ICE (segfault) while compiling
kdelibs 4.0 snapshot
I think this patch fixes the bug, but don't have time to test before
going out for the evening.
Index: decl2.c
===
*** decl2.c (revision 116310)
--- decl2.c (working copy)
*** min_vis_r (tree *tp, int *walk_subtrees,
*** 1547,1553
}
else if (CLASS_TYPE_P (*tp))
{
! if (!TREE_PUBLIC (TYPE_MAIN_DECL (*tp)))
{
*vis_p = VISIBILITY_ANON;
return *tp;
--- 1547,1553
}
else if (CLASS_TYPE_P (*tp))
{
! if (!TREE_PUBLIC (TYPE_NAME (*tp)))
{
*vis_p = VISIBILITY_ANON;
return *tp;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28659
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
--- Comment #5 from geoffk at geoffk dot org 2006-08-21 22:06 --- Subject: Re: [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c On 20/08/2006, at 9:32 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-21 04:32 --- Geoff, Do you have a testcase where you get better debug info from your patch? http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01567.html It took me a while to find it, but here's an example: extern void x(); static void (*f)() = x; However, this patch is clearly not behaving the way I expected. I can reproduce the reported problem on powerpc-darwin when using 'gcc - O -gdwarf-2'. I'll work on a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #36 from tromey at gcc dot gnu dot org 2006-08-21 22:07 --- Subject: Bug 13212 Author: tromey Date: Mon Aug 21 22:07:30 2006 New Revision: 116313 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116313 Log: boehm-gc PR libgcj/13212: * configure.ac: Check for pthread_getattr_np(). Remove GC_PTHREAD_SYM_VERSION detection. * include/gc.h (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New declarations. * pthread_support.c (GC_register_my_thread, GC_unregister_my_thread, GC_get_thread_stack_base): New functions. (GC_delete_thread): Don't try to free the first_thread. * misc.c (GC_init_inner): Use GC_get_thread_stack_base() if possible. (pthread_create_, constr): Removed. (pthread_create): Don't rename. * include/gc_ext_config.h.in: Rebuilt. * include/gc_pthread_redirects.h (pthread_create): Define unconditionally. * include/gc_config.h.in: Rebuilt. * configure: Rebuilt. libjava * java/lang/natThread.cc (_Jv_AttachCurrentThread): Attach thread to GC. (_Jv_DetachCurrentThread): Detach thread from GC. * include/boehm-gc.h (_Jv_GCAttachThread, _Jv_GCDetachThread): Declare. * boehm.cc (_Jv_GCAttachThread): New function. (_Jv_GCDetachThread): Likewise. Modified: trunk/boehm-gc/ChangeLog trunk/boehm-gc/configure trunk/boehm-gc/configure.ac trunk/boehm-gc/include/gc.h trunk/boehm-gc/include/gc_config.h.in trunk/boehm-gc/include/gc_ext_config.h.in trunk/boehm-gc/include/gc_pthread_redirects.h trunk/boehm-gc/misc.c trunk/boehm-gc/pthread_support.c trunk/libjava/ChangeLog trunk/libjava/boehm.cc trunk/libjava/include/boehm-gc.h trunk/libjava/java/lang/natThread.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
-- geoffk at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-11 19:30:06 |2006-08-21 22:08:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
--- Comment #37 from tromey at gcc dot gnu dot org 2006-08-21 22:09 --- I've checked in the patch which enables explicit thread registration. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212
[Bug java/28775] gcj-dbtool fails to work on x86_64: NoSuchAlgorithmException: MD5
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-21 22:19 --- This looks related to PR 27890. FWIW I thought we no longer needed a .security file to be installed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28775
[Bug libgcj/27890] [4.2 regression] lib/logging.properties pollutes common namespace
--- Comment #10 from tromey at gcc dot gnu dot org 2006-08-21 22:19 --- See also PR 28775 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #8 from wintermute2k4 at ntlworld dot com 2006-08-21 22:35 --- Created an attachment (id=12111) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12111action=view) patch to prevent searching of configured path with relocated toolchain The attached patch against gcc 4.1.1 fixes this issue for me. tested on Debian Sarge and Win2kPro. 2006-08-21 Dave Murphy [EMAIL PROTECTED] *gcc/gcc.c move export of GCC_EXEC_PREFIX to set_std_prefix in prefix.c use relocated path to find standard_exec_prefix/just_machine_suffix/specs *gcc/prefix.c use configured path to check if path needs relocated export set_std_prefix path to GCC_EXEC_PREFIX *gcc/toplev.c set std_prefix with path from GCC_EXEC_PREFIX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug driver/28528] [4.0/4.1/4.2 regression] Trouble compiling header files with -x c++ using g++
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-08-21 23:22 --- The same thing happens if you use 'file.i' rather than 'file.h': it gets treated as preprocessed rather than C++ source: $ ./g++ -B./ -c -x c++ file.i -### Reading specs from ./specs Target: i386-apple-darwin9.0.0d2 Configured with: /Volumes/Data/co/gcc-trunk/configure Thread model: posix gcc version 4.2.0 20060818 (experimental) ./cc1plus -fpreprocessed file.i -fPIC -quiet -dumpbase file.i -mtune=i386 -auxbase file -o /var/tmp//ccztNIJB.s ./as -arch i386 -force_cpusubtype_ALL -o file.o /var/tmp//ccztNIJB.s If someone has a built FSF 3.3 around, it would be good if they could check whether this behaviour persists there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug tree-optimization/28794] New: missed optimization with non COND_EXPR and vrp and comparisions
int f(int x, int y)
{
int t;
for (t = 0; t 50; t++)
g(t0);
}
void f1(int x, int y)
{
int t;
for (t = 0; t 50; t++)
g(t!=0);
}
--
The above two functions should produce the same code with f1 being better than
f.
If we change it to:
void f2(int x, int y)
{
int t;
for (t = 0; t 50; t++)
{
int tt;
if (t0)
tt = 1;
else
tt = 0;
g(tt);
}
}
-
We get f1 so we are only folding comparisions in a COND_EXPR which is wrong, we
should also be doing them in MODIFY_EXPRs too.
--
Summary: missed optimization with non COND_EXPR and vrp and
comparisions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28794
[Bug driver/28528] [4.0/4.1/4.2 Regression] C language extensions override -x in C++ driver
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-21 23:27 --- (In reply to comment #6) If someone has a built FSF 3.3 around, it would be good if they could check whether this behaviour persists there. That does not change the fact this is an user visiable regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||3.3.3 Summary|C language extensions |[4.0/4.1/4.2 Regression] C |override -x in C++ driver |language extensions override ||-x in C++ driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug tree-optimization/28794] missed optimization with non COND_EXPR and vrp and comparisions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-21 23:31 --- I found this while trying to figure out how to get VRP to optimize: a_1 != 0 into a_1 if the range of a_1 is [0,1] (well with a NOP_EXPR). If I do it inside simplify_cond_using_ranges, I miss all the MODIFY_EXPRs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28794
[Bug driver/28528] [4.0/4.1/4.2 Regression] C language extensions override -x in C++ driver
--- Comment #8 from janis at gcc dot gnu dot org 2006-08-21 23:34 --- In response to Geoff's request in comment #6: elm3b11% /home/janis/tools/gcc-3.3.5-ppc32/bin/g++ -B./ -c -x c++ 28528.i -### Reading specs from /home/janis/tools/gcc-3.3.5-ppc32/lib/gcc-lib/powerpc-linux/3.3.5/specs Configured with: /home/janis/src/gcc-3.3.5/configure --prefix=/home/janis/tools/gcc-3.3.5-ppc32 --build=powerpc-linux --host=powerpc-linux --target=powerpc-linux --disable-checking --enable-languages=c,c++ Thread model: posix gcc version 3.3.5 /home/janis/tools/gcc-3.3.5-ppc32/lib/gcc-lib/powerpc-linux/3.3.5/cc1plus -fpreprocessed 28528.i -quiet -dumpbase 28528.i -auxbase 28528 -o /tmp/ccFEm6oC.s as -mppc -Qy -o 28528.o /tmp/ccFEm6oC.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #17 from jconner at apple dot com 2006-08-21 23:43 --- I can reduce the stack size in this example to ~13k by not invoking mark_temp_addr_taken from expand_call (calls.c). This allows compiler-generated temps used to store return values to share stack slots, even when the function calls are in the same scope. The validity of this change is supported by testing against i386-Linux and ppc-Darwin on 4.1 and mainline with no regressions, but the original importer of this code has some concerns that this might introduce subtle problems. See discussion here: http://gcc.gnu.org/ml/gcc/2006-08/msg00389.html -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug tree-optimization/28794] missed optimization with non-COND_EXPR and vrp and comparisions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 23:52 --- For x86, there is no difference in the code gen for f and f1/f2, but for PPC32, there is: for f1/f2: addic %r0,%r31,-1 subfe %r3,%r0,%r31 For f: srawi %r3,%r31,31 subf %r3,%r31,%r3 srwi %r3,%r3,31 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|missed optimization with non|missed optimization with |COND_EXPR and vrp and |non-COND_EXPR and vrp and |comparisions|comparisions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28794
[Bug c/28795] New: __builtin_isunordered() and __builtin_isnan() should behave consistently
I expect this is widespread over the entire GCC family, but at least with
Apple's GCC we have a consistency problem with the meaning of various hacky
math flags in GCC and methods to detect NaN's in GCC:
[ollmia:/tmp] iano% cat main3.c
#include math.h
#include stdio.h
#include stdint.h
int main( void )
{
union
{
int32_t i;
float f;
}u = {-1};
printf( __FINITE_MATH_ONLY__ = %d\n, __FINITE_MATH_ONLY__ );
printf( __builtin_isunordered(%f,%f) = %d\n, u.f, u.f,
__builtin_isunordered(u.f, u.f) );
printf( __builtin_isnan(%f) = %d\n, u.f, __builtin_isnan( u.f) );
printf( (%f != %f) = %d\n, u.f, u.f, u.f != u.f );
return 0;
}
[ollmia:/tmp] iano% gcc main3.c -Wall; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
(nan != nan) = 1
[ollmia:/tmp] iano% gcc main3.c -Wall -ffinite-math-only; ./a.out
__FINITE_MATH_ONLY__ = 1
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 0
(nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -mno-ieee-fp ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
(nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -funsafe-math-optimizations ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 0
__builtin_isnan(nan) = 0
(nan != nan) = 0
Here's my plug: I'm (speaking for) the rare developer who can actually use
these flags responsibly, who has actually verified that NaNs do not occur in my
code. However, to be responsible, I also need to guard my application against
NaNs contained in malicious data sources. So, even though I said that NaNs do
not occur, I still need a way to test for them. This is very hard to do in a
cross platform way on GCC at the moment.
Most GCC engineers that I've spoken to say that because we've thrown the
standard out the window for speed, GCC should set all these tests to 0. The
problem is that GCC doesn't seem to have actually done that. What GCC appears
to have done is remove some but not all of them, presumably because it was
convenient for the compiler to do it that way. This doesn't serve the end user.
If there is a philosophy here, either correct at all costs or speed at all
costs, GCC should pick one and stick to it.
Personally, I favor correct at all costs for the __builtins. If the end user
really wants all isnan(x) to return 0 even if x is NaN (which I guarantee you,
he doesn't) he can just define his own test with x != x.
Since I am personally a math library provider and need my isnan() to work
uniformly all the time, even when the user has a temporary bout with insanity
and turns IEEE-754 conformance off, I favor a __builtin_isnan() that always
works properly. Only then can I pay heed to the GCC advice:
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
GCC provides built-in versions of the ISO C99 floating point comparison
macros that avoid raising exceptions for unordered operands. They have the same
names as the standard macros ( isgreater, isgreaterequal, isless, islessequal,
islessgreater, and isunordered) , with __builtin_ prefixed. We intend for a
library implementor to be able to simply #define each standard macro to its
built-in equivalent.
...with emphasis on the last sentence. I can not do this until you are
actually C99 compliant *all the time*. I have to support well written legacy
applications that expect this macro to work *all the time*.
[ollmia:/tmp] iano% gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic
--program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
--
Summary: __builtin_isunordered() and __builtin_isnan() should
behave consistently
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: iano at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 00:07 --- First -ffinite-math-only results are correct. Second this is fully a target issue. Third the -funsafe-math-optimizations problem is PR 19116. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 00:10 --- If you read the C99 standard and it mentions specificly about the case where NaNs are not supported isnan should always return false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 00:13 --- ...with emphasis on the last sentence. I can not do this until you are actually C99 compliant *all the time*. I have to support well written legacy applications that expect this macro to work *all the time*. For if you read the docs for -ffinite-math-only, it specificially says finite fp is only supported which means it is compliant to the C99 standard. And for the fact -mno-ieee-fp says we don't support IEEE FP for compares which means no NaNs when doing compares: -mieee-fp -mno-ieee-fp Control whether or not the compiler uses IEEE floating point comparisons. These handle correctly the case where the result of a comparison is unordered. so this is invalid and/or a dup bug. So closing as invalid. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #4 from iano at apple dot com 2006-08-22 00:14 --- Pinski, look at the data I presented. You do not actually return 0 for these cases -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-22 00:16 --- (In reply to comment #4) Pinski, look at the data I presented. You do not actually return 0 for these cases Try it on a real processor instead of x86 which does funny stuff in the back-end and does not fully support IEEE math without longer compares. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug c/28796] New: __builtin_nan() and __builtin_unordered() inconsistent
Cloning due to closed minded bug screener:
^^^
ATTN: PINKSI -- read comments attached at bottom
^^^
I expect this is widespread over the entire GCC family, but at least with
Apple's GCC we have a consistency problem with the meaning of various hacky
math flags in GCC and methods to detect NaN's in GCC:
[ollmia:/tmp] iano% cat main3.c
#include math.h
#include stdio.h
#include stdint.h
int main( void )
{
union
{
int32_t i;
float f;
}u = {-1};
printf( __FINITE_MATH_ONLY__ = %d\n, __FINITE_MATH_ONLY__ );
printf( __builtin_isunordered(%f,%f) = %d\n, u.f, u.f,
__builtin_isunordered(u.f, u.f) );
printf( __builtin_isnan(%f) = %d\n, u.f, __builtin_isnan( u.f) );
printf( (%f != %f) = %d\n, u.f, u.f, u.f != u.f );
return 0;
}
[ollmia:/tmp] iano% gcc main3.c -Wall; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
(nan != nan) = 1
[ollmia:/tmp] iano% gcc main3.c -Wall -ffinite-math-only; ./a.out
__FINITE_MATH_ONLY__ = 1
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 0
(nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -mno-ieee-fp ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
(nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -funsafe-math-optimizations ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 0
__builtin_isnan(nan) = 0
(nan != nan) = 0
Here's my plug: I'm (speaking for) the rare developer who can actually use
these flags responsibly, who has actually verified that NaNs do not occur in my
code. However, to be responsible, I also need to guard my application against
NaNs contained in malicious data sources. So, even though I said that NaNs do
not occur, I still need a way to test for them. This is very hard to do in a
cross platform way on GCC at the moment.
Most GCC engineers that I've spoken to say that because we've thrown the
standard out the window for speed, GCC should set all these tests to 0. The
problem is that GCC doesn't seem to have actually done that. What GCC appears
to have done is remove some but not all of them, presumably because it was
convenient for the compiler to do it that way. This doesn't serve the end user.
If there is a philosophy here, either correct at all costs or speed at all
costs, GCC should pick one and stick to it.
Personally, I favor correct at all costs for the __builtins. If the end user
really wants all isnan(x) to return 0 even if x is NaN (which I guarantee you,
he doesn't) he can just define his own test with x != x.
Since I am personally a math library provider and need my isnan() to work
uniformly all the time, even when the user has a temporary bout with insanity
and turns IEEE-754 conformance off, I favor a __builtin_isnan() that always
works properly. Only then can I pay heed to the GCC advice:
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
GCC provides built-in versions of the ISO C99 floating point comparison
macros that avoid raising exceptions for unordered operands. They have the same
names as the standard macros ( isgreater, isgreaterequal, isless, islessequal,
islessgreater, and isunordered) , with __builtin_ prefixed. We intend for a
library implementor to be able to simply #define each standard macro to its
built-in equivalent.
...with emphasis on the last sentence. I can not do this until you are
actually C99 compliant *all the time*. I have to support well written legacy
applications that expect this macro to work *all the time*.
[ollmia:/tmp] iano% gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic
--program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
--- Comment #1 From Andrew Pinski 2006-08-22 00:07 [reply] ---
First -ffinite-math-only results are correct.
Second this is fully a target issue.
Third the -funsafe-math-optimizations problem is PR 19116.
--- Comment #2 From Andrew Pinski 2006-08-22 00:10 [reply] ---
If you read the C99 standard and it mentions specificly about the case where
NaNs are not supported isnan should always return false.
--- Comment #3 From Andrew Pinski 2006-08-22 00:13 [reply] ---
...with emphasis on the last sentence. I can not do this until you are
actually C99 compliant *all the time*. I have to support well written legacy
applications that expect this macro to
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #6 from iano at apple dot com 2006-08-22 00:18 --- Subject: Re: __builtin_isunordered() and __builtin_isnan() should behave consistently On Aug 21, 2006, at 5:16 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-22 00:16 --- (In reply to comment #4) Pinski, look at the data I presented. You do not actually return 0 for these cases Try it on a real processor instead of x86 which does funny stuff in the back-end and does not fully support IEEE math without longer compares. Can I get this reviewed by someone a little less prejudicial, please? Cloned as 28796. Ian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 00:23 --- For: gcc main3.c -Wall -ffinite-math-only -O2; ./a.out I get: __FINITE_MATH_ONLY__ = 1 __builtin_isunordered() = 0 __builtin_isnan() = 0 ( != ) = 0 Note I removed the %f to look at the asm easiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 00:24 --- -mno-ieee-fp is specificially documented as that so that part is not a bug for sure. -funsafe-math-optimizations is already mentioned as a different bug. So only builtin_isunordered without optimizations with -ffinite-math is a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug libfortran/28354] 0.99999 printed as 0. instead of 1. by format(f3.0)
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-22 00:25 --- I will take this on, -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-21 11:26:32 |2006-08-22 00:25:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28354
[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 00:28 --- Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. So really this says allow for them, so really this is still not a bug as you should read the fine manual before complaining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-22 00:31 --- For x86, -ffinite-math-only should turn off IEEE-FP compares which you will get the correct results at -O0 which case this is really the problem mentioned in PR 19116 which is about how unsafe-math-optimizations turn that on when really finite-math-only should turn it on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug c/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #5 from iano at apple dot com 2006-08-22 00:31 --- My first complaint is that the implementation is inconsistent. My second complaint is that the fine manual is wrong headed, leading to hacky math flags that are less useful than they otherwise would be. -- iano at apple dot com changed: What|Removed |Added CC||iano at apple dot com Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22 00:34 --- (In reply to comment #5) My first complaint is that the implementation is inconsistent. It is not inconsistent really. Just the -funsafe-math-optimizations is done incorrectly for x86 (see the other bug which I keep on mentioning over and over again). My second complaint is that the fine manual is wrong headed, leading to hacky math flags that are less useful than they otherwise would be. They are not incorrectly headed. It is correct if you don't use the options which turn off IEEE/C complaincy which is what -ffast-math and friends do. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug target/28795] __builtin_isunordered() and __builtin_isnan() should behave consistently
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-22 00:37 --- I should mention We intend for a library implementor to be able to simply #define each standard macro to its built-in equivalent. is when not using -ffast-math and other options which turn off IEEE/C99 complaincy which is what exactly those options do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
[Bug driver/17621] Add option to have GCC not search $(prefix)
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-08-22 00:37 --- (In reply to comment #8) patch to prevent searching of configured path with relocated toolchain Are you aware of this discussion http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html and this alternative patch, installed in a csl vendor branch http://gcc.gnu.org/ml/gcc-cvs/2006-07/msg00684.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17621
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #7 from iano at apple dot com 2006-08-22 00:39 --- Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent On Aug 21, 2006, at 5:34 PM, pinskia at gcc dot gnu dot org wrote: --- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22 00:34 --- (In reply to comment #5) My first complaint is that the implementation is inconsistent. It is not inconsistent really. Just the -funsafe-math- optimizations is done incorrectly for x86 (see the other bug which I keep on mentioning over and over again). Which part of: __builtin_isunordered(nan,nan) = 1 __builtin_isnan(nan) = 0 is consistent? [ollmia:/tmp] iano% gcc main3.c -Wall -ffinite-math-only; ./a.out -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
Re: [Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
Which part of: __builtin_isunordered(nan,nan) = 1 __builtin_isnan(nan) = 0 is consistent? Did you read what the options do because it seems like you did not and you keep on agruing that it is inconsistent except for the fact this is way these options are done as it just says allows for optimizations and not always assume finite math and ignore NaNs all the time. -- Pinski
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #8 from pinskia at physics dot uc dot edu 2006-08-22 00:42 --- Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent Which part of: __builtin_isunordered(nan,nan) = 1 __builtin_isnan(nan) = 0 is consistent? Did you read what the options do because it seems like you did not and you keep on agruing that it is inconsistent except for the fact this is way these options are done as it just says allows for optimizations and not always assume finite math and ignore NaNs all the time. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #9 from iano at apple dot com 2006-08-22 00:49 --- Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent On Aug 21, 2006, at 5:42 PM, pinskia at physics dot uc dot edu wrote: --- Comment #8 from pinskia at physics dot uc dot edu 2006-08-22 00:42 --- Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent Which part of: __builtin_isunordered(nan,nan) = 1 __builtin_isnan(nan) = 0 is consistent? Did you read what the options do because it seems like you did not and you keep on agruing that it is inconsistent except for the fact this is way these options are done as it just says allows for optimizations and not always assume finite math and ignore NaNs all the time. Yes, I did. All one sentence of it: -ffinite-math-only Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. Do you know what an unordered compare is? Ian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-08-22 01:20 --- It turns out that if you compile this with 'gcc -mcpu=G4 -O -gdwarf-2' on powerpc-darwin, this testcase works fine, but if you do it with '-mcpu=G3', it fails; that is, it fails when V4SFmode is not supported by the target. The testcase does correctly generate a DW_AT_const_value: .byte 0x7 ; uleb128 0x7; (DIE (0xa0) DW_TAG_variable) .ascii Foo\0 ; DW_AT_name .byte 0x1 ; DW_AT_decl_file .byte 0x2 ; DW_AT_decl_line .long 0x72; DW_AT_type .byte 0x10; DW_AT_const_value .long 0x4d6e6b28 ; fp or vector constant word 0 .long 0x0 ; fp or vector constant word 1 .long 0x0 ; fp or vector constant word 2 .long 0x0 ; fp or vector constant word 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28692
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #10 from wilson at specifix dot com 2006-08-22 01:37 --- Subject: Re: New: __builtin_nan() and __builtin_unordered() inconsistent iano at apple dot com wrote: Cloning due to closed minded bug screener: ^^^ ATTN: PINKSI -- read comments attached at bottom ^^^ I tried looking at this, but I don't see any clear bugs here. The fact that NaN compares fail with -funsafe-math-optimizations is curious, but Andrew has already pointed out that this is PR 19116. According to the PR, this seems to be a misfeature of the x86 port. It would help if you were a bit more precise what what bug you are reporting. If you provide a large collection of results, and then claim that they are somehow wrong, without saying what exactly is wrong, then we have to guess what bug you are reporting. Sometimes we guess wrong, and answer the wrong the question. If you give a better bug report, you will get a better answer. The only place where you were clear about a problem is where you claimed that it is inconsistent for -ffinite-math-only to return zero for isnan and 1 for unordered. That however is not a clear bug. -ffinite-math-only says that it assumes that there are no NaNs in the input, and you violated that assumption, so the results you will get are undefined. That is, gcc is allowed to give you any answer here. One can argue that the documentation could be improved to indicate this. One could perhaps also argue that this feature is poorly designed. One can't argue that this is an obvious bug. Similarly for -mno-ieee. With this option, isnan and unordered can return any result for a NaN, as this invokes undefined behaviour. Now, I can see that you have a problem. You want the optimizations afforded by options like -ffinite-math-only, but you still want to be able to test for NaNs in data from untrustworthy sources. That makes sense. Unfortunately, this is a feature that we currently don't support, but one which would be reasonable to add. Hence I think this is really more a feature request than a bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #11 from iano at apple dot com 2006-08-22 01:45 --- About the manual wrongheadedness: The major argument that I have heard from members of the GCC community (here and elsewhere) against isnan() in its various forms correctly detecting NaN when various hacky math flags are turned on, is that the hacky math flags are defined to preclude the presence of NaNs. The argument goes that the user actually asked for the possibility all NaNs to be ignored! This is circular reasoning. The fact of the matter is that GCC defines all the meanings of the flags. You can't claim the user wanted isnan(NaN) to return 0, because you provided him with no opportunity to say otherwise. I contend that given the choice, the user will want isnan(NaN) to correctly detect NaN's even if the rest of the application does not, because when one is walking on a tight rope, it is good to have a safety net in case something goes wrong. You can't deal with NaNs in special case code unless you have a way to find them. What you've given him is a choice between unavoidably wrong results, or poor speed. If you can find a set of flags that would allow the user to do speed enhancing things like assume that make the assumption that x-x is always 0, while at the same time have __builtin_isnan(NaN) still work in the same compilation unit -- we want these things to inline for speed! -- then I will be happy to concede this point. Otherwise, I assert that the overly simple interpretation of these flags currently in practice does not serve the developer's needs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- Comment #12 from iano at apple dot com 2006-08-22 02:05 --- That however is not a clear bug. -ffinite-math-only says that it assumes that there are no NaNs in the input, and you violated that assumption, so the results you will get are undefined. That is, gcc is allowed to give you any answer here. One can argue that the documentation could be improved to indicate this. One could perhaps also argue that this feature is poorly designed. One can't argue that this is an obvious bug. Let's go with your interpretation for a moment here: If -ffinite-math-only says that it assumes that there are no NaNs in the input , then it should not return a result saying that there are NaNs there. I don't think the results here are undefined. I think the results are pretty clear. This is a bug. But, yes, you are mostly right. I want something very feature-ish. I would like you to fix/clarify the design you already have in a direction that works well for users. I would like those builtins (or maybe some other hypothetical future builtins) to function correctly all the time, no matter what. In that regard, I think that the fact that __builtin_isunordered() does the right thing in that particular case is pretty nifty. I just can't depend on it, so it's a useless behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28796
[Bug libstdc++/28797] New: Problems with demangling (__cxa_demangle())
I used a simple program which calls __cxa_demangle function. These mangled names were demangled wrong: _Z1fA37_iPS_ - f(int [37], int (*) [37]), should be: f(int[37], int (*) [37]) _Z1fILi2EEvRAplplT_Li3ELi1E_i - void f2(int () [((2) + (3)) + (1)]), should be: void f2(int () [((2)+(3))+(1)]) _Z1fM1AKiPKS1_ - _Z1fM1AKiPKS1_, should be: f(int const A::*, int const A::* const*) _Z3absILd1c1f1496f8a44219EEvv - void abs(double)[1c1f1496f8a44219](), should be: void abs3.14159e-173() _Z3absILd40092acd9e83e426EEvv - void abs(double)[40092acd9e83e426](), should be: void abs3.1459() _Z3absILe08042191a6cc56a2fe117becEEvv - void abs(long double)[08042191a6cc56a2fe117bec](), should be: void abs1.234e-2345l() _Z3absILe804bfff8000EEvv - void abs(long double)[804bfff8000](), should be: void abs-1l() _Z3absILf4016147bEEvv - void abs(float)[4016147b](), should be: void abs2.345f() _Z3absILfc180EEvv - void abs(float)[c180](), should be: void abs-16f() _Z3fooA30_A_i - foo(int [30][]), should be: foo(int[30][]) _Z9function1PVKiPViPKiPi - function1(int const volatile*, int volatile*, int const*, int*), should be: function1(int volatile const*, int volatile*, int const*, int*) _Z9function2PVKiPViPKiRS_RS1_RS3_ - function2(int const volatile*, int volatile*, int const*, int const volatile, int volatile, int const), should be: function2(int volatile const*, int volatile*, int const*, int volatile const, int volatile, int const) _Z9function4PVKi - function4(int const volatile*), should be: function4(int volatile const*) _Z9function5PVKi - function5(int const volatile*), should be: function5(int volatile const*) _Z9function6PVKiS0_ - function6(int const volatile*, int const volatile*), should be: function6(int volatile const*, int volatile const*) _Z9functionjj - functionj(unsigned int), should be functionj(unsigned) _ZlsRKU3fooU4bart1XS0_ - operator(X bart foo const, X bart), should be: operator(X const foo bart, X const foo bart) _ZN3FooIA4_iE3barE - Fooint [4]::bar, should be: Fooint[4]::bar _Znaj - operator new[](unsigned int), should be: operator new[](unsigned) _ZngILi42EEvN1AIXplT_Li2EEE1TE - void operator-42(A(42) + (2)::T), should be: void operator-42(A(42)+(2)::T) _ZngILi42EEvN1AIXplT_Li2 - void operator-42(A(42) + (2)), should be: void operator-42(A(42)+(2)) _ZNSsC1EPKcRKSaIcE - std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const), should be: std::string::string(char const*, std::allocatorchar const) _Znwj - operator new(unsigned int), should be: operator new(unsigned) _ZTv0_n16_NSoD0Ev - virtual thunk to std::basic_ostreamchar, std::char_traitschar ::~basic_ostream(), should be: virtual thunk to std::ostream::~ostream() These issues you can reproduce on Mac OS, IA32 Linux and EM64T Linux Environment: IA32 and EM64T Linux: Red Hat Enterprise Linux WS release 4 (Nahant Update 3); Release: gcc version 3.4.5 20051201 (Red Hat 3.4.5-2) Environment: Mac OS Release: gcc -v Using built-in specs. Target: i686-apple-darwin8 Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8 Thread model: posix gcc version 4.0.1 (Apple Computer, Inc. build 5341) How-To-Repeat: Feed those mangled names to __cxa_demangle() function and check the results of demangling. This report is very close to Bug#:7986. -- Summary: Problems with demangling (__cxa_demangle()) Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kurkov at gorodok dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
[Bug other/28797] Problems with demangling (__cxa_demangle())
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 05:21 --- _Z1fA37_iPS_ - f(int [37], int (*) [37]), should be: f(int[37], int (*) [37]) Isn't that just a space? _Z1fILi2EEvRAplplT_Li3ELi1E_i - void f2(int () [((2) + (3)) + (1)]), should be: void f2(int () [((2)+(3))+(1)]) Likewise? _Z3fooA30_A_i - foo(int [30][]), should be: foo(int[30][]) Likewise? _Z9function1PVKiPViPKiPi - function1(int const volatile*, int volatile*, int const*, int*), should be: function1(int volatile const*, int volatile*, int const*, int*) The older of the volatile and const does not matter so why is this a problem? _Z9functionjj - functionj(unsigned int), should be functionj(unsigned) unsigned == unsigned int so why is this a problem? _ZTv0_n16_NSoD0Ev - virtual thunk to std::basic_ostreamchar, std::char_traitschar ::~basic_ostream(), should be: virtual thunk to std::ostream::~ostream() no, it is still basic_ostreamchar, std::char_traitschar technicially. And some more space issues. The double ones are weird, maybe we should print out the C99 hex float instead, there is a bug about this before too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
[Bug other/28797] Problems with demangling (__cxa_demangle())
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 05:26 --- (In reply to comment #1) The double ones are weird, maybe we should print out the C99 hex float instead, there is a bug about this before too. See PR 13045, there is most likely more discussion about this. The other issue is that demangling for floats are hard between different targets because of different floating point formats. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
