https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #2 from Jeffrey Walton ---
My bad... Here's the error message:
g++ -DNDEBUG -g2 -O3 -Wall -march=native -pipe -c nbtheory.cpp
nbtheory.cpp:655:0: warning: ignoring #pragma omp parallel [-Wunknown-pragmas]
#pragma omp parallel
^
nb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #4 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #3)
> The warning is correct though, maybe it should add a message about needing
> -fopenmp to have them to be known.
>From a dumb user's point of view (folks like me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #6 from Jeffrey Walton ---
(In reply to Manuel López-Ibáñez from comment #5)
> ...
> For what is worth, I understand the point by Andrew that without -fopenmp,
> the #pragmas are effectively ignored, thus the warning seems useful. Per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #8 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #6)
> > Maybe it could be in effect with `-Wextra`?
>
> That would just move the problem somewhere else instead of fixing it. Many
> people do compile with -Wall -We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #13 from Jeffrey Walton ---
This issued caused Crypto++ to remove -Wall (and above) under GCC. Crypto++ is
C++ with lots of interfaces, and it performs a fair amount of intermediate
calculations used in an assert. It really needed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #16 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jeffrey Walton from comment #13)
> > This issued caused Crypto++ to remove -Wall (and above) under GCC.
>
> That seems to be throwing the baby
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #17 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jeffrey Walton from comment #13)
> > This issued caused Crypto++ to remove -Wall (and above) under GCC.
>
> That seems to be throwing the baby
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #20 from Jeffrey Walton ---
(In reply to Manuel López-Ibáñez from comment #19)
> For what is worth, anyone please feel free to take my WIP patch in comment
> #10 and get it finished. You may also claim for yourself any bounty or
> com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #22 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #18)
> ...
> Or you could just change the code causing the warnings.
Fair enough.
There are two warnings that are big offenders. First is the "unused variable"
wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #24 from Jeffrey Walton ---
(In reply to Manuel López-Ibáñez from comment #23)
> (In reply to Manuel López-Ibáñez from comment #21)
> > Now that you posted a complete example here:
> > https://gcc.gnu.org/ml/gcc-help/2015-07/msg00070.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #25 from Jeffrey Walton ---
Jonathan, Manuel, et al -
I'm putting this to bed on our side. We've re-enabled -Wall, and are moving
towards -Wextra.
I did come up with one more use case... The "unused parameter" warning.
Typically, I
: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Compiling under -Wall -Wextra does not produce a warning:
$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036
--- Comment #1 from Jeffrey Walton ---
> I can state from experience the Visual Studio warning alerted us to look at
> a particular dtor, and it was not checking for !std::uncaught_exception()
> before throwing. (It was one of two classes among h
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
When compiling the Crypto++ library with CXXFLAGS that includes `-x c++`, the
test program fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67094
--- Comment #3 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #2)
> That -x c++ with .o files are being treated as c++ source and being compiled
> and that is what is the error message is saying. The .o file is a binary
> file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67094
--- Comment #4 from Jeffrey Walton ---
Andrew/Everyone(In reply to Andrew Pinski from comment #1)
> -x c++ means the input is c++ source no matter what the extension.
Sorry to revisit this...
According to the GCC docs, GCC should not be changin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm trying to detect a debug build, and enjoy the benefit of additional
instrumentation:
# Debug testing
ifneq ($(filter -DDEBUG -DDEBUG=1 -O0 -O1 -Og,$(CXX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
--- Comment #19 from Jeffrey Walton ---
(In reply to Yann Collet from comment #18)
> This issue makes me wonder : how to efficiently access unaligned memory ?
>
>
> The case in point is ARM cpu.
> They don't support SSE/AVX, so they seem unaffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67195
--- Comment #2 from Jeffrey Walton ---
>
> $ uname -a
> Linux localhost.localdomain 4.1.3-201.fc22.x86_64 #1 SMP Wed Jul 29 19:50:22
> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> $ g++ --version
> g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
> C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67195
--- Comment #5 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Jeffrey Walton from comment #2)
> > >
> > > $ uname -a
> > > Linux localhost.localdomain 4.1.3-201.fc22.x86_64 #1 SMP Wed Jul 29
> > > 19:50:22
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55307
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
The following program:
$ cat test.cxx
int main(int argc, char* argv[])
{
__asm__ __volatile__ (
"\t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67301
--- Comment #2 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #1)
> Try:
> int main(int argc, char* argv[])
> {
> __asm__ __volatile__ (
>
> "\t movl %[__ARGC], %%eax \n"
> :
> : [__A
Summary: Please add "-Wno-unused-variable" and friends compiler
warning options
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: noloader at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45411
--- Comment #1 from noloader at gmail dot com 2010-08-26 09:09 ---
Though (5) and (8) are specific to me, there's nothing really special about me
- there's probably lots of lazy programmers who would also like the warning
options.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from noloader at gmail dot com 2010-08-26 14:54 ---
> You didn't say which version of GCC you're using, but it doesn't really matter
> because these options have been in place for many years.
Moot point indeed! But for completeness
$ gcc --vers
"comparison of unsigned expression < 0 is always false"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #2 from noloader at gmail dot com 2010-09-06 05:35 ---
(In reply to comment #1)
>
> *** This bug has been marked as a duplicate of 11856 ***
>
Thanks Andrew. For the record, I don't really consider it a bug - its closer to
undesired behavior when working
--- Comment #5 from noloader at gmail dot com 2010-09-06 06:45 ---
(In reply to comment #4)
> In G++ 4.6+ you can do:
> int i;
> unsigned j;
>
> template
> void
> bar (const T& t)
> {
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
Summary: Switch to warn of global variables in a C++ shared
object
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #2 from Jeffrey Walton 2010-10-20
17:33:43 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > When a module meets the above compile and runtime requirements, a crash can
> > occur in global objects with destructors when m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #3 from Jeffrey Walton 2010-10-20
17:38:59 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > When a module meets the above compile and runtime requirements, a crash
> > > can
> > > occur i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #6 from Jeffrey Walton 2010-10-20
23:18:48 UTC ---
Hi Johnathon,
(In reply to comment #5)
> oh, and I only see one process invovled there ... I'm still confused about the
> claim that more than one process is involved...
My bad - the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #8 from Jeffrey Walton 2010-10-21
02:00:51 UTC ---
(In reply to comment #4)
> I had a look at Cryptopp-SO-Test-1.zip
>
>
>
> I can see some value in the warning you want, but it's not going to help if
> you
> don't use the compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #9 from Jeffrey Walton 2010-10-21
15:04:44 UTC ---
(In reply to comment #4)
> I had a look at Cryptopp-SO-Test-1.zip
>
> building on 32-bit I can reproduce a segfault
>
> it doesn't build on 64-bit at all:
>
> 1) you can insert a p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #13 from Jeffrey Walton 2010-10-21
16:10:41 UTC ---
Hi Jonathon,
(In reply to comment #10)
> you realise you can wait and it will show up?
> http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html
I've been known to be impatient at time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #14 from Jeffrey Walton 2010-10-21
16:13:36 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > Hi Johnathon,
> > (In reply to comment #5)
> > > oh, and I only see one process invovled there ... I'm still confused
> > > a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #15 from Jeffrey Walton 2010-10-21
16:15:38 UTC ---
(In reply to comment #11)
> also, I'm not "the GCC team" and I don't speak for anyone else
My apologies. I made the leap that you were part of the team due to your email
address.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #17 from Jeffrey Walton 2010-10-21
16:59:55 UTC ---
(In reply to comment #16)
> (In reply to comment #13)
> >
> > Good point: here's what I would recommend: common sense. Myself, Alexey, a
> > number of packagers across the globe, an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #18 from Jeffrey Walton 2010-10-21
17:37:15 UTC ---
(In reply to comment #13)
> Hi Jonathon,
>
> (In reply to comment #10)
> > you realise you can wait and it will show up?
> > http://gcc.gnu.org/ml/gcc-help/2010-10/msg00248.html
> I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #21 from Jeffrey Walton 2010-10-21
18:49:49 UTC ---
(In reply to comment #19)
> Oh, I never use the search, it's always been useless
>
> just click on the first month in the list,
> http://gcc.gnu.org/ml/gcc-help/2010-10/ shows the m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #23 from Jeffrey Walton 2010-10-21
19:52:12 UTC ---
Hi Jonathan,
[Sorry about the top post].
I'm going to wrap up my request, and hope you and the GCC team will find that
-Wglobal-variable would be useful under some circumstances.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #24 from Jeffrey Walton 2010-10-22
01:59:34 UTC ---
Hi Jonathan,
(In reply to comment #16)
> (In reply to comment #13)
> >
> > [SNIP]
>
> There are a number of options for making sure the global is private to the
> library, thus av
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #25 from Jeffrey Walton 2010-10-22
05:52:07 UTC ---
Created attachment 22112
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22112
Test for Load/Unload Crash
Attached is a test program similar to the program posted on
http://gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #27 from Jeffrey Walton 2010-10-22
07:37:55 UTC ---
(In reply to comment #26)
> [SNIP]
> Are those libraries that crash designed to be used via dlopen, rather than
> linking to them explicitly?
I'm not sure. How can one tell?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46097
--- Comment #28 from Jeffrey Walton 2010-10-22
19:49:26 UTC ---
(In reply to comment #26)
> I don't think dlmopen has anything to do with C++ namespaces, but I could be
> wrong
>
> Are those libraries that crash designed to be used via dlopen, r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513
Summary: Request: Warning for use of unsafe string handling
functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513
--- Comment #2 from Jeffrey Walton 2010-11-17
01:08:22 UTC ---
Hi Jonathan,
(In reply to comment #1)
> The maintainers of GNU libc, the C and C++ committees and the POSIX working
> group have not seen fit to include those functions, and they're
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513
--- Comment #3 from Jeffrey Walton 2010-11-17
02:04:14 UTC ---
(In reply to comment #1)
> The maintainers of GNU libc, the C and C++ committees and the POSIX working
> group have not seen fit to include those functions, and they're not available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46513
--- Comment #4 from Jeffrey Walton 2010-11-17
03:49:44 UTC ---
(In reply to comment #2)
> Hi Jonathan,
>
> (In reply to comment #1)
> > The maintainers of GNU libc, the C and C++ committees and the POSIX working
> > group have not seen fit to in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
--- Comment #4 from Jeffrey Walton 2010-12-05
14:01:18 UTC ---
Created attachment 22643
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22643
GCC crash on precompiled header, -g3, and empty file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467
Summary: Enhancement: Intrinsic to read CARRY and OVERFLOW
flags (where applicable)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
Summary: internal compiler error: in extract_insn, at
recog.c:2104
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #1 from Jeffrey Walton 2011-07-08
00:45:17 UTC ---
Using the stock Crypto++ makefile did not help:
g++ -DNDEBUG -g -O2 -mtune=native -pipe -c 3way.cpp
g++ -DNDEBUG -g -O2 -mtune=native -pipe -c adler32.cpp
g++ -DNDEBUG -g -O2 -mtune=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #2 from Jeffrey Walton 2011-07-08
00:47:53 UTC ---
For completeness, here's the function
(http://www.cryptopp.com/docs/ref/asn_8cpp_source.html):
00244 void OID::DEREncode(BufferedTransformation &bt) const
00245 {
00246 asser
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #4 from Jeffrey Walton 2011-07-08
08:07:43 UTC ---
(In reply to comment #0)
> Sorry if this was previously reported. Searching returned an error stating I
> used an invalid file extension.
>
> I was attempting to compile the latest C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #5 from Jeffrey Walton 2011-07-08
08:35:11 UTC ---
Created attachment 24710
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24710
File asn.s from class file causing internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #6 from Jeffrey Walton 2011-07-08
08:35:55 UTC ---
Created attachment 24711
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24711
File asn.ii from class causing internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #7 from Jeffrey Walton 2011-07-08
08:36:08 UTC ---
(In reply to comment #3)
> Please add all information and especially preprocessed source, as explained in
> http://gcc.gnu.org/bugs/#detailed
Crypto++ sources:
`svn checkout https://
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #9 from Jeffrey Walton 2011-07-08
09:51:21 UTC ---
(In reply to comment #8)
> The included source compiles OK for me with:
>
> ~/gcc-build/gcc/cc1plus -quiet -O2 -m32 -g -fstack-protector -march=prescott
> -mtune=prescott --param l1-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #10 from Jeffrey Walton 2011-07-09
03:32:20 UTC ---
(In reply to comment #8)
> The included source compiles OK for me with:
>
> ~/gcc-build/gcc/cc1plus -quiet -O2 -m32 -g -fstack-protector -march=prescott
> -mtune=prescott --param l1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49820
--- Comment #6 from Jeffrey Walton 2011-07-23
22:28:07 UTC ---
(In reply to comment #5)
> > CPUs which use 2s compliment representations are usually well equipped to
> > deal
> > with overflow and carry. I would claim a result which overflows is
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
When using MacPorts GCC on OS X and enlisting the Clang Integrated Assembler
via -Wa,-q, the assembler produces a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #1 from Jeffrey Walton ---
Also see LLVM Issue 28427, "Endless stream of warnings when using GCC with
-Wa,-q and Clang Integrated Assembler",
https://llvm.org/bugs/show_bug.cgi?id=28427.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 38862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38862&action=edit
Prepr
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on OS X 10.8.5 with MacPorts 2.3.4 installed. I'm attempting to
compile Jack Lloyd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71812
--- Comment #1 from Jeffrey Walton ---
> I can't submit pubkey_pkcs8.ii.zip. It appears to be causing Gateway
> Timeouts.
The preprocessed source file is available at
https://trac.macports.org/ticket/51796#no1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71812
--- Comment #4 from Jeffrey Walton ---
(In reply to Richard Biener from comment #3)
> Duplicate of PR71811?
Yes, it looks like a duplicate.
GCC's bug tracker search feature absolutely sucks. Did Microsoft provide it
free of charge?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71812
--- Comment #6 from Jeffrey Walton ---
(In reply to Richard Biener from comment #3)
> Duplicate of PR71811?
My bad... That's the same bug report.
When attempting to include the preprocessed source file in the original report,
I kept getting "Ga
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71811
--- Comment #2 from Jeffrey Walton ---
Also see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=71210 (thanks JJ).
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I don't believe this is expected behavior, especially since (1) g++ is being
used, and (2) -std=c++17 is being used.
$ /opt/local/bin/g++ -std=c++17 -dM -E -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71930
--- Comment #2 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #1)
> What makes you think that this is a bug?
I think its a bug (1) g++ is being used, and (2) -std=c++17 is being used. What
does a file extension have to do with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71930
--- Comment #4 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #3)
> (1) so what?
I suppose I should thank my lucky stars g++ did not invoke the preprocessor for
Fortran or Java then.
Maybe GCC could make it round robin so defin
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This looks like an issue similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907. My apologies if it has
already been fixed
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This looks like an issue similar to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907. It also appears similar to
http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132
--- Comment #14 from Jeffrey Walton ---
(In reply to ktkachov from comment #8)
> Fixed on trunk for now.
> Will backport after some time to the branches
Bump... I don't think this has made it into Debian's 4.9.2-10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72736
--- Comment #4 from Jeffrey Walton ---
Thanks, and sorry to waste your time with it.
Before I spin up another report that wastes a lot time, does this look like
another issue with me (likely), or an issue with GCC (unlikely):
internal compiler
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 39027
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39027&action=edit
Preprocessed source file.
Raspber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72736
--- Comment #6 from Jeffrey Walton ---
(In reply to James Greenhalgh from comment #5)
> (In reply to Jeffrey Walton from comment #4)
> > Thanks, and sorry to waste your time with it.
> >
> > Before I spin up another report that wastes a lot time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72738
--- Comment #2 from Jeffrey Walton ---
(In reply to James Greenhalgh from comment #1)
> Testcase needs a #include to compile, but otherwise confirmed
> from GCC 4.9 through to trunk.
>
> Note that it isn't immediately clear that this is valid c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72738
--- Comment #3 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to James Greenhalgh from comment #1)
> > Testcase needs a #include to compile, but otherwise confirmed
> > from GCC 4.9 through to trunk.
> >
> > No
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 39035
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39035&action=edit
Preprocessed test.cc
I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72758
--- Comment #3 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #2)
> Note the testcase is wrong (but only slightly).
Oh, you're right, thanks.
That code was tested on the RPI3 to ensure it compiled as expected under
Aarch32. Usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #5 from Jeffrey Walton ---
I think we are seeing this bug in the field. We are catching lots of failed
self tests as we test on multiple platforms, including Ubuntu 14 ERS and Ubuntu
16 LTS.
The problem makes GCC 4.8.4 through 7.5 pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735
--- Comment #6 from Jeffrey Walton ---
Add 9.3 to the know to fail list:
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #13 from Jeffrey Walton ---
On Wed, Dec 16, 2020 at 9:05 PM eggert at cs dot ucla.edu
wrote:
> ...
> (B) there's no way to shut off the false alarm, not even with '# pragma GCC
> diagnostic ignored "-Wreturn-local-addr"'.
https://gc
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 49827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49827&action=edit
preprocessed ppc_pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416
--- Comment #1 from Jeffrey Walton ---
Created attachment 49831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49831&action=edit
Disassembly of ppc_power9.o
Created with 'objdump --disassemble ppc_power9.o | c++filt >
ppc_power9.disass'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98416
--- Comment #3 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #2)
> This is invalid.
> The instruction which is failing is:
> 9c: f0 00 02 d0 xxspltib vs0,0
>
> Which is only valid in power9 and above.
> You need to mark CP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
--- Comment #40 from Jeffrey Walton ---
Still a problem in 2021.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Hi Everyone,
This is going to be a shitty bug report because we don't have a reproducer. We
believe we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #5 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #3)
> Though there might be an EH issue but there has not been an EH issue for a
> long time .
This is an interesting observation.
The stack trace shows frame #0 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #7 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #6)
> >And the program does not take the exception path. Instead it segfaults.
>
> If I read the backtrace correctly, it is trying to resume an unwind because
> it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #9 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jeffrey Walton from comment #7)
>
> Try putting a breakpoint on the following functions:
> _Unwind_RaiseException
> _Unwind_ForcedUnwind
> _Unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106568
--- Comment #10 from Jeffrey Walton ---
I'm not sure if this is helpful, but Valgrind is showing invalid reads in the
unwind gear:
$ valgrind ./cryptest.exe vv 51
==27339== Memcheck, a memory error detector
==27339== Copyright (C) 2002-2022, an
101 - 200 of 214 matches
Mail list logo
