[Bug debug/57664] [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-21 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, bisecting now.
[Bug fortran/57663] Arithmetic error with -fPIC -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663 --- Comment #2 from Sebastien Bardeau bardeau at iram dot fr --- (In reply to Mikael Morin from comment #1) (In reply to Sebastien Bardeau from comment #0) It seems that the gcc 4.6 branch is still receiving bug fixes, so could you have a look? Unfotunately no; the 4.6 branch has been closed since april. See http://gcc.gnu.org/ml/gcc/2013-04/msg00132.html I missed this, it might be good to add this information on this page: http://gcc.gnu.org/gcc-4.6/ Is there any chance that someone has a look to this bug? I did not test all gcc/gfortran versions, so I am 100% sure that this a 4.6-only issue. Furthermore, ideally I would like to know when it appeared and when it was fixed, in order to warn my users... Thank you.
[Bug c/57665] New: cpp: stringification does not work for __GNUC__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57665 Bug ID: 57665 Summary: cpp: stringification does not work for __GNUC__ Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Ulrich.Windl at rz dot uni-regensburg.de It seems stringification for __GNUC__ and other related numbers does not work: Using #__GNUC__ produces # 4 as output, not the expected ``4''. I tried something like #define GCC_VERSION #__GNUC__ . #___GNUC_MINOR__ . #__GNUC_PATCHLEVEL but all I get is stray `#' in program
[Bug fortran/57663] Arithmetic error with -fPIC -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57663 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is there any chance that someone has a look to this bug? No, but you can do it yourself. I did not test all gcc/gfortran versions, so I am 100% sure that this a 4.6-only issue. Furthermore, ideally I would like to know when it appeared and when it was fixed, in order to warn my users... Introduced between revisions 167584 (2010-12-08) and 167992 (2010-12-17), fixed between revisions 171100 (2011-03-17) and 171653 (2011-03-29).
[Bug c/57665] cpp: stringification does not work for __GNUC__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57665 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 1) You didn't attach a testcase 2) GCC 4.3 is unsupported and unmaintained 3) You have the wrong number of underscores: #define GCC_VERSION #__GNUC__ . #___GNUC_MINOR__ . #__GNUC_PATCHLEVEL ^^^ ^^ 4) why are you expecting __GNUC__ to behave differently to this? #define GNUC 4 #define GNUC_MINOR 3 #define GNUC_PATCHLEVEL 4 #define GCC_VERSION #GNUC . #GNUC_MINOR . #GNUC_PATCHLEVEL const char* ver = GCC_VERSION; That's not how the preprocessor works.
[Bug other/57659] Failure in installing documentation of gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57659 --- Comment #2 from Ellis N. Thomas ExtraLeveLInSoftware at ntlworld dot com --- Oops...re-used a previous report as a template! Pls take (sub)sections 6 as 5. (In reply to Jonathan Wakely from comment #1) (In reply to Ellis N. Thomas from comment #0) 4 Information about the build state [...] 6 Summary of Bugs What happened to chapter 5? :) 6.2 Extra Information If extra information about the matters reported above would be of value please contact: ExtraLeveLInSoftware at ntlworld dot com If someone needs more info I think you can assume they'll ask for it, but they'll post responses to Bugzilla, and as the bug reporter you'll automatically get an email, so there's no need to give your contact details.
[Bug c/57665] cpp: stringification does not work for __GNUC__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57665 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This works fine: #define SJOIN(A,B,C) #A . #B . #C #define JOIN(A,B,C) SJOIN(A, B, C) #define GCC_VERSION JOIN(__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__)
[Bug c++/53211] range-based 'for' expression of type 'const int []' has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.8.2 too.
[Bug libstdc++/57666] New: valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666
Bug ID: 57666
Summary: valarrayT::operator= in c++11 mode does not adapt to
size
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: thunderliu at gmail dot com
Non-member operators for valarray returns instance of _Expr (lazy
evaluation?), instead of another valarray. This is non-conforming but
probably not a bug. But if the returned value is assigned to another
valarray, c++11 requires operator= to be size-adapting, but 4.7.2 does not do
that for _Expr.
For example:
#include valarray
extern C int printf(const char *, ...);
int main()
{
typedef std::valarrayint A;
A a(3), b(3), d;
d=a+b;
printf(%d\n, d.size()); // 0, incorrect
d=a;
printf(%d\n, d.size()); // 3, correct
}
(Preprocessed source attached.)
[Bug libstdc++/57666] valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 thunderliu at gmail dot com changed: What|Removed |Added Target||x86_64-redhat-linux --- Comment #1 from thunderliu at gmail dot com --- Compile the code with -std=c++0x
[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|superbem at gmail dot com |jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, at first I thought this one could be a Dup of 55149 but I'm still seeing it today.
[Bug debug/57667] New: -femit-struct-debug-detailed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57667 Bug ID: 57667 Summary: -femit-struct-debug-detailed Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: evgeny.gavrin at hotmail dot com Created attachment 30331 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30331action=edit file with direct and indirect calls of structs -femit-struct-debug-detailed
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #26 from Martin Liška marxin.liska at gmail dot com ---
Unit tests error:
Program received signal SIGSEGV, Segmentation fault.
0x2aaab39189ed in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
(gdb) bt
#0 0x2aaab39189ed in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
#1 0x2aaab3a77516 in ScDocShell::DoHardRecalc(bool) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
#2 0x2f8df43e in ScFiltersTest::testContentXLS() () from
/ssd/libreoffice/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_sc_filters_test.so
#3 0x2ab8614e in CppUnit::TestCaseMethodFunctor::operator()() const ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#4 0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#5 0x2c332800 in (anonymous namespace)::Prot::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/unoexceptionprotector.so
#6 0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#7 0x2ab78016 in CppUnit::DefaultProtector::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#8 0x2ab813b1 in CppUnit::ProtectorChain::ProtectFunctor::operator()()
const () from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#9 0x2ab8125b in CppUnit::ProtectorChain::protect(CppUnit::Functor
const, CppUnit::ProtectorContext const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#10 0x2ab9073a in CppUnit::TestResult::protect(CppUnit::Functor const,
CppUnit::Test*, std::string const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#11 0x2ab85c1e in CppUnit::TestCase::run(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#12 0x2ab86812 in
CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#13 0x2ab8669c in CppUnit::TestComposite::run(CppUnit::TestResult*) ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#14 0x2ab86812 in
CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#15 0x2ab8669c in CppUnit::TestComposite::run(CppUnit::TestResult*) ()
from /ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#16 0x2ab94878 in
CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#17 0x2ab90518 in CppUnit::TestResult::runTest(CppUnit::Test*) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#18 0x2ab94ac8 in CppUnit::TestRunner::run(CppUnit::TestResult,
std::string const) () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libcppunit-1.13.so.0
#19 0x004026aa in (anonymous namespace)::ProtectedFixtureFunctor::run()
const ()
#20 0x00402b27 in sal_main() ()
#21 0x0040226b in main ()
Output:
CalcAll called
Program received signal SIGSEGV, Segmentation fault.
0x2aaab390c19d in ScDocument::CalcAll() () from
/ssd/libreoffice/solver/unxlngx6.pro/lib/libsclo.so
Source code snippet:
void ScDocument::CalcAll()
{
puts(CalcAll called\n);
ClearLookupCaches();// Ensure we don't deliver zombie data.
puts(CalcAll called2\n);
bool bOldAutoCalc = GetAutoCalc();
puts(CalcAll called3\n);
SetAutoCalc( true );
puts(CalcAll called4\n);
TableContainer::iterator it = maTabs.begin();
puts(CalcAll called5\n);
for (; it != maTabs.end(); ++it)
if (*it)
(*it)-SetDirtyVar();
for (it = maTabs.begin(); it != maTabs.end(); ++it)
if (*it)
(*it)-CalcAll();
puts(CalcAll called6\n);
ClearFormulaTree();
puts(CalcAll called7\n);
SetAutoCalc( bOldAutoCalc );
puts(CalcAll called8\n);
}
Link to dumps:
https://docs.google.com/file/d/0B0pisUJ80pO1OFNEc2h4YWVwa2s/edit?usp=sharing
If you need assembler dumps, I can upload it.
Thanks,
Martin
[Bug debug/57667] -femit-struct-debug-detailed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57667 --- Comment #1 from Evgeny Gavrin evgeny.gavrin at hotmail dot com --- Created attachment 30332 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30332action=edit structs declaration
[Bug c++/57402] [4.9 Regression] ICE: in make_decl_rtl, at varasm.c:1147 when initializing variable-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57402 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-21 Ever confirmed|0 |1
[Bug c++/57401] 'Conflicting declaration' involving using declaration and dependent name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57401 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-21 CC||dodji at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- CC-ing Dodji.
[Bug debug/57667] -femit-struct-debug-detailed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57667
--- Comment #2 from Evgeny Gavrin evgeny.gavrin at hotmail dot com ---
Hi!
From the documentation to -femit-struct-debug-detailed:
The value `base' means that the base of name of the file in which the type
declaration appears must match the base of the name of the main compilation
file.
I've created two files test.c and test-nonbase.h. (attached)
So, as I understand, when compiling like gcc-4.7 test.c -O0 -g2
-femit-struct-debug-detailed=ind:ord:base info about structs declared in
test-nonbase.h shouldn't be emitted.
But I can get all debug info on structs declared in test-nonbase.h using gdb:
Starting program: ./gcc-tests/a.out
Breakpoint 1, main () at test.c:18
18 free(indir_ord);
(gdb) p a
$1 = 5
(gdb) p b
$2 = 98
(gdb) p dir_ord
$3 = {a = 5, b = 97 'a'}
(gdb) p *indir_ord
$4 = {a = 10, b = 98 'b'}
Meanwhile, compiling with -femit-struct-debug-detailed=ord:base gdb can't
find the debug info:
Starting program: ./gcc-tests/a.out
Breakpoint 1, main () at test.c:18
18 free(indir_ord);
(gdb) p dir_ord
$1 = incomplete type
(gdb) p *inddir_ord
No symbol inddir_ord in current context.
(gdb) p *indir_ord
$2 = incomplete type
Let's see the code:
./gcc/opts.c
51 void
52 set_struct_debug_option (struct gcc_options *opts, location_t loc,
53 const char *spec)
54 {
*
62 /* Default is to apply to as much as possible. */
63 enum debug_info_usage usage = DINFO_USAGE_NUM_ENUMS;
64 int ord = 1, gen = 1;
*
96 if (usage == DINFO_USAGE_NUM_ENUMS)
97 {
98 if (ord)
99 {
100 opts-x_debug_struct_ordinary[DINFO_USAGE_DFN] = files;
101 opts-x_debug_struct_ordinary[DINFO_USAGE_DIR_USE] = files;
102 opts-x_debug_struct_ordinary[DINFO_USAGE_IND_USE] = files;
103 }
104 if (gen)
105 {
106 opts-x_debug_struct_generic[DINFO_USAGE_DFN] = files;
107 opts-x_debug_struct_generic[DINFO_USAGE_DIR_USE] = files;
108 opts-x_debug_struct_generic[DINFO_USAGE_IND_USE] = files;
109 }
110 }
111 else
112 {
113 if (ord)
114 opts-x_debug_struct_ordinary[usage] = files;
115 if (gen)
116 opts-x_debug_struct_generic[usage] = files;
117 }
This means that first optional parameter shouldn't affect so much. In case it's
omitted debug info should be emitted both for [dir:] and [ind:], but only for
base files.
Two cases:
1) test.c -O0 -g2 -femit-struct-debug-detailed=ind:ord:base
opts-x_debug_struct_ordinary[usage] = files;
2) test.c -O0 -g2 -femit-struct-debug-detailed=ord:base
opts-x_debug_struct_ordinary[DINFO_USAGE_DFN] = files;
opts-x_debug_struct_ordinary[DINFO_USAGE_DIR_USE] = files;
opts-x_debug_struct_ordinary[DINFO_USAGE_IND_USE] = files;
The following -femit-struct-debug-detailed=ind:ord:base means that debug info
should be emitted for structs used indirectly and declared in file that matches
the base name of the compilation file (test.c/test.h).
So, in the particular case, when struct is used indirectly in test.c and
declared in test-nonbase.h - info on structs shouldn't be emitted.
In case of, -femit-struct-debug-detailed=ord:base - it works correctly and
emits nothing.
[Bug libstdc++/57666] valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to thunderliu from comment #0) Non-member operators for valarray returns instance of _Expr (lazy evaluation?), instead of another valarray. This is non-conforming but probably not a bug. 26.6.1 [valarray.syn]/3 Any function returning a valarrayT is permitted to return an object of another type, provided all the const member functions of valarrayT are also applicable to this type.
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 --- Comment #5 from ktkachov at gcc dot gnu.org --- Please try the attached patch. If it works, I will send it for community review. Hi Zhenqiang, This seems to fix the miscompare on my setup, thanks! I haven't ran a full regression test on it though, but it seems reasonable at first glance. Kyrill
[Bug libstdc++/57666] valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 --- Comment #3 from thunderliu at gmail dot com --- Sorry I missed that. But the remaining (which is the point of this bug) still stands. (In reply to Jonathan Wakely from comment #2) (In reply to thunderliu from comment #0) Non-member operators for valarray returns instance of _Expr (lazy evaluation?), instead of another valarray. This is non-conforming but probably not a bug. 26.6.1 [valarray.syn]/3 Any function returning a valarrayT is permitted to return an object of another type, provided all the const member functions of valarrayT are also applicable to this type.
[Bug debug/57664] [4.8/4.9 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6750 with -fdebug-types-section and lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57664 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Can't really bisect it further due to autoconf version, but it started between 186994 and 187108.
[Bug libstdc++/57666] valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-21 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Yes, it's easy to fix.
[Bug other/57668] New: Regression in vectorizing memcpy pattern.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57668 Bug ID: 57668 Summary: Regression in vectorizing memcpy pattern. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: neleai at seznam dot cz Hi, When I ran atached benchmark that test how gcc can optimize byte by byte memcpy(attached memcpy_byte.c) I got a regression on nehalem and ivy_bridge architectures. I ran it by commands ./run machine 2 machine_result For ivy bridge results between 4.7 and 4.9 are: memcpyO3-4.7.s 0.66 0.65 0.64 0.64 0.64 memcpyO3-4.9.s 0.74 0.74 0.73 0.74 0.74 Also when I look at assemblies and 4.9 version is excessively large compared to 4.7 one.
[Bug other/57668] Regression in vectorizing memcpy pattern.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57668 --- Comment #1 from Ondrej Bilka neleai at seznam dot cz --- Created attachment 30333 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30333action=edit benchmark for memcpy
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-21 CC||gjl at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Would you explain what you are trying to achieve? You can name the function __vectorFOO or __vector_my_ISR_function or whatever without raising a warning.
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se --- Bernd Schmidt has posted a patch for review: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01147.html
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #4 from pebbles at riseup dot net --- (In reply to Georg-Johann Lay from comment #3) Would you explain what you are trying to achieve? For one thing, I'm coding in C++, so the handlers may be mangled to the wrong symbols unless I tell the compiler what to name them. The warning is misleading at least in this case. In C++ it's conventional to place symbols inside namespaces or classes over prefixing them with underscores. I'm writing a library and would like users to be able to define the handlers with names and scopes that match the style conventions of the project. The __ prefix generally indicates that a symbol should not be used by a library user, and I'm trying to indicate the opposite. You can name the function __vectorFOO or __vector_my_ISR_function or whatever without raising a warning. But that requires reading the source of GCC, which I have begun doing but is usually not a prerequisite for coding. The warning should tell me that straight out.
[Bug c/57669] New: Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Bug ID: 57669 Summary: Incorrect floating point values with 32-bit compile Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: oliverst at online dot de Created attachment 30334 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30334action=edit sample code The attached sample produces incorrect values with 32-bit. The function, that produces the incorrect values is part of FLAC 1.2.1. I first ran into the behavior with the 32-bit version of GCC 4.6.3 by MinGW-w64 and was able to confirm it with a -m32 cross-compile of GCC 4.7.3 bundled with ubuntu 13.04. The expected result appears to be the 64-bit one since it matches the values produced by Visual Studio 2012 32-bit and 64-bit as well as clang 3.3 on ubuntu 13.04. The expected result is: 6945.132324 4500.032715 1060.377319 -132.546219 95.539162 216.320663 80.951294 -48.548409 -61.090591 36.541431 273.282440 315.549683 100.133156 -48.032295 72.734283 223.127853 The incorrect result is: 6945.131836 4500.032715 1060.377319 -132.546204 95.539146 216.320633 80.951294 -48.548393 -61.090607 36.541412 273.282410 315.549683 100.133156 -48.032322 72.734268 223.127853 The information about the Mmingw-w64 compile in question: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/mingw64-w32/bin/../libexec/gcc/i686-w64-mingw32/4.6.3/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: /home/ruben/mingw-w64/src/gcc/configure --host=i686-w64-mingw32 --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/mingw32mingw32/mingw32 --prefix=/home/ruben/mingw-w64/mingw32mingw32/mingw32 --with-gmp=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-mpfr=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-mpc=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-ppl=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-cloog=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm' --enable-shared --enable-static --enable-threads=win32 --enable-plugins --disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,fortran,java --enable-libgomp --disable-dw2-exceptions --enable-sjlj-exceptions --enable-fully-dynamic-string --enable-libstdcxx-time --disable-nls --disable-werror --enable-checking=release --with-gnu-as --with-gnu-ld --disable-win32-registry --disable-rpath --disable-werror --with-libiconv-prefix=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install CFLAGS='-O2 -march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= : (reconfigured) /home/ruben/mingw-w64/src/gcc/configure --host=i686-w64-mingw32 --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/mingw32mingw32/mingw32 --prefix=/home/ruben/mingw-w64/mingw32mingw32/mingw32 --with-gmp=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-mpfr=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-mpc=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-ppl=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --with-cloog=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm' --enable-shared --enable-static --enable-threads=win32 --enable-plugins --disable-multilib --enable-libgomp --disable-dw2-exceptions --enable-sjlj-exceptions --enable-fully-dynamic-string --enable-libstdcxx-time --disable-nls --enable-checking=release --with-gnu-as --with-gnu-ld --disable-win32-registry --disable-rpath --disable-werror --with-libiconv-prefix=/home/ruben/mingw-w64/prereq/i686-w64-mingw32/install CFLAGS='-O2 -march=nocona -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= build_alias=x86_64-linux-gnu host_alias=i686-w64-mingw32 target_alias=i686-w64-mingw32 --enable-languages=c,c++,fortran,java,lto,objc,obj-c++ --no-create --no-recursion Thread model: win32 gcc version 4.6.3 (GCC) The information about the version used on ubuntu: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
[Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57408 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- The issue here is that this capture is not valid C++1y because an array bound other than the first one is non-constant. Current 4.9 gives an error and then crashes; I'll fix the crash, but it will still be rejected.
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org --- It is difficult to say why the unit test fails. Would be possible to run it in GDB and figure out why it segfaults? Honza
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org --- What about trying ulimit -m to increase the number of FDs? (it requires root)
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #19 from Jan Hubicka hubicka at gcc dot gnu.org --- chrome.wpa.000i.cgraph: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi/8859591 (OnIOComplete) @0x7f80e10be980 Type: function definition analyzed Visibility: force_output prevailing_def_ironly Address is taken. References: Referring: _ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoSendLengthEi/8859587 (addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt11DoSendQueryEi/8859588 (addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt12DoReadLengthEi/8859589 (addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt14DoReadResponseEi/8859590 (addr)_ZN3net12_GLOBAL__N_113DnsTCPAttempt5StartERKN4base8CallbackIFviEEE/8859580 (addr) Read from file: obj/net/dns/net.dns_transaction.o Availability: available Function flags: Called by: Calls: _ZN3net12_GLOBAL__N_113DnsTCPAttempt6DoLoopEi/8859585 (1.00 per call) Has 1 outgoing edges for indirect calls. marxin@marxinbox /ssd/chromium-2/src/out/Release $ grep _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi *.s chrome.ltrans16.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rax chrome.ltrans29.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi chrome.ltrans29.s:leaq _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi(%rip), %rsi chrome.ltrans29.s:.type _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, @function chrome.ltrans29.s:_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi: chrome.ltrans29.s:.size _ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi, .-_ZN3net12_GLOBAL__N_113DnsTCPAttempt12OnIOCompleteEi This actually looks like partitioning problem. I misread the dump ysterday - it is a local function and it seems that somehow we manage to get referenc eto it from ltrans16 while it is static to ltrans29. Can I see .cgraph dump of ltrans16? If you have -fdump-tree-all dumps (or you can just rebuild ltrans16 with this dump) it should be possible to grep the dumps to work out if the symbol appears as a result of some constant folding.
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #5 from Bud Davis bdavis at gcc dot gnu.org --- As the reporter of this enhancement request, I think it is something that should be left open. Low priority, but this was a 'feature' of some f77 compilers in the past. Even if no-one ever adds this functionality, those porting old f77 code that encounter this will be able to see that it is not implemented and they can infer why it was not added.
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #20 from Martin Liška marxin.liska at gmail dot com --- Link to ltrans16.cgraph dump: https://docs.google.com/file/d/0B0pisUJ80pO1c0JTTmR5Z1pQb28/edit?usp=sharing
[Bug c++/57038] Latest libreoffice compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038 --- Comment #28 from Martin Liška marxin.liska at gmail dot com --- Gdb instruction dump of ScDocument::CalcAll, place where SIGSEGV was received is marked with '', address: 0x2aaab390c19d + B+ ¦0x2aaab390c180 _ZN10ScDocument7CalcAllEv push %r15 ¦ ¦0x2aaab390c182 _ZN10ScDocument7CalcAllEv+2push %r14 ¦ ¦0x2aaab390c184 _ZN10ScDocument7CalcAllEv+4push %r13 ¦ ¦0x2aaab390c186 _ZN10ScDocument7CalcAllEv+6push %r12 ¦ ¦0x2aaab390c188 _ZN10ScDocument7CalcAllEv+8push %rbp ¦ ¦0x2aaab390c189 _ZN10ScDocument7CalcAllEv+9mov%rdi,%rbp ¦ ¦0x2aaab390c18c _ZN10ScDocument7CalcAllEv+12 lea0x21bc66(%rip),%rdi # 0x2aaab3b27df9 ¦ ¦0x2aaab390c193 _ZN10ScDocument7CalcAllEv+19 push %rbx ¦ ¦0x2aaab390c194 _ZN10ScDocument7CalcAllEv+20 sub$0x18,%rsp ¦ ¦0x2aaab390c198 _ZN10ScDocument7CalcAllEv+24 callq 0x2aaab33c8af0 puts@plt ¦ ¦0x2aaab390c19d _ZN10ScDocument7CalcAllEv+29 mov0x1c8(%rbp),%rbx ¦ ¦0x2aaab390c1a4 _ZN10ScDocument7CalcAllEv+36 test %rbx,%rbx ¦ ¦0x2aaab390c1a7 _ZN10ScDocument7CalcAllEv+39 je 0x2aaab390c29d _ZN10ScDocument7CalcAllEv+285 ¦ ¦0x2aaab390c1ad _ZN10ScDocument7CalcAllEv+45 mov(%rbx),%r12 ¦ ¦0x2aaab390c1b0 _ZN10ScDocument7CalcAllEv+48 mov0x8(%rbx),%rax ¦ ¦0x2aaab390c1b4 _ZN10ScDocument7CalcAllEv+52 test %r12,%r12 ¦ ¦0x2aaab390c1b7 _ZN10ScDocument7CalcAllEv+55 je 0x2aaab390c1f5 _ZN10ScDocument7CalcAllEv+117 ¦ ¦0x2aaab390c1b9 _ZN10ScDocument7CalcAllEv+57 mov(%r12,%rax,8),%r13 ¦ ¦0x2aaab390c1bd _ZN10ScDocument7CalcAllEv+61 test %r13,%r13 ¦ ¦0x2aaab390c1c0 _ZN10ScDocument7CalcAllEv+64 je 0x2aaab390c1f5 _ZN10ScDocument7CalcAllEv+117 ¦ ¦0x2aaab390c1c2
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to pebbles from comment #4) (In reply to Georg-Johann Lay from comment #3) Would you explain what you are trying to achieve? For one thing, I'm coding in C++, so the handlers may be mangled to the wrong symbols unless I tell the compiler what to name them. The warning is misleading at least in this case. The ISR macro is defined by AVR-LibC. It adds extern C to ISR if compiled for C++. Thus, the handlers are not mangled and names like __vector_num are used even if compiled for C++. Moreover, you should not use __vector_num firectly, use the support macros from avr/io.h and avr/interrupt.h. They work for C++. If not, please file a bug report against AVR-LibC. In C++ it's conventional to place symbols inside namespaces or classes over prefixing them with underscores. I'm writing a library and would like users to be able to define the handlers with names and scopes that match the style conventions of the project. Don't use __vector_num directly; use defines from AVR-LibC like INT0_vect etc. Cf. the AVR-LibC documentation. You can name the function __vectorFOO or __vector_my_ISR_function or whatever without raising a warning. But that requires reading the source of GCC, which I have begun doing but is usually not a prerequisite for coding. The warning should tell me that straight out. You should read the documentation of AVR-LibC, of course. You can add documentation parts to the GCC documentation if you find it helpful. However, users typically read the AVR-LibC manual because ISR and the vector names are supplyied by AVR-LibC's av/io.h and avr/interrupt.h.
[Bug debug/57667] -femit-struct-debug-detailed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57667
--- Comment #3 from Evgeny Gavrin evgeny.gavrin at hotmail dot com ---
Command to run:
egavrin@debian:~/dev/vd-issues/ld-memory-consumption/gcc-tests$ gcc-4.7 test.c
-O0 -g2 -gdwarf-2 -femit-struct-debug-detailed=ind:ord:base
egavrin@debian:~/dev/vd-issues/ld-memory-consumption/gcc-tests$ gdb ./a.out
*
(gdb) b 18
Breakpoint 1 at 0x400593: file test.c, line 18.
(gdb) run
Starting program:
/home/egavrin/dev/vd-issues/ld-memory-consumption/gcc-tests/a.out
Breakpoint 1, main () at test.c:18
18 free(indir_ord);
(gdb) p dir_ord
$1 = {a = 5, b = 97 'a'}
(gdb) p indir_ord
$2 = (struct IND_ORD *) 0x601010
(gdb) p *indir_ord
$3 = {a = 10, b = 98 'b'}
(gdb)
egavrin@debian:~/dev/vd-issues/ld-memory-consumption/gcc-tests$ gcc-4.7 test.c
-O0 -g2 -gdwarf-2 -femit-struct-debug-detailed=ord:base
egavrin@debian:~/dev/vd-issues/ld-memory-consumption/gcc-tests$ gdb ./a.out
GNU gdb (GDB) 7.4.1-debian
This GDB was configured as x86_64-linux-gnu.
Reading symbols from
/home/egavrin/dev/vd-issues/ld-memory-consumption/gcc-tests/a.out...done.
(gdb) b 18
Breakpoint 1 at 0x400593: file test.c, line 18.
(gdb) run
Starting program:
/home/egavrin/dev/vd-issues/ld-memory-consumption/gcc-tests/a.out
Breakpoint 1, main () at test.c:18
18 free(indir_ord);
(gdb) p dir_ord
$1 = incomplete type
(gdb) p indir_ord
$2 = (struct IND_ORD *) 0x601010
(gdb) p *indir_ord
$3 = incomplete type
[Bug middle-end/57670] New: Member-pointer calls should not be redirected to builtin_unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57670 Bug ID: 57670 Summary: Member-pointer calls should not be redirected to builtin_unreachable Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Created attachment 30335 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30335action=edit Testcase We redirect calls to non-functions to builtin_unreachable. However, we should not do that for member-pointer calls because there we pattern-match IL which can use integers to do a VMT lookup. I'm about to test a simple patch.
[Bug middle-end/57670] Member-pointer calls should not be redirected to builtin_unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57670 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-21 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org --- Mine.
[Bug libstdc++/57666] valarrayT::operator= in c++11 mode does not adapt to size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57666 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.2 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed mainline and 4.8.2.
[Bug c++/17166] Improve diagnostic for empty overload set listing the rejected overloads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17166 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|gcc-bugs at gcc dot gnu.org| Known to work||4.8.0, 4.9.0 Resolution|--- |FIXED --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Lately the diagnostic is good.
[Bug c++/57671] New: Compile Error: When declared a pointer const TYPE const *p ; (p is name of pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57671 Bug ID: 57671 Summary: Compile Error: When declared a pointer const TYPE const *p ; (p is name of pointer) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vlad94009277 at gmail dot com Compile Error: When declared the pointer const int const *p ; Actual result: error: duplicate ‘const’ const int const *p ; expected result: Must be declared the pointer p:
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #6 from pebbles at riseup dot net --- You seem to be speaking from an assumption that this warning code should not change. Is there a reason for not adding this small patch, which makes gcc more extendable and accurate? (In reply to Georg-Johann Lay from comment #5) The ISR macro is defined by AVR-LibC. It adds extern C to ISR if compiled for C++. Thus, the handlers are not mangled and names like __vector_num are used even if compiled for C++. Moreover, you should not use __vector_num firectly, use the support macros from avr/io.h and avr/interrupt.h. They work for C++. If not, please file a bug report against AVR-LibC. extern C does not work inside a class. I'm glad to file a bug report with AVR-LibC for this, but generally it is not expected that C macros work inside classes. The signal and interrupt attributes are described in the gcc attribute documentation. I would like to use them. I am trying to create a way for unknown code using my library to define event handlers. It's true, I can handle this at runtime by calling back to them from for example INT0_vect, relying on GCC to inline the call if it is known at compile time. If it is indeed known, it is more efficient and brings the user closer to the hardware to call it straight from the interrupt vector table, which can only be set up by the linker. Right now gcc restricts my interface specification in such a way that if I allow code to define a static event handler, and I want it to be an interrupt in the interrupt vector table, it must be named __vectorABC or declared with ISR(ABC_vect) and be file scoped. If things become more complex and this static event handler will be called from inside another interrupt handler, the ISR(ABC_vect) convention will no longer work; the interface specification and all code must be updated. If I can give the handler a non-AVR-LibC name, then all that needs to change is the attribute in the header file. Code becomes maintainable, and self-documenting too. I can do this right now, gcc just issues a warning if that name does not start with __vector. I do really appreciate as many alternative solutions as there are, but I am actually going to do this, warning or no, because I am trying to both accurately represent the hardware and abstract it. You can name the function __vectorFOO or __vector_my_ISR_function or whatever without raising a warning. But that requires reading the source of GCC, which I have begun doing but is usually not a prerequisite for coding. The warning should tell me that straight out. You should read the documentation of AVR-LibC, of course. You can add documentation parts to the GCC documentation if you find it helpful. However, users typically read the AVR-LibC manual because ISR and the vector names are supplyied by AVR-LibC's av/io.h and avr/interrupt.h. As you state earlier, AVR-LibC does not intend us to be aware of the __vector_NN naming convention; I don't believe it's mentioned in the docs. Solving my problem by artificially prefixing my function names with __vector, which works but restricts what I can name them in an unpleasant way, involves finding the warning check in the GCC source to understand that that is a solution. This seems like a very small patch that makes GCC more extendable and accurate. I am not too attached to these things changing, although I am curious what the reason is for not considering the patch.
[Bug c/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Julian Taylor jtaylor.debian at gmail dot com changed: What|Removed |Added CC||jtaylor.debian at gmail dot com --- Comment #1 from Julian Taylor jtaylor.debian at gmail dot com --- looks like expected behavior to me, please read: http://gcc.gnu.org/wiki/x87note you may be able to get consistent results by using -mfpmath=sse e.g. clang will always use amd64 mode even on 32 bit, thus probably the same result.
[Bug c++/57671] Compile Error: When declared a pointer const TYPE const *p ; (p is name of pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57671 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Severity|blocker |normal --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Unlike C, C++ does not allow to directly specify a cv-qualifier twice.
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pebbles at riseup dot net --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to pebbles from comment #6) This seems like a very small patch that makes GCC more extendable and accurate. I am not too attached to these things changing, although I am curious what the reason is for not considering the patch. You can propose and explain your change in the gcc-patches@ mailing list, of course. That is the right place to get changes into the compiler.
[Bug driver/45508] Does adding configure-options for specs-hardcoding make sense?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||benoit.hudson at gmail dot com --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 7957 has been marked as a duplicate of this bug. ***
[Bug target/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |target --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds like bug 323.
[Bug driver/7957] change request: more flexible %D specs directive so no need to set LD_LIBRARY_PATH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7957 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #5) I really doubt that we want this option as we have always recommend in setting LD_LIBRARY_PATH. Relying on LD_LIBRARY_PATH can be a liability. The RPATH is evil argument is mostly based on NFS problems, but if I never allow NFS near my systems then that argument doesn't stand up. Users should be able to choose for themselves if they want to use RPATH or LD_LIBRARY_PATH. PR 53002 makes it easier to use specs to solve this problem, PR 45508 comment 10 describes a plan that would be equivalent to --with-rpath-in-specs, so closing this as a dup *** This bug has been marked as a duplicate of bug 45508 ***
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #8 from pebbles at riseup dot net --- (In reply to Georg-Johann Lay from comment #7) (In reply to pebbles from comment #6) This seems like a very small patch that makes GCC more extendable and accurate. I am not too attached to these things changing, although I am curious what the reason is for not considering the patch. You can propose and explain your change in the gcc-patches@ mailing list, of course. That is the right place to get changes into the compiler. All right, thank you. I only started trying to make a patch after noticing what seemed like a bug(?) I see from patch submission docs I should add testcases as well. If you have any more feedback or help, thank you.
[Bug target/57669] Incorrect floating point values with 32-bit compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57669 --- Comment #3 from Oliver Stoeneberg oliverst at online dot de --- It's unoptimized code and using -msse -mfpmath=sse fixes it. But there is another fix: http://msdn.microsoft.com/en-us/library/vstudio/7t5yh4fd(v=vs.110).aspx Changing autoc[coeff] += d * data[sample+coeff]; to FLAC__real tmp = d * data[sample+coeff]; autoc[coeff] += tmp; also provides the same results with 32-bit as 64-bit does.
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- As the reporter of this enhancement request, I think it is something that should be left open. Low priority, but this was a 'feature' of some f77 compilers in the past. G77 does compile the test. Even if no-one ever adds this functionality, those porting old f77 code that encounter this will be able to see that it is not implemented and they can infer why it was not added. IMO the f77 extensions that have not been already added to gfortran should not be implemented, but documented in the section 6.2 Extensions not implemented in GNU Fortran of the manual. I can submit a draft patch for this PR if someone is will to fix my Frenglish and formatting issues and do the commit. As for today, there are 738 opened PRs, among them 245 are UNCONFIRMED.
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 pebbles at riseup dot net changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pebbles at riseup dot net |unassigned at gcc dot gnu.org --- Comment #9 from pebbles at riseup dot net --- I would like to learn to find out if this is a bug and contribute a fix to the gcc sources. At the moment building gcc loads my computer for a day, and it is difficult to develop on. I plan to pursue this when I am set up better, but if anybody else ever cares about it they should look at it. As far as I can tell the patch I attached is good but I haven't turned my test into a testcase or read the gcc development docs yet.
[Bug c++/57658] ICE in tsubst_copy, at cp/pt.c:12213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 --- Comment #3 from Takaki Makino t-gcc-bugzilla at snowelm dot com --- Created attachment 30336 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30336action=edit Reduced testcase Hi Paolo, Thank you for referring to the useful resource. Using these tools I've got a reduced version (attached) I believe this is a valid code. $ g++-4.9 -std=c++11 testcase.cpp testcase.cpp: In instantiation of 'XT::f() [with T = int]::lambda()': testcase.cpp:11:11: required from 'struct XT::f() [with T = int]::lambda()' testcase.cpp:11:9: required from 'bool XT::f() [with T = int]' testcase.cpp:16:16: required from here testcase.cpp:12:62: internal compiler error: in tsubst_copy, at cp/pt.c:12213 typename remove_reference decltype (a) ::type t; ^ 0x59f7f0 tsubst_copy ../../gcc/cp/pt.c:12213 0x57cee9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:14484 0x59081c tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11807 0x59c8fa tsubst_template_args ../../gcc/cp/pt.c:9640 0x59d2fe tsubst_aggr_type ../../gcc/cp/pt.c:9837 0x590a25 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11695 0x5a1581 tsubst_decl ../../gcc/cp/pt.c:10652 0x5913b4 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11101 0x586eef tsubst_expr ../../gcc/cp/pt.c:12931 0x587284 tsubst_expr ../../gcc/cp/pt.c:13070 0x5864b3 tsubst_expr ../../gcc/cp/pt.c:12880 0x587284 tsubst_expr ../../gcc/cp/pt.c:13070 0x584e5b instantiate_decl(tree_node*, int, bool) ../../gcc/cp/pt.c:19112 0x5bcb67 instantiate_class_template_1 ../../gcc/cp/pt.c:9018 0x5bcb67 instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9086 0x647dcb complete_type(tree_node*) ../../gcc/cp/typeck.c:131 0x57dd30 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:14581 0x586a12 tsubst_expr ../../gcc/cp/pt.c:13415 0x586f6f tsubst_expr ../../gcc/cp/pt.c:12894 0x5864b3 tsubst_expr ../../gcc/cp/pt.c:12880 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/41437] No access control for classes in template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
Shane w.shane.grant at gmail dot com changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #5 from Shane w.shane.grant at gmail dot com ---
This bug still exists for g++ 4.8.1. Crops up regardless of where the template
function is that tries to access the protected/private member:
class Base { void snarf() {} };
struct Derived : public Base
{
template class T
void bar( T t )
{
snarf(); // this is incorrectly marked ok
}
};
[Bug c++/57658] [4.9 Regression] ICE in tsubst_copy, at cp/pt.c:12213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Target Milestone|--- |4.9.0 Summary|ICE in tsubst_copy, at |[4.9 Regression] ICE in |cp/pt.c:12213 |tsubst_copy, at ||cp/pt.c:12213 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thank you! Indeed, it looks like a regression present only in mainline.
[Bug target/57631] [patch] spurious warning for avr interrupts with asm labels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57631 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org --- I can have a look at it, but it might take a month or so until I get back to this issue. If I understand correctly, bottom line of what you need is that avr-gcc does not warn for ISR names that are not of the form __vector* Maybe a new command line option -W[no-]isr-name or similar is more general? The default of the option would be 'on' per default.
[Bug c++/57658] [4.9 Regression] ICE in tsubst_copy, at cp/pt.c:12213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57658 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Appeared with r197811. CC-ing Jason.
[Bug c/57672] New: va_list fixinclude needed for AIX 5.3 sys/types.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57672 Bug ID: 57672 Summary: va_list fixinclude needed for AIX 5.3 sys/types.h Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chasonr at newsguy dot com On AIX 5.3, the system file /usr/include/sys/types.h contains this declaration: #ifndef_VA_LIST #define _VA_LIST typedef char *va_list; #endif This conflicts with the fixincluded va_list in stdarg.h. va_list needs to be declared as __builtin_va_list. GCC 4.8.1 already performs other fixincludes for sys/types.h.
[Bug other/53317] Conversion from __int128 to __float128
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53317 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Fixed for 4.9 by: Author: jsm28 Date: Fri Jun 21 19:08:01 2013 New Revision: 200318 URL: http://gcc.gnu.org/viewcvs?rev=200318root=gccview=rev Log: PR other/53317 gcc/testsuite: * gcc.dg/torture/fp-int-convert-float128-timode-2.c: New test. libgcc: * soft-fp/adddf3.c: Update from glibc. [...] http://gcc.gnu.org/ml/gcc-cvs/2013-06/msg00752.html
[Bug target/57637] Miscompare on 178.galgel in SPEC2000 on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to zhenqiang.chen from comment #3) Created attachment 30330 [details] pr57637.patch This patch breaks Ada bootstrap on x86_64 for me: /tmp/objdir/./prev-gcc/xgcc -B/tmp/objdir/./prev-gcc/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -B/tmp/install49/x86_64-unknown-linux-gnu/lib/ -isystem /tmp/install49/x86_64-unknown-linux-gnu/include -isystem /tmp/install49/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -gtoggle -gnatpg -W -Wall -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I/tmp/gcc-4.9-20130616/gcc/ada -I/tmp/gcc-4.9-20130616/gcc/ada/gcc-interface /tmp/gcc-4.9-20130616/gcc/ada/a-except.adb -o ada/a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[3]: *** [ada/a-except.o] Error 1 make[3]: Leaving directory `/tmp/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/tmp/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/tmp/objdir' make: *** [bootstrap] Error 2
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Fri Jun 21 21:51:41 2013 New Revision: 200321 URL: http://gcc.gnu.org/viewcvs?rev=200321root=gccview=rev Log: 2013-06-21 Tobias Burnus bur...@net-b.de * trans-array.c (gfc_trans_deferred_array): Call the finalizer for nonallocatable local variables. * trans-decl.c (gfc_get_symbol_decl): Add local finalizable vars to the deferred list. (gfc_trans_deferred_vars): Call gfc_trans_deferred_array for those. 2013-06-21 Tobias Burnus bur...@net-b.de * gfortran.dg/finalize_17.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/finalize_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
