On 5/22/19 11:17 AM, Richard Biener wrote:
>> Almost ... except that I'd need a platform-agnostic definition. The
>> point is that the code does not care about the underlying hardware at
>> all, only for the vector length supported by it.
>
> And then you run into AVX + SSE vs. AVX2 + SSE case
Hi Matthias!
> I agree, we need more information from the compiler. Esp. whether the user
> specified `-mprefer-avx128` or `-mprefer-vector-width=none/128/256/512`.
> OTOH `-msve-vector-bits=N` is reported as __ARM_FEATURE_SVE_BITS. So that's
> covered.
Almost ... except that I'd need a platfor
[Disclaimer: I sent this to gcc-help two weeks ago, but didn't get an
answer. Maybe the topic is more suited for the main gcc list ... I
really think the feature in question would be extremely useful to have,
and easy to add!]
Hi,
I'm currently writing an FFT library which tries to make use of SI
Compiling and running the following code on a CPU with BMI2 support
prints "BMI2 detected" as one would expect:
#include
int main(void)
{
if (__builtin_cpu_supports("bmi2"))
printf("BMI2 detected\n");
return 0;
}
However, "bmi2" is not documented in the list of arguments at
https://
rs more
often in the future!
Sorry for the noise,
Martin
On 11/17/16 10:53, Markus Trippelsdorf wrote:
> On 2016.11.17 at 10:49 +0100, Martin Reinecke wrote:
>> Hi,
>>
>> At some point in May 2016 there was a patch to the gcc trunk which
>> caused one of my numerical codes
t that the tree-loop-distribution
changes caused the different behavior.
Could someone please give me a hint which sort of loops are most likely
to be compiled differently after the changes, so that I have a better
idea where to look for the problem?
Thanks in advance,
Martin Reinecke
Hi all,
the web page at http://gcc.gnu.org still links to the gcc 7 status
report from March 10, but there is a more recent one from April 15.
Could this please be updated?
Cheers,
Martin Reinecke
Hi Tobias!
>> The attached testcase requires gcc and gfortran, as well as a JDK
>> installation. When running "make" with gcc/gfortran 4.7.2 and
>> Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the
>> behaviour of subsequent READ statements in the Fortran code,
>> depending on the va
On 07/04/13 14:09, Florian Weimer wrote:
> What happens is that the JVM initialization in JNI_CreateJavaVM() calls
> setlocate. This seems to change the behavior of READ. I don't know enough
> about gfortran to judge whether READ should follow the libc locale or not.
All I can say is that I d
On 07/04/13 13:43, Florian Weimer wrote:
> On 07/04/2013 11:22 AM, Martin Reinecke wrote:
>> The attached testcase requires gcc and gfortran, as well as a JDK
>> installation. When running "make" with gcc/gfortran 4.7.2 and
>> Oracle JDK 1.7, a single call to
Hi,
I'm not sure if this is a bug in gcc, or in Java,
or maybe even a feature, so I'm asking for opinion here before
opening a PR...
The attached testcase requires gcc and gfortran, as well as a JDK
installation. When running "make" with gcc/gfortran 4.7.2 and
Oracle JDK 1.7, a single call to JNI
On 01/04/11 15:10, H.J. Lu wrote:
We need a testcase to investigate.
This is now PR47167.
Cheers,
Martin
On 01/04/11 14:48, H.J. Lu wrote:
On Tue, Jan 4, 2011 at 4:43 AM, Martin Reinecke
wrote:
Hi,
while benchmarking a numerical C library making heavy use of SSE2
intrinsics, I have noticed a significant (around 10 percent) slowdown
in the code generated by the current gcc trunk, compared to
Hi,
while benchmarking a numerical C library making heavy use of SSE2
intrinsics, I have noticed a significant (around 10 percent) slowdown
in the code generated by the current gcc trunk, compared to the one
produced by the 4.5.1 release.
It's quite hard to reduce the code to a small test case, b
Hi,
it seems that bootstrap is broken in x86-64 since at least yesterday,
but apparently only if checking is disabled.
Compilation stops with this error message:
gcc -c -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes Wmissing-format-attribute -ped
Hi!
You didn't what target you are using. Pentium D can run both 32bit
and 64bit. codes.
This was done with 32bit code. I have opened PR 42376 describing
the issue and added some more information.
Cheers,
Martin
Hi,
I have noticed a big performance decrease in one of my numerical codes
when switching from gcc 4.4 to gcc 4.5. A small test case is attached.
When compiling this test case with "gcc -O3 perf.c -lm -std=c99"
and executing the resulting binary, the CPU time with the head of
the 4.4 branch is ab
Daniel Jacobowitz wrote:
On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote:
On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote:
/usr/bin/ld: crtbegin.o: No such file: No such file or directory
collect2: ld returned 1 exit status
This probably happens because the
Hi,
current mainline gcc seems to call the linker incorrectly, so that it cannot
find the crt*.o files:
~/tmp>cat bla.c
int main(void) {}
~/tmp>gcc -v bla.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --enab
Hi,
I'm observing the following bootstrap problem with mainline in
i686-pc-linux-gnu:
the initial ./configure dies with:
[...]
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for correct version of gmp.h... yes
checking for MPFR... yes
configure: erro
Hi,
I checked gcc's C99 status page today and noticed that C99 conformance
seems to evolve rather slowly. Most importantly for me, support for
complex data types is marked as broken for several years now.
Is there any hope that this might change in the foreseeable future?
Thanks,
Martin
--
Hi,
I'm trying to learn about GCC's support for vector arithmetic and found
the section "Using vector instructions through built-in functions", which
answers a lot of questions, but unfortunately does not address things
like gathering scalar values into a vector type or reading scalars
out of suc
Hi,
maybe this is some fallout from the toplevel-bootstrap patch...
I configured current mainline with
$SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release
and the bootstrap stopped at
make[2]: Entering dire
Hi,
current mainline configured with the following command
$SRCDIR/configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/afs/mpa/data/martin/mygmp
aborts during bootstrap at this place:
/scratch/ogcc/./gcc/xgcc -B/scratch/ogcc/./gcc/
-B/afs/mpa/data/martin/ugcc/i686-p
Hi!
I found a microcontroller-ported gcc. It used for Microchip's dsPIC products.
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010065&part=SW006012
or
http://www.microchip.com --> Development Tools --> MPLABÂ C30 Compiler
It's is a "60 day demo/upgrad
Hi,
current mainline boostrap breaks (at least for me) on i686-pc-linux-gnu.
configure flags : --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/afs/mpa/data/martin/mygmp
/scratch/gcc>make bootstrap
[...]
stage1/xgcc -Bstage1/ -B/afs/mpa/data/martin/ugcc/i686-pc-linux-gnu/
Hi,
someone at the computing center just told me that the version of "install"
that caused the problem was terribly obsolete and only got installed by
accident. It has been removed now.
If you want to add an autoconf check for this version, I can try to get
a copy of the binary. But I'm not sure
On Thu, Nov 03, 2005 at 10:25:28AM -0800, James E Wilson wrote:
> On Wed, 2005-11-02 at 02:35, Martin Reinecke wrote:
> > Unfortunately I have no way of finding out more about the local "install",
> > as it doesn't accept the --help flag:
>
> Did you check
Hi Jim,
the problem lies in the command
-$(INSTALL_PROGRAM) xgcc$(exeext)
$(DESTDIR)$(bindir)/$(GCC_INSTALL_NAME)$(exeext)
which on my machine evaluates to
/afs/rzg/@sys/bin/install -c xgcc /afs/mpa/data/martin/ugcc/bin/gcc
Apparently this special version of "install" in my path crea
Jim Wilson wrote:
Martin Reinecke wrote:
i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc".
The gcc makefile install rule just does
rm -f $destdir/bin/gcc
install xgcc $destdir/bin/gcc
If destdir/bin/gcc is non-existant, or a plain file
Hi,
I'm observing a strange installation problem with the current mainline.
After configuration with
configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran
--with-gmp=/afs/mpa/data/martin/mygmp --disable-checking
bootstrapping and installing, I end up with the following bin/ directo
Hi,
during the last weeks there has been a great deal of activity on the
gomp-branch, which
I find very exciting, since I work on some OpenMP-enabled codes and would like
to become more
independent of the Intel compilers.
Unfortunately these codes are all written in C++ :(
So here is my questio
On Sat, Aug 13, 2005 at 09:40:11AM -0400, Daniel Berlin wrote:
>
> >
> > Should I open a PR?
> Yes
OK, this is now bug #23378. Please let me know if you need
more information.
Cheers,
Martin
Hi,
a few days ago I noticed that the current mainline produces much worse
code for one of my time-critical codes than it did a few weeks ago.
After some testing I found out that the regression was introduced
into CVS between the timestamps "-D 20050729 22:00:00 UT" and
"-D 20050729 23:00:00 UT",
34 matches
Mail list logo
