[Bug modula2/92647] New: Internal enum may conflict with the time() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92647
Bug ID: 92647
Summary: Internal enum may conflict with the time() function
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: unassigned at gcc dot gnu.org
Reporter: pashev.igor at gmail dot com
Target Milestone: ---
Created attachment 47344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47344&action=edit
Rename "time" to "tiempo"
In the `gm2/mc-boot/GRTint.c` file there is an enum `typedef enum {input,
output, time} VectorType;` which may conflict with the `time()` function that
could be brought in the scope by accident. It happened to me when building for
Dyson [1] since it not using GNU libc. I had to rename "time" to "tiempo" to
fix that :)
[1] https://www.osdyson.org
[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615 Igor Pashev changed: What|Removed |Added CC||pashev.igor at gmail dot com --- Comment #1 from Igor Pashev --- Here is what I see on illumos: 21071:gij-4.7 -classpath build/bootstrap/eclipse-ecj.jar:/usr/share/ant/lib/ - lwp# 1 / thread# 1 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e167b06 mutex_lock_impl () + 156 fd7f4e167bdb mutex_lock () + b fd7f42984a81 _Z13_Jv_MutexLockP11_Jv_Mutex_t () + 51 00733840 () f2f1e001 () () 0002 () - lwp# 2 / thread# 2 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e168f8f cond_wait_queue () + 4f fd7f4e1695e2 __cond_wait () + b2 fd7f4e169612 cond_wait () + 22 fd7f4e169649 pthread_cond_wait () + 9 fd7f42984c1c _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + 13c () - lwp# 3 / thread# 3 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e167b06 mutex_lock_impl () + 156 fd7f4e167bdb mutex_lock () + b fd7f42984c3d _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + 15d () - lwp# 4 / thread# 4 fd7f42984bc7 _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + e7 0100 () I also tried to build openjdk6, and gcj "compiles" 250 files forever :-) I've waited for day or two :-\
[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615 --- Comment #2 from Igor Pashev --- See also #34574
[Bug libgcj/34574] wait() call hangs in _Jv_CondWait taking the monitor with it causing the application to hang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34574 Igor Pashev changed: What|Removed |Added CC||pashev.igor at gmail dot com --- Comment #2 from Igor Pashev --- I can confirm it on illumos with gcc 4.7. Tjis prevent me from building openjdk anf ecj. For ecj: 21071:gij-4.7 -classpath build/bootstrap/eclipse-ecj.jar:/usr/share/ant/lib/ - lwp# 1 / thread# 1 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e167b06 mutex_lock_impl () + 156 fd7f4e167bdb mutex_lock () + b fd7f42984a81 _Z13_Jv_MutexLockP11_Jv_Mutex_t () + 51 00733840 () f2f1e001 () () 0002 () - lwp# 2 / thread# 2 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e168f8f cond_wait_queue () + 4f fd7f4e1695e2 __cond_wait () + b2 fd7f4e169612 cond_wait () + 22 fd7f4e169649 pthread_cond_wait () + 9 fd7f42984c1c _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + 13c () - lwp# 3 / thread# 3 fd7f4e16f427 lwp_park (0, 0, 0) fd7f4e167b06 mutex_lock_impl () + 156 fd7f4e167bdb mutex_lock () + b fd7f42984c3d _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + 15d () - lwp# 4 / thread# 4 fd7f42984bc7 _Z12_Jv_CondWaitP23_Jv_ConditionVariable_tP11_Jv_Mutex_txi () + e7 0100 ()
[Bug preprocessor/51670] New: [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 Bug #: 51670 Summary: [4.7.0] conflicts with new declaration with 'C++' linkage Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: pashev.i...@gmail.com Created attachment 26174 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26174 Build log G++ 4.7.0 (trunk from 20111219) compiler doesn't work on Solaris (x86_64-pc-solaris2.11). But G++ 4.6.2 does. Steps to reproduce: # /usr/gcc/4.7/bin/g++ test.cpp -o test # FAIL # /usr/gcc/4.6/bin/g++ -m64 test.cpp -o test # WIN Build log is attached. Trivial test program and preprocessed files are below.
[Bug preprocessor/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #1 from Igor Pashev 2011-12-23 23:47:20 UTC --- Created attachment 26175 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26175 Trivial test program
[Bug preprocessor/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #2 from Igor Pashev 2011-12-23 23:48:01 UTC --- Created attachment 26176 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26176 /usr/gcc/4.6/bin/g++ -m64 -E test.cpp -o test.46
[Bug preprocessor/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #3 from Igor Pashev 2011-12-23 23:48:35 UTC --- Created attachment 26177 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26177 /usr/gcc/4.7/bin/g++ -E test.cpp -o test.47
[Bug preprocessor/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #4 from Igor Pashev 2011-12-23 23:49:12 UTC --- Created attachment 26178 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26178 Diff of test.46 and test.47
[Bug preprocessor/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #5 from Igor Pashev 2011-12-23 23:51:31 UTC --- Sorry, GCC 4.7 is installed in /usr, not in /usr/gcc/4.7
[Bug target/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 --- Comment #7 from Igor Pashev 2011-12-24 00:27:10 UTC --- Created attachment 26179 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26179 Diff of macros
[Bug target/51670] [4.7.0] conflicts with new declaration with 'C++' linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51670 Igor Pashev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Igor Pashev 2011-12-24 18:39:49 UTC --- (In reply to comment #8) > This is supposed to be handled by fixinclude in the solaris_cxx_linkage rule. > Can you try and see why it isn't applied? Well, I'm a little confused. Directory /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/include-fixed was mostly empty. I run /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/install-tools/mkheaders, and now that directory is full on fixed headers. Now g++ does work. BTW GCC 4.6.2 in Solaris ships all possible fixed headers :-\
[Bug c++/55557] New: g++ 4.7 does not issue a warning on the first auto_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Bug #: 7
Summary: g++ 4.7 does not issue a warning on the first auto_ptr
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pashev.i...@gmail.com
Here is a C++ source code:
# cat -n test.cpp
1 #include
2 using namespace std;
3
4 int main(int argc, char **argv)
5 {
6 auto_ptr x;
7 auto_ptr y;
8 auto_ptr z;
9
10 return 0;
11 }
Command line to compile it with C++11 standard:
g++-4.7 -std=gnu++11 -Wall -Wextra -Wdeprecated-declarations -pedantic
test.cpp
Here is the g++ output:
test.cpp: In function ‘int main(int, char**)’:
test.cpp:7:19: warning: ‘auto_ptr’ is deprecated (declared at
/usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
test.cpp:8:19: warning: ‘auto_ptr’ is deprecated (declared at
/usr/include/c++/4.7/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
test.cpp: At global scope:
test.cpp:4:5: warning: unused parameter ‘argc’ [-Wunused-parameter]
test.cpp:4:5: warning: unused parameter ‘argv’ [-Wunused-parameter]
A warning about auto_ptr being deprecated has been issued only for y and z. I
expect a warning for x too.
Moreover, if I leave only one auto_ptr (say, x) I will see no deprecation
warning at all.
It is expected to see warning on every auto_ptr instantiation.
[Bug c++/55557] g++ 4.7 does not issue a warning on the first auto_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 --- Comment #1 from Igor Pashev 2012-12-01 20:46:12 UTC --- # g++-4.7 --version g++-4.7 (Debian 4.7.2-4) 4.7.2 Copyright (C) 2012 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.
[Bug go/67722] New: Misplaced #endif in libgo/runtime/lfstack.goc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67722
Bug ID: 67722
Summary: Misplaced #endif in libgo/runtime/lfstack.goc
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: pashev.igor at gmail dot com
CC: cmang at google dot com
Target Milestone: ---
libgo fails to build on illumos. Here is a trivial patch:
Index: gcc-5/src/libgo/runtime/lfstack.goc
===
--- gcc-5.orig/src/libgo/runtime/lfstack.goc
+++ gcc-5/src/libgo/runtime/lfstack.goc
@@ -29,7 +29,6 @@ static inline LFNode* lfUnpack(uint64 va
// So we use 17msb of pointers as ABA counter.
# define PTR_BITS 47
# endif
-# endif
# define CNT_BITS (64 - PTR_BITS + 3)
static inline uint64 lfPack(LFNode *node, uintptr cnt) {
return ((uint64)(node)<<(64-PTR_BITS)) | (cnt&(((1<> CNT_BITS) << 3);
}
+# endif /* __sparc__ ... */
#else
static inline uint64 lfPack(LFNode *node, uintptr cnt) {
return ((uint64)(uintptr)(node)<<32) | cnt;
[Bug libgcj/34574] wait() call hangs in _Jv_CondWait taking the monitor with it causing the application to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34574 --- Comment #4 from Igor Pashev --- I can reploduce it with Debian/amd64 and gcc4.9: Thread 3 (Thread 0x7f43f8764700 (LWP 16318)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f445d4f74b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f445d4f72e0 in __GI___pthread_mutex_lock (mutex=0x7f4461280ea0) at ../nptl/pthread_mutex_lock.c:79 #3 0x7f445ef93684 in _Jv_MutexLock(_Jv_Mutex_t*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #4 0x7f445ef8851c in _Jv_MonitorEnter () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #5 0x004030fd in JvSynchronize::JvSynchronize (this=0x7f43f8763de0, o=@0x6057e0: 0x7f44612cbc60) at /usr/include/c++/4.9/gcj/cni.h:99 #6 0x00402f25 in env_test::foo () at TestJVSynchronise19thDec.cc:18 #7 0x00402ef3 in env_test.run()void () at env_test.java:8 #8 0x00402430 in WorkerThread.run()void () at ThreadPool.java:154 #9 0x7f445ef8c16b in _Jv_ThreadRun(java::lang::Thread*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #10 0x7f445ef93ff7 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #11 0x7f445f7bb748 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #12 0x7f445d4f50a4 in start_thread (arg=0x7f43f8764700) at pthread_create.c:309 #13 0x7f445cc02ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f43f7f63700 (LWP 16319)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f445d4f74b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f445d4f72e0 in __GI___pthread_mutex_lock (mutex=0x7f4461280ea0) at ../nptl/pthread_mutex_lock.c:79 #3 0x7f445ef93684 in _Jv_MutexLock(_Jv_Mutex_t*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #4 0x7f445ef8851c in _Jv_MonitorEnter () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #5 0x004030fd in JvSynchronize::JvSynchronize (this=0x7f43f7f62de0, o=@0x6057e0: 0x7f44612cbc60) at /usr/include/c++/4.9/gcj/cni.h:99 #6 0x00402f25 in env_test::foo () at TestJVSynchronise19thDec.cc:18 #7 0x00402ef3 in env_test.run()void () at env_test.java:8 #8 0x00402430 in WorkerThread.run()void () at ThreadPool.java:154 #9 0x7f445ef8c16b in _Jv_ThreadRun(java::lang::Thread*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #10 0x7f445ef93ff7 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #11 0x7f445f7bb748 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #12 0x7f445d4f50a4 in start_thread (arg=0x7f43f7f63700) at pthread_create.c:309 #13 0x7f445cc02ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f44612ef740 (LWP 16118)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f445ef9380b in _Jv_CondWait(_Jv_ConditionVariable_t*, _Jv_Mutex_t*, long long, int) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #2 0x7f445ef88ab5 in void java::lang::Object::wait(long long, int) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #3 0x00402bd5 in Done.waitDone()void () at ThreadPool.java:213 #4 0x00402a2e in ThreadPool.complete()void () at ThreadPool.java:100 #5 0x0040305f in main (argc=1, argv=0x7fff5fac12e8) at TestJVSynchronise19thDec.cc:39
[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615
--- Comment #3 from Igor Pashev ---
I managed to work around this issue by disabling multithreaded compilation in
ECJ:
---
ecj-3.10.1.orig/src/org.eclipse.jdt.core/org/eclipse/jdt/internal/compiler/batch/Main.java
+++
ecj-3.10.1/src/org.eclipse.jdt.core/org/eclipse/jdt/internal/compiler/batch/Main.java
@@ -4106,7 +4106,7 @@ public void performCompilation() {
this.batchCompiler.remainingIterations =
this.maxRepetition-this.currentRepetition/*remaining iterations including this
one*/;
// temporary code to allow the compiler to revert to a single thread
String setting = System.getProperty("jdt.compiler.useSingleThread");
//$NON-NLS-1$
- this.batchCompiler.useSingleThread = setting != null &&
setting.equals("true"); //$NON-NLS-1$
+ this.batchCompiler.useSingleThread = setting == null ||
setting.equals("true"); //$NON-NLS-1$
if (this.compilerOptions.complianceLevel >= ClassFileConstants.JDK1_6
&& this.compilerOptions.processAnnotations) {
The I recompiled eclipse-ecj.jar on a system without this issue (Debian Linux
amd64), copied this jar to my system and rebuilt ecj.
P. S. I think Debian Linux/amd64 is also affected, see Bug 51615, but
multithreaded compilation works there.
[Bug c++/63405] New: Internal compiler error when building OpenAxiom on linux/amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Bug ID: 63405
Summary: Internal compiler error when building OpenAxiom on
linux/amd64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pashev.igor at gmail dot com
Created attachment 33609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33609&action=edit
Preprocessed file
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761549
Error message:
make[3]: Entering directory
'/home/pashev/work/projects/pkg-open-axiom/build-tree/src/syntax'
g++ -DHAVE_CONFIG_H -I. -I../../../src/syntax -I../../config
-I../../../src/include -I../../x86_64-pc-linux-gnu/include -D_FORTIFY_SOURCE=2
-m64 -D_GNU_SOURCE -std=c++11 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -O2 -Wall -c -o libsyntax_a-sexpr.o `test -f 'sexpr.cc'
|| echo '../../../src/syntax/'`sexpr.cc
In file included from ../../x86_64-pc-linux-gnu/include/open-axiom/sexpr:47:0,
from ../../../src/syntax/sexpr.cc:39:
../../x86_64-pc-linux-gnu/include/open-axiom/storage: In instantiation of 'T*
OpenAxiom::Memory::Factory::make(const Args& ...) [with Args =
{std::vector >, bool}; T = OpenAxiom::Sexpr::ListSyntax]':
../../../src/syntax/sexpr.cc:345:37: required from here
../../x86_64-pc-linux-gnu/include/open-axiom/storage:273:52: internal compiler
error: in cp_perform_integral_promotions, at cp/typeck.c:2066
return new(this->allocate(1)) T{args...};
^
# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-14'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-14)
[Bug bootstrap/49681] 4.6.1 cross-build fails in libquadmath/libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49681 Igor Pashev changed: What|Removed |Added CC||pashev.igor at gmail dot ||com --- Comment #1 from Igor Pashev 2011-07-30 22:02:32 UTC --- Confirm.
