: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 48496
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48496&action=edit
Preprocessed sour
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 48498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48498&action=edit
Preprocessed source file ecp
ty: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Created attachment 48500
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48500&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95031
--- Comment #3 from Jeffrey Walton ---
(In reply to David Malcolm from comment #2)
> Please note that C++ isn't supported in the -fanalyzer implementation in GCC
> 10. I hope to get it working for GCC 11 (but there's a lot of work to do).
Oh, s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
--- Comment #7 from Jeffrey Walton 2012-08-21
22:08:38 UTC ---
(In reply to comment #1)
> Also using -fPIC instead of -fPIE is always ok. So I doubt there is a really
> issue here. Since the differences between PIC and PIE comes down to if
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
Bug #: 50610
Summary: G++ 4.4.3: Incorrect code at -O2 (-fwrapv, SafeInt,
c++ templates, template class files)
Classification: Unclassified
Product: gcc
Version: 4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
--- Comment #1 from Jeffrey Walton 2011-10-04
04:07:17 UTC ---
My bad:
jeffrey@studio:~/Desktop/safeint-opt-test$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50610
--- Comment #2 from Jeffrey Walton 2011-10-04
05:24:20 UTC ---
For this problem, the work around was:
try
{
const T* base = ptr;
base += SafeInt(cnt);
}
catch(const SafeIntException&)
{
throw InvalidArgumentExceptio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747
Bug #: 52747
Summary: No warning from toolchain with nested function and
--noexecstack
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747
--- Comment #3 from Jeffrey Walton 2012-03-28
14:33:38 UTC ---
Ah, OK. -Wtrampolines works. But I'm not seeing a warning about the loss of
no-exec stacks:
int main(int argc, char* argv[])
{
(void)argc;
(void)argv;
void foo()
{
print
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52747
--- Comment #5 from Jeffrey Walton 2012-03-28
14:52:29 UTC ---
My apologies for the additional comments.
$ checksec.sh --file ./warn-test.exe
RELRO STACK CANARY NXPIE RPATH
RUNPATH FILE
Full RELR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52753
Bug #: 52753
Summary: GCC not honoring -fPIE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52753
--- Comment #2 from Jeffrey Walton 2012-03-28
16:18:58 UTC ---
Thanks Andreas. Forgive my ignorance, but what does -fPIE do exactly (if not
enable Position Independent Executables)?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
Bug #: 52885
Summary: Request: Add -aslr switch that invokes -fPIE/-pie or
-fPIC/-shared as appropriate
Classification: Unclassified
Product: gcc
Version: 4.6.1
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
--- Comment #3 from Jeffrey Walton 2012-04-24
04:32:35 UTC ---
(In reply to comment #2)
> GCC is not a mind reader.
I kind of knew that.
> There is no way for GCC to know if you want to do
> PIC or PIE code.
Forgive my ignorance, but why does it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
--- Comment #4 from Jeffrey Walton 2012-04-24
04:34:42 UTC ---
(In reply to comment #1)
>
> Also how can you tell the difference between compiling for executable and
> shared library if you don't supply -fPIC? So adding -aslr is not going to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52885
--- Comment #6 from Jeffrey Walton 2012-04-24
04:38:54 UTC ---
(In reply to comment #5)
> >At code generation, I did not think there was even the concept of program or
> >shared object.
>
> And this is where you are wrong. GCC has a concept o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
--- Comment #12 from Jeffrey Walton ---
(In reply to Arseny Solokha from comment #11)
> I believe this is irrelevant by now.
Yeah, no doubt. May as well close it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49670
Jeffrey Walton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782
--- Comment #1 from Jeffrey Walton ---
Also documented in the Intel Intrinsics Guide at
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_loadu_si64.
According to the guide, the intrinsic is the movq instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
--- Comment #3 from Jeffrey Walton ---
(In reply to postmaster from comment #2)
> Portability is one main reason to add missing intrinsics... with combination
> of cpuid check and _xgetbv() we can cleanly check if AVX or MPX is available
> at run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70413
--- Comment #4 from Jeffrey Walton ---
Bumping this.
We ran into a similar issue in GCC 6.3.0 on ARM with -flto. openSUSE enabled
LTO by default, so we added a test case for all platforms which support LTO
(including Debian with its stale packag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #3 from Jeffrey Walton ---
Lloyd's finding can be confirmed on GCC135. For example,
gcc135:~$ /opt/at12.0/bin/gcc -O3 -mcpu=power9 -m64 darn.c -o darn
gcc135:~$ ./darn
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
9FBE0B8B6E8
: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
From Initial SUPERCOP Haswell results for round 2
(https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/kiMo-1jBwDI/KS8VtDwWAgAJ):
$ cat x.c
#include
extern int thenumber(void);
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744
--- Comment #1 from Jeffrey Walton ---
My bad, this should have been included:
$ lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04
$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyrigh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744
--- Comment #3 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #2)
> You want -no-pie; not -fno-pie.
> -no-pie turns off the linking and -fno-pie just turns off the compiler
> option.
Thanks Andrew.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
--- Comment #7 from Jeffrey Walton ---
(In reply to Eric Gallager from comment #6)
> (In reply to Eric Gallager from comment #5)
> > (In reply to Jeffrey Walton from comment #4)
> > > This is kind of weird... When we tested with C++03 by adding -
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
I&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961
--- Comment #1 from Jeffrey Walton ---
It looks like it was reported to the Ubuntu folks at
https://bugs.launchpad.net/ubuntu/+bug/1709727, but I could not find a GCC
report.
There is also a gcc-6 patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961
--- Comment #3 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #2)
> AFAIK AArch64 has multiple configurable sizes of the virtual address space
> and older GCCs like 6 was only supporting one of those sizes, not all of
> them.
> S
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is a tad bit unusual since we can use SSE2, SSE3, ..., AVX, AVX2 as
expected.
According to the GCC docs and -march=bdver1, the arch does enable XOP as
: web
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
This is general feedback on symbol visibility documentation. I feel like the
docs are lacking some important information and it makes a resulting shared
object appear to not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87190
--- Comment #1 from Jeffrey Walton ---
In case it is needed, here's the citation for "Remember the docs say all
symbols are private (not some symbols)":
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html:
Set the default ELF image symbol
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #1 from Jeffrey Walton ---
__m128d is a tad bit cleaner. It does not require the casts.
$ cat test.c
#include
int main(int argc, char* argv[])
{
unsigned char t[16+1];
__m128d x = _mm_load_sd((const double *)(t+1));
_mm_store_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #8 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #0)
> According to Intel
> (https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no
> alignment requirements for _mm_load_sd, _mm_store_sd and _mm
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 from the compile farm. It is ppc64-le machine. It has
both GCC 4.8.5 and GCC 7.2.0 installed. The issue is present on both.
We are tryi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753
--- Comment #2 from Jeffrey Walton ---
(In reply to Bill Schmidt from comment #1)
> GCC 4.8.5 is out of service. This is fixed in all in-service versions of
> GCC (6.4 and later).
Interesting. I'm seeing it in GCC 7.2.0. Are you certain of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753
--- Comment #3 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Bill Schmidt from comment #1)
> > GCC 4.8.5 is out of service. This is fixed in all in-service versions of
> > GCC (6.4 and later).
>
> Interesti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84753
--- Comment #7 from Jeffrey Walton ---
(In reply to Bill Schmidt from comment #4)
> ...
>
> The best performance will be achieved by writing this loop entirely using
> inline asm code, with all data loaded/stored using lxvd2x and stxvd2x (no
> s
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 from the compile farm. I'm having trouble compiling a
program with the C++ compiler.
$ cat test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88078
--- Comment #3 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #2)
> For GCC 8.2 using -std=c++14 instead of -std=gnu++14 will disable the
> __float128 specializations, avoiding the problem of long double and
> __float128 being
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
--- Comment #8 from Jeffrey Walton ---
(In reply to Segher Boessenkool from comment #4)
> This is documented in the ELFv2 ABI, linked from
> https://gcc.gnu.org/readings.html .
>
> ...
> (The vec_vsx_st doesn't have to do with the problem btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
--- Comment #12 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #10)
> Author: jakub
> Date: Thu Nov 29 14:23:21 2018
> New Revision: 266619
>
> URL: https://gcc.gnu.org/viewcvs?rev=266619&root=gcc&view=rev
> Log:
> PR targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88234
--- Comment #13 from Jeffrey Walton ---
The issue is cleared in GCC 9 from DEC 08 2018. Our self tests pass where they
formerly failed. The failures are the reason I wanted a diagnostic run with
UBsan.
On GCC110 and GCC112 with gcc-9 located at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
--- Comment #16 from Jeffrey Walton 2013-02-02
17:01:55 UTC ---
(In reply to comment #15)
> I agree. The main point of all of this is optimization. And in terms of
> optimization, one would want to examine some flag immediately after an
>
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
Cygwin 2.4.1/GCC 5.3.0 can no longer compile a program with std=c++03.
$ uname -r
2.4.1(0.293/5/3)
$ gcc --version
gcc (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217
--- Comment #1 from Jeffrey Walton ---
Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217
--- Comment #2 from Jeffrey Walton ---
Cygwin bug https://sourceware.org/bugzilla/show_bug.cgi?id=19817.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70217
--- Comment #5 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #3)
> dup of PR 70176 ?
>
> My guess is Cygwin uses a new version of newlib which has stricter C headers
> that don't define the C99 functions for __cplusplus < 201
++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working with a HiKey dev board. It provides AArch64.
I'm trying to compile a simple program:
$ cat test.cxx
#if (defined(__ARM_NEON__) || defined(__ARM_NEON)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on GCC112 (gcc112.fsffrance.org on the compile farm).
$ cat test.cxx
#include
typedef unsigned char byte;
typedef v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82112
--- Comment #4 from Jeffrey Walton ---
Thank you very much Jakub.
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
We are catching a compile error under GCC 6.10 on AIX. The error is shown
below. The diagnostic messag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
--- Comment #2 from Jeffrey Walton ---
(In reply to Eric Gallager from comment #1)
> Do you have a complete standalone testcase we could use to reproduce?
Thanks Eric.
We were not able to reduce it to a minimal test case. That was part of the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82209
--- Comment #4 from Jeffrey Walton ---
This is kind of weird... When we tested with C++03 by adding -std=c++03, we got
4 more of them. The check-in of interest is
https://github.com/weidai11/cryptopp/commit/7097546cfcf742cf.
Is there really no w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #7 from Jeffrey Walton ---
Please forgive my ignorance... What was fixed?
The problem statement is/was "Please make all headers for intrinsics be
includable without special compiler flags." But it appears the intrinsics are
not avail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
--- Comment #9 from Jeffrey Walton ---
On Mon, Apr 17, 2017 at 11:04 AM, glisse at gcc dot gnu.org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57202
>
> --- Comment #8 from Marc Glisse ---
> (In reply to Jeffrey Walton from comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377
--- Comment #6 from Jeffrey Walton ---
(In reply to David Malcolm from comment #5)
> Likewise, I tried but failed to reproduce it.
>
> A hunch: given the "-march=native", is there a chance that this bug is
> dependent on the precise CPU flags on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
--- Comment #4 from Jeffrey Walton ---
(In reply to Martin Liška from comment #3)
> As I'm reading the source code, there's no option to do that.
> Apart from 'no_sanitize' attribute, GCC supports 'no_sanitize_undefined'
> attribute (clang does n
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on a PowerMac G5. It runs OS X 10.5.8. It has MacPorts installed
for updated gear.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #1 from Jeffrey Walton ---
Also see Issue 53226 in the MacPorts issue tracker. "gcc5 @5.4: error:
'std::log2' has not been declared", https://trac.macports.org/ticket/53226.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #4 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #3)
> Jeffrey, could you please add the output of '/opt/local/bin/g++-mp-5
> -dumpmachine' to the Target field of this bug report? Thanks.
$ /opt/local/bin/g++-mp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #5 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> ... ^
>
> Because these six functions are missing we treat all C99 math functions as
> mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #7 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #5)
> (In reply to Jonathan Wakely from comment #2)
> ...
> > But OS X 10.5.8 is pretty old, and this might not be worth doing if it
> > doesn't affect current versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #8 from Jeffrey Walton ---
> Wow, this is a surprising statistic (for me)... OS X 10.5 makes up 29.1% of
> the MacPorts downloads. Its the largest percentage for the OS group. Confer,
> http://stats.macports.neverpanic.de/os_statisti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #9 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jeffrey Walton from comment #0)
> > test.cxx:53:21: error: 'llrint' was not declared in this scope
> >llrint(0.0);
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #11 from Jeffrey Walton ---
> Does this C program compile and link on 10.4 and 10.5?
>
> long long llrint(double x);
> long long llrintf(float x);
> long long llrintl(long double x);
> long long llround(double x);
> long long llroun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #13 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #12)
> What's the error?
My bad...
$ cat test.cxx
// #include
long long llrint(double x);
long long llrintf(float x);
long long llrintl(long double x);
long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017
--- Comment #15 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #14)
> OK, thanks. I'm not going to try to add declarations like the libc++ patch
> does, as it looks like that would only be correct for Snow Leopard and not
> ear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71809
--- Comment #6 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #5)
> (In reply to sulit from comment #4)
> > ok
>
> Sulit, I'm seeing the issue under Clang 3.5 on Ubuntu 16. Do you have a LLVM
> bug report for this issue?
Here'
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm working on a VIA C7-D processor. GCC version is 5.4.0 from Ubuntu. I'm
attempting to use GCC's -mtune=c
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
>From the low hanging fruit department... I stumbled upon this on Fedora 25
x86_64 with GCC 6.3.1. I'm actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80377
--- Comment #2 from Jeffrey Walton ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this.
>
> Similar to PR c++/72786, and probably worked-around on trunk by r242965;
> presumably has a specific root-cause though.
Yes, thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67036
--- Comment #4 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #3)
> VC++ prints:
>
> main.cpp(7): warning C4297: 'useless::~useless': function assumed not to
> throw an exception but does
> main.cpp(7): note: destructor or dea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #5 from Jeffrey Walton ---
(In reply to Dominique d'Humieres from comment #4)
> I see the problem after having updated to Xcode 8.0. I am currently testing
> the following patch
>
Just an FYI... Clang 3.7 and below do not witness th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #8 from Jeffrey Walton ---
(In reply to Iain Sandoe from comment #7)
> (In reply to Dominique d'Humieres from comment #4)
> > I see the problem after having updated to Xcode 8.0. I am currently testing
> > the following patch
>
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71767
--- Comment #10 from Jeffrey Walton ---
> than adjusting section definitions - we need to change which ones are
>> > selected in config/darwin.c
>> >
>> I _think_ you can detect which linker at runtime with something like the
>> following:
>>
>>
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
I'm testing on Cygwin64. Cygwin64 provides the 5.2.0 compiler.
Attempting to compile the following results in an error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #2 from Jeffrey Walton ---
(In reply to Andrew Pinski from comment #1)
> Why are you using the builtin directly? You should be using the intrinsics
> form instead.
Its a cross product of (1) that's what the docs tell me to use for R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #3 from Jeffrey Walton ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Why are you using the builtin directly? You should be using the intrinsics
> > form instead.
>
> Its a cross p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #5 from Jeffrey Walton ---
(In reply to Marc Glisse from comment #4)
> For intrinsics, gcc mostly considers Intel as the standard, so the
> documentation would be https://software.intel.com/en-us/node/523865 .
Thanks Andrew.
Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081
--- Comment #7 from Jeffrey Walton ---
(In reply to Marc Glisse from comment #6)
> This comment makes no sense (sorry, couldn't find a nice way to say it).
>
> > Intel builds software
>
> We are talking about gcc, not Intel software. Documentat
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
According the Intel docs, RDSEED intrinsics are available in .
Confer,
http://software.intel.com/sites/landingpage/IntrinsicsGuide/#text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68316
--- Comment #3 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #1)
> As the comment says, you need to include not
OK, thanks. Here we were told to follow Intels docs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081. We had
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
My apologies for *not* having a minimum working example. Sometimes its hard to
craft them, and this is one of those times.
The C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #1 from Jeffrey Walton ---
This also appears to be an issue with GCC 4.8 and 5.1. See
https://groups.google.com/d/msg/cryptopp-users/BlPiQ2eAWhg/IsX18wAT9ZAJ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #2 from Jeffrey Walton ---
> My apologies for *not* having a minimum working example.
If you want to duplicate it, then:
git clone https://github.com/weidai11/cryptopp.git
Open GNUmakefile, and change to (around line 3):
O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #9 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #8)
> The code in algparam.h is just disgusting. AssignFromHelperClass binds a
> reference to NULL just to default-construct a temporary of some type, then
> binds a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #10 from Jeffrey Walton ---
(In reply to Richard Biener from comment #6)
> So I suppose the IsAligned template is wrong.
So I'm clear (please forgive my ignorance)...
According to http://www.felixcloutier.com/x86/MOVDQA.html, vmovdq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #11 from Jeffrey Walton ---
(In reply to Jonathan Wakely from comment #8)
> The code in algparam.h is just disgusting. AssignFromHelperClass binds a
> reference to NULL just to default-construct a temporary of some type, then
> binds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
Jeffrey Walton changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
--- Comment #16 from Jeffrey Walton ---
(In reply to Jakub Jelinek from comment #15)
> I'm saying that if the program does not trigger undefined behavior (e.g. by
> accessing misaligned integers without telling the compiler about it (by
> using m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #13 from Jeffrey Walton ---
A quick update
We did out best to take the advice of Jakub, Janathan, Markus and others:
https://github.com/weidai11/cryptopp/commit/9bf0eed0f6ff6d0b0a2d277e5401d69dc8c0e394.
We are paying for past tr
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
The following source code results in a slew of Unknown Pragma messages. The
problem is, GCC supports OpenMP. GCC responds properly to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943
--- Comment #1 from Jeffrey Walton ---
I've experienced this issue on Cygwin i386 and x86_64 running GCC 4.8.1; Fedora
21 and 22, i386 and x86_64 running GCC 4.9 and 5.1, and a few others.
So it appears to be a widespread issue, and not an isola
1 - 100 of 214 matches
Mail list logo
