[Bug target/55712] cpuinfo.c doesn't compile for x86-64 with medium memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55712 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #29039|0 |1 is obsolete|| --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-12-27 08:11:40 UTC --- Created attachment 29053 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29053 Patch that preserves %rbx over cpuid insn Alternative patch that avoids changing %rbx PIC register.
[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-27 08:41:13 UTC --- Let's reopen this: testcase in Comment #1 isn't fixed yet.
[Bug inline-asm/55775] [4.8 Regression] ICE when building pari
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55775 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-27 08:45:48 UTC --- Fixed.
[Bug java/55764] [4.8 Regression] ICE when building frysk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5
[Bug tree-optimization/55812] thread_local with either a ctor or dtor causes a function call every time through a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55812 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2012-12-27 09:38:15 UTC --- (In reply to comment #3) I think Jason had proposed an attribute for these function calls but it was rejected IIRC. http://gcc.gnu.org/ml/gcc/2012-10/msg00024.html
[Bug target/55816] New: Options from command line are added to target arch attribute eventhough they are in contradiction with that target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55816
Bug #: 55816
Summary: Options from command line are added to target arch
attribute eventhough they are in contradiction with
that target
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aivch...@gmail.com
CC: aivch...@gmail.com, hjl.to...@gmail.com,
ubiz...@gmail.com
Target: i?86-*-* x86_64-*-*
On x86 android gcc we have -msse3 turned on by default, that leads
gcc/testsuite/gcc.target/i386/funcspec-10.c to fail:
extern int foo (int) __attribute__((__target__(arch=i386)));
int
foo (int x)
{
if (x 0)
x = 1;
return x;
}
because compiler produces CMOV, eventhough foo has been declared as arch=i386.
The problem is that isa option from command line (-msse3) is added to arch=i386
within this function.
I believe that there could be other cases when that would be more critical.
Should we turn off enabled from command line isa's inside the function with
target arch attribute, if those isa's are in contradiction with that arch?
[Bug libstdc++/55817] New: void return value in std::vectorT::insert() c++11 should be an iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817
Bug #: 55817
Summary: void return value in std::vectorT::insert() c++11
should be an iterator
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jobst.zieb...@mailbox.tu-dresden.de
Created attachment 29054
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29054
Preprocessed file as created by -save-temps
GCC version: 4.7.1
System type: Mac OS X 10.6.8 (i386-apple-darwin10.8.0)
GCC configure options: --prefix=/Users/JayZ/usr --enable-lto --enable-objc-gc
--disable-multilib
Error occurs by command: ~/usr/bin/g++ --std=c++11 insert_error.cpp
Error message (unfortunately in German - but message should be clear):
insert_error.cpp: In Funktion »int main()«:
insert_error.cpp:8:64: Fehler: Umwandlung von »void« in nicht-skalaren Typen
»std::vectorint::iterator {aka __gnu_cxx::__normal_iteratorint*,
std::vectorint }« angefordert
- A complaint about conversion from type void to type
std::vectorint::iterator
Expected behaviour:
Flawless compilation and no error message.
As documented by the following websites:
- http://www.cplusplus.com/reference/vector/vector/insert/; (C++11 section)
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf; (page
726)
Unless I misread the c++11 library requirements (which I hope I didn't) this
seems to be an error in the vector implementation. The method insert() should
return an iterator.
Sincerely
Jobst Ziebell
[Bug libstdc++/55817] void return value in std::vectorT::insert() c++11 should be an iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55817 --- Comment #1 from Jobst.Ziebell at mailbox dot tu-dresden.de 2012-12-27 16:32:32 UTC --- Created attachment 29055 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29055 The testcase
[Bug middle-end/55814] Missed optimization with short-circuit evaluation of always evaluated comparisons/loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55814
--- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-12-27
17:23:54 UTC ---
An even more pronounced test case, where we could sink
a lot more stores, which in fact could lead to moving
a whole loop:
logical function bar(a,b,c)
logical, intent(in) :: a, b
logical, intent(in), dimension(3) :: c
bar = a .and. b .and. any(c)
end
This is translated by the Fortran FE to
bar (logical(kind=4) restrict a, logical(kind=4) restrict b,
logical(kind=4)[3] * restrict c)
{
logical(kind=4) __result_bar;
{
logical(kind=4) test.0;
test.0 = 0;
{
integer(kind=8) S.1;
S.1 = 1;
while (1)
{
if (S.1 3) goto L.2;
if (NON_LVALUE_EXPR (*c)[S.1 + -1])
{
test.0 = 1;
goto L.1;
}
S.1 = S.1 + 1;
}
L.2:;
}
L.1:;
__result_bar = (*a *b) test.0;
}
return __result_bar;
}
which the middle-end then doesn't optimize - there would
be no need to evaluate the loop if either a or b were false.
[Bug debug/55586] Incorrect .debug_line section for function with variable number of arguments in PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55586 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-27 CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2012-12-27 17:50:31 UTC --- Confirmed.
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 18:07:39 UTC --- Author: jvdelisle Date: Thu Dec 27 18:07:33 2012 New Revision: 194733 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194733 Log: 2012-12-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/48976 * io/inquire.c (inquire_via_unit): Set user stream inquiry variable to appropriate value based on unit access method. (inquire_via_filename): Since filename is not associated with an open unit, set stream inquiry to UNKNOWN. * io/io.h: Define inquire stream parameters. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 18:09:20 UTC --- Author: jvdelisle Date: Thu Dec 27 18:09:13 2012 New Revision: 194734 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194734 Log: 2012-12-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/48976 * gfortran.h (gfc_inquire struct): Add pointer for inquire stream. * io.c (io_tag): Add tag for inquire stream. (match_inquire_element): Add matcher for new tag. (gfc_resolve_inquire): Resolve new tag. * ioparm.def: Add new parameter for inquire stream. * trans-io.c (gfc_trans_inquire): Add tranlste code for inquire stream. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 19:24:47 UTC --- Author: jvdelisle Date: Thu Dec 27 19:24:44 2012 New Revision: 194736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194736 Log: 2012-12-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/48976 * gfortran.dg/inquire_15.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/inquire_15.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 20:13:50 UTC --- Author: jvdelisle Date: Thu Dec 27 20:13:35 2012 New Revision: 194738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194738 Log: 2012-12-27 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/48960 * gfortran.dg/newunit_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/newunit_3.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/48960] OPEN statement modifies NEWUNIT variable on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48960 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 20:14:56 UTC --- Closing
[Bug fortran/48976] INQUIRE with STREAM= not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48976 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-27 20:15:58 UTC --- Closing
[Bug other/9346] make uninstall does not remove all files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346 Koutheir Attouchi koutheir at gmail dot com changed: What|Removed |Added CC||koutheir at gmail dot com --- Comment #5 from Koutheir Attouchi koutheir at gmail dot com 2012-12-27 22:41:57 UTC --- (In reply to comment #3) make uninstall no longer supported so changing to enhancement and It makes no sense to say uninstallation is not supported if installation is supported! If I am able to install from source then I must be able to clean up my system when I choose to. Uninstallation is optional almost only in malicious code... Any respectful software must provide at least a basic way to uninstall it before upgrading it or for removing it entirely.
[Bug fortran/55818] New: Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 Bug #: 55818 Summary: Reading a REAL from a file which doesn't end in a new line fails Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Reported by Elzbieta Burnett at https://groups.google.com/d/msg/comp.lang.fortran/_HBMfv1lR3w/7b28oDQH2sUJ The following program works for INTEGER but not for REAL. See also c.l.f for a similar example. The file looks like 1\n2\n3 without a \n after the 3. That fails for list-directed read. implicit none integer :: stat !integer :: var ! works real:: var ! fails open(99, file=test.dat, access=stream, form=unformatted, status=new) write(99) 1, new_line() write(99) 2, new_line() write(99) 3 close(99) open(99, file=test.dat) read (99,*, iostat=stat) var if (stat /= 0 .or. var /= 1) call abort() read (99,*, iostat=stat) var if (stat /= 0 .or. var /= 2) call abort() read (99,*, iostat=stat) var ! FAILS: stat /= 0 if (stat /= 0 .or. var /= 3) call abort() ! aborts here close(99, status=delete) end
[Bug other/9346] make uninstall does not remove all files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-28 00:04:17 UTC --- (In reply to comment #5) (In reply to comment #3) make uninstall no longer supported so changing to enhancement and It makes no sense to say uninstallation is not supported if installation is supported! If I am able to install from source then I must be able to clean up my system when I choose to. Uninstallation is optional almost only in malicious code... Any respectful software must provide at least a basic way to uninstall it before upgrading it or for removing it entirely. uninstall is hard to support really because it means backing up everything install will overwrite. This is hard to do really. Also it is easy to install in a clean directory and just remove that directory if you want uninstall GCC.
[Bug c/55819] New: Conflicting declaration of getcwd breaks mingw-w64 compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55819 Bug #: 55819 Summary: Conflicting declaration of getcwd breaks mingw-w64 compile Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: lailavrazda1...@gmail.com Output when compiling on x86_64-unknown-linux-gnu for x86_64-w64-mingw32: x86_64-w64-mingw32-g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic -I../../gcc-4.8.0/gcc -I../../gcc-4.8.0/gcc/c -I../../gcc-4.8.0/gcc/../include -I../../gcc-4.8.0/gcc/../libcpp/include -I/root/win64-build/native/include -I/root/win64-build/native/include -I/root/win64-build/native/include -I../../gcc-4.8.0/gcc/../libdecnumber -I../../gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc-4.8.0/gcc/../libbacktrace -DCLOOG_INT_GMP -I/root/win64-build/native/include ../../gcc-4.8.0/gcc/c/c-lang.c -o c/c-lang.o In file included from ../../gcc-4.8.0/gcc/c/c-lang.c:24:0: ../../gcc-4.8.0/gcc/system.h:426:36: error: declaration of C function 'char* getcwd(char*, size_t)' conflicts with In file included from /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/unistd.h:10:0, from ../../gcc-4.8.0/gcc/system.h:256, from ../../gcc-4.8.0/gcc/c/c-lang.c:24: /usr/lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/io.h:266:17: error: previous declaration 'char* getcwd(char*, int)' here make[1]: *** [c/c-lang.o] Error 1 make[1]: Leaving directory `/root/win64-build/src/gcc-build/gcc' make: *** [all-gcc] Error 2
[Bug fortran/55818] Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-28 01:05:18 UTC --- Possible patch, testing. Index: list_read.c === --- list_read.c(revision 194731) +++ list_read.c(working copy) @@ -1429,6 +1429,7 @@ read_real (st_parameter_dt *dtp, void * dest, int goto got_sign; CASE_SEPARATORS: +case EOF: unget_char (dtp, c);/* Single null. */ eat_separator (dtp); return; @@ -1484,6 +1485,7 @@ read_real (st_parameter_dt *dtp, void * dest, int goto got_repeat; CASE_SEPARATORS: +case EOF: if (c != '\n' c != ',' c != '\r' c != ';') unget_char (dtp, c); goto done;
[Bug fortran/55818] Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2012-12-28 01:07:09 UTC --- Assigning to myself
[Bug other/9346] make uninstall does not remove all files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346 --- Comment #7 from Koutheir Attouchi koutheir at gmail dot com 2012-12-28 01:15:24 UTC --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #3) make uninstall no longer supported so changing to enhancement and It makes no sense to say uninstallation is not supported if installation is supported! If I am able to install from source then I must be able to clean up my system when I choose to. Uninstallation is optional almost only in malicious code... Any respectful software must provide at least a basic way to uninstall it before upgrading it or for removing it entirely. uninstall is hard to support really because it means backing up everything install will overwrite. This is hard to do really. Also it is easy to install in a clean directory and just remove that directory if you want uninstall GCC. I understand these implications (which are classic installers matters). Instead of merely saying it's optional just make it clear in the README or INSTALL files or ./configure --help output that If you want to uninstall gdb for whatever reason then please install it in a clean directory to be removed manually, because uninstallation is NOT supported.. This will make it a bit harder to install gdb (because PATH and other environment variables will need to be modified...) but at least it says what should be done. I think this more correct than the optional reason.
[Bug preprocessor/55820] New: cpp: unterminated argument list invoking macro BAR for #include in macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820 Bug #: 55820 Summary: cpp: unterminated argument list invoking macro BAR for #include in macro Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: ger...@pfeifer.com The following was reported to me, and while I am not sure it is fully ISO C, I am told clang accepts this. % more test.* :: test.c :: #define BAR(x) x BAR( #include test.h ) :: test.h :: foo % ~/gcc-x86_64/bin/gcc -E test.c /dev/null In file included from test.c:5:0: test.h:1:0: error: unterminated argument list invoking macro BAR foo ^
[Bug libquadmath/55821] New: Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821 Bug #: 55821 Summary: Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath AssignedTo: unassig...@gcc.gnu.org ReportedBy: ger...@pfeifer.com On platforms that do not support libquadmath, GCC release tarballs still install libquadmath.info. This was reported to me for sparc64-unknown-freebsd* and powerpc-unknown-freebsd*, I am pretty sure it applies to all platforms that do not support libquadmath. This applies to releases only, not for our weekly snapshots, since (only) the former contain pre-built .info files. Actual outcome: libquadmath.info is installed unconditionally. Desired outcome: libquadmath.info is only installed where libquadmath is support (as correctly done already by our weekls snapshots, though not our releases).
[Bug preprocessor/55820] cpp: unterminated argument list invoking macro BAR for #include in macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55820 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-28 04:07:14 UTC --- yes this code is undefined at compile time. GCC used to reject #define in a macro usage but it was decided we will accept that. I can find the old bugs if needed.
