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 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 developing a C++-98 replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #6 from Jason Vas Dias 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 cannot be overloaded the error
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #7 from Jason Vas Dias 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 list
> > rather than this cryptic "no match for ternary 'operat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54348
--- Comment #8 from Jason Vas Dias 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 of a
conditional expression, and not "no matc
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 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 were able to build insn-emit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #3 from Jason Vas Dias 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 to resolve this .
Meanwhile, I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #4 from Jason Vas Dias 2012-08-05
11:43:03 UTC ---
in case the configuration is relevant:
It was created by configure, which was
generated by GNU Autoconf 2.64. Invocation command line was
$ /usr/build2/gcc/gcc-4.7.1/configure -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #7 from Jason Vas Dias 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 (it
will crash if I don't reduce it soon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #11 from Jason Vas Dias
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:
RE: wbrana 2012-08-05 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #13 from Jason Vas Dias
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) .
>
> This is indeed excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #14 from Jason Vas Dias
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-linux-gnu/lib/ -isystem /usr/x86_64-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #15 from Jason Vas Dias
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 < insn-emit.i.xz > insn-emit.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #20 from Jason Vas Dias
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 compiler.
I see no point in proceed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #22 from Jason Vas Dias
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, but that is no longer possible with gcc-4.7.1+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #23 from Jason Vas Dias
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 these
days.
It turned out to be less
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #24 from Jason Vas Dias
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:03 cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #26 from Jason Vas Dias
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 rather than a C compiler. This is
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.
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
: 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
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&action=edit
log file produced by 'make check-g++ 'RUNTESTFLAGS=vect.exp=slp-pr56812*'
Log file showing test failures as re
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&action=edit
slp1 log file
Here is the slp1 log file produced by command:
$
/home/devel/OS/gcc-6-branch/host-x86_64-linux-g
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
-fvect-
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 family
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'
oduct: gcc
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 d
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: comp
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: ---
Created attachment 44383
--> https://gcc.gnu.org/bugzilla/attachment.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:
--- de
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&action=edit
More readable (diff -ur) patch against 6.4.1's cp/decl2.c
Here is a more readable version of the patch
to pri
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 's
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 can
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 from
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 __vdso_clock_gettime(cloc
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 clock_
: gcc
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
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 trying
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 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
Target: i386-pc-solaris2.11
Con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
--- Comment #5 from Jason Vas Dias 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 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 ftp.gnu.org:/pub/gnu/dejagnu> ls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55621
Jason Vas Dias changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
ty: normal
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 c
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++
-B/usr/build/linux/gcc-5.3.0/prev-x86_64-pc-lin
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=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 com
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 / config
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 '^LDF
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, like
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 .
++
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 )
:
: 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=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
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&action=edit
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 n
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
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 .
O
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=81279
--- Comment #7 from Jason Vas Dias ---
Created attachment 41665
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41665&action=edit
Fixed version - also demonstrates point : addresses of members increase
So when I mangle it to actually print
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
St
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 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 \
--enable-targets=all --enab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #2 from Jason Vas Dias 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:
nsIPluginTagInfo2 has been merged int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #4 from Jason Vas Dias 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 attempt that compiles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
--- Comment #5 from Jason Vas Dias 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 then what replaces the Firefox plugi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49077
Jason Vas Dias changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WONTFIX
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
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 pr
77 matches
Mail list logo
