[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Jan Kratochvil jan.kratochvil at redhat dot com changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com 2012-09-30 07:24:30 UTC --- For example PR 35173 would not be filed and also I would find -Wconversion without Google if there was -Weverything.
[Bug fortran/54758] New: accessing gcc builtins from fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54758 Bug #: 54758 Summary: accessing gcc builtins from fortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch I would like to experiment with prefetching in Fortran code (beyond -fprefetch-loop-arrays). A convenient way to do this would be access the gcc_builtins. I tried this the following way: INTERFACE SUBROUTINE builtin_prefetch(a) BIND(C,name=__builtin_prefetch) USE ISO_C_BINDING, ONLY: C_FLOAT REAL(KIND=C_FLOAT), dimension(*) :: a END SUBROUTINE END INTERFACE real*4 :: data(100) DO i=1,100 CALL builtin_prefetch(data(i)) data(i)=0 ENDDO END but it didn't work... test.f90:(.text+0x36): undefined reference to `__builtin_prefetch' no surprise, I guess, but it would be cool if it did.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 09:44:27 UTC --- Hi, There is an implementation of hypot, so I'm wondering if we can't do better. You mean in the libc? It's possible because as you can see the autoconf test handles all the C99 mathematical functions together and if only one is missing the check fails. Now, really, I don't think we want to go fine grained to the level of the single function, but if for example we figure out that a number of targets has available the entire subset of functions required for random and ext/random we could separate those. My point is that we should try to find patterns, like the long double functions are causing troubles and we can separate those. As I said, for those features - isn't just about math - I would rather not fragment everything down to single function, if possible. Testing suggestion. Great, if it works, let's go with that for now. Then, longer term, if you have ideas about the above, please also feel free to send a message to the library mailing list.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 09:44:27 UTC --- Hi, There is an implementation of hypot, so I'm wondering if we can't do better. You mean in the libc? It's possible because as you can see the autoconf test handles all the C99 mathematical functions together and if only one is missing the check fails. Now, really, I don't think we want to go fine grained to the level of the single function, but if for example we figure out that a number of targets has available the entire subset of functions required for random and ext/random we could separate those. My point is that we should try to find patterns, like the long double functions are causing troubles and we can separate those. As I said, for those features - isn't just about math - I would rather not fragment everything down to single function, if possible. Testing suggestion. Great, if it works, let's go with that for now. Then, longer term, if you have ideas about the above, please also feel free to send a message to the library mailing list.
[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 Splitting reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|m68k-*-*| CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-30 09:52:23 UTC --- And on the SPARC.
[Bug middle-end/54759] New: [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759
Bug #: 54759
Summary: [4.8 regression] segfault for gcc.dg/vect/pr49093.c on
Solaris
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebotca...@gcc.gnu.org
CC: de...@gcc.gnu.org
Host: sparc-sun-solaris2.10
Target: sparc-sun-solaris2.10
Build: sparc-sun-solaris2.10
We have a segfault for gcc.dg/vect/pr49093.c on SPARC/Solaris:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff0ae9b0 in strlen () from /lib/libc.so.1
(gdb) bt
#0 0xff0ae9b0 in strlen () from /lib/libc.so.1
#1 0xff1134d8 in _ndoprnt () from /lib/libc.so.1
#2 0xff1154a0 in fprintf () from /lib/libc.so.1
#3 0x00743778 in vectorize_loops ()
at /nile.build/botcazou/gcc-head/src/gcc/tree-vectorizer.c:198
#4 0x0067739c in tree_vectorize ()
at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-loop.c:215
(gdb) frame 3
#3 0x00743778 in vectorize_loops ()
at /nile.build/botcazou/gcc-head/src/gcc/tree-vectorizer.c:198
198 LOC_FILE (vect_location), LOC_LINE (vect_location));
(gdb) list
193
194 vect_location = find_loop_location (loop);
195 if (vect_location != UNKNOWN_LOC
196 vect_verbosity_level REPORT_NONE)
197 fprintf (vect_dump, \nAnalyzing loop at %s:%d\n,
198 LOC_FILE (vect_location), LOC_LINE (vect_location));
199
200 loop_vinfo = vect_analyze_loop (loop);
201 loop-aux = loop_vinfo;
202
(gdb) p vect_location
$1 = 2147483648
(gdb) call expand_location(vect_location)
$4 = {file = 0x0, line = 0, column = 0, data = 0xfb4a5ad0, sysp = false}
This is reproducible with a bare cross-compiler on x86_64-suse-linux:
gdb --args gcc/cc1 -quiet -O1 -ftree-vectorize -fdump-tree-vect-details
-fno-tree-fre -mcpu=v9 pr49093.c
(gdb) b tree-vectorizer.c:197
Breakpoint 1, vectorize_loops ()
at /home/eric/svn/gcc/gcc/tree-vectorizer.c:198
198 LOC_FILE (vect_location), LOC_LINE (vect_location));
(gdb) call expand_location(vect_location)
$4 = {file = 0x0, line = 0, column = 0, data = 0x768dfaa0, sysp = false}
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Attachment #28188|0 |1
is obsolete||
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-30
10:58:18 UTC ---
Comment on attachment 28188
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28188
Testcase for Bug error: invalid initialization of non-const reference of type
‘std::istream
(In reply to comment #9)
Created attachment 28188 [details]
Testcase for Bug error: invalid initialization of non-const reference of type
‘std::istream
Mysterious compiler error in line 35 of the attached testcase (test1.cpp);
marked there as BUG:
test1.cpp:35:45: error: invalid initialization of non-const reference of type
‘std::istream {aka std::basic_istreamchar}’ from an rvalue of type ‘void*’
That's not mysterious, and is not related to this bug report.
Your code can be reduced to:
struct Base {
operator void*() { return 0; }
};
struct Derived1 : Base { };
struct Derived2 : Base { };
Derived1 d1;
Derived2 d2;
Base b = true ? d1 : d2;
The conditional expression cannot implicitly convert two objects of different
types to a common base class, so instead the conversion operator is used to
convert both types to void*
To force the behaviour you expect use an explicit cast on one operand:
istream si = sfile.is_open() ? (std::istream)sfile : sbuf;
[Bug libstdc++/54577] dequeT::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-30 11:40:11 UTC --- Author: redi Date: Sun Sep 30 11:40:06 2012 New Revision: 191866 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191866 Log: PR libstdc++/54577 * doc/xml/manual/status_cxx2011.xml: N2350 changes are missing from sequence containers. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/api.html trunk/libstdc++-v3/doc/html/faq.html trunk/libstdc++-v3/doc/html/index.html trunk/libstdc++-v3/doc/html/manual/abi.html trunk/libstdc++-v3/doc/html/manual/algorithms.html trunk/libstdc++-v3/doc/html/manual/api.html trunk/libstdc++-v3/doc/html/manual/appendix_contributing.html trunk/libstdc++-v3/doc/html/manual/appendix_free.html trunk/libstdc++-v3/doc/html/manual/appendix_gpl.html trunk/libstdc++-v3/doc/html/manual/appendix_porting.html trunk/libstdc++-v3/doc/html/manual/atomics.html trunk/libstdc++-v3/doc/html/manual/backwards.html trunk/libstdc++-v3/doc/html/manual/bk01pt02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03pr01.html trunk/libstdc++-v3/doc/html/manual/bk01pt04.html trunk/libstdc++-v3/doc/html/manual/concurrency.html trunk/libstdc++-v3/doc/html/manual/configure.html trunk/libstdc++-v3/doc/html/manual/containers.html trunk/libstdc++-v3/doc/html/manual/diagnostics.html trunk/libstdc++-v3/doc/html/manual/documentation_hacking.html trunk/libstdc++-v3/doc/html/manual/extensions.html trunk/libstdc++-v3/doc/html/manual/facets.html trunk/libstdc++-v3/doc/html/manual/index.html trunk/libstdc++-v3/doc/html/manual/intro.html trunk/libstdc++-v3/doc/html/manual/io.html trunk/libstdc++-v3/doc/html/manual/iterators.html trunk/libstdc++-v3/doc/html/manual/localization.html trunk/libstdc++-v3/doc/html/manual/memory.html trunk/libstdc++-v3/doc/html/manual/numerics.html trunk/libstdc++-v3/doc/html/manual/parallel_mode.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_design.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_using.html trunk/libstdc++-v3/doc/html/manual/profile_mode.html trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/html/manual/strings.html trunk/libstdc++-v3/doc/html/manual/support.html trunk/libstdc++-v3/doc/html/manual/test.html trunk/libstdc++-v3/doc/html/manual/using.html trunk/libstdc++-v3/doc/html/manual/using_exceptions.html trunk/libstdc++-v3/doc/html/manual/using_headers.html trunk/libstdc++-v3/doc/html/manual/utilities.html trunk/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #86 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-30 12:30:43 UTC --- (In reply to comment #84) LTO might work for many codes, as using allocatables in derived types was not standard Fortran90 (IIRC) and appears needed to trigger the bug. Anyway, since most people will use released versions of gcc, this checking error will be hidden behind --enable-checking=release. Only very few people will be able to locate and in particular reduce wrong code generation that only happens with LTO, so I wouldn't expect bug reports for actual wrong code generation very quickly. Meanwhile a shorter testcase for 4.8, using gfortran -flto -O0. TYPE t REAL, DIMENSION(:), ALLOCATABLE :: r END TYPE t TYPE t_p TYPE(t), POINTER :: d_t END TYPE t_p REAL, DIMENSION(:), POINTER:: d TYPE(t_p) :: x d=x%d_t%r END
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11
||*-*-darwin*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-30
Host|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11
||*-*-darwin*
Ever Confirmed|0 |1
Build|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11
||*-*-darwin*
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-30
12:35:12 UTC ---
I also see it on *-*-darwin*. I have silenced the failures by replacing
std:hypot with hypot.
I have tested the example from
http://en.cppreference.com/w/cpp/numeric/math/hypot , i.e.,
#include cmath
#include utility
#include iostream
std::pairdouble, double cartesian_to_polar(double x, double y)
{
return {std::hypot(x, y), std::atan2(y,x)};
}
int main()
{
std::pairdouble, double polar = cartesian_to_polar(1, 1);
std::cout (1,1) cartesian is ( polar.first
, polar.second ) polar\n;
}
which fails to compile on darwin with
[macbook] f90/bug% g++48 -std=c++11 polar.cpp
polar.cpp: In function 'std::pairdouble, double cartesian_to_polar(double,
double)':
polar.cpp:7:13: error: 'hypot' is not a member of 'std'
return {std::hypot(x, y), std::atan2(y,x)};
^
polar.cpp:7:13: note: suggested alternative:
In file included from /usr/include/math.h:28:0,
from /opt/gcc/gcc4.8w/include/c++/4.8.0/cmath:46,
from polar.cpp:1:
/usr/include/architecture/i386/math.h:340:15: note: 'hypot'
extern double hypot ( double, double );
^
polar.cpp:7:46: error: could not convert '{expression error, atan2(y, x)}'
from 'brace-enclosed initializer list' to 'std::pairdouble, double'
return {std::hypot(x, y), std::atan2(y,x)};
^
while it compiles if I replace return {std::hypot(x, y), std::atan2(y,x)};
with return {hypot(x, y), std::atan2(y,x)}; . Looking at
include/c++/4.8.0/cmath, I don't understand why std::atan2(y,x) is found, but
not std::hypot(x, y).
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-30 12:36:38 UTC --- Created attachment 28302 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28302 include/c++/4.8.0/cmath for darwin
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-30 Ever Confirmed|0 |1 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-30 12:51:11 UTC --- With the patch in comment #10, gfortran (otherwise clean r191847) miscompiles gfortran.dg/class_array_7.f03. If I replace the if ... abort() with prints, I get a is extended_type tmp is base_type a is extended_type a.out(83666) malloc: *** error for object 0x100200f80: pointer being freed was not allocated or [macbook] f90/bug% valgrind a.out ==96855== Memcheck, a memory error detector ==96855== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==96855== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==96855== Command: a.out ==96855== a is extended_type tmp is base_type ==96855== Invalid read of size 4 ==96855==at 0x11782: __realloc_MOD_assign (class_array_7_db.f90:25) ==96855==by 0x11685: __realloc_MOD_reallocate (class_array_7_db.f90:34) ==96855==by 0x11A61: MAIN__ (class_array_7_db.f90:57) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== Address 0x100442408 is 0 bytes after a block of size 40 alloc'd ==96855==at 0x100013679: malloc (vg_replace_malloc.c:266) ==96855==by 0x11830: MAIN__ (class_array_7_db.f90:54) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== a is extended_type ==96855== Invalid free() / delete / delete[] / realloc() ==96855==at 0x10001352D: free (vg_replace_malloc.c:430) ==96855==by 0x11B9D: MAIN__ (class_array_7_db.f90:60) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== Address 0x1004423e0 is 0 bytes inside a block of size 40 free'd ==96855==at 0x10001352D: free (vg_replace_malloc.c:430) ==96855==by 0x116BB: __realloc_MOD_reallocate (class_array_7_db.f90:35) ==96855==by 0x11A61: MAIN__ (class_array_7_db.f90:57) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== ==96855== ==96855== HEAP SUMMARY: ==96855== in use at exit: 168 bytes in 2 blocks ==96855== total heap usage: 25 allocs, 24 frees, 7,321 bytes allocated ==96855== ==96855== LEAK SUMMARY: ==96855==definitely lost: 80 bytes in 1 blocks ==96855==indirectly lost: 0 bytes in 0 blocks ==96855== possibly lost: 0 bytes in 0 blocks ==96855==still reachable: 0 bytes in 0 blocks ==96855== suppressed: 88 bytes in 1 blocks ==96855== Rerun with --leak-check=full to see details of leaked memory ==96855== ==96855== For counts of detected and suppressed errors, rerun with: -v ==96855== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0) Otherwise the patch works as advertised.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 13:14:25 UTC --- Simply, atan2 is C89, hypot is C99. Confirmed that we don't have to do anything special besides making sure that C99 functions like hypot aren't used when _GLIBCXX_USE_C99_MATH_TR1 is not defined. In particular, we definitely don't want to fiddle with the global namespace, a sure recipe for maintainance nightmare.
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-09-30 13:16:16 UTC --- I don't have a strong opinion on whether numeric levels or Weverything are a good idea or not. However, the issues you mention with -Wextra and -Weffc++ (PR16166) are clear-cut: if you propose a patch fixing them, they will be accepted. There is also the problem that the infrastructure for defining flags that enable other flags is quite rudimentary PR53063. If done properly, the documentation about which warnings enable other warnings could be automatically generated. If you really really want to implement a -Weverything, I would start by submitting a patch that makes -Weverything = -Wall + -Wextra + -Wconversion + a bunch of generally useful warnings not included in -Wall or -Wextra and see what happens. Probably you will need to negotiate the specific list of warnings (or the name of -Weverything, e.g., -Wparanoid) with the maintainers, but I think that it should be possible to find a set of very noisy but sometimes useful warnings. But the key point is that very likely nobody is going to implement any of this for you. Clang introduced the concept of categories for diagnostics, which seems much more interesting to me than numeric levels. But I don't really know what is the consensus about this in GCC.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org 2012-09-30 14:19:20 UTC --- (In reply to comment #5) include/c++/4.8.0/cmath for darwin Dominique, it would be more useful if you could show your libstdc++ config.log, and in particular the error message you got for the test for ISO C99 support to TR1 in math.h, to know what functions are missing on darwin (or hppa or others), assuming there isn't already a PR somewhere about it.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 15:32:09 UTC --- Note that the last time I checked, on Leopard, darwin actually enabled _GLIBCXX_USE_C99_MATH_TR1.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-30 15:33:18 UTC --- (In reply to comment #7) include/c++/4.8.0/cmath for darwin Dominique, it would be more useful if you could show your libstdc++ config.log, and in particular the error message you got for the test for ISO C99 support to TR1 in math.h, to know what functions are missing on darwin (or hppa or others), assuming there isn't already a PR somewhere about it. I see ... configure:18907: checking for ISO C99 support to TR1 in math.h configure:19031: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc ++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86 _64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-includ e-c -g -O2 -std=c++98 conftest.cpp 5 conftest.cpp: In function 'int main()': conftest.cpp:129:15: error: 'llrint' was not declared in this scope llrint(0.0); ^ conftest.cpp:130:17: error: 'llrintf' was not declared in this scope llrintf(0.0f); ^ conftest.cpp:131:17: error: 'llrintl' was not declared in this scope llrintl(0.0l); ^ conftest.cpp:132:16: error: 'llround' was not declared in this scope llround(0.0); ^ conftest.cpp:133:18: error: 'llroundf' was not declared in this scope llroundf(0.0f); ^ conftest.cpp:134:18: error: 'llroundl' was not declared in this scope llroundl(0.0l); ^ configure:19031: $? = 1 configure: failed program was: ... configure:19040: result: no configure:19052: checking for ISO C99 support to TR1 in inttypes.h configure:19072: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-c -g -O2 -std=c++98 conftest.cpp 5 configure:19072: $? = 0 configure:19079: result: yes ... configure:19127: checking stdbool.h usability ... configure:21386: result: no configure:21408: checking for hypot declaration configure:21433: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-c -fno-builtin -D_GNU_SOURCE conftest.cpp 5 configure:21433: $? = 0 configure:21449: result: yes configure:21455: checking for hypot configure:21455: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-o conftest -g -O2 conftest.c -lm 5 conftest.c:134:6: warning: conflicting types for built-in function 'hypot' [enabled by default] char hypot (); ^ configure:21455: $? = 0 configure:21455: result: yes configure:21529: checking for float trig functions ... + the same for hypotf and hypotl. Is it enough or should I attach the full log?
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-30 15:37:29 UTC --- Note that the last time I checked, on Leopard, darwin actually enabled _GLIBCXX_USE_C99_MATH_TR1. Well I may have been too quick to say *-*-darwin*, I am sure of ppc-darwin9 and x64_86-darwin10. Apparently there is no failure for the libstdc++ tests and x64_86-darwin12 (see http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02713.html).
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 15:48:36 UTC --- Just confirmed that Snow Leopard is still Ok. As far as I'm concerned, the current status is good enough.
[Bug testsuite/54148] FAIL: gcc.dg/plugin/selfassign.c compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54148 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-09-30 15:52:35 UTC --- Tests don't fail with full bootstrap. It appears TESTING_IN_BUILD_TREE should not be output to site.exp when full build tree isn't available.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #12 from dave.anglin at bell dot net 2012-09-30 16:06:52 UTC --- On 30-Sep-12, at 10:19 AM, glisse at gcc dot gnu.org wrote: Dominique, it would be more useful if you could show your libstdc++ config.log, and in particular the error message you got for the test for ISO C99 support to TR1 in math.h, to know what functions are missing on darwin (or hppa or others), assuming there isn't already a PR somewhere about it. FWIW, the HP-UX 11.11 list is: configure:18907: checking for ISO C99 support to TR1 in math.h configure:19031: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/ test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/ src/.libs -B/o pt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/ hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/ include -isy stem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include-c -g - O2 -std=c+ +98 conftest.cpp 5 conftest.cpp: In function 'int main()': conftest.cpp:67:16: error: 'acoshf' was not declared in this scope acoshf(0.0f); ^ conftest.cpp:68:16: error: 'acoshl' was not declared in this scope acoshl(0.0l); ^ conftest.cpp:70:16: error: 'asinhf' was not declared in this scope asinhf(0.0f); ^ conftest.cpp:71:16: error: 'asinhl' was not declared in this scope asinhl(0.0l); ^ conftest.cpp:73:16: error: 'atanhf' was not declared in this scope atanhf(0.0f); ^ conftest.cpp:74:16: error: 'atanhl' was not declared in this scope atanhl(0.0l); ^ conftest.cpp:77:15: error: 'cbrtl' was not declared in this scope cbrtl(0.0l); ^ conftest.cpp:80:25: error: 'copysignl' was not declared in this scope copysignl(0.0l, 0.0l); ^ conftest.cpp:82:14: error: 'erff' was not declared in this scope erff(0.0f); ^ conftest.cpp:83:14: error: 'erfl' was not declared in this scope erfl(0.0l); ^ conftest.cpp:85:15: error: 'erfcf' was not declared in this scope erfcf(0.0f); ^ conftest.cpp:86:15: error: 'erfcl' was not declared in this scope erfcl(0.0l); ^ conftest.cpp:88:15: error: 'exp2f' was not declared in this scope exp2f(0.0f); ^ conftest.cpp:89:15: error: 'exp2l' was not declared in this scope exp2l(0.0l); ^ conftest.cpp:91:16: error: 'expm1f' was not declared in this scope expm1f(0.0f); ^ conftest.cpp:92:16: error: 'expm1l' was not declared in this scope expm1l(0.0l); ^ conftest.cpp:94:21: error: 'fdimf' was not declared in this scope fdimf(0.0f, 0.0f); ^ conftest.cpp:95:21: error: 'fdiml' was not declared in this scope fdiml(0.0l, 0.0l); ^ conftest.cpp:96:22: error: 'fma' was not declared in this scope fma(0.0, 0.0, 0.0); ^ conftest.cpp:97:26: error: 'fmaf' was not declared in this scope fmaf(0.0f, 0.0f, 0.0f); ^ conftest.cpp:98:26: error: 'fmal' was not declared in this scope fmal(0.0l, 0.0l, 0.0l); ^ conftest.cpp:100:21: error: 'fmaxf' was not declared in this scope fmaxf(0.0f, 0.0f); ^ conftest.cpp:101:21: error: 'fmaxl' was not declared in this scope fmaxl(0.0l, 0.0l); ^ conftest.cpp:103:21: error: 'fminf' was not declared in this scope fminf(0.0f, 0.0f); ^ conftest.cpp:104:21: error: 'fminl' was not declared in this scope fminl(0.0l, 0.0l); ^ conftest.cpp:106:22: error: 'hypotf' was not declared in this scope hypotf(0.0f, 0.0f); ^ conftest.cpp:107:22: error: 'hypotl' was not declared in this scope hypotl(0.0l, 0.0l); ^ conftest.cpp:109:16: error: 'ilogbf' was not declared in this scope ilogbf(0.0f); ^ conftest.cpp:110:16: error: 'ilogbl' was not declared in this scope ilogbl(0.0l); ^ conftest.cpp:112:17: error: 'lgammaf' was not declared in this scope lgammaf(0.0f); ^ conftest.cpp:113:17: error: 'lgammal' was not declared in this scope lgammal(0.0l); ^ conftest.cpp:115:17: error: 'llrintf' was not declared in this scope llrintf(0.0f); ^ conftest.cpp:116:17: error: 'llrintl' was not declared in this scope llrintl(0.0l); ^ conftest.cpp:118:18: error: 'llroundf' was not declared in this scope
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 16:16:25 UTC --- Hopeless ;)
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #12 from janus at gcc dot gnu.org 2012-09-30 16:36:09 UTC --- Author: janus Date: Sun Sep 30 16:36:02 2012 New Revision: 191870 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191870 Log: 2012-09-30 Janus Weil ja...@gcc.gnu.org PR fortran/54667 * intrinsic.texi (C_F_POINTER): Fix description. * resolve.c (gfc_iso_c_sub_interface): Add a check for FPTR argument of C_F_POINTER. Modify two error messages. Cleanup. 2012-09-30 Janus Weil ja...@gcc.gnu.org PR fortran/54667 * gfortran.dg/c_funloc_tests_6.f90: Modified error message. * gfortran.dg/c_f_pointer_shape_test.f90: Ditto. * gfortran.dg/c_f_pointer_tests_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_test.f90 trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-09/msg01962.htm ||l --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-30 16:38:10 UTC --- Patch posted.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from janus at gcc dot gnu.org 2012-09-30 16:42:23 UTC --- Fixed with r191870. Closing. Thanks for the report, Andrew!
[Bug target/54760] New: [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760
Bug #: 54760
Summary: [SH] Add __builtin_thread_pointer,
__builtin_set_thread_pointer
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: olege...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
SH normally uses GBR to store the address of the thread control block (TCB).
Other targets have __builtin_thread_pointer and __builtin_set_thread_pointer to
modify such registers. It has been proposed to make these machine independent
builtins:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00428.html
but so far this has not made it into mainline. In any case the builtin
functions should be added for SH to get/set the GBR. Moreover, code that
accesses variables in the TCB like
struct tcb
{
int a, b, c, d;
};
int test (void)
{
return ((tcb*)__builtin_thread_pointer ())-c;
}
ideally would result in:
rts
mov.l @(8,gbr),r0
[Bug target/54760] [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-30 Ever Confirmed|0 |1
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-30 17:01:26 UTC --- (In reply to comment #11) With the patch in comment #10, gfortran (otherwise clean r191847) miscompiles gfortran.dg/class_array_7.f03. Seems to be fixed by my much extended local version (which still has some issues related to polymorphic coarrays). The following issue I see, however, also with GCC 4.7. I think it should be investigated and seems to be unrelated to my patch: ==96855== Invalid read of size 4 ==96855==at 0x11782: __realloc_MOD_assign (class_array_7_db.f90:25) ==96855==by 0x11685: __realloc_MOD_reallocate (class_array_7_db.f90:34)
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #14 from dave.anglin at bell dot net 2012-09-30 17:15:24 UTC --- On 30-Sep-12, at 12:16 PM, paolo.carlini at oracle dot com wrote: Hopeless ;) Actually, the situation might not be completely hopeless as the libquadmath support works... I had planned to implement the long double aliases but haven't had time to get around to it. -- John David Anglindave.ang...@bell.net
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 17:38:42 UTC --- I was joking, but I see many failures, not only for long double. Anyway, let's make sure we have a fall back, for now.
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2012-09-30 17:41:55 UTC --- Author: danglin Date: Sun Sep 30 17:41:49 2012 New Revision: 191873 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191873 Log: PR target/54083 * gcc.dg/torture/pr53922.c: Skip on 32-bit hppa-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2012-09-30 17:44:09 UTC --- Author: danglin Date: Sun Sep 30 17:44:04 2012 New Revision: 191874 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191874 Log: PR target/54083 * gcc.dg/torture/pr53922.c: Skip on 32-bit hppa-*-hpux*. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Attachment #28257|0 |1 is obsolete|| --- Comment #29 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 17:48:25 UTC --- Created attachment 28303 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28303 always define abs(long long) (v2.1) This an updated patch against rev 191865, with a typo fix (missing '\'). With this patch the std::abs problem goes away on my xgcc setup. So far I've tested it only with 'make all'.
[Bug go/54761] New: FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 Bug #: 54761 Summary: FAIL log Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: ubiz...@gmail.com Host: alpha-unknown-linux-gnu Target: alpha-unknown-linux-gnu Build: alpha-unknown-linux-gnu log libgo test regressed again, probaby when libgo switched to libbacktrace. As instructed in PR52583, I am opening a new PR for this. make GOTESTFLAGS=--keep log/check --- FAIL: log.TestAll (0.01 seconds) ???:1: log output should match ^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is ???:0: hello 23 world ???:1: log output should match ^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is XXX2012/09/30 19:38:55.640536 ???:0: hello 23 world ???:1: log output should match ^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is XXX2012/09/30 19:38:55.641513 ???:0: hello 23 world ???:1: log output should match ^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is XXX2012/09/30 19:38:55.642490 ???:0: hello 23 world ???:1: log output should match ^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$ is XXX2012/09/30 19:38:55.643466 ???:0: hello 23 world FAIL ~/gcc-build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/uros/gcc-build/gcc/xgcc Target: alphaev68-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure --enable-languages=all,obj-c++,go Thread model: posix gcc version 4.8.0 20120930 (experimental) [trunk revision 191866] (GCC)
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org 2012-09-30 17:54:57 UTC --- Test is fixed on 32-bit hpux. Sorry, for messing up proposed patches.
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Attachment #28269|0 |1 is obsolete|| Attachment #28278|0 |1 is obsolete|| --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-30 18:02:33 UTC --- Created attachment 28304 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28304 Updated OPTIONAL patch Current version of my OPTIONAL patch, just to make sure that I don't accidentally delete it locally. It fixes a bunch of issues; however, as the FIXMEs show, there are still wrong-code (segfault at run time) issues related to ELEMENTAL, scalar coarrays and possibly another issue. TODO: - Fix the OPTIONAL issues mentioned above - Support packing of assumed-rank arrays (see just attached test case; but otherwise an unrelated issue) - Fix INTENT(OUT) handling for allocatable polymorphic arrays (cf. comment 0) - Analyse the old issue related to class_array_7.f03 (comment 11, comment 12)
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #16 from dave.anglin at bell dot net 2012-09-30 18:04:26 UTC --- I will commit the attached change if there are no objections. -- John David Anglindave.ang...@bell.net
[Bug go/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-09-30 18:16:20 UTC --- Created attachment 28306 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28306 Gzipped test executable Gzipped alpha test executable, can be used with readelf.
[Bug go/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-09-30 18:18:10 UTC --- Created attachment 28307 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28307 Output of readelf --debug
[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|glisse at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |glisse at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #30 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-30 18:18:15 UTC --- Oops, I thought Marc was already in charge.
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #21 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 18:45:56 UTC --- I've noticed that there seems to be a problem with register allocation related to shift insns. For example in the CSiBE set, I've seen sequences such as mov.w .L342,r2 mov #0,r7 .align 2 .L340: mov r7,r1 add r2,r1 sharr1 mov r1,r3 shll2 r3 mov r3,r0 mov.l @(r0,r5),r3 cmp/gt r4,r3 bf 0f quite often. Not sure why this happens. Maybe because 'gen_shifty_op' (which emits the shift sequence insns) is called after reload and not during the first split pass after combine...
[Bug middle-end/54759] [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 Dehao Chen dehao at google dot com changed: What|Removed |Added CC||dehao at google dot com --- Comment #1 from Dehao Chen dehao at google dot com 2012-09-30 19:05:05 UTC --- Thanks for reporting the bug. I prepared a patch to fix this: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01997.html Could you help verify if it is fixed by this? Thanks, Dehao
[Bug target/54762] New: [SH] Utilize zero-displacement branches for conditional far branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54762
Bug #: 54762
Summary: [SH] Utilize zero-displacement branches for
conditional far branches
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
When the displacement of a conditional branch is too small the branch is
'widened', which results in code like this (a random snippet from CSiBE):
mov.l r8,@-r15
sts.l pr,@-r15
mov.l @(32,r4),r8
tst r8,r8
bt .L293
mov.l @r8,r1
cmp/eq r4,r1
bt .L295
.L293:
bra .L297
mov #-2,r6
.L295:
mov.l @(4,r8),r2
lots of code
.L297:
In such cases zero-displacement branches could be utilized to branch around the
far branch. For example:
mov.l r8,@-r15
sts.l pr,@-r15
mov.l @(32,r4),r8
tst r8,r8
bf 0f
bra .L297
0: mov #-2,r6
mov.l @r8,r1
cmp/eq r4,r1
bt 0f
bra .L297
0: mov #-2,r6
mov.l @(4,r8),r2
lots of code
.L297:
Maybe this could be achieved by adding variations to the existing branch_true
and branch_false patterns like:
(define_insn branch_true_far
[(set (pc) (if_then_else (ne (match_operand 1 t_reg_operand )
(const_int 0))
(label_ref (match_operand 0 ))
(pc)))]
TARGET_SH1
{
return bf 0f \n
bra%l0 \n
0: %#;
}
[(set_attr type cbranch)
(set_attr needs_delay_slot yes)
(set_attr length 4)]) ;; not sure whether length should be 4 or 6
;; in this case...
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #3 from Shane Hart shart6 at utk dot edu 2012-09-30 19:12:48 UTC --- The patch does get rid of memory corruption. However, there seem to be some problems with search_unit returning true if an exception is found when there is only one exception. If n_elist = 1, then high = low = 0, and the funtion will always return 0, even if the unit passed in to search for is in the exception list.
[Bug rtl-optimization/38449] delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449 --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-09-30 19:25:53 UTC --- Author: amylaar Date: Sun Sep 30 19:25:49 2012 New Revision: 191878 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191878 Log: PR rtl-optimization/38449: * hooks.c (hook_bool_const_rtx_const_rtx_true): New function. * hooks.h (hook_bool_const_rtx_const_rtx_true): Declare. * target.def: Merge in definitions and documentation for TARGET_CAN_FOLLOW_JUMP. * doc/tm.texi.in: Add documentation locations for the above. * doc/tm.texi: Regenerate. * reorg.c (follow_jumps): New parameters jump and crossing. Changed all callers. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/hooks.c trunk/gcc/hooks.h trunk/gcc/reorg.c trunk/gcc/target.def
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #4 from tkoenig at netcologne dot de tkoenig at netcologne dot de 2012-09-30 20:24:03 UTC --- Am 30.09.2012 21:12, schrieb shart6 at utk dot edu: If n_elist = 1, then high = low = 0, and the funtion will always return 0, even if the unit passed in to search for is in the exception list. If there are n_elist exceptions, then they can be found in elist[0], ..., elist[n_elist-1]. If there is one exception, then it can be found at elist[0].
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #5 from Shane Hart shart6 at utk dot edu 2012-09-30 20:56:39 UTC --- (In reply to comment #4) Am 30.09.2012 21:12, schrieb shart6 at utk dot edu: If n_elist = 1, then high = low = 0, and the funtion will always return 0, even if the unit passed in to search for is in the exception list. If there are n_elist exceptions, then they can be found in elist[0], ..., elist[n_elist-1]. If there is one exception, then it can be found at elist[0]. That is true, but the function will not return 1 (true, a match was found in elist) when there is only one exception stored. It will skip over the while loop, set *ip to 0, and return 0 (false, the exception was not found!). This can be illustrated: 1) Call the program, setting only one exception (in this case unit 21): [shane@shane-laptop ~/temp/testgfortran]$ GFORTRAN_CONVERT_UNIT='native;big_endian:21' gnu_wrap gdb ./test_read 2) Set a break point at where the library enquires as to the endianness of the file to be opened: Breakpoint 1, _gfortrani_get_unformatted_convert (unit=21) at ../../../libgfortran/runtime/environ.c:848 3) We will step into search_unit (with unit = 21). Everything is great. however, since n_elist = 1, high = low = 0, and the while loop is skipped over: (gdb) step 471 while (high - low 1) (gdb) step 485 if (unit elist[high].unit) 4) And 0 is returned (unit exception not found!) (gdb) step 490 return 0; 5) The library is told to open unit 21 (which is in the exception list at 0) as default endianness: _gfortrani_get_unformatted_convert (unit=21) at ../../../libgfortran/runtime/environ.c:856 856 return def;
[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 21:09:29
UTC ---
Doing this...
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 191865)
+++ gcc/config/sh/sh.c(working copy)
@@ -10079,6 +10079,9 @@
static bool
sh_legitimate_address_p (enum machine_mode mode, rtx x, bool strict)
{
+ if (reload_completed)
+return true;
+
if (MAYBE_BASE_REGISTER_RTX_P (x, strict))
return true;
else if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC)
makes the ICE go away. However, I have not tested this for any other
consequences.
This one is probably the better fix (max_mov_insn_displacement):
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 191865)
+++ gcc/config/sh/sh.c(working copy)
@@ -3457,21 +3457,20 @@
/* SH2A supports FPU move insns with 12 bit displacements.
Other variants to do not support any kind of displacements for
- FPU move insns. */
- if (! consider_sh2a TARGET_FPU_ANY GET_MODE_CLASS (mode) ==
MODE_FLOAT)
-return 0;
- else
-{
- const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
- const int mode_sz = GET_MODE_SIZE (mode);
- int r = 15 * mov_insn_sz * disp_scale;
+ FPU move insns. However, in the worst case, we can still use SImode
+ loads/stores with displacement, such as in the movsf_ie pattern instead
+ of true FPU move insns. It's just going to be more expensive because
+ additional gp reg - fpu reg moves have to be used for that. */
+ const int mov_insn_sz = mov_insn_size (mode, consider_sh2a);
+ const int mode_sz = GET_MODE_SIZE (mode);
+ int r = 15 * mov_insn_sz * disp_scale;
- /* If the mov insn will be split into multiple loads/stores, the
- maximum possible displacement is a bit smaller. */
- if (mode_sz mov_insn_sz)
-r -= mode_sz - mov_insn_sz;
- return r;
-}
+ /* If the mov insn will be split into multiple loads/stores, the
+ maximum possible displacement is a bit smaller. */
+ if (mode_sz mov_insn_sz)
+r -= mode_sz - mov_insn_sz;
+
+ return r;
}
/* Determine the alignment mask for a move insn of the
This makes the ICE go away, but it will wrongly output SH2A fmov.s insns such
as
fmov.s@(16,r7),fr3
when compiling for SH4.
The movsf_ie insn looks a bit ... complicated ... and probably should be split
into multiple insns to be able to handle such cases.
Maybe there's an even easier solution, but I can't imagine one at the moment.
[Bug middle-end/54759] [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-30 21:22:35 UTC --- Thanks for reporting the bug. I prepared a patch to fix this: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01997.html Could you help verify if it is fixed by this? The segfault disappears once the patch is applied, thanks!
[Bug middle-end/40205] OpenMP do loop with MAXINT gives wrong trip count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40205 --- Comment #3 from Paul Keir pkeir at outlook dot com 2012-09-30 21:29:22 UTC --- Still present in GFortran 4.7.2 on 32-bit Ubuntu 12.04.1.
[Bug c++/54763] New: Crash with enable_if (instead of recursive template errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54763
Bug #: 54763
Summary: Crash with enable_if (instead of recursive template
errors)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pk...@outlook.com
Created attachment 28308
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28308
C++11 code which causes an internal compiler error
The attached minimised C++11 test case causes an internal compiler error. Clang
instead gives an endless list of errors such as:
fatal error: recursive template instantiation
exceeded maximum depth of 512
The code, which is also shown below, will run correctly if the enable_if is
instead set to: std::enable_if(I0)::type.
#include type_traits
template unsigned
struct tint {};
double zod(tint0) { return 3.142; }
template
unsigned I,
typename = typename std::enable_if(I0),decltype(zod(tintI-1()))::type
decltype(zod(tintI-1()))
zod(tintI) {
return zod(tintI-1());
}
int main(int argc, char *argv[])
{
zod(tint0());
return 0;
}
[Bug rtl-optimization/11708] [sh4-elf-gcc] Non-Optimal jump code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11708 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 22:27:32 UTC --- I have checked this issue again on rev 191865 and the problem seems to not happen anymore. I've created a new PR 54762 for the issue in comment #7.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 22:47:33 UTC --- (In reply to comment #5) Created attachment 14973 [details] reduced testcase I have tried to reproduce the ICE with the reduced testcase on rev 191865 with the following options: -x c -m4 -mb -fschedule-insns -fPIC -mprefergot -x c -m4 -ml -fschedule-insns -fPIC -mprefergot and optimization levels -O0 -O1 -O2 -O3 -Os -Og. It seems the problem does not happen anymore.
[Bug target/51708] SH Target: SHAD / SHLD constant not CSE-ed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51708 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30 23:11:09 UTC --- In order to 'force' the constant load to be CSE-ed the constant load and dynamic shift patterns have to be emitted in the respective expanders, so that the CSE pass can see the constant load. It would be even better to check whether the shift insn is in a loop when deciding whether to use a dynamic shift insn or not. It is better to convert all non 1/2/8/16 shifts that are buried inside loops to dynamic shifts. If there are enough registers available every shift would become a 1 insn operation.
