[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #4 from jifl-bugzilla at jifvik dot org 2008-07-12 01:53
---
I can't really work out how to provide a testcase as such. To reproduce it all
I'm doing is:
#include
#include
int
main(int argc, char *argv[])
{
std::cout << "Hello world" << std::endl;
return 0;
}
The actual error comes as a result of libstdc++'s interaction with the
surrounding environment when GCC is built with --enable-threads with my OS, and
what that means for the final linked executable running on an ARM board. So
short of giving you my OS and an ARM board I can't think of any way to
construct a piece of code that you can use in your environment to reproduce it.
I guess you're reluctant to try fixing a problem you can't see yourself, so in
that case I'll produce and test a patch, now that I know you're okay with the
__gthread_once approach. And I'll try to keep it as short as possible to avoid
needing to sort out a copyright assignment. In fact, I'll apply for a copyright
assignment now just in case anyway.
Hmm, seems I can't assign this bug to myself :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-07-12 01:22 --- I think maybe this is the right fix, in keeping with what we do now other places. But the error message is not as clear. Index: io.c === --- io.c(revision 137403) +++ io.c(working copy) @@ -694,9 +694,12 @@ data_desc: error = zero_width; goto syntax; } - else - return gfc_notify_std (GFC_STD_F2008, "Fortran F2008: 'G0' in " - "format at %C"); + + if (gfc_notify_std (GFC_STD_F2008, "Fortran F2008: 'G0' in " + "format at %C") == FAILURE) + return FAILURE; + + goto between_desc; } if (u == FMT_ERROR) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #31 from dominiq at lps dot ens dot fr 2008-07-11 22:21 --- Forgot to say that the problem is still there for ppc/intel Darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug libfortran/30617] recursive I/O hangs under OSX
--- Comment #30 from dominiq at lps dot ens dot fr 2008-07-11 22:18 --- >From pr36806 I think the mutex behavior on Darwin needs to be better understood (handled). To answer comment #28, this bug has been "resolved" as "invalid" and not as "undefined"! -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #9 from dominiq at lps dot ens dot fr 2008-07-11 22:10 ---
The executable for the following code
open(unit=11,form='unformatted')
! print *, 'open'
end
also hangs. Stepping with gdb gives:
Breakpoint 1, main (argc=1, argv=0xbfffdb98) at
../../../gcc-4.4-work/libgfortran/fmain.c:11
11 {
(gdb) s
13store_exe_path (argv[0]);
(gdb) s
*__gfortran_store_exe_path (argv0=0xbfffdd04
"/Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out")
at ../../../gcc-4.4-work/libgfortran/runtime/main.c:114
114 if (argv0[0] == '/')
(gdb) s
103 {
(gdb) s
114 if (argv0[0] == '/')
(gdb) s
116 exe_path = argv0;
(gdb) s
117 please_free_exe_path_when_done = 0;
(gdb) s
133 }
(gdb) s
main (argc=1, argv=0xbfffdb98) at ../../../gcc-4.4-work/libgfortran/fmain.c:16
16set_args (argc, argv);
(gdb) s
*__gfortran_set_args (argc=1, argv=0xbfffdb98) at
../../../gcc-4.4-work/libgfortran/runtime/main.c:82
82argc_save = argc;
(gdb) s
83argv_save = argv;
(gdb) s
84 }
(gdb) s
main (argc=1, argv=0xbfffdb98) at ../../../gcc-4.4-work/libgfortran/fmain.c:21
21MAIN__ ();
(gdb) s
25 }
(gdb) s
0x1ee6 in start ()
(gdb) s
Single stepping until exit from function start,
which has no line number information.
0x3014 in dyld_stub_exit ()
(gdb) s
Single stepping until exit from function dyld_stub_exit,
which has no line number information.
0x8fe18b20 in __dyld_fast_stub_binding_helper_interface ()
(gdb) s
Single stepping until exit from function
__dyld_fast_stub_binding_helper_interface,
which has no line number information.
0x8fe18b22 in __dyld_stub_binding_helper_interface ()
(gdb) s
Single stepping until exit from function __dyld_stub_binding_helper_interface,
which has no line number information.
0x8fe18b42 in __dyld_misaligned_stack_error ()
(gdb) s
Single stepping until exit from function __dyld_misaligned_stack_error,
which has no line number information.
0x8fe18b5a in __dyld_stub_binding_helper_interface2 ()
(gdb) s
Single stepping until exit from function __dyld_stub_binding_helper_interface2,
which has no line number information.
0x8fe06e40 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
(gdb) s
Single stepping until exit from function
__dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm,
which has no line number information.
0x8fe0e430 in __dyld__ZNK11ImageLoader15containsAddressEPKv ()
(gdb) s
Single stepping until exit from function
__dyld__ZNK11ImageLoader15containsAddressEPKv,
which has no line number information.
0x8fe13250 in __dyld__ZNK16ImageLoaderMachO13beginSegmentsEv ()
(gdb) s
Single stepping until exit from function
__dyld__ZNK16ImageLoaderMachO13beginSegmentsEv,
which has no line number information.
0x8fe0e457 in __dyld__ZNK11ImageLoader15containsAddressEPKv ()
(gdb) s
Single stepping until exit from function
__dyld__ZNK11ImageLoader15containsAddressEPKv,
which has no line number information.
0x8fe06f22 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
(gdb) s
Single stepping until exit from function
__dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm,
which has no line number information.
0x8fe18b6f in __dyld_stub_binding_helper_interface2 ()
(gdb) s
Single stepping until exit from function __dyld_stub_binding_helper_interface2,
which has no line number information.
0x93b6aeaf in exit ()
(gdb) s
Single stepping until exit from function exit,
which has no line number information.
0xa0a74539 in dyld_stub___cxa_finalize ()
(gdb) s
Single stepping until exit from function dyld_stub___cxa_finalize,
which has no line number information.
0x93b6aeeb in __cxa_finalize ()
(gdb) s
Single stepping until exit from function __cxa_finalize,
which has no line number information.
0x8fe04ee0 in __dyld__ZN4dyld14runTerminatorsEPv ()
(gdb) s
Single stepping until exit from function __dyld__ZN4dyld14runTerminatorsEPv,
which has no line number information.
0x8fe12ee0 in
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContextE ()
(gdb) s
Single stepping until exit from function
__dyld__ZN16ImageLoaderMachO13doTerminationERKN11ImageLoader11LinkContextE,
which has no line number information.
cleanup () at ../../../gcc-4.4-work/libgfortran/runtime/main.c:174
174 {
(gdb) s
0x000fa493 in __i686.get_pc_thunk.bx ()
(gdb) s
Single stepping until exit from function __i686.get_pc_thunk.bx,
which has no line number information.
cleanup () at ../../../gcc-4.4-work/libgfortran/runtime/main.c:175
175 close_units ();
(gdb) s
*__gfortrani_close_units () at ../../../gcc-4.4-work/libgfortran/io/unit.c:688
688 __gthread_mutex_lock (&unit_lock);
(gdb) s
** Simulating stepping into inlined subroutine. **
694 if (__gthread_active_p ())
(gdb) p __gthread_active_p ()
No symbol "__gthread_active_p" in current context.
(gdb) s
689 while (unit_root != NULL)
(gdb) p unit_root
No symbol "unit_root" in current context.
(gdb) s
695 return __gth
[Bug gcov-profile/35720] ICE during build of 4.3.0 on AIX 5.3, function '__gcov_execlp', libgcov.c:858
--- Comment #3 from dje at gcc dot gnu dot org 2008-07-11 22:01 --- Have you tried bootstrapping with a more recent version of GCC than gcc-3.3.3? How did you configure GCC itself? I do not have any problem bootstrapping with GCC 4.0, GCC 4.1, and GCC 4.2. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35720
[Bug java/35485] libjava is disabled by default
--- Comment #2 from dje at gcc dot gnu dot org 2008-07-11 21:57 --- Why build libjava if Java does not work on AIX? -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 21:57:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35485
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #3 from dje at gcc dot gnu dot org 2008-07-11 21:56 --- This patch needs an assignment. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #4 from dje at gcc dot gnu dot org 2008-07-11 21:54 --- Yes, this will substitute "_" for "$", but most programs do not use dollar signs in symbol names, except Java. GNU Java is not supported on AIX, so building libjava does not accomplish much. This is a large patch and requires an assignment. With an assignment, I can consider it. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 21:54:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug fortran/36810] "make" asked me to report this error [GNU Fortran is not working]
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-07-11 21:38 --- As Brian says, get or update GMP. http://gcc.gnu.org/install/prerequisites.html: "GNU Multiple Precision Library (GMP) version 4.1 (or later) Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include." Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36810
[Bug middle-end/36633] [4.4 regression] warning "array subscript is below array bounds" on delete [] with -O2, -Wall
--- Comment #15 from paolo dot carlini at oracle dot com 2008-07-11 21:36 --- I'm tentatively recategorizing as middle-end, if I'm missing something just override me... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug fortran/36810] "make" asked me to report this error [GNU Fortran is not working]
--- Comment #1 from brian at dessent dot net 2008-07-11 21:28 --- Subject: Re: New: "make" asked me to report this error [GNU Fortran is not working] lachele at gmail dot com wrote: > configure:13398: /usr/local/gcc/./gcc/gfortran -B/usr/local/gcc/./gcc/ > -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ > -isystem /usr/local/i6 > 86-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -c > conftest.f >&5 > /usr/local/gcc/./gcc/f951: symbol lookup error: /usr/local/lib/libmpfr.so.1: > undefined symbol: __gmp_get_memory_functions This is your problem. Your GMP is not properly installed. You likely installed a newer GMP in a location not in the default dynamic linker search list and forgot to set LD_LIBRARY_PATH, and it's finding this older version in /usr/local that lacks this symbol. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36810
[Bug libstdc++/36742] [4.2 Regression] g++ -O2 produces wrong code
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-11 21:21 --- (In reply to comment #5) > Isn't this the kind of thing that -Wstrict-aliasing or -Wstrict-aliasing=n > should warn about? Hi Benjamin. My guess is that any possible problem can only have to do with some long standing weaknesses that we have in basic_string and we have big troubles changing without breaking the ABI. Back when #pragma system header didn't work with templates we suppressed a "may" aliasing warning in _S_empty_rep (see comment), and there are chances it may have created actual problems in 4_2-branch, per this PR. Currently, AFAIK, isn't possible to reproduce such problems (Ian committed in 4_3 and mainline very important aliasing-related fixes). Anyway, for the record, this patch of mine: http://gcc.gnu.org/ml/libstdc++/2008-07/msg00051.html fixes this problem in 4_2-branch, passes abi-check. I think it's safe, I don't think code linking vs the amended library can tell that the exported _S_empty_rep_storage array changed type, because it's the same size and the same alignment. If you can double-check may analysis we could imagine committing it, somewhere. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com Last reconfirmed|2008-07-06 13:40:43 |2008-07-11 21:21:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36742
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-07-11 21:20 --- > I think it's actually the same problem, the patch that has fixed it on other > platforms probably doesn't behave the same everywhere. Yep, PE-COFF has a custom binds_local_p hook that doesn't reject DECL_EXTERNAL. That's OK according to http://gcc.gnu.org/ml/gcc/2008-07/msg00205.html Aaron, could you conduct a small experiment? In winnt.c:i386_pe_binds_local_p, just before the 'return true', could you add gcc_assert (!(TREE_CODE (exp) == VAR_DECL && DECL_EXTERNAL (exp))); and see whether it triggers during an Ada bootstrap? If so, what's 'exp'? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug libstdc++/36742] [4.2 Regression] g++ -O2 produces wrong code
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-07-11 20:56 --- Isn't this the kind of thing that -Wstrict-aliasing or -Wstrict-aliasing=n should warn about? I will start to experiment with this, in the thought that we should not actually have stuff in the library with aliasing problems. Not expecting to fix this on the 4.2.x branch though, but if we find issues that can be fixed on trunk/4.3.x, may consider doing so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36742
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-07-11 20:53 --- Hey Jonathan. It would be most helpful if you could come up with a test case. I know, it will be a pain and difficult, etc etc etc yadda yadda yadda, but really this would be enormously helpful. Instead of putting this back to the previous approach, I'd be more inclined to use some kind of gthread_once approach. That's the usual approach that seems to work well when used in locales where order-of-initialization has to be defined with certainty, and in io, etc. As this is present in the 4.2.x toolchain, we should probably adjust the bug report to say this. I suspect this will only be fixed in the 4.3.x toolchain though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
-- gfan at sta dot samsung dot com changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
--- Comment #5 from gfan at sta dot samsung dot com 2008-07-11 20:38 --- Created an attachment (id=15902) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15902&action=view) .c file caused same error of reduced file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug target/36798] internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:12548
--- Comment #4 from gfan at sta dot samsung dot com 2008-07-11 20:37 --- Created an attachment (id=15901) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15901&action=view) .i file cased error of reduced file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36798
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #3 from dberlin at gcc dot gnu dot org 2008-07-11 19:15 --- Subject: Re: [4.4 Regression] Revision 137631 causes many failures I am working on the one x86_64 specific failure first :) On Fri, Jul 11, 2008 at 2:19 PM, hjl dot tools at gmail dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #2 from hjl dot tools at gmail dot com 2008-07-11 18:19 > --- > Some of regressions are run-time failures. As of revision 137717, > there are still: > > FAIL: Array_3 -O3 execution - source compiled test > FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test > FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test > > on both Linux/ia32 and Linux/x86-64. > > > -- > > hjl dot tools at gmail dot com changed: > > What|Removed |Added > > Keywords|missed-optimization | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug fortran/36810] New: "make" asked me to report this error [GNU Fortran is not working]
Sorry but I don't quite know what you want by "triplet". I guessed. I currently have gcc 4.1.1 and I'm trying to build 4.3.1. If that isn't what you wanted, and if the included file doesn't answer, let me know. I suspect the problem is that I haven't installed some needed set of headers or libraries or something. My OS didn't come with g++ or gfortran, and I rpm'd them in so I could install the latest gcc with all the trimmings. I'll keep looking on my own to figure out what happened, but I got the following message, and it asked, so here I am: checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /usr/local/gcc/i686-pc-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/usr/local/gcc' make: *** [all] Error 2 So... I'm copying the requested file. My first guess is that some headers are missing because it says "ac_nonexistent.h: No such file or directory". So, I probably need to install something. I don't think this is something you did wrong. Let me know if you need anything else -- or if it happens to be something you need to fix, or even the name of the package I need to install if you're feeling really generous... :-). I don't see a way to attach a file, so the config file follows -- all 977 lines. I hope I get them all... # more /usr/local/gcc/i686-pc-linux-gnu/libgfortran/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Fortran Runtime Library configure 0.3, which was generated by GNU Autoconf 2.59. Invocation command line was $ /application_downloads/gcc-4.3.1/libgfortran/configure --cache-file=./config.cache --enable-multilib --enable-languages=c,c++,fortran,java,objc --program-transfo rm-name=s,y,y, --with-target-subdir=i686-pc-linux-gnu --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --srcdir=/application_downloads/g cc-4.3.1/libgfortran ## - ## ## Platform. ## ## - ## hostname = newton.woods.ccrc uname -m = i686 uname -r = 2.6.18-8.el5 uname -s = Linux uname -v = #1 SMP Fri Jan 26 14:15:21 EST 2007 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/kerberos/sbin PATH: /usr/kerberos/bin PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /root/bin ## --- ## ## Core tests. ## ## --- ## configure:1390: loading cache ./config.cache configure:1519: checking build system type configure:1537: result: i686-pc-linux-gnu configure:1595: checking for --enable-version-specific-runtime-libs configure:1610: result: no configure:1614: checking for --enable-intermodule configure:1626: result: configure:1655: checking host system type configure:1669: result: i686-pc-linux-gnu configure:1677: checking target system type configure:1691: result: i686-pc-linux-gnu configure:1731: checking for a BSD-compatible install configure:1786: result: /usr/bin/install -c configure:1797: checking whether build environment is sane configure:1840: result: yes configure:1905: checking for gawk configure:1921: found /bin/gawk configure:1931: result: gawk configure:1941: checking whether make sets $(MAKE) configure:1961: result: yes configure:2121: checking whether to enable maintainer-specific portions of Makefiles configure:2130: result: no configure:2244: checking for i686-pc-linux-gnu-gcc configure:2270: result: /usr/local/gcc/./gcc/xgcc -B/usr/local/gcc/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local /i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include configure:2552: checking for C compiler version configure:2555: /usr/local/gcc/./gcc/xgcc -B/usr/local/gcc/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc -linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include --version &5 xgcc (GCC) 4.3.1 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:2558: $? = 0 configure:2560: /usr/local/gcc/./gcc/xgcc -B/usr/local/gcc/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc -linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -v &5 Reading specs from /usr/local/gcc/./gcc/specs Target: i686-pc-linux-gnu Configured with: /application_downloads/gcc-4.3.1/configure Thread model: posix gcc version 4.3.1 (GCC) config
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-07-11 18:44 --- That's the PRE rewrite. I think Danny has access to i686-darwin, but reducing this would be helpful I guess. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug c++/13101] incorrect warning on initialized extern const function pointer
--- Comment #4 from dodji at gcc dot gnu dot org 2008-07-11 18:32 --- A fix for this bug has been committed to trunk in changeset r137723. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13101
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #4 from andreast at gcc dot gnu dot org 2008-07-11 18:31 --- The previously attached natGC.ii is from powerpc-apple-darwin9.3.0. -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 18:31:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #3 from andreast at gcc dot gnu dot org 2008-07-11 18:29 --- Created an attachment (id=15900) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15900&action=view) natGC.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug c++/13699] Extern "C" routine in different namespaces accepted with different exception signature
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-07 04:44:14 |2008-07-11 18:19:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13699
[Bug tree-optimization/36792] [4.4 Regression] Revision 137631 causes many failures
--- Comment #2 from hjl dot tools at gmail dot com 2008-07-11 18:19 --- Some of regressions are run-time failures. As of revision 137717, there are still: FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test on both Linux/ia32 and Linux/x86-64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Keywords|missed-optimization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36792
[Bug c++/13101] incorrect warning on initialized extern const function pointer
--- Comment #3 from dodji at gcc dot gnu dot org 2008-07-11 18:13 --- Subject: Bug 13101 Author: dodji Date: Fri Jul 11 18:12:37 2008 New Revision: 137723 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137723 Log: 2008-07-11 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/13101 * decl.c (grokdeclarator): Warn about initializing variables of storage class 'extern' only after the type of the declarator has been properly computed. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.jason/crash11.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13101
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #7 from andreast at gcc dot gnu dot org 2008-07-11 18:09 --- r137631 seems to be the commit where the hanging starts. I have successful results from 137630 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug c++/31754] Improve column number accuracy in error messages
--- Comment #19 from dodji at gcc dot gnu dot org 2008-07-11 16:50 --- Okay, so the two patches are now committed to trunk in changesets r137716 and r137721. However, given the nature of this enhancement request, I think it will take some on going work to have perfect column number information in the C++ front end when using -fshow-column and eventually enabling that option by default. I will therefore leave the bug open so that we can track the progress of this task. I have also changed the title of the bug to make it more generic. Thanks for reporting this. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Component|other |c++ Summary|Include column number along |Improve column number |line in error messages |accuracy in error messages |main.cpp:5:38 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #18 from dodji at gcc dot gnu dot org 2008-07-11 16:37 --- (From update of attachment 15836) This has been committed to trunk -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15836|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #17 from dodji at gcc dot gnu dot org 2008-07-11 16:36 --- (From update of attachment 15835) This has been committed to trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug bootstrap/36650] Unable to build libgcc, xgcc aborts with a segmentation fault
--- Comment #2 from rwild at gcc dot gnu dot org 2008-07-11 16:34 --- I'm curious: what makes you certain that this bug actually is a duplicate of PR35204? If you're not sure, and I'm not, then let's reopen the bug. Someone who is sure can still mark it as dupe. Thanks, Ralf -- rwild at gcc dot gnu dot org changed: What|Removed |Added CC||rwild at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36650
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #16 from dodji at gcc dot gnu dot org 2008-07-11 16:33 --- Subject: Bug 31754 Author: dodji Date: Fri Jul 11 16:32:29 2008 New Revision: 137721 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137721 Log: 2008-07-11 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/31754 * cp-tree.h (struct cp_decl_specifier_seq): add a location field. It carries the location of the primary type. * parser.c (cp_parser_check_type_definition): update documentation. (cp_parser_check_for_definition_in_return_type, cp_parser_check_for_invalid_template_id, cp_parser_set_decl_spec_type, cp_parser_check_for_definition_in_return_type, cp_parser_diagnose_invalid_type_name, cp_parser_new_expression, cp_parser_explicit_instantiation, cp_parser_type_specifier, cp_parser_simple_type_specifier, cp_parser_omp_for_loop, cp_parser_pragma): use location in error messages. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/semicolon.C trunk/gcc/testsuite/g++.dg/parse/error15.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash16.C trunk/gcc/testsuite/g++.old-deja/g++.law/ctors5.C trunk/gcc/testsuite/g++.old-deja/g++.other/crash25.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
I can't beleive this s.'tocks rise
300% increase to .10, and buys are epxloding. mipx Company Nam'e: M indPix Corpoartion Mra,ket: 0.098 up .002 We called it and it is good. Buy it, and ride" the wave priority Friday- morning.
[Bug tree-optimization/36809] Optimization Sequence
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-11 15:14 --- /home/ammalik/Desktop/MilePost/milepost_gcc_1.0/gcc-4.2.2-ici-1.0-ml-feat-x86/examples/prepared/MiBench-with-MiDataSets/consumer_jpeg_c/src-ccc-ml/../../../../../install/bin/gcc this is not an FSF gcc version. Report to the milepost project. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809
[Bug tree-optimization/36809] Optimization Sequence
--- Comment #4 from abidmuslim at gmail dot com 2008-07-11 15:11 --- Subject: Re: Optimization Sequence I have reported what I am getting using -save-temps option. What else I need to report? Thanks On Fri, Jul 11, 2008 at 4:54 PM, paolo dot carlini at oracle dot com <[EMAIL PROTECTED]> wrote: > > > --- Comment #3 from paolo dot carlini at oracle dot com 2008-07-11 14:54 > --- > The PR is still largely incomplete. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809
[Bug tree-optimization/36809] Optimization Sequence
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-11 14:54 --- The PR is still largely incomplete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809
[Bug tree-optimization/36809] Optimization Sequence
--- Comment #2 from abidmuslim at gmail dot com 2008-07-11 14:51 --- (In reply to comment #1) > Please read about the proper way to submit PRs: > > http://gcc.gnu.org/bugs.html > > and provide the required information. Thanks in advance! > In continuation of the last report. Here are further informations about GCC version 4.2.2 System OpenSuse Here is the complete information about the error. /home/ammalik/Desktop/MilePost/milepost_gcc_1.0/gcc-4.2.2-ici-1.0-ml-feat-x86/examples/prepared/MiBench-with-MiDataSets/consumer_jpeg_c/src-ccc-ml/../../../../../install/bin/gcc -O3 -lm *.c cdjpeg.c: In function read_stdin: cdjpeg.c:148: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. cjpeg.c: In function usage: cjpeg.c:143: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcapimin.c: In function jpeg_write_marker: jcapimin.c:187: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcapistd.c: In function jpeg_write_scanlines: jcapistd.c:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jccoefct.c: In function start_pass_coef: jccoefct.c:101: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jccolor.c: In function null_method: jccolor.c:342: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcinit.c: In function jinit_compress_master: jcinit.c:31: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcmainct.c: In function start_pass_main: jcmainct.c:70: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcmarker.c: In function jinit_marker_writer: jcmarker.c:629: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcmaster.c: In function pass_startup: jcmaster.c:478: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcomapi.c: In function jpeg_abort: jcomapi.c:30: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcparam.c: In function jpeg_quality_scaling: jcparam.c:106: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcprepct.c: In function start_pass_prep: jcprepct.c:79: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jcsample.c: In function start_pass_downsample: jcsample.c:76: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jctrans.c: In function start_pass_coef: jctrans.c:239: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jdapimin.c: In function jpeg_set_marker_processor: jdapimin.c:110: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jdapistd.c: In function jpeg_read_scanlines: jdapistd.c:154: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jdatadst.c: In function init_destination: jdatadst.c:44: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jdatasrc.c: In function init_source: jdatasrc.c:45: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. jdcoefct.c: In function dummy_consume_data: jdcoefct.c
[Bug tree-optimization/36809] Optimization Sequence
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-11 14:25 --- Please read about the proper way to submit PRs: http://gcc.gnu.org/bugs.html and provide the required information. Thanks in advance! -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809
[Bug tree-optimization/36809] New: Optimization Sequence
I am unable to compile the JPEG program with the following optimization phases fixupcfg init_datastructures all_optimizations referenced_vars reset_cc_flags salias ssa alias retslot copyrename ccp fre dce forwprop copyprop mergephi vrp dce dom phicprop phiopt alias tailr profile ch cplxlower sra alias copyrename dom phicprop reassoc dce dse alias forwprop phiopt objsz store_ccp store_copyprop fab alias crited pre alias sink loop loopinit copyprop lim unswitch sccp empty record_bounds ivcanon ifcvt vect veclower2 dceloop cunroll ivopts loopdone reassoc vrp dom phicprop cddce dse forwprop phiopt tailc copyrename uncprop optimized nrv blocks final_cleanup warn_function_noreturn free_datastructures free_cfg_annotations expand rest_of_compilation init_function sibling locators initvals unshare vregs jump cse1 gcse1 bypass ce1 loop2 loop2_init loop2_invariant loop2_unswitch loop2_done cse2 life1 combine ce2 regmove split1 mode-sw life2 lreg greg postreload postreload_cse gcse2 flow2 csa peephole2 ce3 rnreg bbro leaf_regs sched2 stack compute_alignments compgotos free_cfg mach elnotes barriers eh-ranges shorten set_nothrow_function_flags final clean_state However I am able to compile many benchmark programs with this sequence. -- Summary: Optimization Sequence Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: abidmuslim at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36809
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #6 from andreast at gcc dot gnu dot org 2008-07-11 13:57 --- yes, ppc too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-11 13:54
---
Hi again, Mark...
I'm looking into this issue. Does it make sense to you that we need to add a
new operators.def entry? I quickly hacked this addition:
DEF_SIMPLE_OPERATOR ("trait", TRAIT_EXPR, "xx", 2)
and write_expression doesn't crash anymore at the write_string at line 2163
(when (int) code == TRAIT_EXPR)
In case, however, I would need help for the arguments of the above.. Thanks in
advance!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||mark at codesourcery dot com
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org |dot com
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #5 from dominiq at lps dot ens dot fr 2008-07-11 13:53 --- I suspect the problem is specific to Darwin (probably also on ppc: the machinr regress did not test since 2008-07-08 23:54, revision 137630: http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg00776.html). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-11 13:41 --- I cannot reproduce this on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-11 13:36 --- CCing Benjamin... By the way, if the patch would be very short, the full Assignment would not be needed... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2008-07-11 13:26 --- > Could be. You can try the attached patch. The patch does not fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug libstdc++/36801] config/cpu/generic/atomicity_mutex/atomicity.h incorrectly relies on global constructor ordering
--- Comment #1 from jifl-bugzilla at jifvik dot org 2008-07-11 13:03 --- On thinking about this a bit more, I think this would be a regression for the case where __GTHREAD_MUTEX_INIT is used. In the case of __GTHREAD_MUTEX_INIT_FUNCTION, I believe the previous implementation was also susceptible to this issue, although in practice, I don't recall ever seeing it - maybe just luck of link order. So the __GTHREAD_MUTEX_INIT case can probably be addressed by bringing the implementation back to the way it was before. I haven't so far thought of a way to address the __GTHREAD_MUTEX_INIT_FUNCTION case other than the use of __gthread_once(). I would be tempted to provide a patch, but I don't have a copyright assignment for GCC (and of course it takes weeks to sort that out). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36801
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-11 12:58 --- Which has now been checked in on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug other/31754] Include column number along line in error messages main.cpp:5:38
--- Comment #15 from dodji at gcc dot gnu dot org 2008-07-11 12:55 --- Subject: Bug 31754 Author: dodji Date: Fri Jul 11 12:54:22 2008 New Revision: 137716 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137716 Log: 2008-07-11 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/31754 * pt.c, semantic.c: * semantic.c (qualified_name_lookup_error, finish_id_expression): add a location_t parameter so that error message can have a more accurate location. * cp-tree.h: updated prototype * pt.c (tsubst_qualified_id): use location in error messages. * parser.c (cp_parser_postfix_expression, cp_parser_objc_statement, cp_parser_trait_expr, cp_parser_token_is_class_key, cp_parser_uncommitted_to_tentative_parse_p, cp_parser_check_for_invalid_template_id, cp_parser_is_string_literal, cp_parser_error, cp_parser_name_lookup_error, cp_parser_simulate_error, cp_parser_check_decl_spec, cp_parser_check_decl_spec, cp_parser_non_integral_constant_expression, cp_parser_diagnose_invalid_type_name, cp_parser_parse_and_diagnose_invalid_type_name, cp_parser_require_pragma_eol, cp_parser_make_typename_type, cp_parser_string_literal, cp_parser_primary_expression, cp_parser_primary_expression, cp_parser_unqualified_id, cp_parser_nested_name_specifier_opt, cp_parser_postfix_expression, cp_parser_postfix_dot_deref_expression, cp_parser_new_expression, cp_parser_direct_new_declarator, cp_parser_builtin_offsetof, cp_parser_label_for_labeled_statement, cp_parser_statement_seq_opt, cp_parser_jump_statement, cp_parser_block_declaration, cp_parser_simple_declaration, cp_parser_decl_specifier_seq, cp_parser_function_specifier_opt, cp_parser_decltype, cp_parser_mem_initializer_list, cp_parser_mem_initializer, cp_parser_mem_initializer_id, cp_parser_template_parameter, cp_parser_type_parameter, cp_parser_template_id, cp_parser_template_name, cp_parser_template_argument): likewise. Added: trunk/gcc/testsuite/g++.dg/parse/error-column.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/constructor1.C trunk/gcc/testsuite/g++.dg/parse/error1.C trunk/gcc/testsuite/g++.dg/parse/error10.C trunk/gcc/testsuite/g++.dg/parse/error11.C trunk/gcc/testsuite/g++.dg/parse/error12.C trunk/gcc/testsuite/g++.dg/parse/error13.C trunk/gcc/testsuite/g++.dg/parse/error14.C trunk/gcc/testsuite/g++.dg/parse/error15.C trunk/gcc/testsuite/g++.dg/parse/error16.C trunk/gcc/testsuite/g++.dg/parse/error17.C trunk/gcc/testsuite/g++.dg/parse/error18.C trunk/gcc/testsuite/g++.dg/parse/error19.C trunk/gcc/testsuite/g++.dg/parse/error2.C trunk/gcc/testsuite/g++.dg/parse/error20.C trunk/gcc/testsuite/g++.dg/parse/error21.C trunk/gcc/testsuite/g++.dg/parse/error22.C trunk/gcc/testsuite/g++.dg/parse/error23.C trunk/gcc/testsuite/g++.dg/parse/error24.C trunk/gcc/testsuite/g++.dg/parse/error25.C trunk/gcc/testsuite/g++.dg/parse/error26.C trunk/gcc/testsuite/g++.dg/parse/error27.C trunk/gcc/testsuite/g++.dg/parse/error28.C trunk/gcc/testsuite/g++.dg/parse/error29.C trunk/gcc/testsuite/g++.dg/parse/error3.C trunk/gcc/testsuite/g++.dg/parse/error30.C trunk/gcc/testsuite/g++.dg/parse/error31.C trunk/gcc/testsuite/g++.dg/parse/error4.C trunk/gcc/testsuite/g++.dg/parse/error5.C trunk/gcc/testsuite/g++.dg/parse/error6.C trunk/gcc/testsuite/g++.dg/parse/error7.C trunk/gcc/testsuite/g++.dg/parse/error8.C trunk/gcc/testsuite/g++.dg/parse/error9.C trunk/gcc/testsuite/g++.old-deja/g++.pt/niklas01a.C trunk/gcc/testsuite/lib/g++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
[Bug tree-optimization/36765] [4.4 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-07-11 12:45 --- Subject: Bug 36765 Author: rguenth Date: Fri Jul 11 12:44:26 2008 New Revision: 137715 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137715 Log: 2008-07-11 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36765 * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Add aliases from HEAP vars to SMTs. * gcc.c-torture/execute/pr36765.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36765.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765
[Bug tree-optimization/36765] [4.4 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-11 12:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765
[Bug fortran/36808] LOC() produces wrong result on Alpha Linux
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2008-07-11 12:22 --- Please disregard this bug report. It is an error on my part. -- michael dot a dot richmond at nasa dot gov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36808
[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable
--- Comment #7 from bonzini at gnu dot org 2008-07-11 11:58 --- > Wonder why nothing in fwprop.c checks modified_between_p There is code similar to modified_between_p in fwprop.c, that uses def info from the dataflow pass. Part of the fwprop work was to try using the df-scan.c info more than the recursive walks provided by rtlanal.c. That said, the bug should be trivial to fix. I'll try (but not today unfortunately). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753
[Bug fortran/36808] New: LOC() produces wrong result on Alpha Linux
When I run the program listed below on an Alpha workstation I get the following output: ibad1, ibad2, igood1, igood2, loc2, loc1 = -2147483646 -2147483646 2 2 536940884 536940880 On all other platforms the value of ibad1 and ibad2 is 2. Typing gfortran -v produces the following: Using built-in specs. Target: alpha-unknown-linux-gnu Configured with: /home/mrichmon/gcc-4.4-20080704/configure --enable-languages=c,fortran --with-mpfr-include=/home/mrichmon/mpfr-2.3.1 --with-mpfr-lib=/home/mrichmon/mpfr-2.3.1/.libs --prefix=/home/mrichmon/irun --enable-checking=release Thread model: posix gcc version 4.4.0 20080704 (experimental) (GCC) PROGRAM test COMMON /com1/ i1, i2 loc1 = LOC(i1) loc2 = LOC(i2) igood1 = (loc2 - loc1)/2 igood2 = (LOC(i2) - LOC(i1))/2 ibad1 = (LOC(i2) - loc1)/2 ibad2 = (loc2 - LOC(i1))/2 print *, "ibad1, ibad2, igood1, igood2, loc2, loc1 =", ibad1,ibad2,igood1,igood2,loc2,loc1 END PROGRAM test -- Summary: LOC() produces wrong result on Alpha Linux Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36808
[Bug middle-end/36770] PowerPC missed autoincrement opportunity
--- Comment #3 from bonzini at gnu dot org 2008-07-11 11:56 --- Yes, the code produced shows that something (probably fwprop, I trust Andrew though I'd like to see dumps) is turning the GIMPLE code temp = a[0]; a[1] = temp; temp++; into something harder to optimize. It might be also a pass-ordering problem. -- bonzini at gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|PowerPC generated PTR code |PowerPC missed autoincrement |inefficiency|opportunity http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770
[Bug tree-optimization/36807] [4.4 Regression] 176.gcc miscompares
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36807
[Bug tree-optimization/36807] New: [4.4 Regression] 176.gcc miscompares
Happens since the PRE rewrite. Seen on x86_64 and ia64 with -O2 and higher. Not seen for 403.gcc (SPEC 2k6), so might be a 176.gcc bug. -- Summary: [4.4 Regression] 176.gcc miscompares Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36807
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-11 11:12 --- Of course I meant mangling not demangling -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug c++/36797] ICE on SFINAE and __is_empty
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-11 11:08 --- Funny, the problem happen very late. in the demangler. A "workaround" is using std::is_empty ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 11:08:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36797
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
-- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 11:01:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug middle-end/35204] [4.3/4.4 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #30 from marion dot deveaud at siemens dot com 2008-07-11 11:00 --- *** Bug 36650 has been marked as a duplicate of this bug. *** -- marion dot deveaud at siemens dot com changed: What|Removed |Added CC||marion dot deveaud at ||siemens dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug bootstrap/36650] Unable to build libgcc, xgcc aborts with a segmentation fault
--- Comment #1 from marion dot deveaud at siemens dot com 2008-07-11 11:00 --- *** This bug has been marked as a duplicate of 35204 *** -- marion dot deveaud at siemens dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36650
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug target/36806] [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-11 10:59 --- Created an attachment (id=15899) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15899&action=view) patch Could be. You can try the attached patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug target/36806] New: [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9
Starting from revision 137644 up to 137712 (137615 is working), unformatted IOs in FORTRAN give hanging executables. For instance, the executable from the following code data=-1 ! print *, 'before' write(11) data ! print *, 'after' end hangs after creating an empty fort.11 file: [ibook-dhum] f90/bug% time a.out ^C0.000u 0.002s 0:51.34 0.0%0+0k 0+1io 0pf+0w If I compile the code with gfortran 4.3.1 and -S, then compile the assembly with gfortran 4.4.0, I get: Bus error 0.000u 0.002s 0:00.91 0.0% 0+0k 0+1io 0pf+0w The crash occurs in MAIN__ () (gdb) s main (argc=1, argv=0xbfffdb98) at ../../../gcc-4.4-work/libgfortran/fmain.c:21 21MAIN__ (); (gdb) s Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x 0x in ?? () Now if I compile with gfortran 4.4.0 and -S, then compile the assembly with gfortran 4.3.1, the executable gives the right fort.11 file. So it seems that that something is miscompiled in libgfortran. Could it be related to pr36765? -- Summary: [4.4 Regression] Broken unformatted IOs at rev. 137644 on i686-apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36806
[Bug tree-optimization/36765] [4.4 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-07-11 10:42 ---
Turns out this is a problem I already have a patch in my queue. Reduced
testcase:
int __attribute__((noinline))
foo(int i)
{
int *p = __builtin_malloc (4 * sizeof(int));
*p = 0;
p[i] = 1;
return *p;
}
extern void abort (void);
int main()
{
if (foo(0) != 1)
abort ();
return 0;
}
The bug is latent since forever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765
stock watch alert
Incre asing to 10 cents, and volume continues" to rise. T"ick: mpix Croopration-name: Mind Pix Per sahre price: 10 cents up .002 cents The mo-ve is happening. Tkae your action, before you miss it.
[Bug tree-optimization/36765] [4.4 Regression] Revision 137573 miscompiles 464.h264ref in SPEC CPU 2006
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-11 10:15 --- Thanks for reducing this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-11 10:15:59 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765
[Bug c++/36805] New: compilation fails when pointer to template-functions are returned by ?-operator
The following program fails to compile:
template void f()
{}
void g1() {}
void g2() {}
typedef void(*ptrType)();
int main(int argc, char** argv)
{
ptrType p = argc == 1 ? &f : &f; //<-- error
ptrType p2 = argc == 1 ? &g1 : &g2;
ptrType p1;
if (argc== 1)
p1 = &f;
else
p1 = &f;
}
fptr.cpp:11: error: address of overloaded function with no contextual type
information
As f and f are the same pointer-type, this shouldn't fail. It
doesn't fail for non-template-functions and it aslo doesn't fail if an
if/else-clause is used.
tried with gcc-4.3.1, 4.2.4 and 4.1.2 on x86_64 and 4.2.3 on powerpc-uclibc
--
Summary: compilation fails when pointer to template-functions are
returned by ?-operator
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbuergel at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36805
[Bug c/36804] New: For-loop never exits in gcc for ARM.
I've made a small example where a for-loop never exits when it should. I have
tried gcc 4.2.1, 4.2.4 and 4.3.1 with the same result. Gcc 4.1.1 works.
GCC is configured with:
../configure --prefix=/opt/arm-linux/arm --host=i686-linux-gnu
--target=arm-linux-gnu --build=i686-linux-gnu
--includedir=/opt/arm-linux/arm/arm-linux-gnu/usr/include --enable-multilib
--enable-threads --disable-nls --enable-shared --enable-languages=c,c++
--enable-__cxa_atexit --enable-c99 --enable-long-long
The example is compiled with:
arm-linux-gnu-gcc -O1 -Wall -march=armv5 -o bug main.c
main.c:
---
#include
#include
#include
struct dummy {
unsigned short count;
unsigned short options;
};
unsigned foo (unsigned x)
{
return x << 1;
}
int main (int argc, char* argv[])
{
struct dummy *d;
unsigned count;
unsigned i;
unsigned short* w;
unsigned phase;
unsigned long long val;
d = malloc (sizeof(struct dummy));
d->count = 1;
d->options = 0;
count = d->count;
w = malloc (sizeof(unsigned short));
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=36804
[Bug c++/9381] attribute on member function pointer have no effect
--- Comment #11 from techrazy dot yang at gmail dot com 2008-07-11 07:43 --- Created an attachment (id=15898) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15898&action=view) The testcase fail g++ 4.3.0 >From this bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11893, we know the typeof operator make all things correctly. But in gcc 4.3.0, this operator failed, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9381
[Bug c++/9381] attribute on member function pointer have no effect
--- Comment #10 from techrazy dot yang at gmail dot com 2008-07-11 07:41 --- (In reply to comment #1) > From: "Christian Ehrhardt" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: c++/9381: stdcall attribute ignored in member function pointer > type > Date: Tue, 21 Jan 2003 15:10:30 +0100 > > On Tue, Jan 21, 2003 at 04:52:51AM -, [EMAIL PROTECTED] wrote: > > The attached file is miscompiled since the stdcall attribute is ignored in > the fp type definition. The result it that in the function bar the > parameters are popped from the stack even though they have already been > removed by the called fucntion (f1 in this case). > > The answer to this non bug used to be: "The placement of your __attribute__ > is wrong". This should be the proper placement: > > typedef int (__attribute__ ((stdcall)) foo::*fp)(int); > > However, with the new parser this gives a parse error :-( > The following gives a warning with 3.4 but works with all gcc versions, it > is documented as an extension though: > > typedef int (foo::*__attribute__ ((stdcall)) fp) (int); I am afraid, but this did not work in gcc 4.3.0, now. I add this, but still failed with a SIGFAULT... I attach my litter test case file, please try to compile it with g++ 4.3.0, and it will fail... -- techrazy dot yang at gmail dot com changed: What|Removed |Added CC||techrazy dot yang at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9381
