++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
The following is diagnosed as ill-formed by GCC but not by Clang:
int main() {
constexpr auto _ = [] {
char x = 127;
return ++x;
}();
}
:5:5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
Jeff Snyder changed:
What|Removed |Added
CC||jeff-gcc at caffeinated dot
me.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett ---
That's such a good point about the local types in general.
Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be pe
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
Using g++-8.1 and gdb-8.2 both built from source on a CentOS 7.3 host, pretty
printing
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jeffunit dot com
Target Milestone: ---
Created attachment 39502
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39502&action=edit
output of cpuinfo, meminfo and gcc -D
--- Comment #12 from jeff at schwabcenter dot com 2009-05-19 18:07 ---
What he said. I'm perusing your patch, and I appreciate that you removed an
artificial restriction. The right place to catch this is up front, in a
concept check, rather than in _Destroy; since I'm not ab
--- Comment #9 from jeff at schwabcenter dot com 2009-05-19 17:32 ---
OK. Thanks for the explanation. Are the semantics documented somewhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40192
--- Comment #7 from jeff at schwabcenter dot com 2009-05-19 17:09 ---
I understand the desire for backward compatibility, but are the semantics
actually the same? Are the vector values arrays, or do they decay to pointers?
Section 23.1 says standard container elements have to be
--- Comment #5 from jeff at schwabcenter dot com 2009-05-19 16:36 ---
Whoa whoa whoa... The behavior seemed correct before. vector
shouldn't even be legal. Shouldn't the compiler to catch such a mistake?
--
jeff at schwabcenter dot com changed:
What
--- Comment #2 from jeff at schwabcenter dot com 2009-01-14 19:20 ---
I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
#include
#include
using boost::bind;
using std::multiplies;
int main() {
// Fine.
int const lvalue = 5;
bind(multiplies()
y: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at jgarrett dot org
GCC host triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37061
--- Comment #3 from jeff at jeffunit dot com 2008-07-17 02:07 ---
Created an attachment (id=15920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15920&action=view)
Here is the subroutine, run throuh the preprocessor using gcc-3.4.3
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #2 from jeff at jeffunit dot com 2008-07-17 01:59 ---
In order to run the entire program, you will need a fair amount of code.
All needed code can be found at the above URL, along with test data.
--
jeff at jeffunit dot com changed:
What|Removed
--- Comment #1 from jeff at jeffunit dot com 2008-07-17 01:57 ---
Created an attachment (id=15919)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15919&action=view)
this is the preprocessed subroutine that is poorly optimized
--
http://gcc.gnu.org/bugzilla/show_bug
: unassigned at gcc dot gnu dot org
ReportedBy: jeff at jeffunit dot com
GCC build triplet: i586-manbo-linux-gnu
GCC host triplet: i586-manbo-linux-gnu
GCC target triplet: i586-manbo-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot sullivan at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36642
--- Comment #7 from jeff at schwabcenter dot com 2008-03-07 23:43 ---
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html does not list
-Wswitch-default being enabled by -Wall.
--
jeff at schwabcenter dot com changed:
What|Removed |Added
--- Comment #6 from jeff at schwabcenter dot com 2008-03-07 23:42 ---
> Is there any particular reason for changing the docs, rather than the code?
Kindly disregard that question. I have just been informed by a co-worker that
some of our third-party library headers include swi
--- Comment #5 from jeff at schwabcenter dot com 2008-03-07 23:38 ---
Thanks for the quick response and the links. FYI, the latter link seems to be
broken:
http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html
Is there any particular reason for changing the docs
--- Comment #2 from jeff at schwabcenter dot com 2008-03-07 23:24 ---
Created an attachment (id=15278)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15278&action=view)
Fix for this bug
Setting warn_switch_default = value in the OPT_Wall case of
c_common_handle_option (i
--- Comment #1 from jeff at schwabcenter dot com 2008-03-07 23:21 ---
Created an attachment (id=15277)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15277&action=view)
Preprocessed sample code
Compiling the attached file with g++ -Wall should produce "warning: sw
pt started on Fri Mar 7 12:16:38 2008
~$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --enable-languages=c++
--prefix=/export/home/jeff/opt/gcc
Thread model: posix
gcc version 4.2.4 20080214 (prerelease)
~$ g++ -Wall -Wswitch-default main.cc
m
32_MAX_EXP don't match TR 24732
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot sullivan at intel
--- Comment #1 from jeff at thecreems dot com 2007-11-16 14:27 ---
Seems like a good idea. Since we often say that correctness should come before
performance when it comes to optimization, it has always seemed odd to me that
performance was the default mode of operation.
We can
--- Comment #5 from jeff at jeffunit dot com 2007-09-28 01:37 ---
I am using gnu make-3.81
I just verified that the problem is still present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32272
--- Comment #14 from jeff at thecreems dot com 2006-10-23 23:50 ---
(In reply to comment #1)
> Created an attachment (id=12473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view) [edit]
> Source code and very simple build script for Ada and FORTRAN co
--- Comment #8 from jeff at thecreems dot com 2006-10-22 15:50 ---
(In reply to comment #7)
> > No, but there is an obvious one why the Fortran version trounces the Ada
> > version. Let's not compare apples with oranges.
>
> The adverse effect of the indire
--- Comment #1 from jeff at thecreems dot com 2006-10-22 02:02 ---
Created an attachment (id=12473)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12473&action=view)
Source code and very simple build script for Ada and FORTRAN code capable of
showing poor tree and
atus: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
GCC build triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29543
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
GCC host triplet: i686-pc-linux-gnu
http
--- Comment #2 from jeff at thecreems dot com 2006-10-20 17:03 ---
Still there in head
gcc -c bug.adb
+===GNAT BUG DETECTED==+
| 4.2.0 20061020 (experimental) (i686-pc-linux-gnu) Assert_Failure
atree.adb:812
--
http://gcc.gnu.org
--- Comment #4 from jeff at thecreems dot com 2006-10-20 17:01 ---
Seems fixed in trunk
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --disable-checking
--enable-languages=c,fortran,ada --prefix=/home/jcreem/local
Thread model: posix
gcc version
--- Comment #4 from jeff at thecreems dot com 2006-10-20 16:56 ---
I just did a fresh Gcc build today this no longer appears to be a problem
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision
<$rstr7-19b>
--- Comment #3 from jeff dot lanam at hp dot com 2006-09-07 18:36 ---
Subject: RE: ld internal error building libmath in gcc 4.1.1
Thank you for the quick response. I updated binutils and got past that.
I'm a novice at using GNU.
-Original Message-
From: pinskia at gc
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff dot lanam at hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28976
with non-trivial return expression
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at thecreems dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25573
--- Comment #2 from jeff dot myers at eclipse dot org 2005-10-23 23:50
---
This function must be implemented to support the Swing/AWT development using
Eclipse Visual Editor project (http://www.eclipse.org/vep/)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16729
--- Additional Comments From jeff at panasas dot com 2005-09-16 14:50
---
(In reply to comment #3)
> This works for me with 4.1.0 but I really think it is just an accident.
> /[EMAIL PROTECTED]@*/ int cr0; /* really, it's used, but lclint doesn't
> "get&quo
--- Additional Comments From jeff at panasas dot com 2005-09-16 05:44
---
Created an attachment (id=9738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9738&action=view)
Xor test program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
nerated for SSE2 based xor routine when
compiled with -O2 -fomit-frame-pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at panasas dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23909
Summary: GNAT Command lists many commands as available that are
not
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ompilation.
My contact information is:
Jeff Fellin
RFL Electronics
973-334-3100 x327
[EMAIL PROTECTED]
= select.c
/*
* This file contains the procedures for the handling of select and poll
*
* Created for Linux based loosely upon Mathius
--- Additional Comments From jeff at connectrf dot com 2005-01-11 21:03
---
Well that makes sense..
Does anyone have an example of the compiler options to port from VC++ to GCC? A
nice Crossreference table would be just dandy.
--
What|Removed
--- Additional Comments From jeff at connectrf dot com 2005-01-11 20:23
---
Andrew,
You are sure hard to convince...
Where did the error go?
Full rebuild of configuration Release for project Auth
make -k clean all
rm -rf authtest.o authtestdlg.o stdafx.o
--- Additional Comments From jeff at connectrf dot com 2005-01-11 20:03
---
Andrew,
If I take the exact same code, and compile it with VC++ it does not complain!
However, gcc the ONLY thing that has changed, will not compile code that works!
Why? Old wise one, must one rewrite entrie
--- Additional Comments From jeff at connectrf dot com 2005-01-11 19:24
---
Andrew, let me try again. BTW I have looked at the man pages for both gcc and
ld, I must say they are clear as mud, but then most are.
If I take the defaults, in CDT, I receive the errors attached below. If I
--- Additional Comments From jeff at connectrf dot com 2005-01-11 17:44
---
Andrew,
What compiler option flag do I need to set for forward Declartions then? _M was
taking care of those errors however it is not producing the .o? Is there a
Crossrefrence of compiler options between MC
--- Additional Comments From jeff at connectrf dot com 2005-01-10 18:45
---
Andrew,
A view from the ld folks. They believe that the ld is failing due to the
-fpreprocessed switch not producing the .o file..
--- Additional Comments From nickc at redhat dot com 2005-01-10 17:57
--- Additional Comments From jeff at connectrf dot com 2005-01-06 15:33
---
(In reply to comment #1)
> This is not a gcc bug, either this is your bug and the .o file is not an
object file or this is a binutils bug.
Andrew, then perhaps you can explain why the exact same code compi
../i686-pc-cygwin/bin/ld:AuthTest.o:1:
syntax error
collect2: ld returned 1 exit status
make: *** [Auth.exe] Error 1
make: Target `all' not remade because of errors.
Build complete for project Auth
--
Summary: file format not recognized; treating as linker script
Product:
--- Additional Comments From jeff at rtr dot com 2004-11-16 22:00 ---
Subject: Re: 64 bit structure passing problem (g++, not gcc)
Hi,
I tested it with gcc 3.4.3 today and the bug seems to have been fixed.
Regards,
Jeff
According to pinskia at gcc dot gnu dot org
sr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
If that fixes it, you've encountered a known problem (documented in
/install/specific.html IIRC). If not, we'll have to investigate.
JEff
53 matches
Mail list logo
