http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
Bug #: 55621
Summary: no gcc or g++ tests run for solaris2.11 target :
missing
$OBJDIR/gcc/testsuite/config/unix_{gcc,g++}.exp files
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09
08:15:58 UTC ---
After successfully building gcc-4.7.2 for multi-lib i386-pc-solaris2.11
target ( x86_64 Solaris 11 ) , with configure arguments :
$ gcc -v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09
08:55:38 UTC ---
Created attachment 28903
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28903
/usr/GNU/lib/dejagnu/runtest.exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
--- Comment #6 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-12-09
08:59:34 UTC ---
Oops, I picked the last of :
$ lftp ftp.gnu.org
lftp ftp.gnu.org:~ cd pub/gnu/dejagnu
cd ok, cwd=/pub/gnu/dejagnu
lftp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
Jason Vas Dias jason.vas.dias at gmail dot com changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
Bug #: 54179
Summary: please split insn-emit.c !
Classification: Unclassified
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05
11:11:28 UTC ---
Why must we compile 1.8MB of insn-emit.c ?
Can't it be split up ?
Why is gcc-4.7.1 SO much slower ?
ie. evidently the Stage1 and Stage2 compilers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #3 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05
11:36:05 UTC ---
RE:
Your PC is broken.
Comments such as these don't help much.
No, only Linux 3.4+ temperature management is.
I'm working with the Linux developers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #4 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05
11:43:03 UTC ---
in case the configuration is relevant:
quote file=config.log
It was created by configure, which was
generated by GNU Autoconf 2.64. Invocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #7 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-05
12:21:10 UTC ---
Thanks for your response !
I think the cc1 process is somehow operating in slow motion,
even though I've pinned the CPU frequency to 1.8 GHz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #11 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 13:16:03 UTC ---
Thanks for the responses - I will try again with
'--enable-checking=release'.
But, I still don't think this bug is a non-issue - here's why
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #13 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 13:43:21 UTC ---
RE: Steven Bosscher 2012-08-05 12:37:28 UTC \
(In reply to comment #7)
These memory requirements are solely due to the size of the .c file (1.8MB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #14 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 13:46:26 UTC ---
$ time /mnt/sda3/gcc/./prev-gcc/xgcc -B/mnt/sda3/gcc/./prev-gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/bin/
-B/usr/x86_64-pc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #15 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 13:51:27 UTC ---
Created attachment 27939
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27939
pre-processed C from previous comment command
$ xz --uncompress
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #20 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 18:10:24 UTC ---
RE: --disable-bootstrap if you're doing --enable-gather-statistics
but for me this defeats the whole purpose of building a C-only
bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #22 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 19:48:45 UTC ---
RE:
If you want a C-only compiler then you should just configure with
--enable-languages=c only
of course, I tried that first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #23 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 19:51:56 UTC ---
Yes, I was wondering how long it would take to close this bug as INVALID,
which seems to be the standard response to uncomfortable bug reports
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #24 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 20:10:36 UTC ---
$ ps -lp 3863
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 R 0 3863 3862 99 80 0 - 64611 - pts/51-05:55
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #26 from Jason Vas Dias jason.vas.dias at gmail dot com
2012-08-05 20:57:59 UTC ---
Well, when I read on the documentation page
http://gcc.gnu.org/install/configure.html
--enable-build-with-cxx
Build GCC using a C++ compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
Bug #: 54348
Summary: wrong error reported for type mismatch in conditional
expression : error: no match for ternary 'operator?:'
in 'false ?
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21
20:27:36 UTC ---
Oops, I was interrupted adding this comment to my initial comment - will
respond
to subsequent commment next :
Incidentally, I found this issue while
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #6 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21
20:29:53 UTC ---
(In reply to comment #1)
In mainline the diagnostics is better because we output the types. But I agree
that given that the conditional operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #7 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21
20:34:06 UTC ---
(In reply to comment #2)
(In reply to comment #0)
Shouldn't g++ be complaining about initializing a string with a liststring
rather than
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #8 from Jason Vas Dias jason.vas.dias at gmail dot com 2012-08-21
20:52:12 UTC ---
All I'm suggesting is that g++ should try to find the most basic error,
which is that different type objects are returned as the result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49055
Summary: 4.6.0 libjava 64-bit + 32-bit multilib compile fails
due missing -isystem and -nostdinc++ with $OBJDIR !=
$topsrcdir build
Product: gcc
Version: 4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
Summary: gcjwebplugin.cc doesn't compile against latest
xulrunner 2.0b13 sdk
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #1 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20
10:07:20 UTC ---
my config:
$ /usr/build2/gcc/gcc-4.6.0/configure --prefix=/usr --libdir=/usr/lib64\
--with-cpu-32=i686 --with-cpu-64=k8 --enable-languages=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #2 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20
10:17:10 UTC ---
See https://developer.mozilla.org/en/firefox_3.6_for_developers :
Interfaces merged
The following interfaces have been combined together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #4 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20
11:19:25 UTC ---
Created attachment 24298
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24298
patch to gcjwebplugin.cc to compile against xulrunner-2.0
First
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #5 from Jason Vas Dias jason.vas.dias at gmail dot com 2011-05-20
12:56:44 UTC ---
(In reply to comment #3)
gcjwebplugin is dead, it should have been removed, but nobody has done that.
Just don't enable it in configure.
Well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
Jason Vas Dias jason.vas.dias at gmail dot com changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49424
Summary: ICE in lhd_set_decl_assembler_name at langhooks.c:158
with '-flto'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #9 from Jason Vas Dias ---
(In reply to Jakub Jelinek from comment #8)
> Where do you see -nostdlib being used? I see it neither in your #c0, nor in
> #c1.
> Looking at my buildlog, -nostdlib is used to link only some libraries,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #4 from Jason Vas Dias ---
Thanks for having a look at this, Richard .
Yes, "some weirdness" is definitely going on -
but I'd like to determine precisely which "weirdness".
This occurred when building my new LFS system's system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #7 from Jason Vas Dias ---
So since I've produced a working Stage3 compiler in the build directory, './',
'./prev-gcc' should be the directory containing the Stage2 gcc build, and
it does in my case, with a config.log :
$ grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #6 from Jason Vas Dias ---
Yes, Jakub, thanks, I know :
> If you link with g++ or xg++ instead of gcc or xgcc, then the driver is
> adding
> -lstdc++ automatically.
But it is not ME linking, it is the gcc-5.3.0 Makefile.in /
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
I am trying to build gcc-5.3.0 with gcc-5.2.0 , on an x86-64 (Haswell) Linux
box, and am getting this unexpected compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #1 from Jason Vas Dias ---
And it happens for gcov also:
/usr/build/linux/gcc-5.3.0/./prev-gcc/xg++
-B/usr/build/linux/gcc-5.3.0/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/
-nostdinc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70519
--- Comment #2 from Jason Vas Dias ---
In fact, it happens for EVERY executable produced by stage2 compiler!
Why is this - do I need to add '-lstdc++' to LDFLAGS or to
--with-stage1-ldflags / --with-boot-ldflags in order to build gcc-5.3.0 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
--- Comment #7 from Jason Vas Dias ---
Created attachment 41665
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41665=edit
Fixed version - also demonstrates point : addresses of members increase
So when I mangle it to actually print each
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
--- Comment #1 from Jason Vas Dias ---
Obviously, G++ 5.4.0 and 6.3.0 are able to expand the
text '_HeadList...' here into the list of types:
Line 184:
_t._call< _HeadList...
But G++ 7.1.0 is not able to do so, and gives no clue
as to why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
Jason Vas Dias changed:
What|Removed |Added
Attachment #41663|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
--- Comment #5 from Jason Vas Dias ---
Wow! Problem SOLVED! Need a different pair of eyes sometimes ...
But I can't find where this is flagged in gcc 7.1.0 NEWS or ReleaseNotes .
It is a major change of behavior WRT to Variadic Macros, IMHO .
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Created attachment 41662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41662=edit
Example PieceW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
Jason Vas Dias changed:
What|Removed |Added
Attachment #41662|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81279
Jason Vas Dias changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
Jason Vas Dias changed:
What|Removed |Added
CC||jason.vas.dias at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
--- Comment #6 from Jason Vas Dias ---
(In reply to Jason Vas Dias from comment #5)
> It also happens with GCC 5.4.0 -
Also happens in GCC 6.3.0 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944
--- Comment #7 from Jason Vas Dias ---
And there is no workaround, really - one cannot initialize a
C++ class object member of a static thread_local C++ template class object
member in one place, outside the class, and use that same object in a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Attempts to compile the following demo code :
$ echo '
#include
struct A
{ char _a[256];
std::initializer_list _al;
A( std::initializer_list l )
: _a({0
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
I am not seeing how it is possible to initialize a static TLS structure
member that is of a class type :
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80920
--- Comment #5 from Jason Vas Dias ---
I think if GCC cannot get the position of an error correct,
then it should not show the position at all .
rmal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Bug #55665 has reappeared in builds of the gcc-6-branch and gcc-7-branch SVN
trees, and its test case ( g++.dg/guality/pr5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887
--- Comment #1 from Jason Vas Dias ---
No, it looks like the patch
( https://gcc.gnu.org/bugzilla/attachment.cgi?id=28937 )
is applied to 6.4.1's and 7.3.1's tree-inline.c, only
for some reason it is not working for those compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85887
--- Comment #2 from Jason Vas Dias ---
Also affects gcc-5.4.0 and gcc-5.5.0 builds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
--- Comment #4 from Jason Vas Dias ---
Same commands run by GCC 5.5.0 or GCC 7.3.1 succeed:
$ g++5 slp-pr56812.cc -nostdinc++ -std=c++98 -O2 -ftree-vectorize
-fno-vect-cost-model -msse2 -fdump-tree-slp-details=gcc5.out -O3 -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
--- Comment #3 from Jason Vas Dias ---
Created attachment 44174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44174=edit
slp1 log file
Here is the slp1 log file produced by command:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
--- Comment #2 from Jason Vas Dias ---
Created attachment 44173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44173=edit
log file produced by 'make check-g++ 'RUNTESTFLAGS=vect.exp=slp-pr56812*'
Log file showing test failures as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
--- Comment #7 from Jason Vas Dias ---
Aha!
Yes, I was experimenting with the new '-march=haswell' and
'-mtune=intel' options
( which seem to me to be the wrong way round - shouldn't 'haswell' be an
'-mtune' option and 'intel' be an '-march'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85891
--- Comment #5 from Jason Vas Dias ---
Could it be an issue to do with running on different hardware?
The CPU on the machine is a rather old 4-core (8 with HyperThreading)
Haswell :
processor : 0
vendor_id : GenuineIntel
cpu
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85924
--- Comment #1 from Jason Vas Dias ---
Aha! Sorry, it appears that when run from command line, just the -fPIC
option appears, not the -DPIC, but in my make.log for the original
GCC build, I do see:
checking for shl_load in -ldld... libtool:
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
After building
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Building GCC 6.4.1 from gcc-6-branch of 20180521 (SVN Revision 260441) ,
for x86_64 under Linux (RHEL-7.5, glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #14 from Jason Vas Dias ---
RE: Comment #13:
> You said that Andi Kleen had a comment. Can you point me to it?
Here is a quote, from LKML message :
Subject: Re: [PATCH v4.16-rc5 2/2] x86/vdso: \
VDSO should handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #12 from Jason Vas Dias ---
RE: Comment #11 :
> notrace int _RETPOLINE_FUNC_ATTR_
> __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
should of course be
notrace _RETPOLINE_FUNC_ATTR_
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #11 from Jason Vas Dias ---
In reply to Comment #9 :
Thanks Andy -
I think it is because when the retpoline flags are enabled ,
the 'static inline' function calls in vclock_gettime.c
have default function attributes which differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #2 from Jason Vas Dias ---
Created attachment 44384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44384=edit
More readable (diff -ur) patch against 6.4.1's cp/decl2.c
Here is a more readable version of the patch
to print out
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Created attachment 44383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44383=edit
test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #1 from Jason Vas Dias ---
In investigating this problem, I actually modified 6.4.1's gcc/cp/decl2.c
with the following patch to print out which component of the
base struct it thinks uses the anonymous namespace:
BEGIN PATCH:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #3 from Jason Vas Dias ---
Of course, these lines of t2.h from Comment #1 :
template < class _C_, _C_ *_C_OBJ_, void (_C_::*_M_)() >
class NT
{ static constexpr _C_ *c_ = _C_OBJ_;
public:
NT()
{ (c_->*_M_)();
could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #4 from Jason Vas Dias ---
Aha! It is simply that the object pointer template parameter cannot
have static (translation unit) linkage here:
namespace NA
{ class C { ... };
static C c_;
/*^^*/
}
If I remove the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491
--- Comment #6 from Jason Vas Dias ---
Thanks Andrew!
But, please explain, why does using a static reference cause
anonymous namespace issues ?
Where is this mandated in the C++ standards ?
I understand that any reference to a static object
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
This bug occurs under Linux x86_64 with
gcc-4.8.5-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #2 from Jason Vas Dias ---
Thanks H.J. -
RE:
> vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> 4.16-rc5. Why isn't it the case for you?
All I know is , when submitting a patched vclock_gettime.c
in which the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908
--- Comment #8 from Jason Vas Dias ---
Thanks for the clarification, and I hope the kernel
developers stop compiling the mainline vDSO with
-mindirect-branch=thunk-extern -mindirect-branch-register
.
But there are still a few things I am
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.vas.dias at gmail dot com
Target Milestone: ---
Just a niggle:
I don't think this code should produce
77 matches
Mail list logo
